Allow blocks to contain composites as well as components on the reactor composite model

[ntouran]

I was trying to make a "block of blocks" on the composite model (to do a handy unit cell conversion for Hallam while maintaining identity of the constituents) and a lot of issues related to the composite model come up that may make sense to work on to a degree. Specifically I want to make a new 1-D converted block that is made up of several rings, each containing homogenized versions of multiple components.

This kind of issue has caused other various troubles in the past:

• The Batch class
• Bad treatment of 3-D or weird shaped components
• Complex/design-specific block converters

It could also be useful e.g. for TRISO fuel #228

Thus we think it's a good time to polish up the composite pattern a bit to be a bit more arbitrarily nested.

⚠️ There are a lot of related composite issues that are peripheral to this so let's try to do step-wise improvements in the right direction.

Essential Truths:

• Component objects should be considered the Leafs of our tree. (Right now we do have a Leaf object in composites.py but it is 2 lines long).
• Core and Assembly are extremely valuable abstractions for many things ARMI can do, but they should not be essential in the generic tree of ArmiObjects.
• Block objects are relatively close to Composite objects in traditional composite patterns already.

Actions to take now

• Attempt to reconcile the Composite and Block classes:

  • What is a block, aside from a Composite with perhaps a bounding shape/hull? Axial heights within an Assembly are the first thing that comes to mind when thinking about the "weirdness" of a Block w.r.t. a more general Composite.
  • Move Block methods to Composite as appropriate (done largely here)
    • Transition block to use getChildren instead of getComponents
  • Design specific stuff on Blocks and related should continually be funneled to more design- or physics-specific plugins as functions that take blocks as arguments.

