[Gmsh] notes on the file format

Nico Schlömer nico.schloemer at gmail.com
Tue Mar 14 12:39:55 CET 2017


Hi everyone,

Since I've come to tinker with Gmsh once again lately, I've had to deal
with the shortcomings of the format as well. I've found the format hard to
work with for one particular reason: The element table has no fixed size
element types are mixed and tags are provided with the element. A better
design would be to separate the elements by type, e.g.,
```
$Elements
1 # type
777  # number of elements to follow
...
$EndElements
$Elements
2
6131
...
$EndElements
```
and the list the tag separately, e.g.,
```
$Tag
"physical"
1  # entitiy type
5613  # number of entities
<list of indices>
$EndTag
```
This would avoid having to iterate through the file line by line and apply
some logic every time anew. One could rather read (and write) an entire
dataset en bloc, making I/O much more efficient.

Besides, I suppose the "index" variable in nodes and elements could be
omitted -- the information is already given in terms of the order.

Anyhow, I realize that modifying a format is a virtual impossibility, but
if that ever happens, considering the above points would potentially make
processing the data easier. Even better of course would be to use an
existing mesh format by default [1].

Cheers,
Nico

[1] https://xkcd.com/927/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://onelab.info/pipermail/gmsh/attachments/20170314/e2486f92/attachment.html>


More information about the gmsh mailing list