[Lydia]

Hello FOAMers,

currently we are trying to mesh a rather big, complex geometry with the snappyHexMesh tool.
Unfortunately, we are always getting lots of "under.determined cells" which occur after the first meshing step (= in the castellated mesh).

Does anyone have an idea what the criteria for these "under-determined cells" is? And how can they be avoided

After extracting them I loaded the VTK-file in paraview - the cells look rectangular, no irregularity visible - see attached image. Since I'm having about 700 cells, i don't dare to just delete them from my mesh.

Did anyone experience similar problems or maybe have an advise for solving this problem? I think remeshing doesn't really help....

Thanks in advance!
Regards,
Lydia

[mturcios777]

You may want to check if this is even a problem. Run checkMesh on your case and if it tells you its okay, then don't worry about them.

I'm thinking under-determined cells is a designation for snappyHexMesh in assessing mesh quality. As long as your final mesh passes muster I would go ahead with it.

[beck]

After getting around 6k under-determined cells in my grid I had a closer look at them in paraview and found out that every under-determined cell has two opposite faces that have no connection to another cell.

So this could be the criterion of checkMesh to locate under-determined Cells.

In the attached pictures u can see the filtered under-determined cells marked in red.

[mturcios777]

Looks like these occur in regions where the STL domain is "thin" relative to the background hex mesh. What does the final snapped mesh look like, and what is the output from checkMesh when you run it on the final mesh?

[marango]

When you have a look at the source code of the check mesh utility, you will see that there are two kinds of underdetermined cells.

The first kind of cells do have two or less free internal faces that do not belong to boundary patches. This can lead to numerical errors, for example when a tet element has 3 boundary faces.

About the second kind of cells I cannot tell you much. I still don't know what's going on there. But it has something to do with the ration of one face area and the complete element area.

Does anyone else have further information about that?

[Astrodan]

Originally Posted by marango

The first kind of cells do have two or less free internal faces that do not belong to boundary patches. This can lead to numerical errors, for example when a tet element has 3 boundary faces.

Could you point out where in the code this can be found? I checked github and doxygen and couldn't find that part. The only code I found on under-determined cells is in polyMeshGeometry (or same for primitiveMeshGeometry):

bool Foam::polyMeshGeometry::checkCellDeterminant
(
    const bool report,
    const scalar warnDet,
    const polyMesh& mesh,
    const vectorField& faceAreas,
    const labelList& checkFaces,
    const labelList& affectedCells,
    labelHashSet* setPtr
)
{
    const cellList& cells = mesh.cells();

    scalar minDet = GREAT;
    scalar sumDet = 0.0;
    label nSumDet = 0;
    label nWarnDet = 0;

    forAll(affectedCells, i)
    {
        const cell& cFaces = cells[affectedCells[i]];

        tensor areaSum(tensor::zero);
        scalar magAreaSum = 0;

        forAll(cFaces, cFaceI)
        {
            label faceI = cFaces[cFaceI];

            scalar magArea = mag(faceAreas[faceI]);

            magAreaSum += magArea;
            areaSum += faceAreas[faceI]*(faceAreas[faceI]/(magArea+VSMALL));
        }

        scalar scaledDet = det(areaSum/(magAreaSum+VSMALL))/0.037037037037037;

        minDet = min(minDet, scaledDet);
        sumDet += scaledDet;
        nSumDet++;

        if (scaledDet < warnDet)
        {
            if (setPtr)
            {
                // Insert all faces of the cell.
                forAll(cFaces, cFaceI)
                {
                    label faceI = cFaces[cFaceI];
                    setPtr->insert(faceI);
                }
            }
            nWarnDet++;
        }
    }

    // Reporting stuff
    // ...
}

But here I don't really understand what is happening (failing at the tensor areaSum). Anyway, your explanation sounds reasonable, as my underdeterminedCells are all tets at two boundaries at once.

At sort of off topic: I have been googling and cfd-onlining all kind of checkMesh errors lately, and it's quite often hard work of gathering hints and explanations here and there.. would anyone appreciate (and help) collecting that information in a checkMesh-errors wiki-page?

-Timm

[derekm]

it related to the determinant of the cell see this reference

ALGEBRAIC MESH QUALITY METRICS PATRICK M. KNUPP

http://www.google.co.uk/url?sa=t&rct...Y0ZL3Cq9Cl2W1w

[danielpiaget]

Hello Timm,

Regarding this piece code:

-the forAll loops are standard C++ for loops that are defined as macros in openFOAM to permit looping over containers such as map,list,etc.. This way one does not need to define an iterator every time.The iretator in this case is the cFaceI.

-the function appers to do two things, return a true or false value (boolean) and write information to hash table structure via the setPtr pointer of all the faces that have cells that have negative determinants.

-It will keep track of the following qunatities:
-How many determinant calculations have been executed (nSumDet)
-How many determinant of negative value (nWarDet)
-The minimum determinant that was calculated for all the cells(minDet)
-the total sum of all the determinants for all the cells that were treated.

Hope that helps,

Daniel

[amuzeshi]

Originally Posted by derekm

it related to the determinant of the cell see this reference

ALGEBRAIC MESH QUALITY METRICS PATRICK M. KNUPP

http://www.google.co.uk/url?sa=t&rct...Y0ZL3Cq9Cl2W1w

Dear Derekm,
I read thid paper but did not find any relation between its metrics and cell determinants in OpenFOAM.
Did you find any connection?
Thank you.
Ali