h5m: Multiple groups of same type

[Nico Schlömer]

The H5M spec) says about element groups:

The names of the subgroups are application defined. MOAB uses a combination of the element topology name and connectivity length (e.g. "Hex8".).

Question: How do you handle multiple element groups of the same type?

[Iulian Grindeanu]

I do not understand the issue. Can you give an example? Connectivity is usually handled by reader/writer. for VTK or Abaqus format Hex20 might have different conversion tables, but they internally (in h5m) are represented using MOAB convention. And they do represent the same element type. So for what element type / reader-writer combination you would have multiple (different) element groups ?

[Nico Schlömer]

Can you give an example?

Yup. Suppose you have mesh with 6 points and three cells, in order:

• triangle (0, 1, 4)
• quad (1, 2, 3, 4)
• triangle (1, 4, 5)

How is this represented in an H5M mesh?

The apparent problem: There can be only one `TRI3` cell block since names are unique in H5M.

‌

[Iulian Grindeanu]

it is just one group of Tri3 in h5m format; they have the same size of connectivity (3 vertices); Is that a problem ?

[Vijay M]

In MOAB, we also have an additional grouping using sets. You can have triangle1 in set1 and triangle2 in set2 or the union of it etc. So while the cells with same size connectivity belong to a block, TRI3 in your example, you can have different sets for additional grouping internally in case that helps. If this is not what you want either, then perhaps a better explanation of the context would help.

[Nico Schlömer]

Is that a problem?

Well, it’s that most mesh mesh formats permit this kind of cell grouping. If H5M doesn’t, it’s impossible to round-trip mesh format conversion, e.g., VTK->H5M->VTK and get the same mesh out that you put in. This causes problems like this one here.

In MOAB, we also have an additional grouping using sets.

Sets are an additional thing that most mesh formats have and that H5M is able to represent.

I was wondering about this because I thought that the categorized cell block naming (TRI3, QUAD4 etc.) is unnecessary. You could just name the cell blocks anything, cause after all the cell type is given as element_type in the subgroup anyway.

[Vijay M]

You can do a single pass to accumulate all elements of the same type to dump out h5m in one shot, but I do agree that exact grouping preservation will get lost if different triangle elements are in different blocks in the original format. Changing the format to accommodate this may be non trivial in addition to being backwards compatible. However, in the particular issue you pointed out, does the user want this exact preservation for the simulation to work correctly? The topological adjacencies should get deciphered correctly with the current h5m format anyway, and if doesn't, then that's a bug on our side.

[Vijay M]

I think the original layout of the HDF5 file was designed with I/O efficiency in mind so that elements with same vertex sizes can be read in one shot and processed in memory as needed. As you said, there is no reason to stick with TRI3 naming and it could have been arbitrary like Netcdf format. Perhaps @Tim Tautges can shed some more light here.

[Tim Tautges]

You should probably read the docs more closely again, esp the one describing the h5m format. The hdf5 writer in MOAB collapses the holes in handle space such that, for any given combination of (type, #vertices), there's only 1 single block of those entities. As Vijay said, if you require different groupings, that's what sets are for. Note that sets by default don't preserve order, and only allow one occurrence of a given entity per set. If you want order preserved and/or multiple inclusion, use a vector-type set.

• tim

[Nico Schlömer]

@tautges Just for context: I’m trying to round-trip VTK->H5M->VTK, preserving the cell order. VTK allows for arbitrary cell orders, e.g., tri-quad-tri is no problem (as do most mesh formats).

Trying to get this done with sets is perhaps possible, but seems clumsy.

The hdf5 writer in MOAB collapses the holes in handle space such that, for any given combination of (type, #vertices), there's only 1 single block of those entities.

Well, one easy solution to my problem were if the MOAB’s reader instead of the writer could do the collapsing.

@vivay

Changing the format to accommodate this may be non trivial in addition to being backwards compatible.

Are you sure? It seems to me that dropping the meaning of the block names would be easy and perfectly backwards-compatible. In fact, I’d be be surprised if this value is used anywhere now (instead of element_type).

Anyway. As a workaround, I’ll just error out in meshio if there’s more than one cell block of the same type. This limits the usability of H5M somewhat, but that’s the way it is.

[Vijay M]

Well, one easy solution to my problem were if the MOAB’s reader instead of the writer could do the collapsing.

It is inappropriate to make such an assumption when reading, unless we add some user-defined explicit flags to enable this. Most often, users will want what is exactly in the mesh file to be represented in memory and performing some magic transformations during I/O may add to loss of reproducibility. This is not necessarily the case when writing.

Are you sure? It seems to me that dropping the meaning of the block names would be easy and perfectly backwards-compatible. In fact, I’d be be surprised if this value is used anywhere now (instead of element_type).

Anyway. As a workaround, I’ll just error out in meshio if there’s more than one cell block of the same type. This limits the usability of H5M somewhat, but that’s the way it is.

I can take a look at it to see if there is a relatively easy fix for it.

[Vijay M]

One other thought comes to mind. @Iulian Grindeanu can we more generally support NO_MIXED_CELLS option for h5m mesh reads as well? What this option does currently for NetCDF reader is that it takes say pentagons and hexagons in a polygonal mesh and expands them out in a single sequence, instead of having a separate one for pentagons and hexagons. Would that technically solve the issue here, ?

‌

[Iulian Grindeanu]

one problem with this example (https://github.com/nschloe/meshio/issues/1246) is that it is a gmsh format version 4.1; we do not support it currently; we also never quaranteed ping-pong (back-and-forth) conversions would give the same mesh;
NO_MIXED_CELLS option makes sense for polygons only, using it there would not change the order of the polygons only;

‌