> On 14 Sep 2018, at 04:43, jeremy theler <[email protected]> wrote:
> 
> Dear developers,
> 
> I am updating my .msh parser for the new version 4 format. What I found
> was that nodes and elements are "sparse" (borrowing exact terms from
> Gmsh manual) in the sense that they do not constitute a continuous list
> of indexes starting at 1.
> 
> For example, the attached geo generates 45 nodes numbered up to an
> index of 90 and 68 elements up to 184 using latest stable 4.0.1. Even
> using RenumberMeshNodes and RenumberMeshElements (the output is the
> same with these two instructions in and out... what do they actually
> do?).
> 

RenumberMeshNodes and RenumberMeshElements renumber the nodes and the elements 
in the (whole) mesh. In Gmsh 4.0.1 this is now called by default after the 
meshing stage, so that all the meshes generated by Gmsh have nodes/elements 
numbered in a continuous sequence.

In your exemple you only save a part of the mesh, as you define a Physical 
group for only one of the two surfaces. By default Gmsh only saves the parts of 
the mesh that belong to physical groups, so you indeed end up with "gaps" in 
the mesh - corresponding to the parts you didn't save. To save the whole mesh, 
set Mesh.SaveAll=1.

To efficiently deal with the format just use arrays: you will waste some memory 
for empty entries, but that's it. In our reference implementation 
(GModelIO_MSH4.cpp) we put a threshold on the "level of sparsity", which 
determines if we use an array or a map.

> 
> As the manual correctly says, this "sparcity" impacts efficiency and
> performance as arrays cannot be used and other types of objects need to
> appear (linked lists, hashed lists, etc) in order to handle them.
> 
> 
> I still want to use arrays on my code due to performance issues. I
> might re-order the nodes to get them straight at parse-time, but I
> think that should be done on the mesher side (because the same mesh
> might be read several times from the solver side so it makes no sense
> to re-order every time).
> 
> On the other hand, if I use msh2 output (even in Gmsh 4.0.1) the
> sparcity is gone and I can rely on my good old arrays.
> 
> Question is: what are the benefits of this behavior in msh4? 
> 

In previous MSH file formats, we renumbered the nodes and the elements *during 
the file export*. It guaranteed that the "tags" in the mesh file were in effect 
"indices" - always dense (and actually useless... since they were indices). But 
this destroyed the link between the internal representation of the mesh and 
what was exported. It was then impossible to export a mesh and guarantee that 
the state would be the same when reading it back; which led to horrible hacks 
for partitioned (distributed, parallel) meshes, periodic conditions, mesh 
reparametrization, etc. Worse yet, physical groups were handled as attributes 
at the element level, meaning that an element could not belong to more than one 
group: new elements (with the same connectivity but a new tag) were created in 
that case *during file export*, which in effect created a completely new mesh.

MSH 4 gets rid of all these hacks by simply exporting the mesh *as is*: tags 
are not modified, groups are just "grouping" entities and not creating new 
elements, the classification of nodes and elements on geometrical entities is 
saved, etc. In addition to the massive performance boost, MSH 4 thus allows to 
keep a consistent representation of the mesh with all the topological and 
geometrical information necessary to reuse the information for further 
processing.

PS: We had an internal debated about setting Mesh.SaveAll=1 by default in Gmsh 
4. At the end we decided against it, as it would break the workflow of many 
applications which rely on only saving parts of the mesh.

Christophe




> and again, what do RenumberNodes and RenumberElements do?
> 
> --
> jeremy theler
> www.seamplex.com
> 
> <tmp.geo><tmp.msh>_______________________________________________
> gmsh mailing list
> [email protected]
> http://onelab.info/mailman/listinfo/gmsh

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

Free software: http://gmsh.info | http://getdp.info | http://onelab.info


_______________________________________________
gmsh mailing list
[email protected]
http://onelab.info/mailman/listinfo/gmsh

Reply via email to