Logic problem in CUB file reader around reconstruction of geometry

[Former user]

When reading a Cub file, if the user/developer does NOT request that the geometry be read, there should be no attempt to load and reconstruct the geometry/topology.

As reported by Lukasz Kaczmarczyk [e-mail]

I have a strange problem with the reading file test_mesh_cut.cub. Mesh is ok, I can process it. The issue is with the error.

Code:

const char *option;
option = "";
moab.load_file(mesh_file_name, 0, option);

Is this problem with the file or something related to a cubit. The problem appears for v5.1, for older versions seems to be ok.

Regards, Lukasz

129: [0]MOAB ERROR: --------------------- Error Message ------------------------------------ 129: [0]MOAB ERROR: Failed to join the obb trees! 129: [0]MOAB ERROR: construct_obb_tree() line 502 in src/GeomTopoTool.cpp 129: [0]MOAB ERROR: --------------------- Error Message ------------------------------------ 129: [0]MOAB ERROR: Failed to construct obb tree for volume! 129: [0]MOAB ERROR: construct_obb_trees() line 606 in src/GeomTopoTool.cpp 129: [0]MOAB ERROR: --------------------- Error Message ------------------------------------ 129: [0]MOAB ERROR: Error: Failed to rebuild obb trees! 129: [0]MOAB ERROR: GeomTopoTool() line 90 in src/GeomTopoTool.cpp 129: [0]MOAB ERROR: get_senses() line 1075 in src/GeomTopoTool.cpp 129: [0]MOAB ERROR: get_senses() line 1075 in src/GeomTopoTool.cpp

129: [0]MOAB ERROR: get_data() line 277 in src/DenseTag.cpp 129: [0]MOAB ERROR: get_data() line 277 in src/DenseTag.cpp 129: [0]MOAB ERROR: get_data() line 277 in src/DenseTag.cpp 129: [0]MOAB ERROR: get_data() line 277 in src/DenseTag.cpp 129: [0]MOAB ERROR: get_data() line 277 in src/DenseTag.cpp

[Paul Wilson]

(It was actually me that reported this issue!)

Here is some follow up

We may need to revisit some of the logic of the Cub file reader. These errors imply that MOAB is attempting to process a geometry representation in addition to the mesh representation.

Prior to more testing, I can't tell if this is because:

a) Your options don't request that the geometry representation be loaded from the file, but MOAB tries to process the geometry anyway, or

b) The geometry representation is being loaded (although I think your choice of options should be preventing that), and the presence of sheet bodies in your model is causing the geometry processing to fail.

[Karol Lewandowski]

Paul, do you have any suggestions of the options that should be used to prevent that geometry loading? I’ve searched through available options and I could not find anything suitable.

Thanks

[Paul Wilson]

I think this will be fixed by PR #473

‌

[Vijay M]

@Paul Wilson Can I close this issue ?

[Paul Wilson]

I think it is resolved by PR #473, but perhaps others who reported the error (@Karol Lewandowski or Lukasz Kaczmarczyk [e-mail]) should confirm?

[Vijay M]

@Lukasz Kaczmarczyk @Karol Lewandowski can you confirm if this is resolved ?

[Karol Lewandowski]

I will let you know when I install moab v5.1.x with spack

[Vijay M]

I think spack is behind and the installation may be broken. We have a PR in spack to update the builds to 5.2.1. @Iulian Grindeanu can you update us when that gets merged to spack develop ?

[Lukasz Kaczmarczyk]

@Karol Lewandowski Let me know when you need help with that. We can install in spack particular branch for MOAB from scratch, I can help you how.

[Iulian Grindeanu]

@Karol Lewandowski @Lukasz Kaczmarczyk Do you have an example cubit file that you cannot process now ? Can you attach it ? Also, I have added an option to skip topology generation part; I think that part was having issues; that I cannot reproduce now; this branch is not merged yet to develop, maybe it will not be necessary in the end;

https://bitbucket.org/fathomteam/moab/pull-requests/510

[Karol Lewandowski]

I can confirm that this has been fixed. I checked with version 5.2.1

[Vijay M]

Thanks for confirming that v5.2.1 fixes the problem