[atul1018]

Hello All

I have created a mesh using .stl files. First, background mesh is created with blockMesh utility and then snappyHexMesh is performed to cut it as per the .stl files (desired geometry). After this operation, the created mesh has default wall type boundary for all faces. I want to assign cyclic bounadries to front and back and inelt and outlet as well. To do this I use createPatch utility. While doing so, i get the cyclic patches assigned to front and back faces without any problem. strangly, it gives error for inlet outlet. The number of faces in inlet and outlet are exactly the same. after getting the desired mesh (after blockMesh and snappyHexMesh), i also had checked the mesh quality using checkMesh utility, everything seems to be okay.

When createPatch is run, i get the long error as below (last part shown below):

--> FOAM FATAL ERROR: 
face 0 area does not match neighbour by 96.6108% -- possible face ordering problem.
patch:inlet_ my area:8.122e-05 neighbour area:2.83107e-05 matching tolerance:0.0001
Mesh face:31261 fc:(-0.0498982 0.104129 0.00738434)
Neighbour fc:(0.199914 0.101089 0.0108835)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

    From function void Foam::cyclicPolyPatch::calcTransforms(const primitivePatch&, const pointField&, const vectorField&, const pointField&, const vectorField&)
    in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 212.

FOAM exiting

I looked through several posts but couldn't find any solution. It is quite strange that createPatch produces error in spite of having same number of faces in inlet and outlet.

PS:I have shown inlet and outlet part of constant/polyMesh/boundary and createPatchDict files below:

boundary:

    inlet
    {
        type            wall;
        inGroups        1(wall);
        nFaces          369;
        startFace       31095;
    }
    outlet
    {
        type            wall;
        inGroups        1(wall);
        nFaces          369;
        startFace       31464;
    }

createPatch:

{
        
        name inlet_;
        patchInfo
        {
            //type patch;
            type cyclic;
            neighbourPatch outlet_;
         }
        constructFrom patches;
        patches (inlet);
}

{
        name outlet_;
        patchInfo
        {
            type cyclic;
            neighbourPatch inlet_;

        }
        constructFrom patches;
        patches (outlet);
}

Best Regards
Atul

[atul1018]

Update:

I played a bit with snappyHexMeshDict and found out that this matching error occurs when surfaceFeatureEctract utility is activated in snappyHexMeshDict and as the level of edge refinement goes up, this matching error increases. I found this behaviour by doing following:

trial 1- when I comment out the surfaceFeatureExtract section (feartures) in snappyHexMesh, I get the get mesh generated without any error and I can assign cyclic patches to desired boundary patches but as seen in the image attached (figure 1) edges are not captured properly.

trail 2- This time I activate the surfaceFeatireExtract utility so that all the edges are captured properly. I keep the resolution same as that of my background mesh for all the edges (level 0) and repeat the procedure. blockMesh>surfaceFeatureExract>snappyHexMesh>creat ePatch
This also creates mesh without any error (till snappyHexMesh) but when createPatch is called i get this matching error problem:

--> FOAM FATAL ERROR:
face 0 area does not match neighbour by 96.6108% -- possible face ordering problem.
patch:inlet_ my area:8.122e-05 neighbour area:2.83107e-05 matching tolerance:0.0001
Mesh face:31261 fc-0.0498982 0.104129 0.00738434)
Neighbour fc0.199914 0.101089 0.0108835)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

In the attched figure (2) you can see the results of snappyHexMesh. Edges seems to be captured well but corners cells seem to be not perfectly hexahedral (atleast to my eyes).

trial 3-furthermore, i increase the level refinement (level 1) in surfaceFeatureExtract section in snappyHexMeshDict and repeat the procedure again. what is intersting here that after snappyHexMesh execution I get some illegal cells which was not observed in previous two trials. end of log file says:

...
...
Writing mesh to time 3e-05
Wrote mesh in = 0.5 s.
Layers added in = 0.5 s.
Checking final mesh ...
Checking faces in error :
non-orthogonality > 65 degrees : 68
faces with face pyramid volume < 1e-13 : 0
faces with face-decomposition tet quality < 1e-15 : 4
faces with concavity > 80 degrees : 0
faces with skewness > 4 (internal) or 20 (boundary) : 0
faces with interpolation weights (0..1) < 0.05 : 0
faces with volume ratio of neighbour cells < 0.01 : 0
faces with face twist < 0.02 : 0
faces on cells with determinant < 0.001 : 0
Finished meshing with 72 illegal faces (concave, zero area or negative cell pyramid volume)
Finished meshing in = 6.85 s.

nevertheless, i continue to execute createPatch and this time I get again the the same error but higher matching error than trial 2:

--> FOAM FATAL ERROR:
face 0 area does not match neighbour by 144.152% -- possible face ordering problem.
patch:inlet_ my area:7.08421e-05 neighbour area:1.14961e-05 matching tolerance:0.0001
Mesh face:38751 fc-0.05 0.234665 0.058347)
Neighbour fc0.2 0.104113 0.00323326)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

The mesh after snappyHexMesh execution look more strange as more numbers of cells seem to not hexahedra as seen in figure (3).

Now the question remains unsolved, why this matching error between cyclic patches and matching error grows as refinement? Any experience and comment?

Best Regards
Atul

[atul1018]

Hello Community

I am still struggling to figure it out. Why I am getting matching error between cyclic patches when feature of extracting edges are used in snappyHexMesh. When edges are not extracted, I dont get any matching error.

Has someone faced similar problem before and help tyo to resolve the issue.

Best Regards
Atul

[Gavin Tall]

Did you solve this problem please? I seem to have the same problem now. My operation steps are the same as yours: blockMesh, snappyHexmesh, createPatch, there is a mismatch problem, or cannot find the target surface and source surface ?
I have spent a lot of time on this issue and sincerely seek your help

[WALEED123]

Also, I am facing a problem in matching the cyclic patch

please can you help me to solve it
I am requesting you to help me ,I HAVE ONLY THREE DAYS TO SUBMIT MY REPORT


--> FOAM FATAL ERROR: (openfoam-2012)
face 0 area does not match neighbour by 88.5827% -- possible face ordering problem.
patch:sd1 my area:5.86947e-07 neighbour area:1.52026e-06 matching tolerance:0.0001
Mesh face:3981 fc-0.0195852 -0.0226536 0.0045)
Neighbour fc-0.0125116 -0.0431727 0.0035)
If you are certain your matching is correct you can increase the 'matchTolerance' setting in the patch dictionary in the boundary file.
Rerun with cyclic debug flag set for more information.

From void Foam::cyclicPolyPatch::calcTransforms(const primitivePatch&, const pointField&, const vectorField&, const pointField&, const vectorField&)
in file meshes/polyMesh/polyPatches/constraint/cyclic/cyclicPolyPatch.C at line 215.

FOAM exiting

[atul1018]

Hi Waleed

I do not remember exactly how I solved the problem. I played with different keywords and values. For me (as far as I remember), what worked was to increase the match tolerance. From your post, I also see that OpenFOAM suggests you to increase the matchTolerance, if you are certain what are you doing is correct. Try it with 0.001 and once the mesh is done check your mesh with "checkMesh" utility, it will point out details about the mesh quality. Then you can take the decision if the mesh is good enough for simulations.

Best Regards
Atul

[OYYO]

Hello Atul

I also faced this problem about "does not match neighbour" when I generated mesh using ICEM CFD. Increasing the match tolerance is a solution, and after this we can decomposePar our mesh to calc, but initially we must ensure good mesh quality. For example, my checkMesh is OK when I make my the value of match tolerance from 0.0001 to 5.

Good Luck
OYYO