Feature/gunney/extend klee geometry

[gunney1]

Summary

• This PR is a (work-in-progress) feature.
• It does the following:
  • Introduces a conduit::Node for internally storing geomety data and allow for new geometry formats and information without further changes to the code. Currently, this information is stored in a variety of objects:
    1. primal geometries (Tetrahedron, Hexahedron, Sphere, etc.)
    2. aggregate data for geometries not supported by primal (for example, 2D function and refinement level for surface of revolution)
    3. file names for geometries stored in files (for example, ProE mesh)
    4. sidre::Group and topology name (for geometries stored in blueprint mesh convention)
  • Provides a way to populate, store and access geometry data without requiring numerous accessors and constructors.

Problems with using primitives in Geometry

1. They don't have all the parameters needed for shaping (which is why Geometry has to keep supplemental data).
2. We have to add new primitives and change Geometry to support new shapes.
   For these reasons, primitives will be removed in favor of the hierarchy representation. Geometry is supporting both during the transition.

This is a WIP. It is being used in the on-going work to re-factor and improve clipping performance and may still change to support that goal.

Dependencies

The mesh clipping refactor includes multiple PRs. Please review these before this one.

• Fix crash querying whether an exec space uses an allocator id. #1661
• Extend primal geometries for clipping re-factor #1662

[kennyweiss]

I'm a bit confused by this PR. Is there a reason to store both the geometric primitive, e.g. primal::Tetrahedron and the blueprint representation?

Would it make sense to store just the conduit node and create the primal type on the fly?
(I'm asking because, each Geometry stores at most one of the types, e.g. sphere vs. tetrahedron, but there is a class member for each of the types.

I saw WIP in the description. Are you planning to remove the primitives in a later PR?

[gunney1]

Yes, I plan to remove the primitives later. Primitives don't have enough information and they require Geometry to change each time we add a new shape. Geometry is supporting both during the transition from primitives to hierarchy representation.

[gunney1]

Added this info to the PR summary.

[Arlie-Capps]

I think the design of klee::Geometry can and should be refined. It feels like the class has a lot of redundancy which I'd like to eliminate. I also recognize, Brian, that you wrote it this way to solve specific problems, and I feel like I don't fully understand those issues. Also, this PR is in support of a feature you're highly motivated to make available to a user of Axom.

If you're willing to revisit the design of Geometry, perhaps in conjunction with moving a body of code out of the experimental namespace, I'm willing to defer the discussion of Geometry until that date and approve this PR.

[gunney1]

I think the design of klee::Geometry can and should be refined. It feels like the class has a lot of redundancy which I'd like to eliminate. I also recognize, Brian, that you wrote it this way to solve specific problems, and I feel like I don't fully understand those issues. Also, this PR is in support of a feature you're highly motivated to make available to a user of Axom.

If you're willing to revisit the design of Geometry, perhaps in conjunction with moving a body of code out of the experimental namespace, I'm willing to defer the discussion of Geometry until that date and approve this PR.

@Arlie-Capps, I appreciate your point of view and agree completely. klee::Geometry is transitioning from primal primitives to hierarchy to describe the geometry. I've been wanting to complete the transition, but the performance issues kept preempting it. Let me complete it now in this PR and see how that addresses your concerns.

[gunney1]

I think the design of klee::Geometry can and should be refined. It feels like the class has a lot of redundancy which I'd like to eliminate. I also recognize, Brian, that you wrote it this way to solve specific problems, and I feel like I don't fully understand those issues. Also, this PR is in support of a feature you're highly motivated to make available to a user of Axom.
If you're willing to revisit the design of Geometry, perhaps in conjunction with moving a body of code out of the experimental namespace, I'm willing to defer the discussion of Geometry until that date and approve this PR.

@Arlie-Capps, I appreciate your point of view and agree completely. klee::Geometry is transitioning from primal primitives to hierarchy to describe the geometry. I've been wanting to complete the transition, but the performance issues kept preempting it. Let me complete it now in this PR and see how that addresses your concerns.

As discussed in an email thread with @kennyweiss and @Arlie-Capps, completion of klee::Geometry in this PR would be more work than I think is worth it. It would require fixing some features in mint, fixes that would not be needed after merging the other companion PRs in this task. Therefore, I request that this PR be approved with klee::Geometry still in its transitional state, supporting both primal primitives and hierarchy storage. The transition will be completed after the last PR of this series, #1654.