possible issues with conversion from gmsh

Mentioned in the cfd-online forum https://www.cfd-online.com/Forums/openfoam-meshing/213553-meshing-error-bad-token-could-not-get-word.html by user Dewi Madden.

• could be an OpenFOAM parsing issue,
• or a syntax change in gmsh format
• bad input,
• other

Diagnosis awaiting a file or two...

Hello,

This does appear to be a parsing issue from meshes generated in gmsh 4. I've attached a .msh file which reproduces this.hybrid.msh

Input as simple as this in gmsh can reproduce the problem:

SetFactory("OpenCASCADE");
Box(1) = {-1,-1,-1,3,3,3};
Physical Surface("walls") = {1,2,3,4,5,6};
Physical Volume("inside") = {1};

The original GMSH code is here:

I am finding it difficult to generate a spline surface too, is that perhaps an issue?

// Gmsh project created on Sun Dec 30 13:19:41 2018 // Waverider Mesh in 3D Parameterised.

// Definition of Variables

L=-2; // Length of the Waverider c=2; // chord of waverider w=c/2; // width of waverider symmetrical section h=1; // height of waverider ey=1; // Wind Tunnel Addition Factor in y ez=-1; // Wind Tunnel Addition Factor in z alpha=0.5; // Scale Factor of Mid W Point in x beta=0.5; // Scale Factor of Mid W Point in y phi=0.8; // Scale Factor of Mid Tip Point of Waverider in y ext=1;

///////////////////////////////////////////////////////////////////////////////////////// // Aircraft Geometrical Equations //Top Down of Aircraft

// -w --> 0; m1=L/w; i1=L;

// 0 --> w m2=-L/w; i2=L;

// Side View of Aircraft m3=phi*h/L; i3=0;

m4=h*(phi-1)/L; i4=h;

///////////////////////////////////////////////////////////////////////////////////////// // Points of Back Section // Including the W section

Point(1) = {0, 0, 0, 1.0}; Point(2) = {alphaw, betah, 0, 1.0}; Point(3) = {w, 0, 0, 1.0}; Point(4) = {-alphaw, betah, 0, 1.0}; Point(5) = {-w, 0, 0, 1.0}; Point(6) = {0, h, 0, 1.0}; Point(7) = {0, phi*h, L, 1.0}; // Location of the Tip Point of Waverider at z=L

//+ Spline(1) = {5, 6, 3}; //+ Line(2) = {5, 4}; //+ Line(3) = {4, 1}; //+ Line(4) = {1, 2}; //+ Line(5) = {2, 3}; //+

// Adding Diagonal Lines from negative end to positive end // Negative Symmetrical section

x1=-w; x2=-w*(4/5); x3=-w*(3/5); x4=-w*(2/5); x5=-w*(1/5); x6=0; x7=w/5; x8=w*(2/5); x9=w*(3/5); x10=w*(4/5); x11=w*(5/5);

z1=m1*x1+i1;
z2=m1*x2+i1;
z3=m1*x3+i1;
z4=m1*x4+i1;
z5=m1*x5+i1;
z6=m1*x6+i1;

z7=m2*x7+i2;
z8=m2*x8+i2;
z9=m2*x9+i2;
z10=m2*x10+i2;
z11=m2*x11+i2;

	y1=m3*z1+i3;
	y2=m3*z2+i3;
	y3=m3*z3+i3;
	y4=m3*z4+i3;
	y5=m3*z5+i3;
	y6=m3*z6+i3;
	y7=m3*z7+i3;
	y8=m3*z8+i3;
	y9=m3*z9+i3;
	y10=m3*z10+i3;
	y11=m3*z11+i3;

// Straight through the centre of the aircraft yb1=m4z1+i4; yb2=m4z2+i4; yb3=m4z3+i4; yb4=m4z4+i4; yb5=m4z5+i4; yb6=m4z6+i4; yb7=m4z7+i4; yb8=m4z8+i4; yb9=m4z9+i4; yb10=m4z10+i4; yb11=m4*z11+i4;

// Definition of Points Point(8)={x1, y1, z1, 1.0}; Point(9)={x2, y2, z2, 1.0}; Point(10)={x3, y3, z3, 1.0}; Point(11)={x4, y4, z4, 1.0}; Point(12)={x5, y5, z5, 1.0}; Point(13)={x6, y6, z6, 1.0}; Point(14)={x7, y7, z7, 1.0}; Point(15)={x8, y8, z8, 1.0}; Point(16)={x9, y9, z9, 1.0}; Point(17)={x10, y10, z10, 1.0}; Point(18)={x11, y11, z11, 1.0};

Point(19)={0,yb1,z1,1.0}; Point(20)={0,yb2,z2,1.0}; Point(21)={0,yb3,z3,1.0}; Point(22)={0,yb4,z4,1.0}; Point(23)={0,yb5,z5,1.0};

Point(25)={0,yb7,z7,1.0}; Point(26)={0,yb8,z8,1.0}; Point(27)={0,yb9,z9,1.0}; Point(28)={0,yb10,z10,1.0};

