search

terrapower / armi

An open-source nuclear reactor analysis automation framework that helps design teams increase efficiency and quality
https://terrapower.github.io/armi/
Apache License 2.0
232 stars 90 forks source link

`material modifications` can be out of sync with the use of `custom isotopics` #1820

Open keckler opened 3 months ago

keckler commented 3 months ago

A lot of our material classes utilize material modifications specified in the blueprints to do things like specify the enrichments of materials in the blocks. For instance: image

We also now have the ability to specify custom isotopic vectors that are paired with material classes, in which case the custom isotopic will take precedence over the isotopics from the material class (see #1745 ).

To my knowledge, these two methods of specifying isotopics in the blueprints are able to conflict with each other without any warning being printed to the user. I assume that the material modifications are simply ignored with respect to the component's isotopics.

It would seem useful if the user were somehow informed of this situation, though it seems pretty difficult to make that happen without just blasting a warning anytime that the custom isotopic is specified on a component irrespective of if a material modification is used or not.

john-science commented 2 months ago

I think this is the way to go:

It would seem useful if the user were somehow informed of this situation

We should check if the above scenario is true, but I really think it is. We should at least raise a warning if custom isotopics will over-write the material modifications. Perhaps a nice table of all such situations, printed to the log.

But I would also here the debate for raising an error. Though I would want to make sure that didn't break otherwise working downstream modeling.