-
Notifications
You must be signed in to change notification settings - Fork 94
Conserve component density #846
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
Conserve component density #846
Conversation
Edit the Tinput for HT9 and UZr to the reference temperatures to make calculation of density3 consistent with nuclide number densities for testing.
@albeanth I took a quick glance at the docs/release notes and didn't see anything that needed to be updated, but you would probably know better than me. |
Thot: 470.0 | ||
id: 1.0 | ||
mult: 169.0 | ||
od: 1.09 | ||
wire: &component_plenum_wire | ||
shape: Helix | ||
material: HT9 | ||
Tinput: 25.0 | ||
Tinput: 27.548 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you explain in the PR description why these are changing? I assume that this is because we have inputHeightsConsideredHot
set to True
for the tests? Not clear though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reference temperature of HT9 for thermal expansion is 27.548C. The test to check tohat density is conserved only works if Tinput is equal to the reference temperature for thermal expanison.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In line with @jakehader 's comment:
@mgjarrett - for our future selves I think it would be good to leave a comment in this PR on precisely why you/we are making the changes to these temperatures and to armi/materials/zr.py (especially the latter).
I could easily see us coming back a few months later and being totally stumped as to why these temperatures were all changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@albeanth are you looking for a comment directly in the yaml file? Or just include it in the commit message?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The commit message would be fine, but I was thinking about just a general comment in this PR. That way if someone in the future does a git blame and comes back to this PR it will be (somewhat) front and center.
I suppose a comment in the yaml would be ok too - maybe at the very top right off the bat? Not sure where it's best to include it. I'll leave it to your discretion.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See comments.
@mgjarrett Haven't had a chance to review this yet. But am noticing that the coverage dropped pretty drastically. Especially in axialExpansionChanger.py. Can you confirm that you are getting the same coverage drop on your local machine? |
@albeanth I'm not sure why it had coverage decreasing significantly. It's now at -0.003%, which seems better. But when I look at the coveralls report, it looks messed up. Says that 246 existing lines are uncovered and 17 new are covered, which is not consistent with -0.003%. |
What's confusing is that the coverage rose in commit The next 3 commits are just changing function and variable names, but no functional changes have been implemented at all. Now it says coverage decreased. One of those commits broke a unit test, which might have confused coveralls. |
@jakehader I've addressed your comments. I'm trying to understand what happened to the coverage but I'm having trouble understanding what happened from the coveralls report. It does appear that all of the new lines are covered. |
@@ -547,7 +547,7 @@ assemblies: | |||
height: *highOffset_height | |||
axial mesh points: *standard_axial_mesh_points | |||
xs types: *igniter_fuel_xs_types | |||
lta fuel: | |||
lead test fuel: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Need these to have Flags.TEST
so they can be skipped in the density conservation unit test, because the cladding has liner merged at different temperatures.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving, but would love to see a comment addressing this. Thanks @mgjarrett !
#846 (comment)
Okay, after talking with @mgjarrett I think I understand the scope of this change. Basically, we are demonstrating that if the component's input temperature is equal to its material's If the above is correct, then I suggest adding a warning to the user that the component input reference does not align with the material's I am not sure, but this will probably break downstream unit tests that we will have to fix. @opotowsky, would you mind pulling this in and running all internal plugin unit tests and the integration tests? |
@jakehader that summary is correct. I've added a warning when the absolute value of the thermal expansion factor at I am firing off some downstream tests right now. I expect the impacts to be minimal but we will see. |
To my knowledge, no need to add anything to the docs. I would add one line to the release notes commenting on the density conservation bug fix. |
Downstream tests are currently failing; waiting to merge this until we get that resolved |
Downstream tests resolved -- merging! |
I would expect that after #820 is resolved the odd initial temps in blueprints would not longer be needed |
* Add failing unit test for conserving density. * Fix failing density unit test. * Correct Tinput for fuel. * Loosen test criterion for Zr. * Don't change density of fluid materials. * Fix specified expansion test. Edit the Tinput for HT9 and UZr to the reference temperatures to make calculation of density3 consistent with nuclide number densities for testing. * Update specifyTargetComponent to use solid material. * Change function name and update docstring. * Fix function name. * Update variable name. * Fix inadvertent change in test precision. * Fix reference temp for Zr thermal expansion. * Update error message for density check. * Reset the Zr reference temperature. * Add warning for Tinput != referenceTemp. * Add line in the release notes. * Make Tinput warning a single.
Description
The
axialExpansionChanger
was implemented to conserve the initial mass of each component in a block with axial expansion determined by the target component, using the funciton_conserveComponentMass
. Since different components are made of different materials that thermally expand at different rates, this necessarily means that the densities have to be adjusted artificially for the mass to be conserved over the block for each individual component.After testing and discussing the methodology, it has been decided that it is preferred to conserve the realistic density of the material rather than conserving mass within a block. Effectively, we are allowing mass to move between blocks.
The
Tinput
values in the test reactor fordetailedAxialExpansion
were updated because the unit test to ensure density conservation requires that theTinput
is equal to the material reference temperature for calculating thermal expansion factors.Checklist
This PR has only one purpose or idea.
Tests have been added/updated to verify that the new/changed code works.
The code style follows good practices.
The commit message(s) follow good practices.
The release notes are up-to-date with any bug fixes or new features.
The documentation is still up-to-date in the
doc
folder.The dependencies are still up-to-date in
setup.py
.