How can we better support a wider range of reactors?

[john-science]

I believe the ARMI framework was originally too focused on pin-type reactors with hex assemblies, so that will go on the list. But where at the other frustration points for non-Natrium users/developers?

• makes too many hex-assembly assumptions in the Core
• does not support ex-core structures
• enforces "Axial Expansion Changer", even if the reactor does not have assemblies
• assumes people want to do any thermal expansion at all
• assumes people will be using a lattice physics code
• assumes users will want a burn chain defined in the framework
• assumes nuclide flags are useful for everyone

[john-science]

@drewj-tp @keckler @sombrereau @alexhjames @jeffbaylor What do YOU guys think? Help me build this list!

[drewj-tp]

cc @slee-USNC @dturkoglu

[john-science]

Hey @drewj-tp , it looks to me like a couple of your points above could be solved by just tweaking your App. Maybe I could build a tutorial example for this. But let's you do: class MyApp(App), you are subclassing App and so you get a default set of plugins:

armi/armi/apps.py

Line 87 in f3d16df

def __initNewPlugins(self):

armi/armi/apps.py

Lines 98 to 106 in f3d16df

	for plugin in (
	cli.EntryPointsPlugin,
	bookkeeping.BookkeepingPlugin,
	fuelCycle.FuelHandlerPlugin,
	fuelPerformance.FuelPerformancePlugin,
	neutronics.NeutronicsPlugin,
	safety.SafetyPlugin,
	thermalHydraulics.ThermalHydraulicsPlugin,
	reactor.ReactorPlugin,

Well, when in your MyApp class you could over-write the default __initNewPlugins() method and just comment out the ThermalHydraulicsPlugin and maybe even the NeutronicsPlugin.

I'm just thinking aloud, but if some of your problems are that ARMI forces certain functionality through the default plugins in the default App, it is meant to be very easy to remove plugins from the default App.

Thoughts?

[drewj-tp]

That could be useful. I personally get squeamish overwriting methods with leading double underscores.

It doesn't really eliminate the problem in my other comment about Block does too much SFR specific stuff because all block-like things still have to inherit from Block. But it is a way to help ARMI do less by default

[john-science]

I personally get squeamish overwriting methods with leading double underscores.

Let's not worry about that right now. If it solves a problem, I can remove the double-underscore or change the system at a higher-level to make this a part of the ARMI API.

It doesn't really eliminate the problem in my other comment about Block

Sure, sure. I wasn't suggesting it would solve ALL your issues. But this seems like an EASY solution to turn off: Axial Expansion, thermal expansion, and lattice physics. Or so it seems to me.

[drewj-tp]

Some cherry-picked examples

• Block.__init__ sets bondRemoved, displacementX and displacementY to zero which mean a lot to SFRs but not to things that aren't SFRs
• Block.p.puFrac being set at block construction makes a lot of sense for some fast reactors, mox-fueled reactors, but not as much (at construction) for LWRs
  • This is more generally useful through depletion to look at plutonium buildup. But not always the case.
• Block.p.smearDensity doesn't make sense for non-pinned reactors
• Block.getNumPins is a thing that makes sense for pin-type reactors
  • But there's also Block.p.nPins
• HexBlock.verifyBlockDims assumes you have wire, duct, and clad components or else it yells at you.
• HexBlock get/has pin pitch assumes you have clad and wire or else your block is not well defined

[john-science]

Yeah, a better organization might have been (just for example):

• Composite
  • Block
    • PinnedBlock
      • PinnedHexBlock
      • PinnedSquareBlock

More layers of abstraction would give us more control over the methods and parameters on these objects. I can agree to that.

It would also, bonus, make our classes and modules much shorter and easier to parse.

[alexhjames]

I don't have many things with clear things to change but here's what I can think of:

• Philosophically, ARMI is very geared around running ARMI with physics plugins to generate results. Where possible, it would be good to embrace ARMI's additional role as a data model that people look at to get the results of the physics analyses. ARMI and it's database is a very convenient form to pass around at analysis interfaces to communicate data. For example, some of the problems with loading multiple reactors. From a data model aspect, this is a reasonable ask because you need to look at multiple things for data through time, but isn't as relevant if you're just thinking in terms of running an ARMI simulation for a single reactor.
• Axial expansion assumes free expansion which isn't necessarily true depending on assembly design.
• ARMI assumes that all physics will be run at a single mesh snapshot and then things are updated, then things are run again at the next mesh snapshot. This allows for things like remeshing between time nodes, or having assemblies appear in the core during a time node in the middle of the analysis. This is not true for other physics codes which need to simulate through time and therefore have a static mesh that is set at the beginning of time. There isn't necessarily something to change right now but maybe there could be other helper methods that say interpolate results back on the BOL mesh elevations, or that collect all assemblies that will every be in the core at any point in the analysis so that they can be meshed at BOL (and put in like a load queue until they're needed).
• ARMI does poorly with spatially varying quantities. It is common to find errors every so often related to a spatial varying quantity not changing when it should have (like grow to full core, or shuffling, etc). There are lots of assumptions about smearing things over the block/assembly which are not valid for all parameters.