Skip to content
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

Custom isotopics specified as number densities only work on 'Custom' materials #1739

Closed
AidanMcDonald opened this issue Jun 20, 2024 · 3 comments

Comments

@AidanMcDonald
Copy link
Contributor

When defining a material from an existing material class but specifying custom isotopics with number densities, I get warning messages like the following and the custom isotopics are ignored.

You either specified a custom mass density or number densities (which implies a mass density) on <Material: UraniumOxide> with custom isotopics UO2. This has no effect on this Material class; you can only override mass density on Custom materials. Consider switching to number fraction input. Continuing to use <Material: UraniumOxide> mass density.

To replicate the warnings, run armi.configure; o=armi.init(fName="c5g7-settings.yaml") inside armi/tests/tutorials/

This is coming up in the context of running the c5g7 benchmark case with the openmc plugin, so while I could redefine the custom isotopics with number fraction input, I think having the exact same numbers and input format as the reference makes sense and I'm not sure it's necessary to not allow overriding density with custom isotopics. So far I have renamed every material in c5g7-settings.py to "custom", but now I'm missing the useful data from the predefined materials like thermal scattering data.

Could armi override the density and warn the user that they're doing so rather than warning the user that they're trying and ignoring the custom isotopics?

@keckler
Copy link
Member

keckler commented Jun 21, 2024

There has been discussion on something similar in the past. Take a look at this: #535

@keckler
Copy link
Member

keckler commented Jun 21, 2024

Also #1272

@AidanMcDonald
Copy link
Contributor Author

Thanks! I agree that this is a duplicate of #1272, and it looks like pull request #1745 is the fix I had in mind.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants