1. SIGMA Avatar SIGMA
  2. Components
  3. MOAB
  4. Issues

H5M save and load leads to duplicated entities across sets

Issue #99 closed
Johannes Probst created an issue

Our application builds a mesh in MOAB and stores it as H5M. In order to encode model topology information in the mesh, we are using sets and parent/child relations. Amongst other sets, there are 2 notable sets which are supposed to be disjoint and contain the elements belonging to separate bodies.

These 2 sets are the direct children of a set which has a tag named "SIMSCALE_IS_MASTER_REGION_SET".

When we load the H5M file again, we sometimes find that these 2 sets are not disjoint anymore. The overall number of cells in the mesh does not change, though.

So far we have found two examples, both of which are attached. Please note that these are the meshes after writing and they may seem as if it was intended to have overlapping sets. The intersection of both sets should be empty and we have verified that it is empty before writing out the H5M file. We have also add assertions to make sure we're not adding any elements to the set twice. The sets are not of list type. We are accessing MOAB through the iMesh C interface.

We are using a very recent MOAB version (current tip of master as of writing this, revision fa8bb4ff475db377967b31699ef5473ddcf5c3b7) on Ubuntu Linux 16.04, built with HDF5 1.8.16.

If there is any way how we can provide more information, please let us know.

Comments (26)

  1. Johannes Probst reporter

    If h5mvalidate (verbose mode on) is run on the file twoboxes.h5m, it prints "Set 8 (ID 118203) is not ordered but contains duplicate handles. 1 unordered sets had duplicate IDs in their content lists."

    I believe this should be impossible to achieve through API calls. There might be a bug in the implementation of sets, either on the serialization or deserialization. Unfortuately I am unable to pinpoint the issue more exactly.

  2. Vijay M

    Thanks for drilling down on the issue. We are getting ready for a release but I'll get to this once that's done. It is possible that something is not implemented correctly in the iMesh interface rather than the MOAB implementation since we would have caught such inconsistencies quicker. Either way, I will keep you updated on what I find.

  3. Johannes Probst reporter

    Thanks for your reply! I understand that you're busy getting the release done right now. If there is anything I can do to assist in the meantime, or if you have a good place for doing some investigations, please let me know - I'm happy to contribute.

  4. Vijay M

    It would be helpful to have a standalone small example to replicate the issue using say two meshes loaded on filesets and parent/child relations defined on them before writing back to a single file. It is possible that the parent/child entity relations are not preserved or propagated when writing and reloading files through the iMesh workflow. @iulian07 thoughts ?

  5. Iulian Grindeanu

    hello, I see some inconsistencies;
    can you explain the order in which the polygons and polyhedrons are created in MOAB database? Or the methods used? Do you create the elements one by one or in blocks by number of vertices for polygons, number of faces for polyhedra?

    The entity handle space for polygons and polyhedra is divided by number of vertices/faces; the handle space gets divided / assigned in the order they were created; so it could be that a polygon with 3 vertices has an entity handle higher than a polygon with 4 edges; basically, every time a new polygon with 3 vertices gets created, it checks if it has enough space in a sequence previously assigned for polygons with 3 vertices; if not, creates a new sequence, that can be after other sequences of polygons with 4 or 5 vertices; the polygon entity type is 4, so all polygons start with "4" in the first 4 bits (0100); when we write the file, we collect all sequences of polygons with 3 edges, and put it in one dataset in hdf5; we do that with all types; your model has polygons of 3,4,5,6 vertices, and polyhedra of 12, 15, 5, 6 and 9 faces ; in the file the "start id" of each is where the previous gathered sequence ended;

    My guess is that there is some bug when we gather all polygons of a specific type, and then write to the file; It will be hard to reproduce with a small model, because probably the bug appears when the sequences of 3, 4, 5, 6 -vertex polygons are interlaced

    the bug is probably in the hdf5 writer; can the code that creates the mesh in moab be shared somehow? Again, the order in which the elements are created is important, and probably the bug will not show up if you create first all polygons of size 3, then 4, etc;

  6. Iulian Grindeanu

    Hi Johannes, Can you try to set the default sequence size for polygons/polyhedra higher? For example, instead of const EntityID SequenceManager::DEFAULT_POLY_SEQUENCE_SIZE = 16 * 1024; in the file src/SequenceManager.cpp

    can you increase that to let's say const EntityID SequenceManager::DEFAULT_POLY_SEQUENCE_SIZE = 256 * 1024; ?

    If the errors are not there anymore, it would confirm that the problem is in hdf5 set writing

    please let us know ;

  9. Johannes Probst reporter

    Hi Iulian and Vijay thanks for your responses! I have verified that the issue still exists in the current tip of master (7bde9dfb84a8cbeb5a748f43150699d9988df6be) and in fact, it disappears with the change proposed by Iulian.

    In SequenceManager.cpp:25, I inserted 

    const EntityID SequenceManager::DEFAULT_POLY_SEQUENCE_SIZE = 256 * 1024;

    The new H5M file is uploaded (it corresponds to the previous test file "twoboxes.h5m").

    The mesh was created by importing a polyhedral mesh from OpenFOAM to MOAB. The outline of the code is roughly like this:

    • Create the set tagged SIMSCALE_IS_MASTER_REGION_SET
    • Create all tags
    • For each "region" (in our terms, this corresponds to a body, or a part in the mesh. A contiguous part of the space which is filled with material) in the mesh, create an empty entity set ("region set") and make it a child of the SIMSCALE_IS_MASTER_REGION_SET
      • Create the vertices (iMesh_createVtxArr) and add them to the region set
      • Create the faces using their corner vertices (iMesh_createEnt(POLYGON, vertices)) and add them to the region set
      • Create the cells using their faces (iMesh_createEnt(POLYHEDRON, faces)) and add them to the region set
      • Create a set for the boundary faces of the region, add the boundary faces and make this set a child of the region set

    All entities are created in the same order as they appear in the source files. There is no particular ordering - the entities are created one by one in the order they appear in the files. I have also uploaded the original mesh in OpenFOAM format.

    I'm glad to see this issue moving forward :) Please reach out if I can contribute, or if you have questions.

  10. Iulian Grindeanu

    Thanks Johannes for your help;

    I assume that you also need to keep a local array for vertices and polygons (from local index to the iMesh entity handle ), and for polyhedra too.

    While changing sequence size works for a small problem, it will not work in general; I have a good idea where the bug is, but it will not be an easy solution;

    Having a converter from OpenFOAM to moab would be very nice, it would absolve you of writing this code.

    if you write each body in a separate file, and then you merge the files using mbconvert, do you still see the errors in the region sets? Of course, you will not have then the parent-child relationship between the master region set and region sets; but maybe you will still see the errors (maybe even with the new sequence size :( ? )

    This would help us in setting up the test on our side, if you can upload a separate file for each body, and if the error is reproducible.

    If not, how hard would be for you to share the original code, that reads the OpenFOAM mesh and writes the h5m file? Is it hard to extract from your application? It could become a OpenFOAM reader in MOAB in the long term, which would be nice to have :)

  11. Johannes Probst reporter

    Iulian, you're welcome. Always here to help! What you surmised is correct, there are several "bookkeeping" arrays and maps which keep track of everything. Those might allow me to sort the elements like you suggested earlier (I still have to double-check this).

    I know how important it is to reproduce a bug locally and I'd love to share the OpenFOAM converter if it were possible. Unfortunately it is not compatible out of the box with MOAB's source code because it's written in Go and there are some licensing issues as well since it depends on some restricted third-party libraries. It would be a bigger refactoring.

    I'll try the experiment with merging the files using mbconvert tomorrow.

  13. Johannes Probst reporter

    After several attempts I have now found a way to reproduce the bug on your end.

    Using the workaround suggested by Iulian (increase the poly sequence size), I was able to create an H5M file which is correct and contains an extra tag named "ORDER" which corresponds to the order in which the entities were created. It is uploaded under the name only-polygons-with-fixed-moab-and-order-tag.h5m.

    To reproduce the bug, I have written a C++ program which reads this file and copies the entities, using the ORDER tag, to a new mesh and saves it to disk. If this is run with a recent MOAB version 5830e8eb5757d081dcf17cc82d6ec4b91bea9fa4, the new H5M file will contain the problem (h5mvalidate complains about an invalid set, as above).

    The source code of this program is attached (reproduce.cpp), as well as its input file (only-polygons-with-fixed-moab-and-order-tag.h5m). The result broken.h5m is also attached, for completeness.

    Compile with g++ -g -I/opt/moab/include -std=c++11 reproduce.cpp -L/opt/moab/lib -liMesh -lMOAB -o reproduce.

    It takes no arguments and expects the file only-polygons-with-fixed-moab-and-order-tag.h5m in the current working directory (the filename is hardcoded in the application). It writes a file broken.h5m to the current working directory which fails in h5mvalidate with

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

    To keep the program minimal and simple, the filenames are hardcoded and no memory management is done. I hope this doesn't cause too much inconvenience.

    The mesh contains only polygons (polyhedra seem not to be necessary).

    Please let me know if you were able to reproduce the bug. Should you have any questions, feel free to reach out.

  14. Iulian Grindeanu

    Thanks Johannes; I am able to run your code, and reproduce the bug; It is very helpful to be able to reproduce it in our environment; indeed, the order elements are created is important

    I will let you know when we have a fix

  17. Johannes Probst reporter

    Hi Iulian

    I have just rebuilt MOAB with your changes and tested it. I observed that the original problem which led us to the discovery of the bug (having duplicate cells across sets) has disappeared. That's great news!

    I also tested with the reproduction method described above and ran the result through h5mvalidate with the result that it still reports "1 unordered sets had duplicate IDs in their content lists." The result (broken-after-edd9ba.h5m) is attached for your convenience.

  19. Iulian Grindeanu

    ok, thanks;

    the second set is still wrong, it is missing some polygons with 5 vertices, while some polygons with 4 vertices are duplicated

  23. Iulian Grindeanu

    I am glad it works, thank you for your help! We will merge the branch to master soon, after the PR is reviewed

  27. Log in to comment
Assignee
–
Type
bug
Priority
major
Status
closed
Component
–
Version
5.0.0
Votes
2
Watchers
4