Possible inconsistency in test_applyThermalExpansion_CoreConstruct

[drewj-usnctech]

While working on updating our internal ARMI fork, I stumbled on this test. In particular these confusing lines

armi/armi/reactor/tests/test_reactors.py

Lines 898 to 899 in 3b199b6

	nonEqualParameters = ["heightBOL", "molesHmBOL", "massHmBOL"]
	equalParameters = ["smearDensity", "nHMAtBOL", "enrichmentBOL"]

The test is ensuring that some parameters, like height, are changed when thermal expansion is applied. Understandably, enrichment and number of heavy metal atoms at BOL shouldn't change just because height or other dimensions change. But how then can moles and mass of heavy metal be allowed to change if the number of atoms does not change?

[drewj-usnctech]

Okay this might be related to a misunderstanding in the nHMAtBOL parameter. That appears to be a density, not a total number

armi/armi/reactor/blocks.py

Lines 803 to 805 in 3b199b6

	hmDens = bolBlock.getHMDens() # total homogenized heavy metal number density
	self.p.molesHmBOL = self.getHMMoles()
	self.p.nHMAtBOL = hmDens

So these thermal expansion routines conserve density when thermally expanded? That at least is my takeaway looking at this test

armi/armi/reactor/tests/test_reactors.py

Lines 886 to 925 in 3b199b6

	def test_applyThermalExpansion_CoreConstruct(self):
	"""test that assemblies in core are correctly expanded.
	Notes:
	------
	- all assertions skip the first block as it has no $\Delta T$ and does not expand
	"""
	originalAssems = self.r.core.getAssemblies()
	# stash original axial mesh info
	oldRefBlockAxialMesh = self.r.core.p.referenceBlockAxialMesh
	oldAxialMesh = self.r.core.p.axialMesh
	nonEqualParameters = ["heightBOL", "molesHmBOL", "massHmBOL"]
	equalParameters = ["smearDensity", "nHMAtBOL", "enrichmentBOL"]
	_o, coldHeightR = loadTestReactor(
	self.directoryChanger.destination,
	customSettings={"inputHeightsConsideredHot": False},
	)
	for i, val in enumerate(oldRefBlockAxialMesh[1:]):
	self.assertNotEqual(val, coldHeightR.core.p.referenceBlockAxialMesh[i])
	for i, val in enumerate(oldAxialMesh[1:]):
	self.assertNotEqual(val, coldHeightR.core.p.axialMesh[i])
	coldHeightAssems = coldHeightR.core.getAssemblies()
	for a, coldHeightA in zip(originalAssems, coldHeightAssems):
	if not a.hasFlags(Flags.CONTROL):
	for b, coldHeightB in zip(a[1:], coldHeightA[1:]):
	for param in nonEqualParameters:
	p, coldHeightP = b.p[param], coldHeightB.p[param]
	if p and coldHeightP:
	self.assertNotEqual(
	p, coldHeightP, f"{param} {p} {coldHeightP}"
	)
	else:
	self.assertAlmostEqual(p, coldHeightP)
	for param in equalParameters:
	p, coldHeightP = b.p[param], coldHeightB.p[param]
	self.assertAlmostEqual(p, coldHeightP)

[drewj-usnctech]

Another wrinkle, there's a seemingly repeated test in test_updateBlockBOLHeights_DBLoad

armi/armi/reactor/tests/test_reactors.py

Lines 927 to 954 in 3b199b6

	def test_updateBlockBOLHeights_DBLoad(self):
	"""Test that blueprints assemblies are expanded in DB load.
	Notes:
	------
	- all assertions skip the first block as it has no $\Delta T$ and does not expand
	"""
	originalAssems = sorted(a for a in self.r.blueprints.assemblies.values())
	nonEqualParameters = ["heightBOL", "molesHmBOL", "massHmBOL"]
	equalParameters = ["smearDensity", "nHMAtBOL", "enrichmentBOL"]
	_o, coldHeightR = loadTestReactor(
	self.directoryChanger.destination,
	customSettings={"inputHeightsConsideredHot": False},
	)
	coldHeightAssems = sorted(a for a in coldHeightR.blueprints.assemblies.values())
	for a, coldHeightA in zip(originalAssems, coldHeightAssems):
	if not a.hasFlags(Flags.CONTROL):
	for b, coldHeightB in zip(a[1:], coldHeightA[1:]):
	for param in nonEqualParameters:
	p, coldHeightP = b.p[param], coldHeightB.p[param]
	if p and coldHeightP:
	self.assertNotEqual(p, coldHeightP)
	else:
	self.assertAlmostEqual(p, coldHeightP)
	for param in equalParameters:
	p, coldHeightP = b.p[param], coldHeightB.p[param]
	self.assertAlmostEqual(p, coldHeightP)

