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
231 stars 90 forks source link

Resolving axial component linkages for blocks with multiple identical component definitions #769

Open keckler opened 2 years ago

keckler commented 2 years ago

In the current implementation of the axialExpansionChanger, linkages between axially-continuous components are inferred via a set of criteria: https://github.com/terrapower/armi/blob/a4b54cac85dbf90ee8b28aa94fce51ab31593efc/armi/reactor/converters/axialExpansionChanger.py#L480-L529

However, at least one case slips through the cracks of this logic. If one defines a block with multiple independent pins that have the same exact geometry and material class, but that utilize different enrichments (or something else defined via the material modifications).

In such a case, the axialExpansionChanger will not be able to disambiguate the identical components, and when trying to link them to the components in the blocks above/below, it won't know which ones to link up and it will crash.

This might sound like an unlikely scenario, but I am trying to model more than one assembly that has these properties.

My first thought is that in such a complicated scenario, we might force the user to use an explicitly-defined grid for their block, as is demonstrated in the LWR blueprints tutorial: https://terrapower.github.io/armi/tutorials/walkthrough_lwr_inputs.html

That would make the various pin positions completely unambiguous, and the linkage relationships should be completely obvious.

@albeanth @jakehader @onufer

keckler commented 1 year ago

@albeanth are there any thoughts on this? I am getting to a point where this is actively blocking, so I'm hoping we can make an effort to resolve this. More than willing to help here.

keckler commented 1 year ago

The nice thing about the option that I mentioned above (to base the linking off of a block's grid) is that blocks that look "normal" already get a grid auto-defined when the block is instantiated: https://github.com/terrapower/armi/blob/76031431c1d96e17c1135874926bd24ac92a3e65/armi/reactor/blocks.py#L2054-L2115

jakehader commented 1 year ago

Thanks for pinging on this again @keckler. @albeanth let's set up a discussion internally about how to handle this and maybe make a simple use case that can serve as a unit test. I feel like grids would be a natural way to connect components together but I have to admit that I haven't even studied the current implementation to know if this is a good fit or if this would be a significant change.