[Gmsh] Issue with reference to node 0 in elements list in *.msh file
Nathan J. Neeteson
nneeteson at rglinc.com
Tue Mar 12 17:43:32 CET 2019
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:
[cid:image001.png at 01D4D8BF.ABACD1D0]
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<mailto:nneeteson at rglinc.com> | rglinc.com<http://rglinc.com/>
API Q1(tm) and ISO 9001:2015 certified facilities.
Email disclaimer located at http://rglinc.com/disclaimer
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20190312/a0b5a49a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.png
Type: image/png
Size: 9039 bytes
Desc: image001.png
URL: <http://onelab.info/pipermail/gmsh/attachments/20190312/a0b5a49a/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mesh.geo
Type: application/octet-stream
Size: 40904 bytes
Desc: mesh.geo
URL: <http://onelab.info/pipermail/gmsh/attachments/20190312/a0b5a49a/attachment-0001.geo>
More information about the gmsh
mailing list