Meshset gets mutated during H5M write and load

[Former user]

In our use case we build MOAB meshes and persist them in H5M format files. We also make use of meshsets and parent/child relationships (e.g to encode model topology information).

In this particular case we are experiencing a problem of a meshset having different entities before and after H5M writing/loading. ​ Please find the snippet to reproduce the problem attached reproduce.cpp. Overview of the steps:

1. Load sample mesh original.h5m (find attached) as moab::Core orig_mesh.
2. Copy part of the mesh {vertices, faces, and a meshset containing faces} to a new maob::Core new_mesh mesh.
3. Write the copied mesh new_mesh to a H5M format file "new.h5m".
4. Load the newly serialized "new.h5m" into a third new mesh moab::Core *test_mesh.
5. Compare coordinates of faces belonging to a meshset in new_mesh and test_mesh. This comparison results in meshsets having one different face.

Run the reproduce.cpp:

g++ reproduce.cpp -g -I/opt/moab/include -std=c++11 -L/opt/moab/lib -liMesh -lMOAB -o reproduce
# Make sure you have `original.h5m` in the current working directory
./reproduce

The original.h5m was produced using the increased poly sequence size

const EntityID SequenceManager::DEFAULT_POLY_SEQUENCE_SIZE = 256 * 1024;

as suggested in the issue #99.

We discovered this problem because we are using face meshsets to store mesh surfaces and visualize them. The visualization of the face meshset of new_mesh and of test_mesh are also attached as "sphere-surface-from-memory.png" and "sphere-surface-from-h5m.png".

We are using the current head of the master branch (commit ef8e6de260eaa708b3ca4bfaf2624224f9e6f0cf).

Let us know how we can help further.

[Iulian Grindeanu]

Thanks for pointing this to us; It is (again ) a bug related to ordering of polygons in memory; their internal order does not correspond to creation order;

Until we fix this, another solution (in short term), besides increasing the DEFAULT_POLY_SEQUENCE_SIZE , is to generate triangles and quads instead of polygons, if possible; that would allow for a better match between internal order and creation order;

Issue110 > diff -rpu reproduce_org.cpp reproduce_fix1.cpp
--- reproduce_org.cpp   2019-09-01 07:21:12.082346997 -0500
+++ reproduce_fix1.cpp  2019-09-01 07:24:46.176353159 -0500
@@ -64,6 +64,10 @@ std::map<moab::EntityHandle, moab::Entit
         for (auto i = 0; i < src_face_vertices.size(); i++) {
             new_face_vertices[i] = src_vtx_to_new_vtx.at(src_face_vertices[i]);
         }
+        if (3==src_face_vertices.size())
+            face_type=moab::MBTRI;
+        else if (4==src_face_vertices.size())
+            face_type=moab::MBQUAD;
         check(dst_mesh->create_element(face_type, new_face_vertices, src_face_vertices.size(), new_face));
         src_face_to_new_face[src_face] = new_face;
     }

[Johannes Probst]

Hi Iulian, thanks for your reply! I’m glad you were able to reproduce the problem on your side.

We have taken a look at your suggestion and we see that this would basically mix triangles, quadrangles and polygons in the same mesh. There is some code on our side which relies on the fact that the mesh is either purely polyhedral, or purely “FEA style”. Since we’d like to use MOAB as a long-term mesh storage format we’re afraid that the persistent nature of the solution would force us to modify this logic to deal with mixed entities and maintain it forever. Also, if I understand correctly, it would only delay the problem to higher counts of polygons (i.e. bigger meshes). Since we’re worried that this will cause problems again in the near future we prefer to wait until there is a proper fix.

Are you planning to bring a definitive fix in MOAB in place? The reason I’m asking is that this bug is holding us back from releasing a bigger change in our system’s architecture which is to use MOAB for long-term mesh archiving for all types of meshes. Right now we cannot use it for polyhedral meshes because of the issues we’ve encountered.

[Iulian Grindeanu]

Yes, of course we would like to fix the underlying issue; what I suggested is only another temporary fix; and yes, the bug will resurface for higher counts; What is your timeframe for release ?

Polyhedral meshes can still use triangles and quads as faces, can’t they ? Are we making any assumption about faces of a polyhedra? Or are you relying in your code about the type of faces ?

thanks again for reporting the bug!

[Johannes Probst]

Hi Iulian, thanks for your prompt response!

Our plan for releasing this is the end of September (i.e. in about two weeks). At the moment we have the system in a somewhat hybrid state where MOAB is used for all FEA-like meshes but not for polyhedral. The rest of the system is in readiness for the release on polygons as well, we basically just need to flip a switch.

You’re right, in principle a face is a face. We have quite a lot of code where we make quite rigid assumptions, though (so as to avoid bugs). At the moment we treat every mesh which isn’t purely polyhedral, or purely FEA-zoo as an error.

Also there is quite a lot of code which generates metadata (e.g. quality metrics) where the numbers would be skewed if the faces had different type. As an example, we track the quality separately for triangles, quadrangles and polygons, and expect to have either one or the other.

[Iulian Grindeanu]

https://bitbucket.org/fathomteam/moab/pull-requests/434/fix-for-issue-110/diff

please see this PR; it should fix the issue

[Johannes Probst]

Hi Iulian! Thanks for the quick fix!

We’ve integrated the patch already and are running our tests against it right now. We’ll let you know what we find out.

‌

[Johannes Probst]

Hi Iulian. We have meanwhile tested the fix and it seems to work well. I have approved the PR.

[Vijay M]

@Iulian Grindeanu I assume this issue has been resolved. If so, please mark it as completed.

[Iulian Grindeanu]

resolved by https://bitbucket.org/fathomteam/moab/pull-requests/434/fix-for-issue-110/diff