Multi-group cross section generation in Cardinal

[nuclearkevin]

Reason

Currently multi-group cross sections are generated as a pre-processing step to a deterministic radiation transport simulations using an external code (either continuous energy Monte Carlo or a fine-group deterministic calculation on representative lattice elements). These cross sections have to be generated for a range of material properties to account for multi-physics feedback in the final coarse-group calculation, which further increases the complexity of this pre-processing step and increases the time to final result. Adding multi-group cross section generation to Cardinal would improve the workflow for coupled deterministic transport codes (i.e. Griffin) as the generation of input data would be contained within a coupled Cardinal input file using the multi-app system. Additionally, these multi-group cross sections could be re-generated on the fly on select timesteps / Picard iterations to account for the evolution of temperature/density/depletion feedback.

Design

There are two approaches that could be used to generate multi-group cross sections:

• The first approach would avoid using Cardinal's mapped tally system and instead add the necessary OpenMC tallies to the problem directly based on homogenization regions defined by the user. This would be done in a user object which is responsible for adding the tallies and generating the multi-group cross sections. A transfer would need to be developed to move the resulting multi-group cross sections from the Cardinal child/parent multi-app to the deterministic multi-app. These cross sections could then be provided to the deterministic code as material properties using a custom material class (to avoid issues with export control, this should be implemented in the deterministic code).

• The second approach would use Cardinal's mapped tally system (CellTally / MeshTally) which would allow for the generation of multi-group cross sections on the mesh mirror. This would require an overhaul of the [Filters] and [Tallies] systems to allow for functional expansion filters (to generate scattering cross sections). An auxvariable could be used to generate the final mesh-based multi-group cross sections, which can be moved to the deterministic app using standard transfers. An action could be used to automate the setup of the input syntax required for this approach. These mesh-based cross sections could then be provided to the deterministic code as material properties using a custom material class (to avoid issues with export control, this should be implemented in the deterministic code). This approach is higher fidelity and would allow for the refinement of generated cross sections through the use of AMR on the mesh mirror, but also has a large memory penalty compared to the first approach.

Regardless of the approach taken, the cross sections should be dumped to disk after they're generated. This would allow for a optional "shortcut" where Cardinal doesn't re-run the problem to generate cross sections if it finds them on disk for a specific timestep.

Impact

The addition of multi-group cross section generation to Cardinal would improve the workflow for coupled deterministic codes and allow for on-the-fly re-generation of cross sections to account for variable multi-physics feedback.

[nuclearkevin]

Pinging @tjlaboss for input on the preferred approach from the Griffin side of things. My vote is for the first option (as it's the quickest to implement and the closest to the standard MGXS workflow), but from an R&D standpoint the second approach would be interesting to look into.

[tjlaboss]

I was just looking at this today. I'll let you know what I think.