Remove Nuclide Flags

[john-science]

@drewj-tp and @keckler suggest that we remove the nuclide flags feature from ARMI. They put forward the notion that Nuclide Flags do not add value for them, and frequently slow them down.

There are three options for every nuclide flag:

https://github.com/terrapower/armi/blob/0e830d2c8dece43c57b657caefaed8e8c7ba276b/armi/testing/reactors/smallHexReactor/smallHexReactor-bp.yaml#L2-L6

The question is: Is it possible these are only used by one downstream plugin and can be safely moved from ARMI to that project?

https://github.com/terrapower/armi/blob/0e830d2c8dece43c57b657caefaed8e8c7ba276b/armi/reactor/blueprints/isotopicOptions.py#L82-L91

Second Question: Is it possible we could solve the user problem by just auto-defining defaults so the system never complains at you for missing nuclides in the list?

[partofthething]

No doubt they can be a pain. I will just say that it's useful to have some way of telling ARMI how to map its compositions into different nuclides for representations in different neutronics systems. The main issue is that different nuclear code data people often build data libraries in weird and unpredictable ways. Notional examples:

• ENDF/B-VII.0 in MC**2-3 has elemental carbon but no C-12, but in MCNP it's the opposite, and in DRAGON it's something else, and in CASMO something else entirely!
• ENDF/B-VIII.1 has isotopic C-12 but no elemental, except in OpenMC and SERPENT
• Some libs have C-12 but no C-13 or elemental
• Do you want to model boron depletion or not?
• Do you want to model tritium production or not?
• Do you want the iron in your steel to activate to literally hundreds of trace nuclides? If so, why are you willing to run your code so slowly?

Another thing nuclide flags does is allow you to define the size of your transmutation/decay chain. If you want to model all U-238 going directly to Pu-239 you can do that, but if you have a high power density reactor and want to model U-239 and Np-239 along the way, then you can do that by including them in your nuclide flags. To know if you need these levels of fidelity, you need to estimate the modeling sensitivity to these kinds of effects, and having a method by which to configure it has been useful.

Fundamentally it's about the tradeoff between computational efficiency, availability of nuclear data, and physical fidelity. If you model all decay chains and activation pathways by default, you'll have hydrogen activating all the way up to uranium justl ike in nature, but your code will run slowly.

I think it might be wise to keep them at least somewhere as a concept but feel free to let Certain Applications make aggressive default assumptions so that they get out of the way of people e.g. in final design who have vast computational budgets while leaving flexibility for the little guys running on little workstations.

[drewj-tp]

Here is my source of frustration.

1. I try to make a new reactor from scratch.
2. I have materials in the blueprints.
3. I try to run the model.
4. ARMI tells me "I know you have these nuclides, but you did not tell us you had these nuclides. Please copy these nuclides from the error to your blueprints"
5. Add nuclides to blueprints
6. Repeat 3-5 until no errors appear.

This is not a good user experience for people building models from scratch.

The main issue is that different nuclear code data people often build data libraries in weird and unpredictable ways.

This, 1000000000%.

Another thing nuclide flags does is allow you to define the size of your transmutation/decay chain

But also, if I am doing depletion with a code that handles a full transmutation chain (e.g., Serpent), the burn: true flags do nothing. I can't easily tell Serpent not to deplete some nuclide. Instead, I would use flags to specify what components should be depleted.

I think there is value in this level of "middleware" between whatever nuclear data you bring and what physics codes you're trying to use. But I would encourage us to think about how we can make this a plugin specific behavior.

Or, in the spirit of this being more about "how" you're modeling the reactor (settings) vs. "what" you're modeling (the reactor via blueprints), maybe this needs to be settings behavior that plugins / applications can

Is it possible we could solve the user problem by just auto-defining defaults so the system never complains at you for missing nuclides in the list?

I don't think open source armi should set this default behavior.