where the only difference is the axial meshing isn't checked. Presumably because the reactor written to the database already has the axial mesh updated?
But the test doesn't appear to do anything with a loaded data file, whereas previous iterations of the test called self.r.core.processLoading(self.o.cs, dbLoad=True)

[john-science]

It appears to me that different people wrote the different tests at different times. Probably, we could reduce the number of tests there, yeah.

This would be a rare case where we have more testing than we need. :)

[drewj-usnctech]

@jakehader @onufer @john-science could you provide some helpful context and history on these changes? Axial expansion under inputHeightsConsideredHot == False appears to conserver density not mass, whereas radial expansion Tinput != Thot conserves mass but not density

[john-science]

@albeanth Could you speak to the axial expansion aspect here?

[albeanth]

Hey there, yes I can speak to this a bit. This is also motivation for me to actually carve out the time to finish adding the axial expansion routine to the docs....

---

So these thermal expansion routines conserve density when thermally expanded?

The thermal expansion routine for ARMI lives in armi/reactor/converters/axialExpansionChanger.py::axiallyExpandAssembly. Inside, there is the concept of an axial expansion "target component" within each block. This is used to redistribute blocks bounds as different components within a given block can expand at different rates. The "target component" (e.g., fuel component within a pin-type fuel block) always has its mass preserved. The other components (e.g., clad) can have their mass redistributed across different blocks. However, their density in g/cc is preserved. One important note as well:

armi/armi/reactor/converters/axialExpansionChanger.py

Lines 110 to 113 in d53c17d

	Notes
	-----
	- Is designed to work with general, vertically oriented, pin-type assembly designs. It is not set up to account
	for any other assembly type.

---

But the test doesn't appear to do anything with a loaded data file, whereas previous iterations of the test called self.r.core.processLoading(self.o.cs, dbLoad=True)

Yeah, these are strikingly similar now, but there is a key difference in that test_updateBlockBOLHeights_DBLoad checks the blueprints assemblies. In #1047, the way in which standard core construction and db load-based runs (e.g., restart or snapshot runs) are initiated was changed (as you pointed out with the removal of self.r.core.processLoading(self.o.cs, dbLoad=True)).

DB loads now don't have special treatment in r.core.processLoading and instead we just ensure that the blueprints assemblies are thermally expanded if inputHeightConsideredHot == False.

These tests in their current form could easily be combined into a single test that would hopefully be more clear. This looks like cleanup that just hasn't happened yet.

[drewj-usnctech]

Thanks for the insight @albeanth

The "target component" (e.g., fuel component within a pin-type fuel block) always has its mass preserved. The other components (e.g., clad) can have their mass redistributed across different blocks. However, their density in g/cc is preserved.

Do I understand this right? During axial expansion, "target" (fuel) components will be expanded to conserve mass, but not density. For every other block, density is preserved but not mass in that block? The phrase "mass redistributed across different blocks" is throwing me off.

Docs would be greatly appreciated on the axial expansion mechanisms. Having the expansion in the blueprints stage vs. the reactor loading does make it a little more clear that there may be some changes in total reactor mass for axial expansion. But I presume this is by design, sort of like setting Tinput != Thot in a component blueprint spec. Although that seeks to preserve mass during the expansion...

re testing, yeah I missed the line for how the originalAssemblies are produced

armi/armi/reactor/tests/test_reactors.py

Line 934 in 3b199b6

originalAssems = sorted(a for a in self.r.blueprints.assemblies.values())

for "dbload" test and

armi/armi/reactor/tests/test_reactors.py

Line 893 in 3b199b6

originalAssems = self.r.core.getAssemblies()

for test w/o "dbload"

[albeanth]

