Open keckler opened 3 months ago
@keckler It appears to me that AM242
and AM242M
are the exact same thing, just with a different name:
It appears am242m
is the preferred name, to differentiate it from am242g
. The logic really looks like we won't want to use the name am242
because then people won't know if it is m
or g
, as that would not be clear.
Thoughts?
Yeah, I think that is fine. But then we should not allow AM242
in the nuclide flags. We should make people enter AM242M
to avoid the ambiguity and the inconsistency between the nuclide flags and the isotopic definitions.
Yeah, I think that is fine. But then we should not allow
AM242
in the nuclide flags. We should make people enterAM242M
to avoid the ambiguity and the inconsistency between the nuclide flags and the isotopic definitions.
I could do that.
We could also throw a loud warning that the nuclide you entered is being renamed, and loudly inform people this is just a convenience pass-through for them.
A little research showed me that "AM242"
is used extensively in our downstream projects. (I gave up counting after a dozen.)
While many projects are already correctly using AM242G
and AM242M
, just dropping AM242
will be quite a big set of changes in the ecosystem.
Thoughts?
Interesting. I know that I am responsible for at least some of that. I would be willing to migrate anytime that a change is made here.
I think a good path here is to move towards deprecation, starting with a warning. Maybe in the next-next release, we drop it?
So, this whole situation is, it turns out, extremely well documented in the code:
But there isn't any (good or pleasant) way to inject a DeprecationWarning
only when people use AM242
. They would have to see it every time they run any ARMI simulation. #shrug
There is a bit of an inconsistency in the different sections of the blueprints when it comes to specifying the isotope AM242.
The
nuclide flags
portion of the blueprints allows you to putAM242
without complaining. But then if you putAM242
into one of your components, the run will fail during blueprints instantiation. For instance, using the attached input files which have AM242 in both the nuclide flags and a custom material:To get this error to go away, you have to change the
AM242
in the custom material into eitherAM242M
orAM242G
.The error is raised here: https://github.com/terrapower/armi/blob/b3a9992c4db122a061d407096fdcd762c0e86fc5/armi/reactor/blueprints/componentBlueprint.py#L320-L362
If you look into that
nucsInProblem
set, which is derived from the nuclide flags in the blueprints, you'll find that it hasAM242G
andAM242M
in it, but not plain oldAM242
like was specified by the user:So somewhere in the problem initialization, the
AM242
nuclide flag is converted intoAM242G
andAM242M
. But this makes is confusing if one tries to simply enter nuclide flags for the isotopes corresponding to their materials.If we are going to force users to use
AM242M
andAM242G
, then we should do so consistently.example-blueprints.yaml.txt example.yaml.txt