-
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
Update stationary block methods #665
Conversation
* Split fuelHandlers.py into separate scripts * Update fuelHandlerInterface.py for merging
* Split fuelHandlers.py into separate scripts * Update fuelHandlerInterface.py for merging * Update stationary block methods
I love it! I have made two comments/requests. But they are pretty minor. |
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.
Seems like a good change.
- This is a breaking change and will break all previous inputs that used the
stationaryBlocks
setting. This needs to be documented in the documentation and in the release notes. - Would you consider adding a migration so that users with the deprecated setting can proceed easily? Or at least provide a meaningful error message telling them how to proceed.
* Add testing for dischargeSwap * Add error for old stationary block setting
I am not familiar which specific documentation this would go in. I assume that the release notes are here: |
That's it! A quick one-sentence explanation of the breaking change. |
…#15) * Remove ``stationaryBlocks`` setting * Remove ``_swapFluxParam`` method. Update ``_transferStationaryBlocks`` method for clarity.
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.
@HunterPSmith, very sorry for the long review time on this. Can you work with @opotowsky to make sure we understand the full scope of the impact to internal plugins offline and testing before we land this?
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.
@jakehader @HunterPSmith Internal plugins and testing are a go. This PR is good to merge from that perspective. |
Great, thanks @opotowsky! @HunterPSmith, can you address the last comments here and we will merge? |
Thank you both! Should be good to go now |
Updated the way that ARMI handles stationary blocks. ARMI now has a global setting called stationaryBlockFlags which can be set by the user to identify flags for stationary blocks. By default, GRID_PLATE has a stationary flag, unless set by user in the input file. When a reactor object is initialized, a reactor attribute called stationaryBlockFlagsList is generated which contains a list of the flags in the reactor that are considered stationary. ARMI now operates on stationaryBlockFlagsList in order to control stationary blocks.
Description
Updated the way that ARMI handles stationary blocks. ARMI now has a global setting called
stationaryBlockFlags
which can be set by the user to identify flags for stationary blocks. By default,GRID_PLATE
has a stationary flag, unless set by user in the input file. When a reactor object is initialized, a reactor attribute calledstationaryBlockFlagsList
is generated which contains a list of the flags in the reactor that are considered stationary. ARMI now operates onstationaryBlockFlagsList
in order to control stationary blocks.Added testing to satisfy requirement MDN-FMM-004 of the FMM SRSD.
This PR will require the MCNP plugin to be updated.
Checklist
If user exposed functionality was added/changed:
doc
folder.setup.py
.