Do I understand this right? During axial expansion, "target" (fuel) components will be expanded to conserve mass, but not density. For every other block, density is preserved but not mass in that block? The phrase "mass redistributed across different blocks" is throwing me off.

Yeah, you've got this right. Another way to think about it. The non-target components, clad, duct, etc have their total assembly mass preserved, but on a block-by-block basis, we preserve density. Here's a graphic that I made when I was drafting out the axial expansion algorithm to try and help explain.

A breakdown of each block from bottom to top; the components within each block are listed from inner- to outer-most and the axial expansion "target component" within each block is bolded:

1. Fuel block: fuel, clad, duct. Initial height of 1.0.
2. Fuel block: fuel, clad, duct. Initial height of 1.0.
3. Plenum block: clad, duct. Initial height of 1,0.
4. Clearance block (to allow for axial expansion without mechanical binding): duct. Initial height of 0.5.
5. "Dummy" block: no solid components. Is typically coolant and represents what would be above the assembly in the core.

It's presence is to ensure that all assemblies maintain a uniform total height. It gets artificially chopped/expanded depending on the expansion/contraction of the blocks below it.

At step 3, we have axially expanded all of the solid components and have alignment. This represents the most physically accurate representation of what is expected to happen in a pin-type assembly. However, it has an axially disjoint mesh that can't be used by most deterministic solvers. So we have to unify it. This occurs in step 4. Here we choose to redraw the block boundaries based on the "target component" to conserve mass (the idea was that it would be important to preserve the fuel mass post-expansion). If we focus on the bottom-most fuel block, we see that the fuel component expands more than the clad and duct. So post-expansion, we will have more clad and duct mass in this block. However, the increase in mass is proportional to the new block volume so the density is preserved. Also, the total assembly mass of all of the clad and duct is preserved (so we aren't adding/taking away any clad or duct mass, which is important).

there may be some changes in total reactor mass for axial expansion.

Since we preserve mass of all solid components on the assembly level, the total reactor mass should not change post-expansion.

[albeanth]

whereas radial expansion Tinput != Thot conserves mass but not density

I'm a bit less familiar with radial expansion as it predates me joining TerraPower, but will comment on it (@onufer / @jakehader feel free to correct me if I'm wrong).

Radial expansion doesn't actually do physical expansion/modification to the ARMI model (unlike axial expansion). The radial "expansion" occurs whenever you query the dimensions of the component.

armi/armi/reactor/components/component.py

Lines 813 to 834 in d53c17d

	def getDimension(self, key, Tc=None, cold=False):
	"""
	Return a specific dimension at temperature as determined by key
	Parameters
	----------
	key : str
	The dimension key (op, ip, mult, etc.)
	Tc : float
	Temperature in C. If None, the current temperature of the component is used.
	cold : bool, optional
	If true, will return cold (input) value of the requested dimension
	"""
	dimension = self.p[key]
	if isinstance(dimension, _DimensionLink):
	return dimension.resolveDimension(Tc=Tc, cold=cold)
	if not dimension or cold or key not in self.THERMAL_EXPANSION_DIMS:
	return dimension
	return self.getThermalExpansionFactor(Tc) * dimension

The delta between the temperature, Tc (which is typically c.temperatureInC), then generates a thermal expansion factor that modifies the returned dimension - which in turn affects the value that gets returned if you query quantities that depend on dimension.

This unit test was added semi-recently to serve as a bit of a walkthrough for how mass and density are related during expansion. I would consider walking through that test to get a feel for how things are handled.

armi/armi/reactor/tests/test_components.py

Line 553 in 49f357b

def expansionConservationHotHeightDefined(self, mat: str, isotope: str):

But yes, you're right in that during radial expansion mass is conserved, but density is not. When considering axial expansion conservation, it is definitely a bit confusing. Maybe/hopefully we can clean it up in the future.

[drewj-usnctech]

That test is a good resource! It would be great if it was more exposed, like included in the docs in some way. Well it's already included in the API docs but you only ever see that if you search for it directly. Glad to see testing of some expansion mechanisms

[albeanth]

Yeah, unless you know it's there and what you're looking for, you'd never find it in the API docs. We should consider making more visible.

Adding a note here to possibly include these tests to serve as a tutorial in the docs #935.