Axisymmetric blockMeshDict: FOAM FATAL ERROR: wedge ... centre plane does not align with a coordinate plane by

Question

I'm trying to follow this tutorial to create the axisymmetric model below:

Following the discussions over here, my blockMeshDict file is:

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      blockMeshDict;
}

convertToMeters 0.001;

wa 5.0;
cr 10.0;
pr 8.0;
cl 50.0;
px 20.0; 
pl 10.0; 
px2 #calc "$px+$pl"; 
ms 50; 

vertices
(
    (0                      0                         0)    //00
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    0)    //01
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   0)    //02
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $px)  //03
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $px)  //04
    (0                      0                         $px)  //05
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $px)  //06
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    0)    //07
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   0)    //08
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $px)  //09
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $px2) //10
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $px2) //11
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $px2) //12
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $px2) //13
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $cl)  //14
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $cl)  //15
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $cl)  //16
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $cl)  //17
    (0                      0                         $cl)  //18
    (0                      0                         $px2) //19
);

blocks
(
    hex (0  1  2  0  5  4  3  5)         ($ms 1 $ms) simpleGrading (1 1 1)
    hex (1  7  8  2  4  6  9  3)         ($ms 1 $ms) simpleGrading (1 1 1)
    hex (4  6  9  3  12 11 10 13)        ($ms 1 $ms) simpleGrading (1 1 1)
    hex (12 11 10 13 15 16 17 14)        ($ms 1 $ms) simpleGrading (1 1 1)
    hex (19 12 13 19 18 15 14 18)        ($ms 1 $ms) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    inlet
    {
        type patch;
        faces
        (
            (0 1 2 0)
            (1 7 8 2)
        );
    }
    outlet
    {
        type patch;
        faces
        (
            (18 15 14 18)
            (15 16 17 14)
        );
    }
    walls
    {
        type wall;
        faces
        (
            (7  8  9  6)
            (6  9  10 11)
            (11 10 17 16)
        );
    }
    wedgeBack
    {
        type wedge;
        faces
        (
            (0  1  4  5)
            (1  7  6  4)
            (4  6  11 12)
            (12 11 16 15)
            (19 12 15 18)
        );
    }

    wedgeFront
    {
        type wedge;
        faces
        (
            (0  2  3  5)
            (2  8  9  3)
            (3  9  10 13)
            (13 10 17 14)
            (19 13 14 18)
        );
    }

    axis
     { 
           type empty;
           faces  
           (
               (0  5  5  0)
               (19 18 18 19)
           );
    }
);

mergePatchPairs
(
);

But when i run the blockMesh I get the warnings like:

Creating block mesh topology --> FOAM Warning : From function Foam::polyMesh::polyMesh(const Foam::IOobject&, const Foam::Xfer > >&, const cellShapeList&, const faceListList&, const wordList&, const Foam::PtrList&, const Foam::word&, const Foam::word&, bool) in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 871 Found 3 undefined faces in mesh; adding to default patch.

followed by the error:

--> FOAM FATAL ERROR: wedge wedgeFront centre plane does not align with a coordinate plane by 0.360319 From function virtual void Foam::wedgePolyPatch::calcGeometry(Foam::PstreamBuffers&) in file meshes/polyMesh/polyPatches/constraint/wedge/wedgePolyPatch.C at line 98.

unfortunately Googling the error message doesn't return much. I would appreciate if you could help me know what is the problem and how I can solve it.

Googling the error message might or might not help with OpenFOAM, however, I find OpenFOAM's error messages quite telling and useful. It tells you exactly what is wrong, although, I have to admit, for the newcomer, including myself, they are sometimes hard to read. But given enough experience, OpenFOAM's error messages are really helpful. — Dohn Joe, Aug 23 '18 at 08:44
BTW: [the Computational Science](https://scicomp.stackexchange.com/questions/tagged/openfoam) SE site is the more common place to post OpenFOAM related questions. I have no idea how this is done, yet I propose to migrate the question to SciComp SE. — Dohn Joe, Aug 23 '18 at 08:50
@DohnJoe I will try your code and come back here. thanks a lot for your help. — Foad S. Farimani, Aug 23 '18 at 08:52
@DohnJoe I tried computational science stackexchange for my [new question](https://scicomp.stackexchange.com/questions/30080/implementing-brent-solver-instead-of-newton-method-in-thermoi-h-to-resolve-maxim). did not get much help though! — Foad S. Farimani, Aug 23 '18 at 17:48
Well, OpenFOAM is a very specific topic. So, don't expect immediate answers. Unfortunately, the OpenFOAM community is rather small. — Dohn Joe, Aug 23 '18 at 19:30

score 2 · Answer 1 · answered Aug 23 '18 at 08:43

2

The way you compute the point coordinates seems quite weird to me, e.g. what is the parameter wa supposed to mean? It seems that you intended it to be an angle.

I managed to get a valid mesh by changing the patch type of the wedge patches to the type patch, which is more forgiving than the type wegde. I do this frequently when trouble-shooting blockMeshDicts.

Furthermore, I changed the order of the vertices in the inlet patch definition. The vertex list in a patch definition has to adhere the "right-hand rule", see the User Guide.

For cases employing axi-symmetry, the User Guide recommends having a small wedge angle, e.g. 1°, for the axi-symmetric domain. This is most probably the reason behind your error stating that the wedge centre plane doesn't align.

Thus, I propose:

Keep the wedge patches as being of the type patch for the time being
Sort out your geometry, so that you are able to produce a 1° slice of geometry
Change the wedge patches back to wedge, once your geometry is a 1° slice

FoamFile
{
    version     2.0;
    format      ascii;
    class       dictionary;
    object      blockMeshDict;
}

convertToMeters 0.001;

wa 4.0;
cr 10.0;
pr 8.0;
cl 50.0;
px 20.0; 
pl 10.0; 
px2 #calc "$px+$pl"; 
ms 50; 

vertices
(
    (0                      0                         0)    //00
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    0)    //01
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   0)    //02
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $px)  //03
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $px)  //04
    (0                      0                         $px)  //05
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $px)  //06
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    0)    //07
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   0)    //08
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $px)  //09
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $px2) //10
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $px2) //11
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $px2) //12
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $px2) //13
    (#calc "$pr*cos($wa/2)" #calc "-$pr*sin($wa/2)"   $cl)  //14
    (#calc "$pr*cos($wa/2)" #calc "$pr*sin($wa/2)"    $cl)  //15
    (#calc "$cr*cos($wa/2)" #calc "$cr*sin($wa/2)"    $cl)  //16
    (#calc "$cr*cos($wa/2)" #calc "-$cr*sin($wa/2)"   $cl)  //17
    (0                      0                         $cl)  //18
    (0                      0                         $px2) //19
);

blocks
(
    hex (0  1  2  0  5  4  3  5)         ($ms 1 $ms) simpleGrading (1 1 1)
    hex (1  7  8  2  4  6  9  3)         ($ms 1 $ms) simpleGrading (1 1 1)
    hex (4  6  9  3  12 11 10 13)        ($ms 1 $ms) simpleGrading (1 1 1)
    hex (12 11 10 13 15 16 17 14)        ($ms 1 $ms) simpleGrading (1 1 1)
    hex (19 12 13 19 18 15 14 18)        ($ms 1 $ms) simpleGrading (1 1 1)
);

edges
(
);

boundary
(
    inlet
    {
        type patch;
        faces
        (
            (0 2 1 0)
            (1 2 8 7)
        );
    }
    outlet
    {
        type patch;
        faces
        (
            (18 15 14 18)
            (15 16 17 14)
        );
    }
    walls
    {
        type wall;
        faces
        (
            (7  8  9  6)
            (6  9  10 11)
            (11 10 17 16)
        );
    }
    wedgeBack
    {
        type patch;
        faces
        (
            (0  1  4  5)
            (1  7  6  4)
            (4  6  11 12)
            (12 11 16 15)
            (19 12 15 18)
        );
    }

    wedgeFront
    {
        type patch;
        faces
        (
            (0  2  3  5)
            (2  8  9  3)
            (3  9  10 13)
            (13 10 17 14)
            (19 13 14 18)
        );
    }

    axis
     { 
           type empty;
           faces  
           (
               (0  5  5  0)
               (19 18 18 19)
           );
    }
);

mergePatchPairs
(
);

answered Aug 23 '18 at 08:43

Dohn Joe

313
4
15

Thanks a lot. some points: 1. wa stands for wedge angle and I considered as 5 as told in [this page](https://www.openfoam.com/documentation/user-guide/boundaries.php), is it better if we consider it smaller or closer to 5? 2. it doesn't affect the solution if we change wedge to patch? 3. the normal to every face must be outwards? or all of them should be in the same direction? this is really confusing! – Foad S. Farimani Aug 23 '18 at 08:51
1

Note, that what you enter in the trigonometric functions is an angle in radians, not degrees. Because of this, I was only able to create a valid mesh with values of wa=4 and wa=5. – Dohn Joe Aug 23 '18 at 08:54
aaaah, the common undergrad mistake! I will fix this now. it is indeed 5 degrees! – Foad S. Farimani Aug 23 '18 at 08:56
1

The wedge patches have to be of the type `wedge`, once you run your simulation, yet for trouble-shooting the mesh setting them to the type `patch` makes mesh generation more forgiving. The image I posted is with the wedge patches having the type `patch`, if I would set them to be of the `wedge` type, mesh generation would fail, and I would not be able to see the block-structure. – Dohn Joe Aug 23 '18 at 08:56
1

The patches are defined in a way, so that the face normal points outwards. The [Right-hand rule](https://en.wikipedia.org/wiki/Right-hand_rule) is very useful for this purpose. Point your thumb in a way, so it points outwards; and then follow your index finger around the patch boundary to visit all vertices. – Dohn Joe Aug 23 '18 at 08:59
1

The User Guide: _The order in which the vertices are given must be such that, looking from inside the block and starting with any vertex, the face must be traversed in a clockwise direction to define the other vertices._ – Dohn Joe Aug 23 '18 at 09:00
Is this `wa 5.0*constant::mathematical::pi/180;` a correct way of changing from degrees to radians? – Foad S. Farimani Aug 23 '18 at 09:01
1

There is a pre-defined function to use: `radHalfAngle #calc "degToRad($halfAngle)";`, but what you posted should also do the trick. – Dohn Joe Aug 23 '18 at 09:05
shockingly enough fixing the degree-radian issue removed the above error! but now I have this error: `FOAM FATAL IO ERROR: Block hex (0 1 2 0 5 4 3 5) (50 1 50) simpleGrading (1(1) 1(1) 1(1)) has inward- pointing faces 4(1 2 3 4) 4(0 1 4 5) 4(0 5 3 2) 4(0 0 2 1) 4(5 4 3 5)` I am gonna fix that one now. – Foad S. Farimani Aug 23 '18 at 09:05
I guess you need to revisit the block definition. I managed to create a valid block 0 with an alternative vertex-ordering `hex (0 2 1 0 5 3 4 5)`. The error message _inward- pointing faces_ means that most probably the vertex-ordering of the block definition is wrong. – Dohn Joe Aug 23 '18 at 09:11
Ok, I think there are two ways to consider faces. one when defining blocks/hexs then the normal of two faces defining the hex should point to the same direction, in our case negative z. but when defining boundaries they normal should point outwards. is this true? – Foad S. Farimani Aug 23 '18 at 09:19
I fixed the normals as explained in the above comment and no wI get the error: ` FOAM FATAL ERROR: Inconsistent number of faces between block pair 0 and 1 From function void Foam::blockMesh::calcMergeInfo() in file blockMesh/blockMeshMerge.C at line 217.` – Foad S. Farimani Aug 23 '18 at 09:20
1

block definition is independent of face definition. – Dohn Joe Aug 23 '18 at 09:21
1

Another trouble-shooting tip: set the number of cells to 1 for all blocks and for all directions. Once a single-cell-per-block mesh can be successfully created, then set your cell numbers to the desired values. _Inconsistent number of faces between block pair X and Y_ means, that two neighbouring, connected blocks are discretized with non-matching cell numbers. – Dohn Joe Aug 23 '18 at 09:23
awesome. I changed all the `$ms` mesh sizes to 1 and now it compiles. what is wrong with those though? – Foad S. Farimani Aug 23 '18 at 09:27
now I'm able to divide al the hexs in z direction without any issues, and first and last hex in x direction. the problem arises when I try to mesh 2, 3 and 4 in x direction! you may find my latest `blockMeshDict` [here](https://gist.github.com/Foadsf/22edbd7a7bdefefc24005753c8f89d40) – Foad S. Farimani Aug 23 '18 at 10:18
weird, but I was able to divide 2, 3 and 4 hexes in x direction by changing the y parameter! you may see the updated `blockMeshDict` [here](https://gist.github.com/Foadsf/22edbd7a7bdefefc24005753c8f89d40). I also get this warnings now: ` FOAM Warning : From function virtual void Foam::wedgePolyPatch::calcGeometry(Foam::PstreamBuffers&) in file meshes/polyMesh/polyPatches/constraint/wedge/wedgePolyPatch.C at line 70 Wedge patch 'wedgeBack' is not planar. At local face at the normal differs from the average normal Either correct the patch or split it into planar parts` – Foad S. Farimani Aug 23 '18 at 10:32
1

from [here](https://www.cfd-online.com/Forums/openfoam/176129-solved-wedge-patch-not-planer-error.html#post703640) I solved the problem by changing writePrecision in controlDict file from 6 to 7! OpenFOAM is freaking weird! – Foad S. Farimani Aug 23 '18 at 10:48
1

Yeah, the issue with `writePrecision` is a tricky one. I had similar problems in the past. So, why does this happen? The `#calc` entries in the blockMeshDict are compiled and run to perform the computations. Any results are written to disk with the precision set by `writePrecision`. Thus, computing a point coordinate may use an intermediate result in the form of: `os << (8.000000*cos(0.017453/2));`. With too small a precision, some computations might not be accurate enough. – Dohn Joe Aug 23 '18 at 10:57
1

_divide 2, 3 and 4 hexes in x direction by changing the y parameter_ Take a good look at Figure 5.4 in the [User Guide](https://cfd.direct/openfoam/user-guide/v6-blockMesh/). The local x-,y- and z- directions of an individual block are not necessarily in line with the global x-, y- and z-directions of the global coordinate system. – Dohn Joe Aug 23 '18 at 11:00
another weird behaviour: if I use `radHalfAngle #calc "degToRad(5)";` I get the same planar... warning, unless I change the `writePrecision` to 8 in `controlDict` file! – Foad S. Farimani Aug 23 '18 at 11:07
As I can see when you define a hex the direction from point 0 to 1 is x, from 1 to 2 is z and the one perpendicular tho these is y. Hence for 2, 3, 4 the y and z are switched! – Foad S. Farimani Aug 23 '18 at 11:11
1

Take another look at Figure 5.4 from the [User Guide](https://cfd.direct/openfoam/user-guide/v6-blockMesh/). The edge 0-1 is the local x-direction, or x_1; the edge 1-2 is the local y-direction, or x_2; and the perpendicular direction to the two aforementioned edges is the local z-direction. – Dohn Joe Aug 23 '18 at 11:14
It would be great if these point could be categorized and cleaned up for future reference. – Foad S. Farimani Aug 23 '18 at 11:15

Axisymmetric blockMeshDict: FOAM FATAL ERROR: wedge ... centre plane does not align with a coordinate plane by

1 Answers1