Writing and loading H5M breaks polygon sets

We have discovered one case where MOAB seems to write out broken sets to the H5M file. We discovered this bug when investigating some issues in our visualization pipeline. In the case of one polyhedral mesh with 3 spheres, we observe holes in the visualization of one hemisphere (see the picture attached).

Our tests showed that the bug appears only if the mesh is written to the disk as H5M and read back. If the mesh is kept in memory, the issue does not appear.

The file fails in h5mvalidate with

Set 1 (ID 419398) is not ordered but contains duplicate handles.
1 unordered sets had duplicate IDs in their content lists.

This bug seems similar to Issue 99. We have also tested the suggestion of increasing the poly sequence size using

const EntityID SequenceManager::DEFAULT_POLY_SEQUENCE_SIZE = 256 * 1024;

and this makes the issue disappear.

Using this workaround we were able to generate a H5M file which is error-free (we also verified that it is visualized correctly by our pipeline). To enable you to reproduce the bug, we also implemented a C++ application, similar to the last one, this time without iMesh but directly calling the native MOAB C++ interface. It reads the correct H5M file, copies the entities and sets using the "ORDER" tag, and writes the result back.

The application is attached as main.cpp and can be compiled with g++ -I/opt/moab/include -std=c++11 -L/opt/moab/lib main.cpp -lMOAB.

It expects a file named "spheres.h5m" in the current working directory (also attached) and writes a file "mesh-copy.h5m" (also attached) which contains the problem.

This was tested with commit 78d0b938fcf80fcdfb34fa39583fbce544b56953 (tip of master as of writing this).

Comments (5)