Accounting for symmetry in volume-integrated parameters

[bsculac]

What is the change?

The block parameters initialB10ComponentVolume, massHmBOL, and molesHmBOL did not have a location tag that would cause them to be multiplied by the symmetry factor when expanding to full core, so the VOLUME_INTEGRATED tag was added. This should cause these values to be correctly accounted for when assemblies are placed on symmetry boundaries. A survey of other parameters was made, and the VOLUME_INTEGRATED tag was added as needed to cause all block parameters that should change with the volume of the block to have the tag.

The assembly method moveTo is modified to have a check for the symmetry factor of the source and destination locations. The ratio of the symmetry factors is used to adjust the volume integrated parameters in the blocks within the assembly to account for the blocks being split between different sections of the core.

The moveTo method is used for placing the assembly in the core and for movement within the core, so this change should account for all the modifications needed to correctly represent block parameters that change based on the volume of the block. Note that this does not change values that are calculated on the fly, such as the volume with the getVolume method.

Changes that are made based on discovered knock on effects from this change:

1. The getParamMax assembly method did not account for the symmetry factor when making comparisons between assemblies. It would therefore return incorrect values for parameters which were stored in a way that accounted for the symmetry factor. See https://github.com/terrapower/armi/pull/2017/files#diff-447b13bcb80d46b6c7901b9dae9ec8bcdf6f4f5f176a61b7beae558fd368dba2R216-R224

Why is the change being made?

Incorrect values were calculated for initialB10ComponentVolume and downstream values dependent on it for assemblies located in the center of 1/3rd symmetric cores.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify any new/changed code.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes have been updated if necessary.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in pyproject.toml.

[bsculac]

Working on running a test case to demonstrate that the parameters are correctly accounted for in assemblies that are split between symmetric portions of the core.

[john-science]

@bsculac Are you hoping this PR will make it into the (imminent) ARMI 0.5.0 release?

[bsculac]

@bsculac Are you hoping this PR will make it into the (imminent) ARMI 0.5.0 release?

I don't think it needs to hold up the release. I'm not sure I'll have enough time to wrap it up before code freeze, I'm out until after Thanksgiving.

[bsculac]

John and I talked about this for a bit. I think we arrived at two conclusions:

1. The core idea of adjusting some parameters as an assembly is placed to/from a position like the center position in a 1/3rd symmetric core (i.e. somewhere it would be in multiple symmetric sections of the core) is fine. The specific means may need different implementations, e.g. selecting all volume integrated parameters for adjustment may not be ideal. Also, the knock on effects of this change would have to be thoroughly evaluated.

2. However, the problem this PR is attempting to fix may need a different solution than adjustment of parameters upon an assembly's placement in the core. John was of the opinion that when an assembly is constructed and initially placed in the core it should have no valid parameters that would need adjustment for the symmetry factor, those parameters should be assigned in interactBOL. I don't necessarily disagree, but this is a decision the project needs to make (or reaffirm).

@john-science please correct me if I've misrepresented our discussion, or if you'd like to add anything.