[Gmsh] Issue with reference to node 0 in elements list in *.msh file

[Christophe Geuzaine]

Dear Nathan,

This is indeed strange. As there were many bug fixes since 4.0.1, I would really recommend updating your model to the latest Gmsh release. The difference in numbering comes from an upgrade in OpenCASCADE, which changed the way some entities are constructed.

If the issue persists with the latest version we will investigate.

Cheers,

Christophe

> On 12 Mar 2019, at 17:43, Nathan J. Neeteson <nneeteson at rglinc.com> wrote:
> 
> Hello everyone,
>  
> I am have been experiencing an odd issue with Gmsh recently. Essentially, in one of my meshes sometimes when I export it as a *.msh file, there is a reference to a 0 node in the $Elements list – there is no 0 node in the $Nodes list and this causes gmshToFoam to fail when converting the mesh.
>  
> I am constrained to using 2.2 mesh format since that’s all that gmshToFoam can handle, as far as I can tell. Here is a snippet from the $Elements list in a mesh file that is indicative of the problem:
>  
> <image001.png>
>  
> So element 925908 is of type 4, is of dimension 2, belongs to physical 601 and elementary 65, and is composed of nodes 0 (!!), 320410, 321806, and 321926. This is not an isolated instance either, there are many such elements in the mesh with 0 nodes. I tried google searches to find information but as far as I can tell, no-one has ever experienced this before?
>  
> The other bizarre thing is this: to make the mesh construct faster to make debugging easier, I increased the size of my smallest elements to greatly reduce the number of nodes in the mesh, and the problem went away. When the mesh has in the range of 10s of millions of cells it occurs, but when I reduce to hundreds of thousands, no references to node 0 in any elements.
>  
> Can anyone please tell me what the meaning is of a node 0 in an element? Does it simply mean that that element failed to construct, or reflect some kind of quality issue with the mesh? Is it a bug with gmsh?
>  
> I have attached the geo file that created the situation, unfortunately it is a quite complicated file (probably poorly scripted in terms of performance). It compiles with Gmsh 4.0.1, but when I tried to load the script with the newest version of Gmsh it failed, due to what I can only assume were changes to the ordering of elements from either the Boundary or Extrude function breaking my dynamically generated line loops. So the geo file may be of limited investigative value. I also would have created a smaller script that reproduces the issue if I could, but I have no idea how to reproduce this issue.
>  
> If anyone could give me any advice or insight into this issue I would appreciate it.
>  
> Thanks,
>  
> Nathan Neeteson, M.Sc.
> Flow Control Research Engineer
> RGL Reservoir Management Inc.
> Corporate Head Office
> P 780.851.8243 | C 613.929.6283
> nneeteson at rglinc.com | rglinc.com
> API Q1™ and ISO 9001:2015 certified facilities.
>  
> Email disclaimer located at http://rglinc.com/disclaimer <mesh.geo>_______________________________________________
> gmsh mailing list
> gmsh at onelab.info
> http://onelab.info/mailman/listinfo/gmsh

— 
Prof. Christophe Geuzaine
University of Liege, Electrical Engineering and Computer Science 
http://www.montefiore.ulg.ac.be/~geuzaine