[petr.f.]

Hi all,

when meshing with snappy (a bit comlicated area - underhood ), the checkMesh reports the following errors:

--
<<Number of duplicate (not baffle) faces found: 22. This might indicate a problem.
<<Number of faces with non-consecutive shared points: 26. This might indicate a problem.
<<Writing 76 faces with non-standard edge connectivity to set edgeFaces
<<Writing 1 cells with two non-boundary faces to set twoInternalFacesCells
Number of regions: 1 (OK).

Checking patch topology for multiply connected surfaces...
Patch Faces Points Surface topology
ffminx 0 0 ok (empty)
ffmaxx 0 0 ok (empty)
ffminy 0 0 ok (empty)
ffmaxy 0 0 ok (empty)
ffminz 0 0 ok (empty)
ffmaxz 0 0 ok (empty)
atmosphere 47880 53403 ok (non-closed singly connected)
inlet 18310 26322 ok (non-closed singly connected)
outletHVAC 1955 2892 ok (non-closed singly connected)
outletValve01 212 240 ok (non-closed singly connected)
outletValve02 222 265 ok (non-closed singly connected)
outletValve03 213 256 ok (non-closed singly connected)
outletValve04 220 260 ok (non-closed singly connected)
outletValve05 220 250 ok (non-closed singly connected)
outletValve06 221 241 ok (non-closed singly connected)
topWall 69468 83231 ok (non-closed singly connected)
wallLargeCells 156898 188065 ok (non-closed singly connected)
wallSmallCells 484344 563698 multiply connected (shared edge)
<<Writing 2 conflicting points to set nonManifoldPoints
--

I can't get rid of it no matter what snapping features, number of prism layers of quality settings I use. Does that mean the problem is in the underlying stl geometry?

P.

[louisgag]

In case someone is reading on this old post..

Originally Posted by petr.f.

<<Number of faces with non-consecutive shared points: 26. This might indicate a problem.

I had a similar problem using snappyHexMesh and I was able to mitigate it by using the faceType baffle; condition and then using mergeOrSplitBaffles to properly separate the baffles, which snappy was apparently not able to do properly due to the highly complex geometry I'm using.

-Louis

[damon707]

Hello Louis,

Sorry for bringing this old post back again.

Could you please explain more thorougly how did you manage to solve the edgeFaces problem?

Kind regards,
George

[louisgag]

this is quite old so I'm not sure what it was but maybe it was this:


in snappy*Dict:

geometry
{
...
    cropRotor.stl
    {
    type triSurfaceMesh;
    name cropRotor;
    regions
    {
    ascii
    {
    name cropRotor;
    }
    }
    }
...
 dupliCropRotor.stl
    {
    type triSurfaceMesh;
    name dupliCropRotor;
    regions
    {
    ascii
    {
    name dupliCropRotor;
    }
    }
    }
};



...


    refinementSurfaces
    {

        cropRotor
        {
        level       (8 8); // 3 5
        faceType baffle;
    cellZone cropRotor;
    faceZone cropRotor;
    cellZoneInside inside;
//    gapLevelIncrement 3; //- Optional increment (additioinal to max level) in small gaps
        }




...


    refinementRegions
    {
        "cropRoto.*"
        {
            mode        inside;
            levels      ((1E15 6));
        }
        "dupliCropRoto.*"
        {
            mode    distance;
                levels  ((0.25 5));
        }
...
}

...


allowFreeStandingZoneFaces false;

(I don't remember if I only had twice the same geometry (rotor and dupliRotor) only to have more control over the refinement or if that was linked to the edgeFaces problem (I also don't remember anything about these edgeFaces issues...)



and then after

runParallel snappyHexMesh $nProcs -overwrite

then I would create AMI patches with

pointSync false;

runParallel createPatch $nProcs -overwrite

and then

runParallel mergeOrSplitBaffles $nProcs -split -overwrite;

Good luck