Switch for enabling / disabling thermal expansion

[drewj-usnctech]

After some internal discussions, we were wondering if there was a way to disable ARMI's thermal expansion. Thinking in our group would be to rely on a structural mechanics tool that could also provide stresses for expansion, allow for more complicated expansion routines (inner component pushes secondary component with pushes a tertiary component)

The other motivating factor is if we truly want to just look at materials at elevated temperatures, if we set Tinput == Thot in our blueprint file, we don't get any expansion. Which is the intent. However, if linear expansion methods are defined on a Material, we could see modified material densities.

The goal would be to model the Material and Component with "nominal" density and dimensions, but pull nuclear data from off-nominal temperatures

[john-science]

Heya!

Okay, no, we definitely don't have that feature built in. You're totally right that my first thought was to set Tinput == Thot.

I guess my first question for this is:

Where else would thermal expansion be happening?

Off the top of my head, sure, linear expansion of the Materials is one place. You'll also want to make sure you are using the default Setting in your YAML file: axialExpansion: false. Is there somewhere else that isn't coming to my mind right now? Probably.

So, you want a Setting that does those two things, but also forces Material.density() and Material.linearExpansion() to always return some nominal value? That's probably doable.

Perhaps one hiccup is that right now in the Material class, we don't really have an idea of a "nominal" temperature. Perhaps you / we would have to pick one. Like setting the entire Reactor to Tinput, for instance. And just calculating Material properties like density() and linearExpansion() at Tinput.

[john-science]

@ntouran @jakehader Before I go off all half-cocked on the details here, can you think of some way of achieving what Drew wants, without writing a lot of code?

[albeanth]

Hi there @drewj-usnctech - here's my 2 cents! Hope it helps.

To totally turn off thermal expansion while introducing minimal amounts of code, you can do a few things:

• As @john-science points out, having axialExpansion = False is good. Though it's not used anywhere in framework and is just set for downstream plugins, it doesn't hurt.
  • A similar take on detailedAxialExpansion. Setting it to False is a good idea.
• Setting Tinput == Thot is also a good move.
  • As you've found it can be a good hack to get thermal expansion coefficients to be zero. Though this isn't always the case and really depends on how the linearExpansionPercent is set in your armi/materials file.
  • E.g., if you check out armi/materials/ht9.py::HT9::linearExpansionPercent

    armi/armi/materials/ht9.py

    Lines 62 to 70 in d012383

    	def linearExpansionPercent(self, Tk=None, Tc=None):
    	"""
    	Gets the linear expansion from E.2.2.2 in [MFH]_ for HT9.
    	The ref gives dL/L0 in percent and is valid from 293 - 1050 K.
    	"""
    	tk = units.getTk(Tc, Tk)
    	self.checkPropertyTempRange("linear expansion", tk)
    	return -0.16256 + 1.62307e-4 * tk + 1.42357e-6 * tk ** 2 - 5.50344e-10 * tk ** 3

    you'll see that the linear expansion factor that gets returned to armi/materials/material.py::Material::density won't be 0.0 if Tinput == Thot. To really make sure those factors are indeed 0.0, you should modify the linearExpansionPercent method in the material class.
