Insufficient testing on buReducingAssemblyRotation
ARMI provides functionality for a fuel handler to do "burnup reducing" assembly rotation
https://github.com/terrapower/armi/blob/f1f3dbea05c2564404a03d8e053f72c2af15daa9/armi/physics/fuelCycle/assemblyRotationAlgorithms.py#L38-L40
https://github.com/terrapower/armi/blob/f1f3dbea05c2564404a03d8e053f72c2af15daa9/armi/physics/fuelCycle/hexAssemblyFuelMgmtUtils.py#L32-L41
The testing for this functionality is lacking, in my opinion; it checks that that the orientation is different, not "optimal"
https://github.com/terrapower/armi/blob/f1f3dbea05c2564404a03d8e053f72c2af15daa9/armi/physics/fuelCycle/tests/test_assemblyRotationAlgorithms.py#L30-L50
So that could use some improvement.
I propose we add more testing, specifically on the internal getOptimalAssemblyOrientation function, to check that
- We get the correct, not just different, orientation rotating an assembly "in place" (
a is aPrevin the function) - We get the correct orientation rotating an assembly in the location of a different assembly (
a is not aPrev)
Addendum
This last sentence
https://github.com/terrapower/armi/blob/f1f3dbea05c2564404a03d8e053f72c2af15daa9/armi/physics/fuelCycle/hexAssemblyFuelMgmtUtils.py#L40-L41
is wrong and should be removed. If we don't have any pin information, the getOptimalAssemblyOrientation raises an error
https://github.com/terrapower/armi/blob/f1f3dbea05c2564404a03d8e053f72c2af15daa9/armi/physics/fuelCycle/hexAssemblyFuelMgmtUtils.py#L119-L122
If we had unit tests for this that were of very small reactors (~three rings), would that make it easier to hand-calculate the optimum rotation?
(And yes, ditch that last sentence.)
If we had unit tests for this that were of very small reactors (~three rings), would that make it easier to hand-calculate the optimum rotation?
It's probably good to have. I'm working on a test that picks up a test reactor like
https://github.com/terrapower/armi/blob/b436537edfed991e6ff560a1d1b2d4b018507db1/armi/physics/fuelCycle/tests/test_fuelHandlers.py#L64-L73
So we already have something that's halfway decent. The trick is setting the block data such that you have a known input state (pin powers, max burnup pin index, etc.) such that you can compare the rotation you get vs. the rotation you expect