Create ARMI inputs for MHTGR-350 Benchmark #224
Labels
Comments
ntouran
added
documentation
ntouran
changed the title
|
Related to the TRISO fuel, is the current / planned support for a fixed structure reflecting the standard five-layer TRISO (fuel, buffer, inner pyrolytic carbon, SiC, outer pyrolytic carbon- https://en.wikipedia.org/wiki/Nuclear_fuel#TRISO_fuel) or a generalized structure? |
|
Well it's a known need at least but we don't have it quite scheduled. Let me make another issue to track that explicitly because it's so fundamental. I'll tag you and try to get you to help define requirements. (see #228) |
drewj-usnctech
added a commit
to drewj-usnctech/armi
that referenced
this issue
Nov 17, 2021
Provides a yaml-interface for - modeling particle fuel with arbitrary layers - multiple particle fuel types in the reactor - assigning particle fuel as children to some parent component We have been decently successful with these changes internally in that downstream plugins can see `Component.particleFuel` and perform actions based on their content. What follows is an overview of the interface, implementation, and a discussion of where to go next. Related to terrapower#228 and would support modeling the MHTGR-350 benchmark terrapower#224 This patch is submitted to kick-start a discussion on better ways to add this feature into ARMI, leveraging the domain knowledge of the ARMI developers and the "particle fuel aware" plugins internally developed at USNC Tech. Input interface --------------- ```yaml particle fuel: demo: kernel: material: UO2 id: 0 od: 0.6 Tinput: 900 Thot: 900 flags: DEPLETABLE buffer: material: SiC id: 0.6 od: 0.61 Tinput: 900 Thot: 900 ``` ```yaml matrix: shape: Circle material: Graphite Tinput: 1200 Thot: 1200 id: 0.0 od: 2.2 latticeIDs: [F] flags: DEPLETABLE particleFuelSpec: demo particleFuelPackingFraction: 0.4 ``` With this interface it's possible to define several specifications in the model and assign them to different cylindrical components. Implementation -------------- The particle fuel is stored as a child of the parent component, such that `<Circle: Matrix>.children` is used to dynamically find the particle fuel spec. We can't store the specification as an attribute because we have to support potentially dynamic addition and removal of children to this component. Something like `self.particleFuel = spec` that makes spec a child would also have to understand what happens if we remove the spec from the parent, e.g., `self.remove(self.particleFuel)`. What is then the outcome of `self.particleFuel` unless we always check the children of the matrix? By making the particle fuel spec a `Composite` and placing it in the `.children` of the parent, the spec is able to be written to and read from the database. Adds `Component.setParticleMultiplicity`. The method is called during block construction when the block's height is available to the matrix component (particle's parent). The multiplicity is determined from the matrix volume and target packing fraction. Note: the particle mult is, by design, for a single component. Unresolved issues ----------------- - Volume of the parent matrix is not reduced by the volume occupied by the particles. - No support for homogenizing regions that contain particle fuel - Various homogenization properties don't account for particle fuel (e.g., `Core.getHM*`) - Particle fuel is not included in some text-reporting, leading to statements like ``` [info] Nuclide categorization for cross section temperature assignments: ------------------ ------------------------------------------------------ Nuclide Category Nuclides ------------------ ------------------------------------------------------ Fuel ``` and ``` [warn] The system has no heavy metal and therefore is not a nuclear reactor. Please make sure that this is intended and not a input error. ``` - No provided routines for packing the particles into their parent. This could be facilitated with a dedicated packing plugin and an unstructured 3-D `SpatialGrid` class. It's burdensome to expect the user to define the exact location of _every_ particle every time. But, if some `Plugin` performs the packing and creates this spatial grid, the multiplicity is tackled, and you potentially avoid adding or removing particles as their parent expands or contracts. - Unsure if material modifications make their way down to the materials in the particle fuel spec. The implementation suggests it as the `matMods` argument is passed into the particle fuel YAML object constructor. But we have yet to stress test that Next steps ---------- This patch is submitted because we continue to find places where this approach does not play well with the rest of the ARMI stack. While Blocks that contain particle fuel are correctly able to compute their heavy metal mass by iterating over their children, which in turn finds the particle fuel. However, higher-level actions like `Core.getHM*` do not go down to the sub-block level, instead asking to homogenize Blocks. The homogenization methods are not yet aware of the particle fuel because they rely on `Component.getNuclides` which reports the nuclides for it's `Material`, and does not include the children. This approach is sensible because if I'm writing a neutronic input file and I can exactly model the matrix and it's particle fuel, I would expect `matrix.getNuclides` to return the nuclides for _just the matrix_. Then, being informed of the particle fuel, I can write those materials and geometry uniquely. However, codes that cannot handle particle fuel and/or work with homogenized regions (e.g., nodal diffusion) would need this homogenized data. Allowing `Component.getNuclides` to return the nuclides on the child particle fuel would support this case, but not the previous case. My speculation is that the optimal strategy lies somewhere in making the matrix object not a `Component` but a `Block` and having the ARMI Composite tree accept blocks that potentially contain blocks. I think this is valid using the API but the user interface would need some work. Having the matrix be a block would provide a better interface for homogenization and exact representation of the particle fuel. I think... Other related changes --------------------- Added `Sphere.getBoundingCircleOuterDiameter` so that the particle fuel composites can be properly added to the database. They need to be "sortable" other wise `Database3._createLayout` breaks trying to sort components. This enables the particle fuel spec to be added to and read from the HDF data file The material constructor is a more public function as it is needed both in creating `Components` but also in creating the particle fuel spec. Added `MATRIX` flag Signed-off-by: Andrew Johnson <a.johnson@usnc-tech.com>
This was referenced Jan 7, 2022
7 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In #223 we discussed how to model something similar to the MHTGR-350 described in this benchmark document. It would be nice to start building inputs representing this core as a good way to:
The text was updated successfully, but these errors were encountered: