Extension of composite tree to include "stacks" of block-like things #960
Replies: 3 comments 2 replies
-
Discussion Notes: Working on the AboveWe're currently envisioning the work as happening in three major phases: Phase 1 - Fix the ARMI Composite Model StructureLet's fix the ARMI Composite pattern.
Phase 2 - Model a particle-fuel-like Compact
Phase 3 - 1D Grid of Compacts
TODOsHere are some first steps to take:
|
Beta Was this translation helpful? Give feedback.
-
Something that came up in a chat today: having a Thinking of the MHTGR-350 reactor (#224) you could think of a fuel element as a
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 |
Beta Was this translation helpful? Give feedback.
-
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
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 |
Beta Was this translation helpful? Give feedback.
-
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
Use case
Consider two examples
These are (basically) right cylinders containing a homogenous material. Something ARMI supports pretty easily. Make a
Circle
Component
, fill it with aMaterial
, place it in aBlock
and let the height of theBlock
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 eachAssembly
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
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
andmaterial modifications
for the fueled and un-fueled regionsPossible solution path
Taking the MHTGR as an example, there are spec sheets and figures describing individual compacts
![image](https://user-images.githubusercontent.com/83778714/200374360-2ecc7218-6551-4456-8625-300133c4b5bd.png)
![image](https://user-images.githubusercontent.com/83778714/200374478-67a1c846-9477-48e1-9c3d-40628efbd10e.png)
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)
stacks
orrods
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.🚨 potential problem if sum of heights in
compact
definition != corresponding entry infuel rod.heights
. Maybe a way to infer heights from the item in thegroups
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.
![image](https://user-images.githubusercontent.com/83778714/200384795-852e41fb-2053-4119-9d46-d3203d88b21c.png)
Define the bounding hexagon as a duct with
ip != 0
and then some innerDerivedShape
to capture all the holesAlso 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 aShape
,Material
, temperature inputs? I went withchild
Final assembly
Since
fuel element
is aBlock
, it could go right into theAssembly
section nicely. But we get the same problem with heights as before. The height of onefuel element
is defined byfuel 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 withI think it's totally valid to only apply
xs types
andmaterial modifications
to entries inassemblies.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 withmaterial modifications
would be passing it down to children of theBlock
to do e.g., enrichment in the homogenized fuel + matrix compact mixture.Possible design concepts
Like the proposed
stack
concept, anAssembly
is also an ordered collection ofComposite
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 aComponentGroup
(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
Beta Was this translation helpful? Give feedback.
All reactions