Upgrade reactor data model to fully support an arbitrarily-deep composite design pattern

[ntouran]

Right now we have a sort-of hybrid Composite design pattern for the reactor data model, with the following players:

• ARMI's ArmiObject is the official pattern's Component (sorry, we have a naming conflict here)
• ARMI's Composite is the pattern's Composite (yay)
• ARMI's Component is the pattern's Leaf

Things that could be improved:

• ARMI's Leaf class is the parent of Component and Material. This should be cleaned up so that there's just Component and it' only used for Component. (this is #1007)
• It should be possible to add Components and Composites to any parent Composite arbitrarily.
  • I have a branch going that tried allowing Components to have children but I've decided that this approach will be more sustainable/realistic.
• Assembly and Block are special Composites. This is sort of ok but shouldn't be forced.

But for this ticket, let's just focus on the 2nd bullet: Allow deeper nesting of components and composites within composites.

This will support #477.

[john-science]

@drewj-usnctech Just FYI.

[jakehader]

@ntouran, I think there is a challenge associated with parameter definitions and assignments of a composite tree like this, at least in the context of how we are doing things. I think that every Assemblies and Blocks aren't really all that special, just that we have associates them in a certain way and then applied methods on those classes to make them special. If anything, the assembly and blocks are just short cuts that we take to associate the composites within together for fuel management and some axial "mesh" for Neutronics related calculations.

It would be interesting to me if we were to look at what it would mean to get rid of blocks and move to a mesh-based system for parameter storage.

I have a hard time knowing what we mean by an arbitrarily deep tree if we don't consider also rethinking assemblies and blocks. Also, will number density calculations start taking a very long time if we have like 4+ layers of composites? We might need to get a bit fancier with caching again?

[drewj-usnctech]

😍

I put a lot of my thoughts on some possible extension classes in https://github.com/terrapower/armi/discussions/960

I think there is merit to having the Composites be semi-physically grounded (e.g., an Assembly contains Blocks axially stacked together) because Monte Carlo codes modeling the full Reactor state need to know where things are. Another way of putting this, I don't think adding a free Component to an Assembly is a good move: where does that Component live in the reactor?

Blocks are kind of a mix of 0-D to 2-D collections of components already depending on how you view the geometry

• everything lumped somewhere in the block --> good for nodal diffusion codes that don't need the sub-assembly geometry
• everything concentric around the center of the block
• some smart pin building (I have N identical pins, put them on a lattice for me)
• user-defined lattice grid

will number density calculations start taking a very long time if we have like 4+ layers of composites?

probably? This could be an opportunity to look at distributing the composite tree navigation in parallel with threading, multiprocesing, or something extra. The number density of one component in a block doesn't depend on it's neighbor so they could be done in parallel

[john-science]

Bump. This is still super important.

Perhaps I need to pin this as High Priority for the next release.

[john-science]

And one year later... I still feel like this is really important for the over-all ARMI mission.