Line(6) = {3, 17}; Line(7) = {17, 16}; Line(8) = {16, 15}; Line(9) = {15, 14}; Line(10) = {14, 7}; Line(11) = {7, 12}; Line(12) = {12, 11}; Line(13) = {11, 10}; Line(14) = {10, 9}; Line(15) = {9, 5};

Spline(16) = {9, 20, 17}; Spline(17) = {10, 21, 16}; Spline(18) = {11, 22, 15}; Spline(19) = {12, 23, 14};

Line(20) = {6, 20}; Line(21) = {20, 21}; Line(22) = {21, 22}; Line(23) = {22, 23}; Line(24) = {23, 7}; Line(25) = {1, 7}; Line(26) = {2, 7}; Line(27) = {4, 7};

Line Loop(1) = {1, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15}; Plane Surface(1) = {1}; Line Loop(2) = {1, -5, -4, -3, -2}; Plane Surface(2) = {2}; Line Loop(3) = {14, 15, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13}; Plane Surface(3) = {3};

/////////////////////////////////////////////////////////////////////////////////////////

// Wind Tunnel Coordinates

Point(29) = {0, h+ey, L, 1.0}; Point(30) = {0, h+ey, L+ez, 1.0}; Point(31) = {0, h+ey, 0, 1.0}; Point(32) = {0, h+ey, -ez, 1.0}; Point(33) = {0, phih, L+ez, 1.0}; Point(34) = {0, -ey, L+ez, 1.0}; Point(35) = {0, -ey, L, 1.0}; Point(36) = {0, -ey, 0, 1.0}; Point(37) = {0, -ey, -ez, 1.0}; Point(38) = {0, 0, -ez, 1.0}; Point(39) = {0, betah, -ez, 1.0}; Point(40) = {0, h, -ez, 1.0}; Point(41) = {0, h+ey, -ez, 1.0}; Point(42) = {0, h, -ez, 1.0}; Point(43) = {0, phi*h, -ez, 1.0};

Line(28) = {33, 30}; Line(29) = {30, 29}; Line(30) = {29, 7}; Line(31) = {7, 33}; Line(32) = {33, 34}; Line(33) = {34, 35}; Line(34) = {35, 7}; Line(35) = {29, 31}; Line(36) = {31, 32}; Line(37) = {32, 40}; Line(38) = {40, 43}; Line(39) = {43, 39}; Line(40) = {39, 38}; Line(41) = {38, 37}; Line(42) = {37, 36}; Line(43) = {36, 35}; Line(44) = {6, 40}; Line(45) = {6, 31}; Line(46) = {1, 38}; Line(47) = {36, 1};

Line Loop(4) = {34, -25, -47, 43}; Plane Surface(4) = {4}; Line Loop(5) = {30, -24, -23, -22, -21, -20, 45, -35}; Plane Surface(5) = {5}; Line Loop(6) = {29, 30, 31, 28}; Plane Surface(6) = {6}; Line Loop(7) = {32, 33, 34, 31}; Plane Surface(7) = {7}; Line Loop(8) = {45, 36, 37, -44}; Plane Surface(8) = {8}; Line Loop(9) = {46, 41, 42, 47}; Plane Surface(9) = {9}; Line(48) = {6, 1}; Line Loop(10) = {48, 46, -40, -39, -38, -44}; Plane Surface(10) = {10};

/////////////////////////////////////////////////////////////////////////////////////////

// 2D Section Transfinite Nx=20; Ny=20; Transfinite Line {29, 31, 33} = Nx Using Progression 1; Transfinite Line {35, 24, 23, 22, 21, 20, 43} = Nx Using Progression 1; Transfinite Line {36, 44, 46, 42} = Nx Using Progression 1; Transfinite Line {28, 32} = Nx Using Progression 1; Transfinite Line {30, 34} = Ny Using Progression 1; Transfinite Line {45, 48, 47} = Ny Using Progression 1; Transfinite Line {37, 38, 39, 40, 41} = Ny Using Progression 1; /////////////////////////////////////////////////////////////////////////////////////////

//+ Recombine Surface {6, 5, 8, 10, 9, 4, 7};

// EXTRUDE TO GENERATE 3D /////////////////////////////////////////////////////////////////////////////////////////

Extrude {ext, 0, 0} { Surface{6}; Surface{5}; Surface{8}; Surface{10}; Surface{9}; Surface{4}; Surface{7}; }

Extrude {-ext, 0, 0} { Surface{6}; Surface{5}; Surface{8}; Surface{10}; Surface{9}; Surface{4}; Surface{7}; }//+

///////////////////////////////////////////////////////////////////////////////////////// // Physical Surfaces Physical Surface("airfoil") = {1,2,3}; Physical Surface("inflow") = {69, 219, 403, 253, 416, 394, 372}; Physical Surface("topAndBottom") = {111, 295, 57, 241, 125, 309, 367, 183, 393, 209, 407, 223}; Physical Surface("frontAndBack") = {219, 69, 403, 253, 313, 341, 337, 363, 129, 2, 157}; Physical Surface("outflow") = {129, 313, 345, 341, 337, 363, 179, 153, 157, 161, 125, 309, 295, 111, 241, 57};

