Use a more robust method for determining number of pins in HexBlock._rotatePins()

[mgjarrett]

What is the change?

Use block.getNumPins() instead of counting Flags.CLAD components. Round this number up to a number of pins that fits exactly into a regular hex lattice.

Why is the change being made?

1. Using block.getNumPins(): because counting the multiplicity of Flags.CLAD components on a block will not always be equal to the number of pins (e.g., a solid steel reflector slug)
2. Rounding up the number of pins: If a block is missing pin locations from a full hex lattice, we should round up the number of pins. The math for mapping the indices only works if the number of pins fits exactly into a regular hex lattice (19, 37, 61, 91, etc.)

---

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.

[mgjarrett]

Note that I just realized #1846 will make rotatePins private, so if that is merged first then I would have to update the release notes, which currently mark this as being an API change.

[drewj-tp]

The justCompute=True behavior is something that I think could be moved off of HexBlock.rotatePins. The place it's used in ARMI at least is just to find post-rotation location of pins to minimize burnup

armi/armi/physics/fuelCycle/hexAssemblyFuelMgmtUtils.py

Line 105 in f5267e0

indexLookup = maxBuBlock.rotatePins(possibleRotation, justCompute=True)

Which feels like overkill to emulate rotating every single pin in a block just to see where one pin would end up. So I put some of the code in armi.utils.hexagon in afd4528.

If there are other needs for justCompute=True, let me know and I can try to fold them in to #1846 or we can put them in a new ticket

[mgjarrett]

Marking this as draft until #1846 is merged; this PR will be updated after that

[mgjarrett]

after #1846 made _rotatePins private, it no longer makes sense to add the optional numPins argument to this function, because users won't be calling this function directly anyway.

However, I think it could still be worthwhile to make the determination of the number of pins more robust. Block has a getNumPins method that is more robust than the one-liner used.

armi/armi/reactor/blocks.py

Lines 1047 to 1079 in abd1db4

	def getNumPins(self):
	"""Return the number of pins in this block.
	.. impl:: Get the number of pins in a block.
	:id: I_ARMI_BLOCK_NPINS
	:implements: R_ARMI_BLOCK_NPINS
	Uses some simple criteria to infer the number of pins in the block.
	For every flag in the module list :py:data:`~armi.reactor.blocks.PIN_COMPONENTS`,
	loop over all components of that type in the block. If the component
	is an instance of :py:class:`~armi.reactor.components.basicShapes.Circle`,
	add its multiplicity to a list, and sum that list over all components
	with each given flag.
	After looping over all possibilities, return the maximum value returned
	from the process above, or if no compatible components were found,
	return zero.
	"""
	nPins = [
	sum(
	[
	(
	int(c.getDimension("mult"))
	if isinstance(c, basicShapes.Circle)
	else 0
	)
	for c in self.iterComponents(compType)
	]
	)
	for compType in PIN_COMPONENTS
	]
	return 0 if not nPins else max(nPins)

Is there any reason not to use getNumPins here?

armi/armi/reactor/blocks.py

Line 2141 in abd1db4

numPins = self.getNumComponents(Flags.CLAD)

[drewj-tp]

Can you update the PR description accordingly? The Block.rotatePins method has been removed, but the PR description discusses changes to it