• Allow components to be specified in input without a block (Allow components to be input outside of a block in blueprints #504)

• Delete Leaf and write docs formalizing Component as our leaf

• Clean up ArmiObject to not know about children.

• See if a bunch of Component methods don't make sense directly on ArmiObject

• Think of better name for ArmiObject.

  • GOF uses Component which we already use as a physical primitive.
  • What about PartBase, PartGroup and Part for ArmiObject, Block/Composite, Component? Or perhaps ComponentBase, ComponentGroup, Component?

Important related issues that may need concurrent resolution:

• Shapes and dimensions. Blocks probably should have a shape rather than be one (e.g. get rid of HexBlock).
• Params are based on class and that might be confusing

[drewj-usnctech]

Having Components as leafs feels like a good design choice. A lot of the comments reinforce some (maybe incorrect) thinking I've had about the ARMI design

• Components are simple(ish) well-defined shapes represented by a single material
• A physics code with unlimited geometry fidelity should be able to resolve all Components (e.g., Monte Carlo code)
• Blocks are collections of Components
• A physics code with reduced geometry fidelity (e.g., nodal diffusion) should be provided homogenized Blocks (or Assemblies)

This approach also explains some of the difficulties in #477 where Block.getHM* doesn't traverse down to the particle fuel: it introduces weird behavior for Component.getNuclide* methods where you would have to take potential child components into account.

And my two cents would be that

ComponentBase, ComponentGroup, Component

feels natural and self-describing

[ntouran]

I have added the concept of ComponentGroups to blueprints for your consideration in #525. This is still a half-implementation that doesn't quite add the component groups to the blocks but it's an attempt at least.

I'm kind of imagining that you could define the kernel + buffer as a component group and then put it in a block where the graphite is a DerivedShape that fills in the extra space.

[john-science]

I have various and sundry thoughts:

• "It could also be useful e.g. for TRISO fuel" - love it
• "Delete Leaf and write docs formalizing Component as our leaf" - awesome
• "Think of better name for ArmiObject" - Meh, I'm indifferent here.

Does this help us getting any closer to modeling your typical light water reactor? Long term, do we need to add any flexibility to our geometry/component models to make that leap? (Long term thinking, for sure. But we're talking architecture, and I know that's on our high-level goals.)

[ntouran]

Shapes and dimensions. Blocks probably should have a shape rather than be one (e.g. get rid of HexBlock)

Ok so as I've been thinking more about #228 and #477 while working through #525 and reading @drewj-usnctech's feedback, I think this little quoted point is really important and probably has to go through.

I am fairly close in #525 to being able to re-implement the ParticleFuel class from #447. What we need is to be able to make a ComponentGroup that has a shape (a Circle in this case), and then is made up of the TRISO particles + the derived shape matrix. This can be input roughly identically to how Drew did it in #477, as shown below (with slightly more generic language).

The triso compact child of the fuel2 block is a kind of Composite that has to have that shape element to it in order to do its magic during construction:

• Compute the multiplicities of TRISO particles based on the blend/packing fraction and total volume
• Set the matrix volume to the space that's left

The blocks have shape, and the components have shape, but composites can't currently have shape. Thus I think we need to change blocks and components both under the hood so that they and all other subclasses of ArmiObject HAVE shapes rather than being shapes. This will be a pretty major refactor but can probably be done without changing any actual results or input.

Then this kind of thing will be pretty simple within the normal data model:

blocks:
    fuel2: &block_fuel2
        triso compact: 
            shape: Circle
            blend: triso particle
            blend frac: 0.350
            material: Graphite
            Tinput: 25.0
            Thot: 600.0
            id: 0.0
            od: 1.2446
        duct: 
            shape: Hexagon
            material: UZr
            Tinput: 25.0
            Thot: 600.0
            ip: 9.0
            mult: 1.0
            op: 10.0
        coolant: 
            shape: DerivedShape
            material: Graphite
            Tinput: 25.0
            Thot: 600.0

components:
    # triso dims from Table 4 in TRISO benchmark
    kernel:
        shape: Sphere
        material: UZr
        Tinput: 25.0
        Thot: 600.0
        id: 0.0
        mult: 1.0
        od: 0.010625
    buffer:
        shape: Sphere
        material: Graphite
        Tinput: 25.0
        Thot: 600.0
        id: kernel.od
        mult: 1.0
        od: 0.015625
    ipyc:
        shape: Sphere
        material: Graphite
        Tinput: 25.0
        Thot: 600.0
        id: buffer.od
        mult: 1.0
        od: 0.017375
    sic:
        shape: Sphere
        material: SiC
        Tinput: 25.0
        Thot: 600.0
        id: ipyc.od
        mult: 1.0
        od: 0.019125
    opyc:
        shape: Sphere
        material: Graphite
        Tinput: 25.0
        Thot: 600.0
        id: sic.od
        mult: 1.0
        od: 0.021125

component groups:
    triso particle:
      kernel:
        mult: 1
      buffer:
        mult: 1
      ipyc:
        mult: 1
      sic:
        mult: 1
      opyc:
        mult: 1
        

[ntouran]

I made #540 to track this subtask

[ntouran]

For further clarification, the driving need here is be able to add shape-related information to general Composites in addition to just Blocks and Components.

It must be stated that the concept of geometry-specific HexBlocks, CartesianBlocks, etc. is also useful and should probably not be removed, at least yet.

[john-science]

@drewj-usnctech

Hey man!

If you could define your reactor using a format like the one above, would it be sufficient for your needs?

We use phrases like "blend" and "component group" to be more general than "particle" or "particle fuel", for other uses.

(Obviously, we are planning on talking together about supporting this completely in the database and for the ability to get masses, volumes, and other things recursively.)

The idea here is that Components can have Components in them, and on the blueprint side we signal that with the keyword "blend".

[john-science]

NOTE: We have some concern to be careful with expansion and mass conservation.

[drewj-usnctech]

@john-science @ntouran this looks great. I think we could use this to design the particle fuel specs. One potential concern, maybe related to

NOTE: We have some concern to be careful with expansion and mass conservation

if the matrix material expands, you could potentially have a case where you have introduced more fuel into the reactor.

A potential fix would be to have something like a plugin very early on that converts these packing fractions to multiplicities. Taking into account the size of the component in the block (e.g., same fuel compact in two Blocks, each with a different block height). Then, even if your matrix expands or contracts, you have a fixed multiplicity