Inconsistency with 'sfp' SystemBlueprint object and o.r.core.sfp

The problem/observation

• in marching through armi/reactor/tests/test_reactors.py::loadTestReactor, there are two designs stored in bp.systemDesigns, Core and sfp. https://github.com/terrapower/armi/blob/55766354067d8b1cffed02a48d36cd5d59c10718/armi/reactor/reactors.py#L145-L147
• The core object is built just before this for loop here, https://github.com/terrapower/armi/blob/55766354067d8b1cffed02a48d36cd5d59c10718/armi/reactor/reactors.py#L143-L144. For loadTestReactor it gets 73 assemblies in core and 8 blueprints assemblies.
• The sfp object is then built in structure.construct. It contains the 4 sfp assemblies defined in the input and 8 blueprints assemblies.

After both objects have been constructed, when r is returned the sfp object seems to be missing.

• r.sfp is not a thing…
• r.core.sfp is an “AssemblyList object: Spent Fuel Pool”, but contains no assemblies.

Then in loadTestReactor, we put stuff into r.core.sfp https://github.com/terrapower/armi/blob/55766354067d8b1cffed02a48d36cd5d59c10718/armi/reactor/tests/test_reactors.py#L188-L191

• So, now we have these 10 assemblies in r.core.sfp, but the original 4 assemblies from the input are no where to be found (at least I can’t find them).

Impacts

For the most part, I don’t think this a huge deal (otherwise we would have found it by now). But, it does raise an issue if a user assigns assemblies in the SFP via the inputs or wants to see what assemblies are in the sfp on a database load.

• Since there isn’t a registered r.sfp object and r.core.sfp doesn’t get written to the database (at least in my tests it doesn’t), then there is no way to check what is actually in the sfp on a database load (either put in via a shuffle or initialized there via an input).

  • I imagine this is certainly something we’ll want to support. Knowing what is in the SFP feels important. Especially when we’re shuffling assemblies out of the core.

• There is a disconnect between where ARMI stores SFP assemblies from inputs (in Core: sfp object) vs where it stashes them as a result of shuffling (in r.core.sfp).

• This also wreaks havoc a bit on the global assem counter as it has been ticked to account for SFP assemblies, but they aren’t anywhere to be found. https://github.com/terrapower/armi/blob/55766354067d8b1cffed02a48d36cd5d59c10718/armi/bookkeeping/db/tests/test_database3.py#L331-L351

[ntouran]

SFP was around before the reactor could have child systems and is kind of shoe-horned in for transitional reasons. It’s supposed to end up being just another system alongside the core as a child of the reactor. And r.sfp might be useful as a convenient shortcut for that child, kind of like how r.core is a convenient shortcut for the core system.

We anticipate more systems like this being added to models for other non-core things, like pumps and heat exchangers, etc.

[keckler]

So the increased memory requirements that come with enabling this setting may not actually be worth much.

Well, I would disagree with this statement. Just because they aren’t written to the database doesn’t mean that the SFP assemblies can’t still be used during the run. In a non-restart run, they can definitely still be valuable.