-
Notifications
You must be signed in to change notification settings - Fork 90
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
Fixing a couple of plots to use initial block height #1998
base: main
Are you sure you want to change the base?
Conversation
This looks fine, but I have not gotten a chance to test it with my real models. Are you trying to get this merged within the coming week-ish? I don't have any strong need to get it merged for the coming release, but what are your priorities? |
Trying to test now |
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.
Unfortunately, this does not appear to work right now. When I test it out on some dummy problem, I'm still getting the hot heights printed by plotAssemblyTypes()
when it is called during the BOL reports
interface (via newReportUtils.insertCoreAndAssemblyMaps()
).
The issue appears to be that plotAssemblyTypes()
is called based on blueprints, and block definitions in blueprints don't appear to have parents, and thus we get kicked into the except
of the try/except
clause that you added.
I think that, if we passed actual assemblies that have been constructed from the blueprints, then this will work? Let me know if that doesn't make sense.
I think that this PR will break an existing usage where hot heights are desired. armi/armi/reactor/converters/uniformMesh.py Lines 958 to 992 in 68268c1
That block of code calls to |
What is the change?
Moving certain plots to use the BOL block height.
Why is the change being made?
This is to improve consistency in our block plots.
close #1158
Checklist
doc
folder.pyproject.toml
.