Physical Volume("fluid") = {10, 11, 12, 5, 4, 3, 9, 2, 13, 6, 14, 8, 1, 7};

Hi, any progress on this? I'd happily attempt a fix if I could figure out how to do a PR in gitlab. I would very much appreciate being able to use this soonish.

mentioned in issue #1215 (closed)

@gavin If you compile $FOAM_UTILITIES/mesh/conversion/gmshToFoam/gmshToFoam.C with debug flags

options

and run with

FOAM_ABORT=true gmshToFoam hybrid.msh

it shows aborting in the reading of the vertices. It probably has to do with the number of vertices to be read - it thinks there are only 29. This has probably changed in the format. Does this point you in the right way?

@Mattijs I appreciate your hint very much, I am just now getting to the point in my project where I planned to use a gmsh-generated mesh. Hopefully I will be able to provide some suggested code on this soon!

@Mattijs I figured out why the mesh converter expected only 29 nodes. It's because gmsh v4 or above uses a different .msh format than previous gmsh versions; see the gmsh 4.1 manual, Ch. 9. I wrote the attached suggested update to gmshToFoam.C which can handle all current versions of gmsh, can someone please check it?

After solving the issue @djmads encountered, I found that there were still some issues with the construction of a polyMesh. It seems to happen with older gmsh versions too with the old .C file, maybe related to some changes on the develop branch. Does anyone know why the following warning would occur?

--> FOAM Warning : From function Foam::polyMesh::polyMesh(const Foam::IOobject&, Foam::pointField&&, const cellShapeList&, const faceListList&, const wordList&, const wordList&, const Foam::word&, const Foam::word&, const wordList&, bool) in file meshes/polyMesh/polyMeshFromShapeMesh.C at line 592 Found 624 undefined faces in mesh; adding to default patch. Finding faces of patch 0

Also, I attached a very simple .msh file for anyone to test the new gmshToFoam on. It's a cube with its boundaries named "walls" and the inside named "inside".

gmshToFoam.C

simple.msh

To clarify, the current gmshToFoam.C fails because a variable of type word gets instantiated on the string “” at the end of the .msh file, which causes the originally reported error.

Adding

if (line == “”) break;

in main()’s outer loop over the .msh file’s lines fixes the original issue, revealing the warning I just mentioned. While the mesh is created, it seems to have incorrect patch groups. Stuff like foamToVTK then fails when ran on it.

As an update @mark @Mattijs, this consequences of that warning manifest as only the boundary mesh appearing when viewed in Paraview. It seems that faces on the boundary are mixed up with faces on the inside, from what I can tell after a simple laplacianFoam run showing garbled data on the boundary. I would very much appreciate a hint of any sort... I think the gmshToFoam.C part of the problem is pretty much solved but spent all day today struggling to get the polyMesh initialized correctly.

• Thanks. Do you think we should merge the two versions of readPoints/readCells or is there too little overlap.

• The warning from the polyMesh constructor comes from not all boundary faces being present in the 'boundaryFaces' (line 1495 in your gmshToFoam.C) so it puts them into the 'default' patch. You have to make sure that the boundaryFaces corresponds to the OpenFOAM faces for that patch.

Thanks so much, I do think there is too little overlap. The way that the loops over the lines are set up is completely different. In fact, the new readCells should be a little bit faster since it has less conditionals in the loops.

Something that may make sense is lumping the part of readPoints/readCells which is not responsible for reading data into one function, which would consolidate some LOC.

On the warning, thanks, I will look into that.

So, I can confirm there has been some sort of regression, since I just checked out the latest master branch and find that it cannot correctly convert the test cases for gmshToFoam in utilities/mesh/conversion/gmshToFoam/gmsh. I have no clue which commit to look back to which may work correctly...

I'm getting the same in v1812. Bad token - could not get word. Will have a look.

mentioned in commit 3691f8ab

Maybe it is easy to make a testcase of e.g. 2x2x2 hexes with all sides in different patches? This would give opportunity to test:

• matching patches to boundary faces
• avoiding matching to internal faces

mentioned in commit e0d28425

Well, despite the fact that things like foamToVTK and polyDualMesh crash due to not being able to find a patch, it seems that solvers run fine on the mesh. The temporary workaround I've been using has been to start a solve with laplacianFoam or something simple, run polyDualMesh, export with foamToVTK, and then use that to view the mesh. I'm going to run some cases soon and see if the results come out not ridiculous, and will keep you posted.

Above does not sound correct. It is unlikely there is something wrong with polyMesh. Do you have a simple testcase (e.g. 2x1x1 hexes) which has some internal faces and some external faces in different patches? This would make it a lot easier to get the face matching working.

@Mattijs you're right. I apologize, it actually seems to be working. I would view my mesh in constant/polyMesh with paraview, but for some reason, paraview does not display the internal mesh at time 0, and will only display boundary faces. That mislead me to think the mesh internals were not being converted, but in fact, they were. The meshes produced by the version of gmshToFoam.C above seem to work just fine; testament to this is that I've got some cases from it running on AWS at this very moment.

assigned to @Mattijs and unassigned @mark

mentioned in commit d2d11b12

mentioned in commit 82a39ec8