[Gmsh] node and element sparsity in msh4

[Christophe Geuzaine]

> On 16 Sep 2018, at 04:04, jeremy theler <jeremy at seamplex.com> wrote:
> 
> 
>>> I would need to know the biggest tag of the nodes or elements
>>> before
>>> readuing them, not just the number of non-zero elements. Otherwise
>>> I
>>> need to either double-parse the file or reallocate the array each
>>> time.
>> 
>> No: you need some temp buffer for reading the raw data anyway (it's
>> mixed int/float data and might have to be swapped). So just keep
>> track of (tag,vertex) pairs in a vector while reading like we do in
>> the reference GModelIO_MSH4.cpp implementation; then create the array
>> (or map if too sparse) for indexing once you've read the vertices.
> 
> Yes, this is my current approach (since your last email) but this
> requires an extra loop over the nodes/elements. If I had it beforehad I
> can create the map while reading the node/element data in a single
> loop.

OK. We have created an issue to track all suggestions for a future revision of MSH4:

https://gitlab.onelab.info/gmsh/gmsh/issues/444

@everybody: don't hesitate to add your own comments/suggestions in there.

We want to make this format as easy to use as possible, while supporting all the features needed by Gmsh (model topology, geometry parametrization, distributed meshes, etc.) and maintaining excellent performance.

Christophe


> 
>> We could indeed add min/max vertex/element tags in the section header
>> in a future revision of the format. Such a revision will include
>> 
>> - changes based on user feedback
>> - additional features for high-performance parallel IO (MPI IO)
>> - ability to use 64 bit node and element tags (for very large meshes)
>> - reworked post-processing fields with the ability to choose float
>> size
>> 
>> We could include an option to renumber *based on physical
>> definitions*, i.e. we could renumber all the nodes/elements that are
>> needed by physical groups first, followed by all the other
>> nodes/elements. Not sure if it's worth the hassle though?
> 
> No, it won't make any difference as if there is one combinations of
> options that lead to sparse indexes my parser should be able to cope
> with them anyway. But an early indication of the non-zero entries lead
> to a better implementation.
> 
> Regards
> --
> jeremy theler
> www.seamplex.com
> 
> 

— 
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