@keckler I don't suppose you could provide an example plot for Tony?

@albeanth Do you have any thoughts on this? (Also, should we do a round-up of all the axial expansion-related tickets that are lying around?)

Yeah, I can easily get him an example of the issue. I can send privately.

Here is a redacted example

It seems to me that the best way to solve this would be for these pictures to just represent the cold heights. That would avoid the clashing prints due to thermal expansion introducing tiny differences in the block heights.

Besides, my assumption is that users use these types of plots to (1) verify their inputs, and (2) to show other people what their assemblies look like. Both of those tasks would be more digestible if the block heights were displayed as cold heights.

If we agree on this, then I can make a PR for this.

.... If we agree on this, then I can make a PR for this.

Also supports the proposed direction in #1824

If we agree on this, then I can make a PR for this.

I like the proposal. Go for it. And thanks, man.

The suggestion I made above (to print the plots at cold heights) is not easily to do in practice. The reason for this is that axial thermal expansion takes place before these plots can possibly be generated.

The plots are generated within the ReportInterface.interactBOL() hook:

Oddly, the axial thermal expansion takes place even before the interactInit() hooks of the interface stack. This means that basically nothing can be configured to happen before axial thermal expansion messes with the defined reactor. This is a real shame, and highlights another motivation for converting axial thermal expansion into a plugin/interface.

I would say this is still a problem, but it has suddenly turned into something that is very difficult to fix. I am leaving the ticket open, but unassigning myself because I do not have the bandwidth to do something so complex.

Oddly, the axial thermal expansion takes place even before the interactInit() hooks of the interface stack. This means that basically nothing can be configured to happen before axial thermal expansion messes with the defined reactor. This is a real shame, and highlights another motivation for #1843 (comment).

Yeah, thermal expansion occurs during core construction. Specifically on the blueprints assemblies to get them to their Thot dimensions. This was done because users were complaining that dbloads were taking too long because we were thermally expanding every single assembly in the core. So to make the dbloads faster, we changed to thermally expanding the blueprints assemblies, and as such, occurs very early on.
Here's the PR that made that change --> #1047

If you want to make thermal expansion a plugin/interface, you'll need to convince the powers at be that allowing interfaces to call other interfaces is an ok design choice (while recognizing that this capability does currently exist and is used).

Our team opinion here is we need a method that can go up to the blueprints and get the T=0 heights from a block.

Our team opinion here is we need a method that can go up to the blueprints and get the T=0 heights from a block.

This method would have other benefits outside this plot, e.g., axial thermal expansion between hot and as fabricated heights of blocks.

Can this Issue be closed, now that we have Drew's PR "Adding Block.getInputHeight" ?

#1927

It looks to me like it can.

Can this Issue be closed, now that we have Drew's PR "Adding Block.getInputHeight" ?

#1927

It looks to me like it can.

We'd have to make the change to use that method in the plots but that should 🤞 be all that's needed