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?

[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.