search

terrapower / armi

An open-source nuclear reactor analysis automation framework that helps design teams increase efficiency and quality
https://terrapower.github.io/armi/
Apache License 2.0
232 stars 89 forks source link

Dedicated Composite sub-class for modeling particle fuel #1055

Open drewj-usnctech opened 1 year ago

drewj-usnctech commented 1 year ago

I've been thinking about how our downstream clients will detect the presence of particle fuel. Looking at discussions in

🚨 a lot of the earlier description / design / acceptance criteria is duplicated in and moved to #1134 🚨

Encourage a specific Composite subclass where the children are all spheres to model one particle fuel object. Some specific design concepts / requirements

  1. Children are only allowed to be Sphere Components
  2. Multiplicity of each child is one as there is one layer of each material with a certain radii in a kernel. For your "standard" TRISO (#228), this would be
    • fuel kernel
    • porous graphite layer
    • inner pyrolytic graphite
    • inert layer of SiC
    • outer pyrolytic graphite (same Material as inner pyrolytic graphite, but with different id and od parameters
  3. Multiplicity of the ParticleFuel itself can be greater than one to signify the number of a given particle in the parent Compact - #1134
  4. Multiplicity must be able to be serialized / deserialized from database
    • so stored as a parameter?
  5. Layers are not allowed to be overlapping
  6. Support for linked dimensions (as fuel kernel expands, inner diameter of next layer increases)
    • Not trying to add in a fully feature TRISO expansion routine, but linked dimensions will help support that
  7. Iteration goes from innermost layer to outermost layer
  8. Item access via __getitem__ picks up the given layer, so pf[0] would be the innermost, pf[-1] would be the outermost, etc.
john-science commented 1 year ago

I'd be happy to have a ParticleFuelCompact class in ARMI. At a guess, we'd want to wait until #1008 is done to try implementing this.

We would want to support it in the blueprint readers, too. That's always a fun part.

drewj-usnctech commented 1 year ago

Realized that the design here is largely duplicated from #1134 so I updated the description and acceptance criteria to be specific to the thing that models one particle fuel particle. Let me know if you'd like to see any changes @john-science @slee-usnc

john-science commented 2 weeks ago

I believe the solution goes something like this:

  1. All Composites must be able to contain recursively more Composites
  2. Free the methods in Block to realize their new full potential as deep Composite.
  3. We create a base Pin (or FuelPin) Composite to go in Blocks
  4. We create a base ParticleFuel (or TrisoFuel) Composite to go in Blocks

From my perspective, (1) seems like the first step, regardless.