[hsieh]

Hi,

When I issued checkMesh to check my mesh, I got:

***Faces not in upper triangular order
<<Writing 1 unordered faces to set upperTriangularFace
Topological cell zipup check ok
..
Failed 1 mesh check.
--------------------------
Can anyone explain what this means? Thanks!

Pei

[lr103476]

The order of the faces is only important for convergence rate of the linear solver. Use renumberMesh to reorder the faces and this message will be gone....

Frank

[hsieh]

Hi, Frank,

Thanks for the quick respond!

According to the warning message, there is only 1 face that is unordered. When I issued "renumberMesh . case", and then checkMesh, I still got the same warning. Did I use the renumberMesh util correctly?

Pei

[lr103476]

Mmm, that's the way to use it, works fine here....

[fra76]

I had the same problem.
As far as I know, that warning is just a small bug in the current checkMesh (1.4.1).
Using renumberMesh, however, can imporve your simulation time a lot!

Francesco

[hjasak]

There's no bug: mesh face ordering is strictly enforced and necessary for good performance of Incomplete Cholesky preconditioning. Just run renumberMesh and it will get fixed.

Hrv

[fra76]

Hi Hrvoje,
that's what I mean. Even after renumberMesh, the error from checkMesh doesn't disappear. The same happened to Pei.

Francesco

[hjasak]

OK, look at it here: sit in a cell, visit all neighbours, ask for a cell neighbour label and pick out the smallest one. No error here:

// Add the faces in the increasing order of neighbours
for (label neiSearch = 0; neiSearch < nNeighbours; neiSearch++)
{
// Find the lowest neighbour which is still valid
label nextNei = -1;
label minNei = oldCells.size();

forAll (neiCells, ncI)
{
if (neiCells[ncI] > -1 && neiCells[ncI] < minNei)
{
nextNei = ncI;
minNei = neiCells[ncI];
}
}

if (nextNei > -1)
{
// Face is internal and gets reordered
reverseFaceOrder[curFaces[nextNei]] = nMarkedFaces;

// Stop the neighbour from being used again
neiCells[nextNei] = -1;

nMarkedFaces++;
}
else
{
FatalErrorIn
(
"fvMesh* fvMeshBandCompression::renumberedMesh() const"
) << "Error in internal face insertion"
<< abort(FatalError);
}
}


I bet you've got 2 cells sharing more than one face - that is not allowed.

Hrv

[schmidt_d]

Gents,

There are a few ways I could imagine two cells end up sharing a face. Some of them involve seriously non-convex cells. However, if you just have some degenerate edges, then collapseEdges might be worth a try. You have nothing to lose.

David

[ufocfd]

got an error with upper triangular face ordering
but Im pretty sure that I have now got the cell faces ordered
in such a way that the neighbour cells are increasing sequence.
Given that the errors are on the octree transition surface,
is it a concave face issue?

https://twitter.com/garcfd/status/15...8ZWYGSnklx12iQ