Initial clipping code re-factor

[gunney1]

Summary

• This PR is an initial refactoring of the clipping code in IntersectionShaper.

• IntersectionShaper has 4 significant jobs that make it big and a bit unwieldy.

  1. Clip user-specified geometries against the cells of a mesh to compute overlap volumes. Clipping accounts for more than 95% of the time spent in shaping and is the motivation for the current effort. The intention is to provide fast clipping functionality for IntersectionShaper to use.
  2. Combine overlap volumes using replacement rules.
  3. Support multiple mesh formats (Blueprint and MFEM) stored in multiple hierarchy classes (Sidre and Conduit).
  4. Support multiple execution spaces to be selected by the user at run time.

• This PR

  • Contains the bulk of the refactoring work, introducing key classes and interfaces.
  • Implements the clipping code outside of IntersectionShaper. The idea is to eventually remove the IntersectionShaper's clipping code and use the new clipping code instead.
  • Introduces well-defined interfaces to support shape-specific approaches to improve clipping performance. Clipping involves some shape-specific operations and some common operations. Both have been re-factored to support a variety of potentially faster algorithms.
  • Begins implementing shape-specific clipping approaches. The tetrahedral shape is included here as an example. More will follow in Improve clipping code performance #1654.
  • Provides a mesh wrapper that presents basic and derived mesh data as ArrayView objects, regardless of whether the mesh is Blueprint or MFEM, and stored in Sidre or Conduit. This part is a work-in-progress in that MFEM support has not started.

Completed work

• The MeshClipper class provides the access point for the clipping functionality.
  • MeshClipper::clip computes the overlap volume for every cell in the mesh.
  • The MeshClipper::clip method uses fast geometry-specific operations where they are available and falls back on a general method where they aren't.
  • The general method, discretizing the geometry and checking its discrete pieces against every zone, was taken from the IntersectionShaper. This general method is the only choice when using the current IntersectionShaper.
  • The general method is provided by MeshClipperImpl, a class templated on execution-space . This class contains computeClipVolumed3D, the code taken from IntersectionShaper. The two other versions of this method do the same thing but on a subset of cells or tets (from cells) that excludes those outside or inside the geometry.
• Geometry-specific operations are implemented through the abstract base class MeshClipperStrategy.
  • This is where geometry-specific operations are implemented (if available), such as fast screening operations and specialized clipping code.
    • Screening is the process of determining whether a mesh cell is completely outside or completely inside a geometry. Cells that can be labeled this way are excluded from the much more expensive clipping operation.
    • An example of specialized clipping is for the plane geometry. which takes advantage of its simplicity.
• The ShapeMesh encapsulates the mesh being shaped into. It provides a uniform interface for accessing the mesh data, regardless of whether the data is stored in Conduit or Sidre or by blueprint or (future) MFEM convention. ShapeMesh also computes and caches a variety of mesh-dependent data to amortize their cost among all clipping geometries.
• Test for MeshClipper.

New codes are in namespace experimental, because this is a work in progress.

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
• Feature/gunney/extend klee geometry #1666

[Arlie-Capps]

I found a few typos and unclear spots, a possible data write conflict within a loop, and a need for refactoring three methods down to one. Let's chat about the loop: perhaps I don't understand what is going on well enough.

The refactoring three methods to one needs to happen, but we can do it when this gets moved out of experimental namespace.

[Arlie-Capps]

@gunney1 , I appreciate your work on this, and your fixes. As we discussed, there is work to be done in a future PR. This one looks to be in a good shape.