Can HexBlock.verifyDims be generalized or exposed to plugins?

[drewj-usnctech]

The current implementation of HexBlock feels heavily tied towards sodium fast reactor design with some baked-in assumptions

• tightly packed fuel pins
• separated by wire wrap
• all the way out to the duct

armi/armi/reactor/blocks.py

Lines 1745 to 1757 in b9eb9ca

	def verifyBlockDims(self):
	"""Perform some checks on this type of block before it is assembled."""
	try:
	wireComp = self.getComponent(Flags.WIRE)
	ductComps = self.getComponents(Flags.DUCT)
	cladComp = self.getComponent(Flags.CLAD)
	except ValueError:
	# there are probably more that one clad/wire, so we really dont know what this block looks like
	runLog.info(
	"Block design {} is too complicated to verify dimensions. Make sure they "
	"are correct!".format(self)
	)
	return

Any reactor not adhering to this design is likely to see a lot of warnings in their runlog like

[info] Constructing assembly `fuel`
[warn] No component matched Flags.WIRE in <fuel block-bol-000 at ... >. Returning None
[warn] No component matched Flags.CLAD in <fuel block-bol-000 at ... >. Returning None

This feels like something where generalization / plugins could be useful. But it both needs to be more general but also design specific. Exposing this to a plugin that handles sodium fast reactors and LWRs would need some additional logic to know how to check the validity of a Block

There's also this section of code that will never be executed because it's directly after an exception in the same scope

armi/armi/reactor/blocks.py

Lines 1774 to 1786 in b9eb9ca

	if pinToDuctGap is not None and pinToDuctGap < -0.005:
	raise ValueError(
	"Gap between pins and duct is {0:.4f} cm in {1}. Make more room.".format(
	pinToDuctGap, self
	)
	)
	wire = self.getComponent(Flags.WIRE)
	wireThicknesses = wire.getDimension("od", cold=False)
	if pinToDuctGap < wireThicknesses:
	raise ValueError(
	"Gap between pins and duct is {0:.4f} cm in {1} which does not allow room for the wire "
	"with diameter {2}".format(pinToDuctGap, self, wireThicknesses)
	)

[keckler]

I very much agree that HexBlock should not be so specific. Even for SFRs, it is overly specific.

So there is that.

But I also think that you should be able to make your own block type from within a plugin that is recognized when building a case, without any changes needed to the current framework. I might be wrong about that, but I know it is possible for components and I anticipate it could work the same for blocks.

Is this what you are hoping to do? Maybe I am unclear about how your thoughts on how to potentially resolve this.

[drewj-usnctech]

@keckler Hmm I don't think having the Block-type be potentially reactor specific is what I was envisioning. Can you expand more on

But I also think that you should be able to make your own block type from within a plugin that is recognized when building a case, without any changes needed to the current framework

as I may be missing something.

I think more what I was looking for would be a solution where a Plugin can perform the validation on a block. So something like a SFR Block validator would look for

• number of pins fully fills a hexagonal ring structure
• wire and clad to duct ratio item from the snippet above

but then applications could build, e.g., an FFTF-validator, something for the MHTGR (#224), C5G7 validator, etc.

[keckler]

Right, so you are definitely thinking more broadly than I was. And your solution might be better in the long run, but I'm imagining it will take more lifting up-front.

I was basically just thinking that you could implement your own block class from within your plugin. It could essentially just be a direct subclass of the HexBlock class with its own implementation of the verifyBlockDims method. And then you could use this MySubclassedHexBlock or whatever in building your inputs, and not have to deal with the stupid checks that are currently implemented on HexBlock.verifyBlockDims.

I just didn't know if you knew that it was a possibility to define your own blocks in your plugins. If you did know that already, then sorry for the confusion! And if you didn't know that and want me to help explain that, I'd be happy to try. Just let me know.

[drewj-usnctech]

Ah gotcha. I just found these two plugin hooks that look like they could work

armi/armi/plugins.py

Lines 253 to 286 in eeb28b4

	@staticmethod
	@HOOKSPEC
	def defineBlockTypes():
	"""
	Function for providing novel Block types from a plugin.
	This should return a list of tuples containing ``(compType, blockType)``, where
	``blockType`` is a new ``Block`` subclass to register, and ``compType`` is the
	corresponding ``Component`` type that should activate it. For instance a
	``HexBlock`` would be created when the largest component is a ``Hexagon``::
	return [(Hexagon, HexBlock)]
	"""
	@staticmethod
	@HOOKSPEC
	def defineAssemblyTypes():
	"""
	Function for providing novel Assembly types from a plugin.
	This should return a list of tuples containing ``(blockType, assemType)``, where
	``assemType`` is a new ``Assembly`` subclass to register, and ``blockType`` is
	the corresponding ``Block`` subclass that, if present in the assembly, should
	trigger it to be of the corresponding ``assemType``.
	.. warning::
	The utility of subclassing Assembly is suspect, and may soon cease to be
	supported. In practice, Assembly subclasses provide very little
	functionality beyond that on the base class, and even that functionality can
	probably be better suited elsewhere. Moving this code around would let us
	eliminate the specialized Assembly subclasses altogether. In such a case,
	this API will be removed from the framework.
	"""

now things make more sense.

Thanks!