Differences and purposes of Tinput, Thot, refTempK, and refDens

[drewj-usnctech]

So far as I can tell, Tinput and Thot help determine expansion of Components. Tinput is the temperature where Component dimensions are given, but Thot is the temperature modeled. So the physical models would reflect the geometry after expanding components from Tinput to Thot.

I get more confused when we throw refTempK in the mix. It's only defined for some materials as the "reference temperature." https://github.com/terrapower/armi/search?q=refTempK shows hastelloy and inconel alloys, SiC, and Zr. Hastelloy uses it for linearExpansionPercent

armi/armi/materials/hastelloyN.py

Lines 133 to 151 in b709d34

	def linearExpansionPercent(self, Tk=None, Tc=None):
	r"""
	average thermal expansion dL/L. Used for computing hot dimensions
	Parameters
	----------
	Tk : float
	temperature in (K)
	Tc : float
	Temperature in (C)
	Returns
	-------
	%dLL(T) in m/m/K
	"""
	Tc = getTc(Tc, Tk)
	refTempC = getTc(Tk=self.p.refTempK)
	return 100.0 * self.meanCoefficientThermalExpansion(Tc=Tc) * (Tc - refTempC)

Inonel allows use it in polyfitLinearExpansionPercent which doesn't appear to be used

armi/armi/materials/inconel600.py

Lines 140 to 181 in b709d34

	def polyfitLinearExpansionPercent(self, power=2):
	r"""
	Calculates the coefficients of a polynomial fit for linearExpansionPercent.
	Based on data from http://www.specialmetals.com/documents/Inconel%20alloy%20600.pdf
	Uses mean CTE values to find percent thermal strain values. Fits a polynomial
	to the data set and returns the coefficients.
	Parameters
	----------
	power : int, optional
	power of the polynomial fit equation
	Returns
	-------
	list of length 'power' containing the polynomial fit coefficients for linearExpansionPercent
	"""
	refTempC = getTc(None, Tk=self.p.refTempK)
	Tc = [100.0, 200.0, 300.0, 400.0, 500.0, 600.0, 700.0, 800.0, 900.0]
	alpha_mean = [
	1.33e-05,
	1.38e-05,
	1.42e-05,
	1.45e-05,
	1.49e-05,
	1.53e-05,
	1.58e-05,
	1.61e-05,
	1.64e-05,
	]
	linExpPercent = [0.0]
	for i, alpha in enumerate(alpha_mean):
	linExpPercentVal = 100.0 * alpha * (Tc[i] - refTempC)
	linExpPercent.append(linExpPercentVal)
	Tc.insert(0, refTempC)
	return numpy.polyfit(
	numpy.array(Tc), numpy.array(linExpPercent), power
	).tolist()

but I imagine there's a need for it in a mechanics plugin.

refDens is defined for just about everything and used heavily. Not a lot of confusion on what it means, but more on how it relates to refTempK.

My original assumption would be that refTempK is the temperature at which refDens is defined. As such, would I be correct in assuming the density of a Component at a temperature of refTempK is refDens? This is the case for SiC at least, or very close to correct

>>> from armi.reactor.components.basicShapes import Circle
>>> from armi.materials.siC import SiC
>>> s = SiC()
>>> s.p.refTempK
298.15
>>> s.p.refDens
3.21
>>> circ = Circle("demo", s, Tinput=s.p.refTempK-273.15, Thot=s.p.refTempK-273.15, od=1)
>>> circ.density()
3.1597241245892773
>>> circ.density() / s.p.refDens - 1
-0.015662266483091214

About 1.5% difference so not a massive difference, but not nothing

[drewj-usnctech]

@john-science @ntouran @keckler re-upping for some insight

[john-science]

Okay, so if you do a git grep refTempK in ARMI, you get:

armi/materials/hastelloyN.py:        self.p.refTempK = 273.15 + 20
armi/materials/hastelloyN.py:        refTempC = getTc(Tk=self.p.refTempK)

armi/materials/inconel600.py:        self.p.refTempK = 294.15
armi/materials/inconel600.py:        refTempC = getTc(None, Tk=self.p.refTempK)

armi/materials/inconel625.py:        self.p.refTempK = 294.15
armi/materials/inconel625.py:        refTempC = getTc(None, Tk=self.p.refTempK)

armi/materials/inconel800.py:        self.p.refTempK = 273.15 + 21.0
armi/materials/inconel800.py:        refTempC = getTc(Tk=self.p.refTempK)

armi/materials/inconelX750.py:        self.p.refTempK = 294.15
armi/materials/inconelX750.py:        refTempC = getTc(None, Tk=self.p.refTempK)

armi/materials/materialParameters.py:        pb.defParam("refTempK", units="K", description="Reference temperature")

armi/materials/siC.py:        self.p.refTempK = 298.15

It appears that refTempK is just the temperature upon which we decide the thermal linear expansion is zero. So, somewhere between 0C and room temp.

I am not sure I even like that this parameter exists. It is not used in enough places I think it really needs to exist. Maybe I will remove it entirely.

[john-science]

@ntouran Could you help us grok the difference between Material.density() and Material.p.refDens? It feels like there is some internal inconsistency here, probably historical, which is making it a bit hard for us to disentangle what they are supposed to be used for.

For instance, it might be that they have very clear purposes, but aren't used correctly in siC.

[keckler]

Your understanding of Thot and Tinput are exactly correct. But I think the meaning of refTempK is a little more ad hoc.

In the case of SiC that you point out, you can actually see that its density() method overwrites that of the base class and defines some rho0 and Tc0 of its own:

armi/armi/materials/siC.py

Lines 99 to 106 in 20ca687

	def density(self, Tc=None, Tk=None):
	Tc = getTc(Tc, Tk)
	(TLowerLimit, TUpperLimit) = self.propertyValidTemperature["density"][0]
	self.checkTempRange(TLowerLimit, TUpperLimit, Tc, "density")
	rho0 = 3.16
	Tc0 = 0.0
	cA = self.cumulativeLinearExpansion(Tc=Tc)
	return rho0 * (1 + cA * (Tc - Tc0)) ** (-3)

I also just noticed that, based on the last line in that method, the density is being thermally-expanded in 3D for SiC. This is a bug and is in direct contradiction to what the base density() method indicates should be happening:

armi/armi/materials/material.py

Lines 337 to 370 in 20ca687

	def density(self, Tk: float = None, Tc: float = None) -> float:
	"""
	Return density that preserves mass when thermally expanded in 2D.
	Warning
	-------
	This density will not agree with the component density since this method only expands in 2 dimensions.
	The component has been manually expanded axially with the manually entered block hot height.
	The density returned by this should be a factor of 1 + dLL higher than the density on the component.
	density3 should be in agreement at both cold and hot temperatures as long as the block height is correct for
	the specified temperature.
	In the case of Fluids, density and density3 are the same as density is not driven by linear expansion, but
	rather an exilicit density function dependent on Temperature. linearExpansionPercent is zero for a fluid.
	See Also
	--------
	armi.materials.density3:
	component density should be in agreement with this density
	armi.reactor.blueprints._applyBlockDesign:
	2D expansion and axial density reduction occurs here.
	"""
	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

So both of these facts could explain why in your demonstration above that the density from circ.density() does not align exactly with that of s.p.refDens.

What is the meaning of this? I don't really know, unfortunately. To me, it indicates that the construction of the SiC class is not internally-consistent, and thus it has issues. Clearly it has not been tested as thoroughly as it should be.

From my experience, many of the material classes in the public-facing ARMI framework are lacking in a variety of ways, whether that be lack of properties, inconsistent properties, or just flat-out bugs. This is especially the case for (what we at TP have historically considered) more esoteric materials like SiC.

So I understand that this does not really answer your question of "what is refTempK?" To my knowledge, refTempK is not used consistently. I think it probably is supposed to be used in conjunction with refDens as you indicate, but obviously you've found a violation of that principle, and it is not done consistently throughout all material classes.

All this goes to say, my opinion is that the material classes in the framework need to be carefully vetted before being used for "real" analysis.

Hopefully someone like @ntouran or @jakehader might have a better answer for you.