Simplifying blueprints building with axial expansion

[albeanth]

For building assembly-based cores from blueprints, we have two options when it comes to block heights:

1. blueprints inputs have cold block heights and inputHeightsConsideredHot: False (i.e., the inputHeights setting gets "used")
   • during initial construction (before any axial expansion), the blocks are at the cold height and the number densities are at the hot temperature Thot.
   • So there is a disconnect between the two and results in the wrong mass.
   • To correct the mass, we first adjust the number densities to the cold temperature (increase them). The mass is now correct.
   • Then, we expand the block using the axial expansion changer (during construction of the blueprints) and it does the correct height and number density expansion (conserving mass with the correct mass).
2. blueprints inputs have hot heights and inputHeightsConsideeredHot: True (i.e., the inputHeights settings is "unused" because it's the default value)
   • during initial construction, the blocks are at the hot height and number densities are at the hot temperature.
   • there is no disconnect and the mass is correct. no axial expansion functionality required.
   • this is the legacy approach and requires users to do thermal expansion by hand and manually input hot heights in the blueprints.

Since (I think) option 2 is no longer used very much, I think it would be nice to consider the following breaking change.

1. remove option 2 from ARMI,
2. remove the inputHeights setting, and
3. simply require that the heights inputted in the blueprints match Tinput

This new change would simplify the blueprints inputs options and core construction process/assumptions, in my opinion.

This would indeed break inputs from many years ago, but I personally don't think new versions of ARMI need to provide backwards compatibility that far. Just my 2 cents though.

I'm curious to know what others think.

[keckler]

Yes, I think this is the right path forward. I don't necessarily think this is high priority, but it is a change that I would like to see. My most major concern with the current implementation is that the non-physical option (inputHeightsConsideredHot: True) is the default. I would certainly expect that the default corresponds to False, because that is the way most modeling works and the True option will almost never give you a simulation that aligns with reality if you have any sort of TH feedback.

I think in general the thermal expansion stuff could use an overhaul. The framework carries around a lot of baggage due to the way thermal expansion was initially implemented.

[albeanth]

I don't necessarily think this is high priority, but it is a change that I would like to see.

Agree and agree.

My most major concern with the current implementation is that the non-physical option (inputHeightsConsideredHot: True) is the default.

Yeah this choice was made at the time for backwards compatibility. When this was introduced, if we did it the other way around, all of the input files that existed would just break. But I think we're far enough away from there now that we can make the switch and yank the whole thing out.

I think in general the thermal expansion stuff could use an overhaul. The framework carries around a lot of baggage due to the way thermal expansion was initially implemented.

I'm curious to know if there are specifics you have in mind?

[albeanth]

I think in general the thermal expansion stuff could use an overhaul. The framework carries around a lot of baggage due to the way thermal expansion was initially implemented.

I'm curious to know if there are specifics you have in mind?

@keckler bump

[keckler]

I probably intended this comment to be about thermal expansion generally, not axial specifically. A couple things off the top of my head:

1. The separation between radial and axial thermal expansion is, in the first place, odd. The two are obviously intertwined from a physical perspective, so being able to have one without the other makes little sense, and is therefore confusing
2. The only way to "turn off" radial thermal expansion is to set Thot = Tinput on every component. This is a big burden to the user, and even still will only actually work if TH feedback is not being used (more on this in the next point)
3. Radial thermal expansion cannot actually be turned off if TH feedback is implemented (i.e. if component temperatures are updated during the run). The inability to completely turn off radial thermal expansion is, IMO, a serious drawback. It means that one cannot even actually assess the impact of the radial thermal expansion being included in the calculation.
4. The fact that one has to specify Thot on every component, even for simulations of room temperature models, is a burden.

At the core, I think that a lot of weird problems that we have with ARMI come from the fact that the thermal expansion stuff is too deeply embedded into the framework, when in reality it should be a plugin just like all other physics models. It makes it so that thermal expansion complicates pretty much everything in an ARMI-based simulation, when the reality is that most people who model nuclear reactors don't even care about thermal expansion for steady-state simulations.

[bsculac]

This would indeed break inputs from many years ago, but I personally don't think new versions of ARMI need to provide backwards compatibility that far. Just my 2 cents though.

I say anyone who needs the old functionality can check out the old portion of the tree.

I would like to see the component input temperature be used as the input temperature for all related parameters. I feel like it's a bit of a trap to have an input temperature specified for a component but some of the data is assumed to be provided at hot temperatures (definitely not biased on this, nope 🙃). In general I would like all the expansion stuff to be able to start from cold/initial and go to hot. That feels intuitive to me.

While we are thinking about any sort of overhaul to inputs/how materials are handled, I am going to heavily advocate for adopting a materials input system like what is discussed in #767 (comment). This isn't really necessary for a change to the axial expansion changer, but I want to make sure whatever we do here fits with what is discussed in the link.

[albeanth]

@john-science do you have thoughts on this discussion? Removing this would be a great simplification for users and untangle some downstream dev work.

[john-science]

Obviously, I like the idea.

It is a source of confusion that ARMI's blueprints have some dimensions input as hot and some as cold. What a poor design. I'm all for the change purposed, to simplify by removing option (2). Great.

I would need one of you to help me scout out and see how to correct for this change in our internal projects. Downstream is where I think the work will be.

[albeanth]

@john-science this popped back into my head and I'd like to bubble it back up for consideration.

[john-science]

Well, I still like the idea. I guess I think this is a medium-sized task, so perhaps we can talk offline about timelines and schedules?

[albeanth]

Sure. Yes. Let's. Plop something on my calendar?