- don't return silently if errors are encountered when reading a mesh in MSH4
- bug fix in read periodic sections
is there any documentation about version 3 and/or 4?
The current spec for MSH4 is available here: https://gitlab.onelab.info/gmsh/gmsh/wikis/mesh-partitioning
The current implementation is ready for testing - don't hesitate to send feedback.
(MSH3 will never be formally released - it was mostly a test)
Hey @geuzaine I have been reading the msh4 format specification and saw some example output files from Gmsh. I haven't updated my .msh parser to handle this format yet. As far as I can tell, the new format give less redudant information (so the size is slighly smaller), is more flexible when partitioning the mesh (I am not there yet) but the main point is that is enables elements to belong to more than one physical entity, am I right?
On the one hand, msh4 is more compact and flexible. But on the other hand, it is a step closer to the computer and a step away from the human because in msh2 the ASCII files where more or less easy to read. With the new format, all the numbers the information in the header blocks and the node/element definition (i.e. coordinates or node indexes) is mixed up and it is hard to decode by the human.
You requested feedback and that is what I have so far :-)
@jeremy: the main goal for MSH4 is higher performance for large meshes, while keeping the generality of the older MSH formats and a human/debugging-friendly ASCII mode. In our tests MSH4 is now on-par or faster than competing "general" formats like MED or CGNS. MSH4 also fixes the handling of physical groups inherited from MSH1/MSH2 (#94 (closed)), in the same way as MSH3 (which was never documented).
A second goal for MSH4 was to correctly handle the BREP of the model, even for partitioned meshes. The partitioner now creates a self-consistent BREP of the partitioned entities, complete with references to parent entities in the original BREP. This allows to partition/unpartition/repartition a mesh on-the-fly and efficiently access all the required topology information (neighbors, boundaries, etc.) for distributed meshes.
The format is a bit more complicated to read due to the headers (which allow to have homogeneous data blocks that can be read in a single read operation), but once you get a hang of it I find it actually conceptually simpler. It should also be much easier to parse by external codes.