Set up mesh-based R2S example on FNG dose

[paulromano]

For a mesh-based R2S workflow, I'm envisioning the following steps:

1. Perform neutron transport calculation to get 1-group microscopic cross sections in each mesh element
2. Determine the material corresponding to each mesh element. If a mesh element crosses a material boundary, we'll need a means of Geometry Homogenization #13.
3. Feed the materials and micro XS into IndependentOperator, which will provide us activated materials.
4. Create a MeshSpatial source using the decay photon source in each mesh element.

[paulromano]

@pshriwise talked at length through the needs for item 1 above. There are fundamentally two paths to get 1-group micro XS on mesh elements:

Path 1

Use the MicroXS.from_model(...) method, which under the hood relies on the mgxs module. The mgxs module nominally supports meshes; however, right now it claims only RegularMesh is supported (not clear why) and furthermore you can't get microscopic cross sections because these require dividing by the average number density of each nuclide, and we simply don't know that for mesh elements (which may cross materials boundaries). Another thing to note here is that in order to get reaction rates, every desired nuclide needs to be present in the material, hence why the MicroXS class will force nuclides to be added. If we wanted to extend support of mgxs to allow generation of microscopic cross sections on any mesh, we'd need to:

• Remove the limitation for only RegularMesh to be used, and
• Either allow averaged nuclide densities to be calculated on mesh elements (through a stochastic volume calculation?) or refactor our tally system so that $\sigma \phi$ can be tallied rather than $N \sigma \phi$ (also requires that we allow nuclides to be tallied that are not present in materials).

Path 2

Extend the MicroXS class to enable a new option whereby we tally a flux spectrum for each mesh element and then collapse 1-group reaction rates using the existing openmc_nuclide_collapse_rate. This would also require that we allow nuclides to be tallied that are not present in materials.

[paulromano]

Update: A few changes have already been merged/submitted to OpenMC related to this:

• New multiply_density option on tallies openmc#2539
• Use multiply_density in depletion reaction rate helper classes openmc#2559
• Remove initial dilute nuclides in depletion openmc#2568
• Remove use of mgxs module in MicroXS.from_model openmc#2572
• Remove initial dilute nuclides in MicroXS openmc#2579

I also just opened an issue regarding refactoring of MicroXS and IndependentOperator:

• Design of the MicroXS and IndependentOperator classes openmc#2580

[paulromano]

Update: we've had one more branch merged in OpenMC:

• Refactor MicroXS class and usage in IndependentOperator openmc#2595

We talked yesterday at length about how to handle the mesh-based workflow. To summarize:

1. First, we need to determine volume fractions of materials within mesh elements. See Geometry Homogenization #13 for further discussion.
2. The MicroXS class needs to be extended to support using a mesh as the domain and getting fluxes and microscopic cross sections on each mesh element. The simplest approach is to have a single flux and set of micros over the whole mesh element, but if we want to get fancy we could try to compute per-material fluxes and micros within a single element. The problem here is that for tallies, we would need a mesh filter and a material filter that covers all possible materials (there's no good way to limit it to only the combinations of materials / mesh elements that appear together).
3. With the volume fractions determined in step 1, homogenize the materials within a mesh element and then activate it with the fluxes / micros determined in step 2. Alternatively, we can activate each material in a mesh element independently, resulting in possibly multiple decay photon sources per mesh element.
4. Determine the decay photon source from each activated composition and set up an overall photon source using the MeshSpatial class. Further developments are needed here (see Mesh-based Source Routines #12).