Extension of composite tree to include "stacks" of block-like things

[drewj-usnctech]

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

[john-science]

Discussion Notes: Working on the Above

@ntouran @drewj-usnctech

We're currently envisioning the work as happening in three major phases:

Phase 1 - Fix the ARMI Composite Model Structure

Let's fix the ARMI Composite pattern.

• Material should not subclass Leaf (or any other ArmiObject).
• Leaf and Component should be merged (and called Component)
• Component should still be the "leaf" of our composite model (subclass ArmiObject directly)
• Allow Composites to have infinitely deep sub-Composites

Phase 2 - Model a particle-fuel-like Compact

• It will have some particle fuels inside a volume of graphite
• This is not really doable with ARMIs current composite model, thus Phase 1.
• We will test out modeling such a structure, to see if our new composite model is sufficient.

Phase 3 - 1D Grid of Compacts

• 1D grid of the above Compacts, stacked vertically
• This will be a lot like an Assembly, but not exactly the same, perhaps.

TODOs

Here are some first steps to take:

1. Storing 1D grid in DB - ticket incoming
2. Merge Leaf and Component
3. Composites should have sub-composites
4. Material should not subclass Leaf
5. Research: Think about test cases for Phase 3

[drewj-usnctech]

Thanks @john-science!

From the Tech side, we've got the following handles for tagging, discussions, and hopefully closing tickets

• @dturkoglu
• @cbroman-usnctech
• @slee-USNC

I'll have the issue up for "Storing 1D grid in DB" by EOD tomorrow. And I'm good to poke at it, research solutions, and maybe implement it

[drewj-usnctech]

Re Phase 2

The will be arranged in a hex lattice

I just want to make it clear that for reactors like the MHTGR 350, the compacts will be on a hexagonal lattice inside the fuel element. But that's not the same as saying the particles inside the compact are on a hexagonal lattice. Nor that all reactor concepts will have hexagonal lattices of compacts. It's a good first model to solve and build towards. But it should not be backed in to the solution

[drewj-usnctech]

Something that came up in a chat today: having a Compact composite class with strictly two children: a matrix Component and something to represent the particle fuel - #1055. The matrix would define the shape of the compact (cylinder, potentially spherical for pebble bed reactors). The Compact would / could be a child of a Block along with it's sibling Component children. Would require what we're calling arbitrarily deep composite tree (#1008) or at least a little deeper.

Thinking of the MHTGR-350 reactor (#224) you could think of a fuel element as a Block with the following children

block
  - circular coolant component
  - fuel compact composite
    - circular matrix component
    - particle fuel composite
      - spherical fuel kernel
      - spherical buffer
      - spherical ipyc
      - ...

Then, if the compact is placed on a lattice grid, the multiplicity of the compact is easy to get: number of lattice sites. And the matrix could have a multiplicity of (1 - packing fraction) to account for the volume occupied by the particle fuel. And the particle fuel (and subsequent layers) would have a multiplicity on the order of thousands to reflect the number of particles in one compact

[drewj-usnctech]

Follow up from a chat with @john-science @cbroman-usnctech and @slee-USNC

We've got something internally that we're ready to push out. But it's would be a pretty large PR in it's own right. So, in favor of breaking it into smaller PRs, here's what I'm considering

1. PR for making the composite tree a little less tied to the Assembly -> Block -> Component paradigm. This would touch and likely close Remove reliance on Composite.iterComponents #1211
2. Introduce the Compact and ParticleFuel classes to be buildable from API only. No blueprints. This would likely close Provide a Compact class to hold particle fuel and matrix #1134 and Dedicated Composite sub-class for modeling particle fuel #1055

• These two are pretty linked but we could introduce the ParticleFuel class prior to the Compact.

4. Building these from blueprints.

The internal solution we have to 3 is largely derived from #477 and could use some improvement. I think having some discussion on how the blueprint should look prior to closing out 3 would be very fruitful