-
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
Cleaned Uniform Mesh Converter Mapping #1003
Closed
Closed
Conversation
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
Mapping anything from a non-uniform assembly to a uniform assembly and then back will cause numerical diffusion of that value. This could be a block parameter (like mgFlux, detailedDpa, etc.) or number densities. This commit deals with the issue of block parameters being mapped back and forth. The number density issue has already been addressed for the nonUniformAssemFlags case, but it seems to still be present for the detailedAxialExpansion case.
The power isn't used for any real calculations, but it's necessary to map power onto the uniform mesh reactor because some downstream physics solvers want to check the energy balance before proceeding. The "energy balance" is checked by comparing the sum of b.p.power to the power specified by the settings input.
Extend NeutronicsUniformMeshConverter class for gamma cases and flux recon cases.
Add a test to verify that reactor params are mapped correctly by global flux executer when nonUniformAssems are used. Needed to fix a bug to get reactor params to map.
Thank you sir! |
-Remove unused imports. -Revert changed mapNumberDensities option -Go back to better parameter description. -Explain when neutron parameters in gamma category
This reverts commit 1fd66ce.
@mgjarrett @keckler Are we keeping both this and PR #992? I figured we'd close #992 and just use this one. But it seems like Chris is reviewing #992 and new commits are going here? Maybe I'm confused...? |
Parameter categories that need to be mapped for gamma might include multigroup quantities (depending on the gamma source production method selected). Neutronics needs to avoid mapping back cumulative parameters--even though they aren't mapped in, they can be present on the uniform assembly because the blocks were deepcopy'd from the original non-uniform assembly.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Description
This is a cleaned up version of #992 , which got messy because it had to pull in a bunch of main branch updates from parameters being moved around.
Checklist
doc/release/0.X.rst
) are up-to-date with any bug fixes or new features.doc
folder.setup.py
.