-
Notifications
You must be signed in to change notification settings - Fork 87
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Component density differs if you create component through blueprints vs programatically #819
Comments
Thoughts @john-science, @albeanth ? |
@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 |
Looking into it. |
I believe the issue you've identified here boils down to an inconsistency between the default behavior of the Component constructor and case setting, 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 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:
|
I would be curious to know how this problem relates to this docstring: armi/armi/materials/material.py Lines 341 to 348 in bc556fc
This has been in our codebase for at least 3 years. |
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 |
- fixed an Issue (#819) where components initialized through the constructor would have different density than those created through blueprints.
- fixed an Issue (terrapower#819) where components initialized through the constructor would have different density than those created through blueprints.
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
The text was updated successfully, but these errors were encountered: