Component density differs if you create component through blueprints vs programatically

[onufer]

Component density differs if you create component through blueprints vs programmatically .

This is due to having to remember to call applyHotHeightDensityReduction() if you do so programmatically. This is not great because if you forget to call it, your component wont be equal to the 3D density. We should strive to have components density always equal to 3D density. We used to do this on component construction, but #657 changed this.

I don't think that it needed to, the math just might be a little different for axial expansion.

#818 writes a unit tests demonstrating this behavior

[onufer]

Thoughts @john-science, @albeanth ?

[john-science]

@albeanth Okay, my read of the situation is this is a bug. Unless you disagree, I am assigning the bug to you, because it has the phrase applyHot in it. Holler at me if I'm wrong.

[albeanth]

Looking into it.

[albeanth]

Component density differs if you create component through blueprints vs programmatically .

I believe the issue you've identified here boils down to an inconsistency between the default behavior of the Component constructor and case setting, inputHeightsConsideredHot (introduced with #657). Testing on my end shows that if the case settings have inputHeightsConsideredHot: False, then the number densities from a Component built via blueprints and programmatically are the same.

Some more details:

As of now (after #804), the constructor of Component expects that the "height" of the component is cold. So when a Component is built programmatically, the number densities are computed with the adjustment for hot radial dimensions only. However, the default behavior of the blueprints expects the "height" of the Component to be hot (via inputHeightConsideredHot: True) , and therefore the number densities are adjusted for both hot radial and hot axial conditions via a call to applyHotHeightDensityReduction. This inconsistency results in the discrepancy you've identified.

So an option for a fix: Have the default behavior of the Component constructor compute number densities that assume hot radial and hot axial dimensions to match the default behavior of Components built through the blueprints.

Some impacts of this change:

• If the case setting inputHeightsConsideredHot: False, then we will need to recompute/adjust Component number densities to account for a cold axial height when building from blueprints.
• If a user wants to build a Component programatically that has a cold "height", they will need to manually call the method to adjust the number densities.
  • note: this is the same scenario you are experiencing now, just reversed.

[john-science]

I would be curious to know how this problem relates to this docstring:

https://github.com/terrapower/armi/blob/bc556fc5ce3f0445a4b1e841f00b8bdc3888f5a3/armi/materials/material.py#L341-L348

This has been in our codebase for at least 3 years.

[albeanth]

I would be curious to know how this problem relates to this docstring:

@keckler has pointed this out as well in https://github.com/terrapower/armi/issues/770 and it feels related to #820 .

I'll spend some time on this today.

[onufer]

We should strive to have components density always equal to 3D density.

If we dont than we have to update a whole bunch of doc strings and how the framework wroks.

@albeanth, this is not related to #820 . There are 2 separate issues read through #818 comments.

#820 are very small differences, much less than expansion