Cell-wise densities

[zhardy-lanl]

Implementation of cell-wise densities into the LBS framework. This change has the effect of the code "assuming" microscopic cross sections instead of macroscopic. This allows for more control over cross sections based on material states and flexibility in how the problem is defined. Of course, using a default density of one in all cells has the same effect as assuming a macroscopic cross sections.

What this PR does

• Added a density attribute that gets initialized to one in LBSSolver and associated getters.
• Hooked up densities to source functions for scaling scattering and fission sources.
• Hooked up densities to sweepers for scaling sigma_t.

What this PR doesn't do

• Read in and set cell-wise densities from files
• Include routines to set densities outside of the non-const getter.

[andrsd]

👍

[ragusa]

can we have an input file in the test? something like, homogeneous medium, fully reflected, solution saturates to q/sigma_a. next, double the density and the solution should now saturate at half the previous value. simple enough but would test the change in density

[zhardy-lanl]

can we have an input file in the test? something like, homogeneous medium, fully reflected, solution saturates to q/sigma_a. next, double the density and the solution should now saturate at half the previous value. simple enough but would test the change in density

We can but it would require a bit of work since there is currently no way to set cell-wise densities. I was planning on adding a test when I eventually add a way to set the densities. Adding one know would require that to be done now. This is intended to be the infrastructure for using cell-wise densities. I suppose you could view the tests passing as proof that adding unit densities did not change anything.

[ragusa]

@zhardy-lanl can you create an issue to add the test I described earlier: homogeneous medium, fully reflected, solution saturates to q/sigma_a. next, double the density and the solution should now saturate at half the previous value. simple enough but would test the change in density.

[ragusa]

@zhardy-lanl : can we agree that our units must be:

• cross sections in 1/cm when density is not supplied (obvious)
• cross sections in barns and densities in at/(barn-cm) otherwise? (this is quite common in codes that deal with microXS. it avoids carrying large numbers because of Avogadro's ....).

[zhardy-lanl]

@zhardy-lanl can you create an issue to add the test I described earlier: homogeneous medium, fully reflected, solution saturates to q/sigma_a. next, double the density and the solution should now saturate at half the previous value. simple enough but would test the change in density.

Sure, I can create an issue. I'd like to think a little more carefully about the test. The test you propose would catch whether or not we missed a spot in the code where we should be multiplying by density but are not. I think it would be equally as useful to have a multi-material test where instead of scaling cross sections we set material densities via whatever API I end up implementing for this.

See #161

[zhardy-lanl]

@zhardy-lanl : can we agree that our units must be:

• cross sections in 1/cm when density is not supplied (obvious)
• cross sections in barns and densities in at/(barn-cm) otherwise? (this is quite common in codes that deal with microXS. it avoids carrying large numbers because of Avogadro's ....).

On point 1 I agree. My only point of contention would be that there is nothing in the code that I am aware of that is explicitly tied to units (constants, etc.). If there aren't any constants tied to particular units in the code, then the code should be agnostic to units. In other words, the units of the problem are set by the units of the cross section data and densities.

Point 2 I feel a little differently. I don't think we need to have strict enforcement of at/(barn-cm) vs. at/cc. The user supplies both the cross sections and the densities, it should be their responsibility to ensure consistency of units in that regard. When we have time-dependent solvers this becomes a bit more important as that time scales can vary dramatically based on the application making the time units of choice far less standard.

More generally, there isn't anything (constants) in the code that I know of that is tied to specific units.

[ragusa]

except that the mesh and the macroXS need to be compatible. So, yes, the user should put the densities and microXS in whatever they feel like, as long as the resulting macroXS is compatible of the length units used in the mesh.