tl;dr It would be great if Blocks could contain things other than components for models with lots of axial heterogeneity

This is related to a few discussions / issues that have already been raised

• Create ARMI inputs for MHTGR-350 Benchmark #224
• Make example showing how to make blueprints objects in a script #225 // Programmatic inputs example #226
• Add component group capabilities #525
• Allow blocks to contain composites as well as components on the reactor composite model #503
  • Very very similar. Maybe a duplicate / concrete example?

Use case

Consider two examples

1. LWR fuel pellets
2. HTGR fuel compacts with homogenized matrix and particle fuel

These are (basically) right cylinders containing a homogenous material. Something ARMI supports pretty easily. Make a Circle Component, fill it with a Material, place it in a Block and let the height of the Block define the height of the rod stack or segment of the rod stack. Not too complicated.

But if I am starting with a fuel pellet spec that defines one pellet, there isn't a direct way to model that singular pellet without making each Block one pellet tall. Then each Assembly would have hundreds of Blocks, each on the order of cm. Maybe not great for diffusion codes to have cm tall nodes.

Say I also want to define an unfueled region where no particle fuel exists in the compact. Now I have three axial regions per compact

1. Lower unfueled graphite disk
2. Middle region with
   1. Homogenized matrix + particle fuel cylinder, surrounded by
   2. Unfueled graphite annulus
3. Upper unfueled graphite disk

Now the number of blocks per assembly grows by 3x, with the unfueled blocks being < 1 cm tall. And there's far more bookkeeping to keep track of xs types and material modifications for the fueled and un-fueled regions

Possible solution path

Taking the MHTGR as an example, there are spec sheets and figures describing individual compacts

and how these compacts fit into the total fuel element

we could cast some of these specifications into component groups and sub-blocks with some new / new-ish blueprint sections

componentGroup

Like a block but kind of using the "free component" definition idea from #505

A single Compact is defined as a 1-D stack or block-like structure with three layers (lower unfueled, middle, upper fueled)

componentGroup:
  unfueled:
    disk:
      shape: Circle
      material: Graphite
      od: 0.6223  # compact radius from Table 4
    gap:
      shape: Circle
      material: Helium
      id : disk.od
      od : 0.635  # compact gap radius Table 4
  fueled:
    matrix:
      shape: Circle
      material: HomogFuelAndMatrix
      od : 0.6  # some inner unfueled region thickness
    shell:
      shape: Circle
      material: Graphite
      id: matrix.od
      od: 0.6223  # compact radius from Table 4
    gap:
      shape: Circle
      material: Helium
      id : shell.od
      od : 0.635  # compact gap radius Table 4

stacks or rods

Rods has a lot of meaning in the nuclear world so it might be a better (or worse) way to describe a 1-D axial collection of things?

But take the componentGroup definitions from above and stack then together into one compact. Then stack compacts to make a fuel rod.

stacks:
  compact:
    groups: [unfueled, fueled, unfueled]
    heights: [0.5, 2, 0.5]
  fuel rod:
    groups: [compact, compact, ...]
    heights : [3, 3, ...]

🚨 potential problem if sum of heights in compact definition != corresponding entry in fuel rod.heights. Maybe a way to infer heights from the item in the groups entry?

Block

Now we start touching on blocks with things other than components (#503) to make a fuel element. From the benchmark you can see the element is a hexagonal graphite block with a ton of holes drilled in it.

Define the bounding hexagon as a duct with ip != 0 and then some inner DerivedShape to capture all the holes

blocks:
  fuel element:
    duct:
      shape: Hexagon
      material: Helium
      ip: 14
      op: 14.172
    background:
      shape: DerivedShape
      material: Graphite
# put rod stacks, coolant holes
    fuel rod:
      child: fuel rod
      latticeIDs: [F]
    coolant:
      shape: Circle
      material: Helium
      od: 0.635  # Table 3 small coolant hole size
      latticeIDs: [C]

Also would want some component for the lumped burnable poisons on lattice sites but the idea would be the same.

❓ How to specify that the object on the lattice site is not a Component and does not have a Shape, Material, temperature inputs? I went with child

Final assembly

Since fuel element is a Block, it could go right into the Assembly section nicely. But we get the same problem with heights as before. The height of one fuel element is defined by fuel rod which is defined by the height of a compact, which depends on the height of each layer in the compact. If there was a "magic" value to instruct ARMI to "infer" the height of something in the stack based on the contents, we could define the assembly with

assemblies:
  fuel assem:
    blocks: [fuel element, fuel element]
    heights: [INFER, INFER]

I think it's totally valid to only apply xs types and material modifications to entries in assemblies.ANY.blocks, as you may have all the compacts (or fuel pellets) in one fuel element (or axial section of the fuel bundle) have the same enrichment, but allow some axial variation in enrichment. The challenge with material modifications would be passing it down to children of the Block to do e.g., enrichment in the homogenized fuel + matrix compact mixture.

Possible design concepts

Like the proposed stack concept, an Assembly is also an ordered collection of Composite objects with some heights. So maybe a shared parent class? That also could help some of the yaml builder operations (error checking if height of a child is greater than the sum of grand-child heights, inferring and setting height of a child)

A Block is another form of a ComponentGroup (proposed in #503) so maybe there's some sharing / inheritance that could be done there?

I still think there's a lot of value in the composite tree going Reactor -> Core -> Assembly -> Block. I guess the big change is now (like in #503) blocks can have components or something else as children. And keeping blocks as homogenizable things for nodal diffusion codes helps not break back compatibility. Also keeping various tree traversal methods (Block.get* works with component and stack / component-group children)

In theory, there's a way to do this that any input file that does only has components on blocks sees no changes.

Additional hurdles

Thermal expansion? How does expansion of a fuel pellet in a rod impact the perceived height of the Block that contains it?

You can imagine that the total composite tree could get massive, both in terms of depth and width if this goes far enough