Geometry Homogenization

[paulromano]

For mesh-based R2S workflows, we need a way to compute volume fractions of materials within mesh elements in order to determine a homogenized composition for activation purposes.

[paulromano]

We discussed a notional approach for this over call yesterday. The "simplest" way would be to set up one volume calculation per mesh element where the bounds of the enclosing rectangular prism match the bounding box of the mesh element. Determining element bounding boxes for our regular mesh types should be fairly straightforward. For unstructured meshes, I'm not sure how that will work (@pshriwise is there an easy way to get per-element BBs for unstructured meshes?).

@pshriwise pointed out that it may be easier and/or more efficient to implement a method on the C++ side since we already have a capability to uniformly sample the volume of a mesh element. Although now that I'm thinking about this, does that really help us in determining the volume fraction?

[pshriwise]

Although now that I'm thinking about this, does that really help us in determining the volume fraction?

I think where it helps us is in sampling efficiency when doing these volume calculations. I can see two roads to doing this:

1. The bounding box approach: Determine a bounding box for each mesh element (for unstructured mesh this should be a simple call to the mesh library or they are easy to construct on-the-fly, but this will need to be done in C++ once we've loaded the mesh). Sample points within the bounding box and reject points that lie outside the mesh element. Perform calculation of material/cell volume fractions as usual.

2. The element sampling approach: Use the methods we've added to the mesh class to directly sample points uniformly within an element. Perform calculation of the material/cell volume fractions as usual.

One extra step that's needed for approach 2 is determining the element volume so the volume fractions are meaningful, but we can compute that analytically fairly easily for all the mesh types we're looking to support in this proejct. Whereas with 1 we can calculate the volume of the element based on the rejection ration of points inside/outside the volume calculation box.

I think the win with approach 2 is sampling efficiency. We're guaranteed to have points inside the box and don't have to worry about bounding boxes tightly fitting those elements.

Looking at element types beyond the scope of this project and what we have implemented in OpenMC (curvilinear elements), approach 1 could be handy to keep in mind. It's sometimes easier to compute point containment than it is to compute volumes for these elements and 1 would give us a way of doing this.

With all that written out, I do think that approach 2 would be the most elegant for our purposes.

[paulromano]

One extra step that's needed for approach 2 is determining the element volume so the volume fractions are meaningful, but we can compute that analytically fairly easily for all the mesh types we're looking to support in this proejct

Thanks, that's the answer I was looking for 😄 Looking at our current capabilities, we already have the ability to determine element volumes for all mesh types (@pshriwise pointed out to me that this may not be robust for more exotic element types in libMesh). The position sampling is already implemented for our unstructured mesh classes, but not the structured meshes yet.

Edit: @pshriwise does have position sampling implemented on his mesh_source branch.

[paulromano]

I've started a new mesh-mat-volumes-fracs branch with the initial implementation of calculating material volume fractions over mesh elements. The remaining work on this is:

• Finish hooking it up to openmc.lib, namely figuring out how to pass results back
• Implement MPI parallelization? Easiest way is to do this is by splitting it up over mesh elements
• Add function to compute a homogenized material using Material.mix_materials

We need to be careful on the last step to account for voids properly. Fortunately, mix_materials already handles void when the volume fractions don't sum to unity. On the C++ side, we may not need to explicitly count void because volume fractions summing to less than 1 would indicate that the remainder is void.

[paulromano]

PR for the volume fraction capability has been submitted, openmc-dev/openmc#2802

[paulromano]

PR for computing homogenized materials has been submitted, openmc-dev/openmc#2971

[paulromano]

I crossed off the material volume fractions with MPI above. I don't see an easy way to go about this since we are relying on openmc.lib, which means the script itself would have to be called with mpiexec. Perhaps if we run into cases where the homogenization step becomes limiting, we can revisit.