CFD Online Discussion Forums

CFD Online Discussion Forums (
-   OpenFOAM Meshing & Mesh Conversion (
-   -   failed meshCheck after fluent3DMeshtoFoam conversion (

Jonathan September 17, 2012 07:32

failed meshCheck after fluent3DMeshtoFoam conversion
Hi guys,

i have a series of meshes created in ICEM which i am using for some turbomachinery calculations. They pass all the necessary mesh checks in ICEM, and run fine in Fluent.

However, when trying to move the case across to openFoam, I am getting the following error message after running checkMesh.


Checking patch topology for multiply connected surfaces ...
    Patch              Faces    Points  Surface topology                 
    ENDWALL            9448    9739    ok (non-closed singly connected) 
    INLET              5112    5291    ok (non-closed singly connected) 
    PERIODIC            21868    22165    ok (non-closed singly connected) 
    periodic_sh        21868    22165    ok (non-closed singly connected) 
    CASING              10753    10288    ok (non-closed singly connected) 
    ROTOR              26176    25629    ok (non-closed singly connected) 
    S2_HUB              1421    1500    ok (non-closed singly connected) 
    S2_CASING          1421    1500    ok (non-closed singly connected) 
    S2_OUTLET          4118    4290    ok (non-closed singly connected) 
    S2_PERIODIC        6958    7150    ok (non-closed singly connected) 
    periodic_sh_1      6958    7150    ok (non-closed singly connected) 

Checking geometry...
    Overall domain bounding box (0.130442 -0.0549434 -0.037182) (0.203 0.0872359 0.13)
    Mesh (non-empty, non-wedge) directions (1 1 1)
    Mesh (non-empty) directions (1 1 1)
    Boundary openness (4.86395e-16 -1.29608e-15 -1.3501e-15) OK.
    Max cell openness = 7.93896e-15 OK.
    Max aspect ratio = 224.232 OK.
    Minumum face area = 5.1445e-11. Maximum face area = 4.86281e-06.  Face area magnitudes OK.
    Min volume = 2.31935e-15. Max volume = 3.03066e-09.  Total volume = 0.000532324.  Cell volumes OK.
    Mesh non-orthogonality Max: 74.6538 average: 22.1037
  *Number of severely non-orthogonal faces: 1329.
    Non-orthogonality check OK.
  <<Writing 1329 non-orthogonal faces to set nonOrthoFaces
    Face pyramids OK.
    Max skewness = 2.66588 OK.
  **Error in coupled point location: 26520 faces have their 0th vertex not opposite their coupled equivalent. Average mismatch 0.000975553.
  <<Writing 26520 faces with incorrectly matched 0th vertex to set coupledFaces

Failed 1 mesh checks.


I am converting the mesh using fluent3DMeshtoFoam, and have manually correctly the periodics after import in the boundary dictionary.

Any ideas as to what is going wrong? any help always much appreciated,

best regards

l_r_mcglashan September 17, 2012 14:47

It means that the order of the points in a coupled face is different on either side of the patch. For example the points on a face are arranged as follows:

side 1 face : 0 1 2 3
side 2 face : 3 0 1 2

Where the labels denote a unique point location. To fix it you just need to rotate the face on one side of the patch.

Jonathan September 18, 2012 05:18

HI laurence

thanks very much - i understand - much appreciated.

I guess my next question is how this happens - it is a direct import using fluent3DMeshToFoam from an ICEMCFD generated 'fluent' mesh. I wonder if somehow you cannot import ICEM .msh files directly into OF and somehow you have to run them through fluent?

Secondly, any hints on rotating the faces? i presume this has to be done via CL and OF utility?

again, thanks a lot

l_r_mcglashan September 18, 2012 09:25

Ordinarily I think they should be rotated, because polyTopoChange::reorderCoupledFaces is called by that utility. To help more I'd need to have the original mesh before conversion or a minimal example.

Jonathan September 18, 2012 09:28

hi thanks Laurence,

i have minimal c++ background at the moment, so any help you could offer would be much appreciated, although i am sure you (like everyone!) are quite busy ...

if you dont mind having a look that would be much appreciated, i can upload to the mesh to dropbox or upload here ... its not too big ~ 150MB from memory ...


l_r_mcglashan September 18, 2012 11:08

If you can put it up somewhere I'll try to take a look. Is there anything obvious wrong? Have you viewed the set coupledFaces in paraview?

Jonathan September 18, 2012 11:16

hi laurence,

thanks a lot - thats v kind!

in trying a few things this afternoon, i have realised that i only get the error once i manually edit the boundary file to reflect the presence of the periodics (i am modelling a turbine stage).

if i import using fluentMeshToFoam, i get an error relating to OF not recognising what 'periodic' patches are ... obviously this is just because of the nomenclature used in the different solvers, although i would have thought, as a 'fluent' mesh translater - this terminology would somehow have been included!

anyway, so i am importing using fluent3DMeshToFluent, which doesnt give the error, and then i am manually changing the periodics in the boundary file from 'patch' to 'cyclic' + all the necessary key words (neighbourPatch, tolerance etc).

its only once i upgrade the boundary file, that i get the error i posted.

re: paraView - no! i thought this was purely post-processing! But the mesh is read in and rendered correctly if i start paraFoam from the case directory ... even after i have edited the boundary file ...

anyway ... i will upload it into DB and post the link.

thanks v much

Jonathan September 18, 2012 11:26


Originally Posted by Jonathan (Post 382378)

anyway ... i will upload it into DB and post the link.

link to mesh

Jonathan September 18, 2012 11:34

too quick

Originally Posted by l_r_mcglashan (Post 382376)
Have you viewed the set coupledFaces in paraview?

Hi Laurence,

sorry, i read your previous post too quickly - apologies!

no, i havent looked at the problem set yet, but based on the above, it must be connected to the periodic / cyclic faces on the mesh.


l_r_mcglashan September 18, 2012 14:49

1 Attachment(s)
Ok, basically coupled patches aren't really handled by that utility, because to order coupled patches, you need to know about all the others. You don't know this upon initialisation.

One solution (which will mean you don't have to manually edit the patches as well) is to put the attached createPatchDict in your system/ folder and run createPatch. This will force the ordering of the faces.

Jonathan September 18, 2012 15:31

hi Laurence,

many thanks for your help - that seems to have worked!

so to paraphrase (for my own benefit!) - effectively since fluent3DMeshToFoam doesnt recognise (for some reason) fluent periodics, it does not reorder / couple the faces as required, and so changing the boundary file following having completed the import with the fluent periodics as simple 'patches' effectively causes the checkMesh to fail ...

createPatch remakes the selected patches and reorders them as required ...


so finally, is it then correct that fluent3DMeshToFoam cannot handle fluent periodics, and neither can fluentMeshToFoam (as per my previous post) - so effectively one has to use this as a work around for fluent meshes with periodics???

again thanks for your help - much appreciated

l_r_mcglashan September 18, 2012 15:59

Yes. It could handle periodics, but ignores them. In line 909 there's a comment about not being able to read in the transformation of one cyclic face to another:


    //- Periodic halves map directly into split cyclics. The problem is the
    //  initial matching since we require knowledge of the transformation.
    //  It is ok if the periodics are already ordered. We should read the
    //  periodic shadow faces section (section 18) to give use the ordering
    //  For now just disable.
    //fluentToFoamType.insert("periodic", cyclicPolyPatch::typeName);

Jonathan September 19, 2012 04:33

Hi Laurence,

thanks again for your help - i have managed to read in the mesh, and the solution on the periodics appears to be matching - so thanks v much.

re:code comments - i see - unfortunately i am still doing a crash course in c++ so hopefully in a while will be used to looking for comments like these.

thanks again

Tobias Adam May 6, 2014 07:21

I got the same error message from checkMesh because of my cyclics.
I just did the simulation and thought it was okay.
Is it possible to get good results with incorerectly matched cyclics?
Or is it absolutely necessery to fix it with create patches?

when I used createPatches, with the createPatchDict above I got the following error message:
"ill defined primitiveEntry starting at keyword 'patches' on line 49 and ending at line 157
So I used the createPatchDict from the propellor-tutorial and it worked :-)

Best regards Tobi

majid pourdian August 12, 2016 11:52

checkmesh error
I create a geometery with blockmesh in turbomashinary and have four cyclic patches,blockMesh is OK,but it has checkmesh error,give me following error:
Error in coupled point location.
its so wonderful that when I decrease mesh number, error disapeared and when I change it to wall, error disapeared.
could anyone help me?
thank you

Mehrez August 12, 2016 21:31

When you use cyclic boundary conditions, the 2 patches should have the same surface meshes. Otherwise, you can use "cyclicAMI" boundary conditions in order to interpolate from one face to another.

Originally Posted by majid pourdian (Post 613813)
I create a geometery with blockmesh in turbomashinary and have four cyclic patches,blockMesh is OK,but it has checkmesh error,give me following error:
Error in coupled point location.
its so wonderful that when I decrease mesh number, error disapeared and when I change it to wall, error disapeared.
could anyone help me?
thank you

All times are GMT -4. The time now is 22:04.