meshio: Wrong mesh total volume with MSH4 format

Hi,

I think there might be an error when reading Gmsh v4 format.

I have a box split as 6 horizontal boxes with different physical groups. A vertical box (a fault) cuts the 4 middle boxes. No issue whatsoever while meshing. I still check that everything is fine by calculating the total volume of my tetrahedra cells (it should equal 6e10 in my case).

With a mesh file exported as MSH4, I get a bigger volume. Nevertheless, the volume is correct when I export my mesh as MSH2. Both meshio.Mesh objects have the same number of tetra, but I noticed that the one for MSH2 has fewer points (5333 instead of 5337 for MSH4). I don’t know if it helps, though.

I attach an archive containing the Gmsh script (actually generated by pygmsh), the two Gmsh mesh files (v2 and v4) and a script to check the total volume of the mesh: mesh4.zip

Note that everything is alright if I do not define physical groups.

About this issue

Original URL
State: closed
Created 5 years ago
Comments: 24 (24 by maintainers)

Most upvoted comments

Here you go: https://gitlab.onelab.info/gmsh/gmsh/issues/675

Update: the bug is known and is fixed in the development version.

keurfonluu on Oct 25, 2019

Sorry, I reopen the issue because I think that I figured out what’s going on.

Gmsh 4.4.1 on Windows exports to MSH4 with one extra node compared to MSH2 (node 892):

3 73 0 8
885
886
892
887
888
889
890
891
1.9094841541679 1.854819586758833 -0.9289565732495784
2.159267773830474 2.212772901957076 -0.9182659643526144
1.809354945981777 1.881992026041631 -0.8649675049590133
2.206256706527594 2.230978328829988 -1.096770135423909
2.169757106314774 2.226374625230513 -1.030571381121748
1.734212940584615 1.745333884906713 -1.06144994650878
2.216726141239009 2.122168929620742 -1.05853354798943
1.83210465513853 1.844069935125439 -1.014305723781135
$EndNodes

Node 892 is the only node that is not in the correct order, it is not used in any element and does not exist in MSH2 file (basically, it is useless). Logically, it should not be used in any tetra cell in meshio. However, when I check whether any tetra cell uses this node in meshio:

for i, cell in enumerate(msh4.cells["tetra"]):
    if 891 in cell:
        print(i)

Output:

But no cell uses node 890 while they should. If I remove node 892 from the MSH4 file (and edit the file accordingly), everything is alright.

It does not change the fact that Gmsh should not export this node in the first place, though.

mesh4_5.zip

Note:

msh4.points[890]
array([ 1.83210466,  1.84406994, -1.01430572])

msh4.points[891]
array([ 1.80935495,  1.88199203, -0.8649675 ])

keurfonluu on Oct 24, 2019

I get an error reading mesh4.msh from mesh4_2.zip in Gmsh 4.5.0-git-0c1b63c8d on Ubuntu 19.04:

Error   : Unknown entity 0 of dimension 3
Error   : Could not read elements
Error   : Error loading 'mesh4.msh'
Info    : Done reading 'mesh4.msh'

How was this file generated? The first mesh4.msh from mesh4.zip was O. K.

gdmcbain on Oct 20, 2019