Uniform Mesh Converter Parameter Mapping and Power Parameter Recalculations

[jakehader]

The problem statement is as follows - The uniform mesh converter currently performs block-level parameter mapping between a uniform mesh assembly/core to a detailed mesh assembly/core. During this data transfer process, parameters like linPow or data that is relative to the number of pins/components in the destination assembly must be considered. Right now only a volume weighting is being applied, but in instances of pin-level quantities we should also recalculate power-like parameters based on the target number of pins.

One example where this rears its head is in an internal application where we have moving control rods using the nonUniformAssemFlags and in some parts of the assembly is a DUCT block that contains no pins, but when the global flux calculation is performed there are some CONTROL blocks that are homogenized into the DUCT block. When the global flux calculation sees the power and goes to compute linPow it sees that there are in fact "pins" in this homogenized region, but when the flux/power results are mapped back to the DUCT and other CONTROL blocks the DUCT does not contain any pins. Again, this leads the results to show a pin-level linear power in the DUCT blocks because of the way the uniform mesh converter is treating the migration of data, but this parameter should actually be zeroed out.

I recommend that the ARMI develop team consider tracking dependencies of parameters in terms of other parameters within certain parameter setters. Ideally, we need to just map flux data back to core assemblies in this conversion process and then recalculate all flux-dependent parameters (i.e., reaction rates, power, linear powers, etc.). Right now only the recalculation of reaction rates is handled and therefore there is a chance that power and power-like data is incorrect.

[john-science]

Can we have a meeting to discuss the requirements of the new non-uniform assembly feature?

I feel like we're starting down the road of making many little PRs, like we did with the Axial Expansion feature recently.

I really think it would be better to define a high-level view of this new feature, define requirements, then lay out a good high-level design before starting work. That's a good strategy for medium-to-large features, so we don't have a never-ending stream of little changes and fixes (which lead to messier code, which is harder to update and fix).

[jakehader]

Sure. All the changes to the uniform mesher have been to (1) extend it's parameter handling and remove hard-coded parameter names, and (2) refactors to expose the API in a different way to downstream plugins and applications. The underlying scope of this class has not changed in that it's job is to make a reactor core model that has a uniform axial mesh, consistent with some user mesh input or derived from the reference assembly.

The real issue is that we have too many stale block parameters registered in the framework and likely our internal plugins, and these parameters have never been audited to have the correct location and category metadata. Finally, it doesn't make sense to map flux-dependent data directly from one region to another because while flux is a continuous function (or generally should be) spatially, things like power and reaction rates have discontinuities at material boundaries. This ticket aims to shift towards only mapping flux and flux-like parameters and having all other flux-dependent parameters be recalculated.

[john-science]

we have too many stale block parameters

That's a really good point.

I would even split that into two separate problems:

1. We have some totally unused parameters, and we have no way to find them.
2. I bet ARMI has some parameters that should be moved to a specific Plugin.

@ntouran Any ideas how I would go about finding unused parameters?

[jakehader]

I have them documented and I can share @john-science