• You can also set inputHeightsConsideredHot = False.
  • On process loading of your blueprints, this will forgo applying armi/reactor/components/component.py::Component::applyHotHeightDensityReduction

    armi/armi/reactor/blueprints/blockBlueprint.py

    Lines 119 to 128 in d012383

    	if cs["inputHeightsConsideredHot"]:
    	if "group" in c.name:
    	for component in c:
    	component.applyHotHeightDensityReduction()
    	componentBlueprint.insertDepletableNuclideKeys(
    	component, blueprint
    	)
    	else:
    	c.applyHotHeightDensityReduction()
    	componentBlueprint.insertDepletableNuclideKeys(c, blueprint)

  • But this will spin up the axialExpansionChanger to thermally axial expand your Core from Tinput to Thot

    armi/armi/reactor/reactors.py

    Lines 2239 to 2248 in d012383

    	if not cs["inputHeightsConsideredHot"]:
    	runLog.header(
    	"=========== Axially expanding all (except control) assemblies from Tinput to Thot ==========="
    	)
    	axialExpChngr = AxialExpansionChanger(cs["detailedAxialExpansion"])
    	for a in self.getAssemblies(includeAll=True):
    	if not a.hasFlags(Flags.CONTROL):
    	axialExpChngr.setAssembly(a)
    	axialExpChngr.expansionData.computeThermalExpansionFactors()
    	axialExpChngr.axiallyExpandAssembly(thermal=True)

  • If you have your linearExpansionPercent methods set to 0.0 (or to be 0.0 when Tinput == Thot) you should be good as all of the thermal expansion factors will be 0.0.
  • One last note, the axialExpansionChanger is only designed to work with pin-type assemblies. So if you are interested in pebble-fueled / non-pin-type reactors it might be best to modify the source to skip it. Or maybe open an ARMI issue to skip instances of running the axialExpansionChanger if a core type is pebble fueled.

[keckler]

But @albeanth , if you modify the linearExpansionPercent methods to return 0.0 all the time, then you won't get proper densities in many (most/all?) of the materials, even at their Tinput values.

Right?

[albeanth]

@keckler I think it'll be ok, actually. If I'm interpreting it right, you'll basically be setting dLL in armi/materials/material.py::Material::density to 0.0. So the factor, f, that would be used to adjust the reference density, refDens , would just be 1.0, and you would always be returning the reference density.

armi/armi/materials/material.py

Lines 362 to 374 in d012383

	Tk = getTk(Tc, Tk)
	dLL = self.linearExpansionPercent(Tk=Tk)
	if self.p.refDens is None:
	runLog.warning(
	"{0} has no reference density".format(self),
	single=True,
	label="No refD " + self.getName(),
	)
	self.p.refDens = 0.0
	f = (1.0 + dLL / 100.0) ** 2
	# dRhoOverRho = (1.0 - f)/f
	# rho = rho + dRho = (1 + dRho/rho) * rho
	return self.p.refDens / f # g/cm^3

[drewj-usnctech]

I think we've had issues setting linearExpansionPercent to be zero in the past. But that was more if Tinput != Thot

One approach would be to always return Material.p.refDens during calls to Material.density

Lastly, this recommendation from @albeanth (nice to meet you!)

If you have your linearExpansionPercent methods set to 0.0 (or to be 0.0 when Tinput == Thot) you should be good as all of the thermal expansion factors will be 0.0.

would work. But it would require two Material classes for e.g., UO2 : one with linear expansion and one without linear expansion. Granted, at the heart of the ask here is to toggle off linear expansion so that might be acceptable.

I guess I was more hoping for a single setting that would allow us to keep one material module and instruct ARMI not to do any expansion along the way. Starting to see the layers to this problem might require more work 😅

[drewj-usnctech]

This is also related to a thread in the particle fuel PR #702 - loading particle fuel onto a Component before it's dimensions are expanded

#702 (comment)

[drewj-usnctech]

I'm not sure if it's at the Component or Material level, but I've seen some methods have a cold switch which seems to imply using Tinput values, not Thot. If I'm remembering right

[albeanth]

@drewj-usnctech Was just looking over the ARMI discussions page and remembered this thread. There have been a couple of recent ARMI PRs that are relevant to this discussion - namely #804 and (probably less so) #797.

#804 represents a little more under-the-hood/possible "gotcha" for number density adjustments to account for radial expansion if there is a $\Delta T$ between Tinput and Thot on your components. If you have Tinput == Thot, your number densities will not be changed and you should be good.

#797 - As long as you have inputHeightsConsideredHot: True (which is the default) you should avoid doing axial expansion during Core::processLoading.

Anyway, just a heads up. Let me/us know if you're having issues.