Allow users to always provide input for non-uniform assemblies in the blueprints

[jakehader]

Currently, if the detailedAxialExpansion setting is set to False, the user input is for all the assemblies in the blueprints file are required to contain axial mesh points that are all aligned, whereas when the detailedAxialExpansion setting is set to True this restriction is lifted. It would be best if the ARMI framework allowed users to provide a mesh structure that they would like (based on the core design of each assembly) and then for the framework to handle this on reactor construction.

For instance, if we allowed any mesh to be provided when detailedAxialExpansion is set to False we could immediately call the UniformMesh converter on reactor construction before any work is performed and this would still allow a user to perform analyses using a uniform mesh.

In this case, the logic for processLoading on the reactor needs to be modified to call the UniformMesh converter if detailedAxialExpansion is set to False within the makeAxialSnapList method.

processLoading:

https://github.com/terrapower/armi/blob/0c7ef201c9f1ce5256e925b127b4a49c40659456/armi/reactor/reactors.py#L2245-L2248

makeAxialSnapList:

https://github.com/terrapower/armi/blob/0fa09f9fb43d2d1dae062f7fa89d8b2084cb0ab7/armi/reactor/assemblies.py#L575

This update will allow more flexibility for users and will also allow users to create a single blueprints file that represents the design of their reactor system. This is important for @onufer in the near term.

[jakehader]

@albeanth - Would you be able to take a stab at this?

[onufer]

@jakehader just to clarify, specifying a non-uniform mesh will result in the reactor state being stored on a uniform mesh in memory, correct (i think this is what direction @albeanth is going)? Rather than converting to a uniform mesh prior to each global flux solve?

[jakehader]

@onufer that is correct!

[albeanth]

My working branch to address this issue.

https://github.com/albeanth/armi/tree/processLoadUpdate

[john-science]

How far have our recent PR go to solving this Issue?

#735 - Process load update and new uniform mesher #827 - Support non-uniform assemblies with detailedAxialExpansion disabled

If we made some progress, what do we have left to do to complete this ticket?

[albeanth]

I think this is still an open issue. #735 was designed to address it, but opened up a hefty can of worms. It was decided to shelve that approach for now until a more formal refactor of the impacted system(s) (namely detailedAxialExpansion) can occur.

#827 aims to address this issue but needs more testing, in my opinion.