Description
Explicit void regions should be supported in kinetic Random Ray solver (#3702). I have derived the necessary equations for the isotropic approach:
and for the propagation approach:
and
where
The region averaged scalar flux is computed as
Difficulties
An inverse-velocity multi-group cross section is needed for kinetic Random Ray in void regions. This quantity can be obtained for using a CellFilter, but the current Random Ray automagic setup machinery relies on MaterialFilter objects to create an MGXS library. The simplest method I could come up with around this would be to
- Determine if kinetic XS are needed
- Determine what void cells (if any) exist in the model
- Tack on an
inverse-velocity tally with a CellFilter and EnergyFilter
- Manually add the inverse velocity values to the MGXS library under a specially named material called
VOID_MATERIAL or something similar.
- Add processing infrastructure to the C++ side to detect this material name and utilize the void region machinery on that material.
Alternatives
An alternative approach would be to add an attribute to material classes on the C++ and Python side to indicate they are void materials, however this is a more complicated approach.
Compatibility
This feature shouldn't change any existing APIs. The VOID_MATERIAL added to the MGXS will only be utilized in the Random Ray solver. It's a bit of a hacky solution, and I'd love something more robust. If anyone has any input I'd appreciate the feedback!
Description
Explicit void regions should be supported in kinetic Random Ray solver (#3702). I have derived the necessary equations for the isotropic approach:
and for the propagation approach:
and
where
The region averaged scalar flux is computed as
Difficulties
An
inverse-velocitymulti-group cross section is needed for kinetic Random Ray in void regions. This quantity can be obtained for using aCellFilter, but the current Random Ray automagic setup machinery relies onMaterialFilterobjects to create an MGXS library. The simplest method I could come up with around this would be toinverse-velocitytally with aCellFilterandEnergyFilterVOID_MATERIALor something similar.Alternatives
An alternative approach would be to add an attribute to material classes on the C++ and Python side to indicate they are void materials, however this is a more complicated approach.
Compatibility
This feature shouldn't change any existing APIs. The
VOID_MATERIALadded to the MGXS will only be utilized in the Random Ray solver. It's a bit of a hacky solution, and I'd love something more robust. If anyone has any input I'd appreciate the feedback!