more streamlined handling of point and cell data

[nschloe]

For mesh formats that can only write one point/cell data array of int data, unconditionally pick the first one found and warn if there are more candidates.

[tianyikillua]

Yes I see your approach here. We all assume that there may exist several int dtyped point or cell data in the mesh (say a user defined a point array as the number of cells that each point is connected to), and you use the first one as the tag for interoperability.

Actually I still prefer maintaining a list of these official tag data for each format, since explicit is better than implicit

• Either really provide a global list of these keys
• Either point mesh.point_tags to a particular data array

[nschloe]

Actually I still prefer maintaining a list of these official tag data for each format, since explicit is better than implicit

But that is implicit, too. The user never sees the "official tag list", it's a member of some function or class. When she writes a file, it's completely unclear why one set has been selected instead of another.

The way we have it right now, at least we have a warning about it. If the user thinks it's the wrong cell_data written out, she needs to provide only one cell_data item. That's as explicit as it gets.

[tianyikillua]

Okay. So I suppose currently for practical use we must save "gmsh:physical" first in the cell_data?

Do you plan to add a test file for testing interoperability?

Also the MED format needs to be included. It's by far the most comprehensive format: point / cell data as well as point / cell tags are supported.

What about exposing the mesh.*_tags attributes?

[nschloe]

So I suppose currently for practical use we must save "gmsh:physical" first in the cell_data?

If you want "gmsh:physical" to be saved, then I suggest this to be the only cell_data you pass.

Do you plan to add a test file for testing interoperability?

We can do that.

What about exposing the mesh.*_tags attributes?

Do you mean *_sets? (Otherwise I don't know what you mean.)

[gdmcbain]

So I suppose currently for practical use we must save "gmsh:physical" first in the cell_data?

Actually for practical use downstream when reading Gmsh MSH 4.1, I recommend users ignore "gmsh:physical" and instead read .cell_sets, or rsther .cell_sets_dict.
I don't know how to deprecate the old behaviour; it's part of the value of an attribute.

The complication is Gmsh version.. This is only for reading MSH 4.1, which is genersted by default by Gmsh 4. Older Gmsh can't generate MSH 4.1, only MSH 2.2. I believe Gmsh 3 is still distributed by a number of Linux package managers.

It would be easy enough to populate the .cell_sets` on reading any format with a simple cell-colouring (Gmsh's MSH 2.2, MEDIT, …), just with a bit of redundancy.

But what about attempting this in the property .cell_sets_dict? Should this dig into .cell_data for int-valued colourings?