-
Notifications
You must be signed in to change notification settings - Fork 91
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
Move cold height expansion to bp #1047
Merged
Merged
Changes from 7 commits
Commits
Show all changes
12 commits
Select commit
Hold shift + click to select a range
a20e709
initial cut, no tests
onufer 09cf47b
minor updates
onufer 9d8d4f5
move snap list into construction, fix tests
onufer 4441c0a
fix empty blueprints testing
onufer e638b1c
rm setting change
onufer 5e7de3c
delete prints in test
onufer 3b9c048
simplify assemCheck
onufer b653946
move more logic outside blueprints
onufer 5009175
comment
onufer 35811a0
remove unused import
onufer fdbf6f9
better doc string
onufer e89bcbb
resolve merge conflicts
onufer File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -89,7 +89,9 @@ | |
from armi.reactor import assemblies | ||
from armi.reactor import geometry | ||
from armi.reactor import systemLayoutInput | ||
from armi.reactor.flags import Flags | ||
from armi.scripts import migration | ||
|
||
from armi.utils import textProcessors | ||
|
||
# NOTE: using non-ARMI-standard imports because these are all a part of this package, | ||
|
@@ -102,6 +104,7 @@ | |
from armi.reactor.blueprints.componentBlueprint import ComponentGroups | ||
from armi.reactor.blueprints import isotopicOptions | ||
from armi.reactor.blueprints.gridBlueprint import Grids, Triplet | ||
from armi.reactor.converters.axialExpansionChanger import AxialExpansionChanger | ||
|
||
context.BLUEPRINTS_IMPORTED = True | ||
context.BLUEPRINTS_IMPORT_CONTEXT = "".join(traceback.format_stack()) | ||
|
@@ -321,18 +324,80 @@ def _prepConstruction(self, cs): | |
self.assemblies[aDesign.name] = a | ||
if currentCount != 0: | ||
assemblies.setAssemNumCounter(currentCount) | ||
|
||
self._checkAssemblyAreaConsistency(cs) | ||
|
||
runLog.header("=========== Verifying Assembly Configurations ===========") | ||
self._checkAssemblyAreaConsistency(cs) | ||
|
||
# pylint: disable=no-member | ||
getPluginManagerOrFail().hook.afterConstructionOfAssemblies( | ||
assemblies=self.assemblies.values(), cs=cs | ||
# if assemblies are defined in blueprints, handle meshing | ||
# assume finest mesh is reference | ||
assemsByNumBlocks = sorted( | ||
john-science marked this conversation as resolved.
Show resolved
Hide resolved
|
||
self.assemblies.values(), | ||
key=lambda a: len(a), | ||
reverse=True, | ||
) | ||
referenceAssembly = assemsByNumBlocks[0] if assemsByNumBlocks else None | ||
|
||
if not cs["detailedAxialExpansion"]: | ||
# make the snap lists so assems know how to expand | ||
nonUniformAssems = [ | ||
Flags.fromStringIgnoreErrors(t) for t in cs["nonUniformAssemFlags"] | ||
] | ||
# prepare core for mesh snapping during axial expansion | ||
for a in self.assemblies.values(): | ||
if any(a.hasFlags(f) for f in nonUniformAssems): | ||
continue | ||
a.makeAxialSnapList(referenceAssembly) | ||
if not cs["inputHeightsConsideredHot"]: | ||
# expand axial heights from cold to hot | ||
self._coldDimsToHot(referenceAssembly, cs["detailedAxialExpansion"]) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @john-science happy to move this stuff else where and have a 1 line call to hit here. |
||
|
||
# pylint: disable=no-member | ||
getPluginManagerOrFail().hook.afterConstructionOfAssemblies( | ||
assemblies=self.assemblies.values(), cs=cs | ||
) | ||
|
||
self._prepped = True | ||
|
||
def _coldDimsToHot( | ||
self, | ||
referenceAssembly, | ||
isDetailedAxialExpansion, | ||
): | ||
""" | ||
Expand BOL assemblies, resolve disjoint axial mesh (if needed), and update block BOL heights | ||
|
||
Parameters | ||
---------- | ||
assems: list | ||
list of :py:class:`Assembly <armi.reactor.assemblies.Assembly>` objects to be thermally expanded | ||
""" | ||
runLog.header( | ||
"=========== Axially expanding all assemblies (except control) from Tinput to Thot ===========" | ||
) | ||
assems = list(self.assemblies.values()) | ||
|
||
axialExpChanger = AxialExpansionChanger(isDetailedAxialExpansion) | ||
for a in assems: | ||
if not a.hasFlags(Flags.CONTROL): | ||
axialExpChanger.setAssembly(a) | ||
# this doesn't get applied to control assems, so CR will be interpreted | ||
# as hot. This should be conservative because the control rods will | ||
# be modeled as slightly shorter with the correct hot density. Density | ||
# is more important than height, so we are forcing density to be correct | ||
# since we can't do axial expansion (yet) | ||
axialExpChanger.applyColdHeightMassIncrease() | ||
axialExpChanger.expansionData.computeThermalExpansionFactors() | ||
axialExpChanger.axiallyExpandAssembly(thermal=True) | ||
if not isDetailedAxialExpansion: | ||
for a in assems: | ||
if not a.hasFlags(Flags.CONTROL): | ||
a.setBlockMesh(referenceAssembly.getAxialMesh()) | ||
# update block BOL heights to reflect hot heights | ||
for a in assems: | ||
if not a.hasFlags(Flags.CONTROL): | ||
for b in a: | ||
b.p.heightBOL = b.getHeight() | ||
b.completeInitialLoading() | ||
|
||
def _assignTypeNums(self): | ||
if self.blockDesigns is None: | ||
# this happens when directly defining assemblies. | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
Hmmm
So, the primary blueprint code knows about the Axial Expansion?
But two-thirds of the projects that use ARMI, and half the ones at TerraPower, don't even have axial assemblies.
So, how does this code work for, say, a molten chloride reactor?
I ask for two reasons:
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.
If you look at the code it’s only called if input heights considered cold
Both before and after this change the same calls are made by the time o=armi.init is done running. o=armi.init is about the minimal thing you can do and the new code will be just as fast or faster for those circumstances (because its producing the correct assemblies before the deepcopy, rather than deepcopying and then fixing them all after....
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.
That's a fair point. Okay, so we aren't breaking non-axial-type reactors.
But we are importing something that is specific to a TYPE of reactor (albeit a common one) into a part of the code that (right now) reads YAML files and builds some math.
It just feels like something that should be in assemblyBlueprint.py. But, I assume, it was just hard to work into that module?
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.
you need to know the meshes of each of the individual assemblies to go through the processes since they all have their indices mapped to the reference assembly (see
a.makeAxialSnapList(referenceAssembly)
). I dont see anywhere in that module where there are the full set of assemblies. The nice thing about doing it here is that the blueprints assemblies will exists for the shortest possible time ad the incorrect dimensions/masses since they are fixed right after construction (line 322)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.
if you want, right after the area consistancy check i could move all the new code to
axialExpansionChanger
and have it be
Fundamentally though, blueprints should be responsible for producing assemblies with correct masses and elevations. It can certainly call someone else to do the work 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.
blueprints/__init__.py
already has many direct references to assemblies at the top level. So I think you're not causing a design flaw so much as stuck within the system we created.if cs["settingName"]
statements, which point to some non-blueprint method. Unless that list gets long, that's probably going to look a little ugly, but not be heart-breakingly bad.Sorry, I'm not trying to be a bother. I have just learned by hard experience that improving something at the start can save a TON of time spent on technical debt later. I keep meaning to give a talk on that.
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.
Great. thanks for clarifying @john-science. I genuinely don't think this list of things will grow considerably... I would recommend describing molten salt reactors and TRISO-based fuel as "non-pin-based" or "non-assembly-based" as opposed to "non-axial-type reactors".
Molten salt reactors still typically care about axial expansion of their vessel and the impact of that on reactivity (I spent a couple years on a molten salt project). Its just that the framework currently doesn't support it. Its not a trivial feature though and its a bit different from a fuel pin expanding. It took a couple hundred hours for us to get cold to hot dims working for pin-based-reactors. I am sure that if we had the capability to input cold vessel dims and have the framework expand the vessel to hot, molten salt reactors would want to use the capability. Its just we don't have it now, so those folks tend to continue to use hot axial heights.
If/when we have this capability, I would image we would change the call to
expandColdDimsToHot
to determine a different changer to use for non-pin based reactors rather than having another if statement here in blueprints.Sure, after moving the logic to the axial expansion module, I'm convinced.
what more do you need to approve the PR?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.
Thanks. And, always, I am interested in learning more about reactor design/analysis. Sorry, my graduate degrees are in physics, but not the right kind. I'm happy to learn.
I added one little comment about a docstring, but I'm good otherwise. The logic looks sound, and I like the new layout better.
Thanks, man!