Allow OBBs to be recovered from file

Issue #74 new
Paul Wilson created an issue

Although the OBBs are written to an H5M file when they exist, there is no way to recover them when reading a file. This breaks a performance benefit of reading a file that has OBBs when it was expensive to generate the OBBs.

In prior versions of DAGMC, each geometry set was tagged with the EntityHandle of the OBB root, allowing this data to be recovered.

This should be added again in GTT when OBBs are generated, and then also in the GTT initialization process (find_geomsets??), and possibly in add_geo_sets.

Comments (12)

  1. Patrick Shriwise

    I've been thinking about this a bit and I'm still a little torn as to whether or not this should be a supported feature.

    We've encountered problems in the past with mesh modification on a file with an OBB tree making the existing tree invalid and subsequent queries on the tree questionable. It may be better to always require trees to be built at runtime.

  2. Patrick Shriwise

    Another option could be to provide some kind of validation tool which would:

    • ensure that all entities are accounted for in the tree leaves for the meshsets that are a part of the tree (volumes and surfaces)

    • verify that each leaf box contains the mesh entities it is supposed to

  3. Paul Wilson reporter

    This capability has saved countless CPU hours especially for work with geometry duplication. I think we need to rely on user wisdom unless we have another solution.

    Would any of the validation options you mention be faster then rebuilding the tree?

  4. Patrick Shriwise

    I suppose that's true wrt the geometry duplication. It seems that it might almost be best in that case to write a temporary file, clear out the master instance, and load the temporary file into all processes, but that's maybe a separate matter.

    Naively, I would say that yes the validation options would be faster than rebuilding the tree, which is an O(N log N) process. The validation would, I think, be an O(N) process with a little bit of additional time tacked on to get to the leaves of the tree, but that should be small as no tests are really being performed when visiting interior nodes.

  5. Paul Wilson reporter

    This needs:

    • a new OBB_ROOT tag that allows each volume or surface set to be tagged with the EntityHandle of its OBB Tree Root at the time the tree is built
    • a new method upon reading a file that repopulates GTT::rootSets or GTT:mapRootSets
      • this needs to be done carefully to be sure we restore all the necessary data structures, but probably simple (set_root_set)
  6. Paul Wilson reporter

    (Tagging @cadangelo for her benefit/opinion)

    The biggest question may be decided how this is invoked. Currently, the GeomTopoTool constructor has an option to find and reconstruct data structures for geometry sets from the current MOAB instance. Perhaps this capability should be similarly invoked. In fact, it might only make sense to do it if that option has also been invoked?

    if (find_geoments) {
        find_geomsets();
        if (restore_obbs) {
           restore_obb_index();
       }
    }
    
  7. Chelsea Dangelo

    I agree with @pshriwise that the safest, and therefore default, option should be to rebuild the tree at runtime, but it's also important to give the option to recover the obbs. I like this option to restore the obbs only if the geomsets have been recovered. We can add in a check for the OBB_ROOT tag on all the geomsets. If all geomsets have the tag, we can repopulate the GTT::rootSets or GTT:mapRootSets.

  8. Paul Wilson reporter

    Any time we rebuild trees, we should be sure to delete any old trees and cleanup properly. I see a few options:

    • build all trees (after deleting existing trees)
    • check for missing trees and

      • build missing trees only
      • build all trees if any are missing (after deleting existing trees)
    • restore trees from tags

    Which of these should we be supporting? Others?

  9. Patrick Shriwise

    @gonuke I think you laid it out nicely. The only thing I'd guard against is a partial recovery of the trees, so I'm in favor of "building all trees if any are missing" over "building missing trees only". IMO it should be all or none.

    FYI this still may not fix issues we've seen in the past where the mesh is modified by other applications (make_watertight) and invalid OBBs are written to file. Because we are choosing to not check the validity of existing trees here, those applications should be responsible for removing any spatial data structures like this or writing only geometry sets to the new file. (Unless some kind of validity check is intended for the restore_obbs process.)

  10. Chelsea Dangelo

    The safest option is to rebuild everything if any are missing. I'm not sure how often it will occur, but in the case of combining geometries (like we did for NASA- adding hab + phantom + Mars), it could be nice to have the option to build missing trees if some pieces already have obbs and others do not. If we are doing a partial rebuild, we have to consider: 1) if a missing surface obb is being built, also delete/rebuild its parent volume obb and 2) delete/rebuild the implicit compliment obb.

  11. Paul Wilson reporter

    We can just decide to only do full rebuilds for the time being and document why we don't do partial rebuilds. it is definitely the easiest choice and probably covers most cases with the most robust solution.

  12. Log in to comment