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...
No child items are currently assigned. Use child items to break down this issue into smaller parts.
Link issues together to show that they're related. Learn more.
Activity
- Maintainer
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};
By Gavin Ridley on 2019-01-14T14:39:27 (imported from GitLab project)
Edited by Admin - Maintainer
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};
By Dewi Madden on 2019-01-28T12:04:58 (imported from GitLab project)
- Maintainer
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.
By Gavin Ridley on 2019-02-21T02:39:46 (imported from GitLab project)
- Admin mentioned in issue #1215 (closed)
mentioned in issue #1215 (closed)
By Gavin Ridley on 2019-02-23T18:45:53 (imported from GitLab project)
- Maintainer
@gavin If you compile $FOAM_UTILITIES/mesh/conversion/gmshToFoam/gmshToFoam.C with debug flags
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?
- Maintainer
@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!
By Gavin Ridley on 2019-04-04T01:43:40 (imported from GitLab project)
- Maintainer
@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".
By Gavin Ridley on 2019-04-06T00:07:18 (imported from GitLab project)
Edited by Admin - Maintainer
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.
By Gavin Ridley on 2019-04-06T01:52:07 (imported from GitLab project)
- Maintainer
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.
By Gavin Ridley on 2019-04-08T23:46:25 (imported from GitLab project)
- Maintainer
-
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.
-
- Maintainer
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.
By Gavin Ridley on 2019-04-10T12:54:52 (imported from GitLab project)
- Maintainer
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...
By Gavin Ridley on 2019-04-10T20:16:45 (imported from GitLab project)
- Maintainer
I'm getting the same in v1812.
Bad token - could not get word
. Will have a look. - Mattijs Janssens mentioned in commit 3691f8ab7ba1a198576a2fb422b4e05322aeeeaf
mentioned in commit 3691f8ab7ba1a198576a2fb422b4e05322aeeeaf
- Maintainer
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
- Mattijs Janssens mentioned in commit e0d28425b1e80eac0b958b4116b1ced5eba56848
mentioned in commit e0d28425b1e80eac0b958b4116b1ced5eba56848
- Maintainer
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.
By Gavin Ridley on 2019-04-14T04:27:30 (imported from GitLab project)
- Maintainer
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.
- Maintainer
@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.
By Gavin Ridley on 2019-04-25T15:11:55 (imported from GitLab project)
- Mattijs Janssens assigned to @Mattijs and unassigned @mark
- Mattijs Janssens mentioned in commit d2d11b1283a3c593a3db6a23b371e293c61c6776
mentioned in commit d2d11b1283a3c593a3db6a23b371e293c61c6776
- Kutalmış Berçin mentioned in commit 82a39ec8c6d9cfb791e32c203343818b406928a6
mentioned in commit 82a39ec8c6d9cfb791e32c203343818b406928a6
- Mark OLESEN mentioned in commit 076ba4e2
mentioned in commit 076ba4e2
Sorry to make an old issue active.
Is there any resolution on the issue? From what I have gathered, the GMSH .msh format has the correct elements, but the conversion fails to assign the right patches to the "Physical Boundaries". This could most possibly be an issue with the gmshToFoam.C which is unable to handle higher order elements, and non-volume based elements. For example: GMSH, in the .msh file includes points, lines, quads and hexahedrons, for a simple 9x9x1 cuboid domain. The utility would fail when reading points as "15" (the entity tag for a point) is not defined in the gmshToFoam.C code.
If I bypass this by just reading volumes (no surfaces, lines or points), it assigns default patches to all the quad surfaces in the domain (of which there are 198).
- Maintainer
Hi @kuti Sure, please find the .geo and .msh files attached. The domain is a simple 1x1x0.1 cuboid. This domain is broken up into 4 hexahedral cells.
If you look at the .msh file, you will note that after the "$Elements" tag, for entityDim 0, the element type is 15 (not accounted in the gmshToFoam.C routine).
To get around that problem, I deleted those elements. Now, gmshToFoam can create a PolyMesh, but it fails to assign the physical names to the faces. Below is the console output when ran gmshToFoam on the above .msh file after removing the elements with element type 15.
// * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * // Create time
Starting to read mesh format at line 2 Read format version 4.1 ascii 0
Starting to read physical names at line 5 Physical names:6 Surface 1 FrontAndBack Surface 2 LeftWall Surface 3 RightWall Surface 4 TopWall Surface 5 BottomWall Volume 6 Internal
Starting to read points at line 44 Vertices to be read: 18 Vertices read: 18
Starting to read cells at line 110 Cells to be read:40
Mapping region 1 to Foam patch 0 Mapping region 4 to Foam patch 1 Mapping region 2 to Foam patch 2 Mapping region 5 to Foam patch 3 Mapping region 3 to Foam patch 4 Mapping region 6 to Foam cellZone 0 Cells: total: 4 hex : 4 prism: 0 pyr : 0 tet : 0
CellZones: Zone Size 0 4
Patch 0 gets name FrontAndBack Patch 1 gets name TopWall Patch 2 gets name LeftWall Patch 3 gets name BottomWall Patch 4 gets name RightWall
--> FOAM Warning : From 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 643 Found 16 undefined faces in mesh; adding to default patch defaultFaces Finding faces of patch 0 Finding faces of patch 1 Finding faces of patch 2 Finding faces of patch 3 Finding faces of patch 4
FaceZones: Zone Size
Writing zone 0 to cellZone Internal and cellSet
End
- Maintainer
assuming resolved considering the commits above.
please open a new ticket if the issue persists.
- Kutalmış Berçin closed
closed