Volumetric Mesh Class Design/Integration

[pshriwise]

At the moment, it's unclear what the best approach to defining how volumetric vs. surface mesh should be treated.

Given that we're we'd like to go is the ability to run both surface and mesh tracking (even on what is initially a fully volumetric mesh).

To get from a volumetric mesh to a surface mesh, a shelling capability should be included.

Current mental model for this:

Basic case: If only surface elements are available for a mesh, surface tracking only.

• If a geometry mesh is used and contains volumetric elements, track on the volume elements unless otherwise specified.
• If specified, shell a set of volume elements and create a volume. A set of volume elements can be identified separately based on whatever criterion matters to the user. In the context of surface tracking across a "cell" (region of constant material), this would be a block with a certain material identifier.
  • Thoughts on this:
    • It should be possible for this to happen after model initialization (+ or - accel. data structure creation)
    • The specified "shell" elements will need to be subtracted from any volumes/blocks they are currently part of.
    • If the shell elements span multiple materials, figure out how that should be handled. Given that it will need some kind of special treatment, it should probably be an error for now.
• There should also be mode in which all volumetric elements are shelled based on material assignment by default for simplicity.

Note: this does not need to be addressed by the time tracklength tallies on volumetric mesh is supported

[pshriwise]

I was thinking this morning that perhaps the best way to handle this would be, for a volumetric mesh, to default to treating all volume-meshed regions as meshed with an option to "shell" (typically called skinning but that kinda grosses me out) volumes to produce a surface mesh for tracking. This capability should rely on a generic capability to shell sets of volumetric elements, the topology update for the internal XDG data structures will be unique to this operation, however.

If a mesh is provided that is part surface mesh, part volumetric mesh, then we'd default to volumetric elements. This isn't possible at the moment (I'll make a separate task to support this later), but I'll think about it as we go forward.

In this scenario we'd want to provide options to shell a subset of the volumes (if they're already surface mesh do nothing) and an option to shell all of the volumes (for brevity).

In terms of the trees, they will need to be designed in a way that the tree type is agnostic to the geometry defined therein. This should be possible for both of the targeted ray tracing libraries (Embree and GPRT). Where this becomes more complicated is the cases where we want to use "passthrough" options to lean on the backend mesh library data structures.

[pshriwise]

Another thing to consider is how volumetric mesh data will be handled by the particle transport codes. One of the primary motivations for using volumetric mesh is that each element can have its own properties, but this isn't always straight forward to communicate to the transport code. The main question in my mind whether or not the transport code should house an 1:1 mapping with one cell for every element (resulting in a very large number of cells) or if volumetric regions should be managed uniquely. To a degree, this is probably something to be managed on the transport side, but when it comes to tallies this might make their specification overly complicated, requiring definitions with the cell IDs of every cell/element in the volumetric mesh. Assigning and mapping these IDs becomes more complex in this case as well.

Given all of that, what I'd probably lean toward is an ID "sub-space" for the volumetric mesh volumes, where, in the case of OpenMC, filter bins are added based on the number of elements in a volumetric mesh. This might need to be a specialized filter type....

[pshriwise]

Thoughts on past thoughts above:

I'm not sure that metadata should be considered too much in this design. Even the consideration of volumetric elements may not be important for these interfaces. If a volume has internal elements, we can indicate this and the Monte Carlo code can use the surface or volume elements as it sees fit.

This kind of answers my concerns about specialization for volumetric regions.