No such specialized method exists for a CartesianBlock, and in that case getPinPitch() will look to to an underlying grid for definition.
If a user also defines a pin grid for the block, they must also define a pin pitch there using the lattice pitch attribute (defaults to 1.0, I think?). Since the defined grid forces the user to input a lattice pitch that is NOT temperature dependent and is not based on any built-in assumptions on what defines the pin pitch, I guess you might think that this is the "real" pin pitch. That would certainly be my expectation, since I would have input that value explicitly.
But regardless, it is likely that the two pin pitches do not agree, in which case the question of which is right must be asked.
My expectation would be that getPinPitch() first checks if a grid has been defined, and if not then tries to find the pitch based on the clad+wire diameters.
For most "real" assembly definitions the difference is probably very small. But the reason that I bring this up is because I'm modeling assemblies that don't always have wires, or for one reason or another the assumptions in getPinPitch() are tripped up by my assembly definitions. Basically anytime that an assembly has multiple pin definitions, HexBlock.getPinPitch() will fail, and this is a problem that can be easily rectified by pulling the pin pitch from an available grid definition.
keckler
commented
1 year ago
HexBlockhas agetPinPitch()method which infers the pin pitch based on the (possibly) temperature-dependent diameters of the clad+wire: https://github.com/terrapower/armi/blob/360791847227df3f3a337a996ef561e00f846a09/armi/reactor/blocks.py#L2160-L2195No such specialized method exists for a
CartesianBlock, and in that casegetPinPitch()will look to to an underlying grid for definition.If a user also defines a pin grid for the block, they must also define a pin pitch there using the
lattice pitchattribute (defaults to 1.0, I think?). Since the defined grid forces the user to input a lattice pitch that is NOT temperature dependent and is not based on any built-in assumptions on what defines the pin pitch, I guess you might think that this is the "real" pin pitch. That would certainly be my expectation, since I would have input that value explicitly.But regardless, it is likely that the two pin pitches do not agree, in which case the question of which is right must be asked.
My expectation would be that
getPinPitch()first checks if a grid has been defined, and if not then tries to find the pitch based on the clad+wire diameters.For most "real" assembly definitions the difference is probably very small. But the reason that I bring this up is because I'm modeling assemblies that don't always have wires, or for one reason or another the assumptions in
getPinPitch()are tripped up by my assembly definitions. Basically anytime that an assembly has multiple pin definitions,HexBlock.getPinPitch()will fail, and this is a problem that can be easily rectified by pulling the pin pitch from an available grid definition.