Make application of material modifications more robust against incorrect types

[keckler]

What is the change?

This PR adds a deeper interrogation of the error conditions that come up during the application of material modifications. The intention is to catch when the user may have specified a material modification of the wrong type in their blueprints, which before would have been silently ignored.

Why is the change being made?

I came across an instance in my own work where a material modification of the wrong type was being specified. This was a bug that had been in my model for multiple years, and I was surprised to find that ARMI did not seem to care to warn me.

The root of this problem is the way that the material modifications infrastructure is designed. Material modifications are applied during the construction of components here:

armi/armi/reactor/blueprints/componentBlueprint.py

Lines 367 to 375 in 1920ff0

	if len(matMods) > 1:
	# don't apply if only customIsotopics is in there
	try:
	# update material with updated input params from blueprints file.
	mat.applyInputParams(**matMods)
	except TypeError:
	# This component does not accept material modification inputs of the names passed in
	# Keep going since the modification could work for another component
	pass

As can be seen above, the whole thing is wrapped in a try/except, with the only error condition being checked a ValueError. The assumption with that code is that the ValueError will only be triggered when a material modification with an invalid name is passed to the material's applyInputParams() method. That is a very bold assumption, as basically anything could go wrong during the execution of applyInputParams(), includingValueErrors that are indicative of real bugs.

As a concrete example, let's look at the material modifications within UraniumOxide:
https://github.com/terrapower/armi/blob/main/armi/materials/uraniumOxide.py#L109-L132

That material will take U235_wt_frac and TD_frac, both of which should be floats. But from my yaml blueprints file it would be entirely possible for me to specify a str. This would obviously break UraniumOxide.applyInputParams(), which would raise a ValueError. However when that ValueError is raised, the try/except around applyInputParams() will just pass and the material modification is left at its default value. This would be a bug.

---

Checklist

• This PR has only one purpose or idea.
• Tests have been added/updated to verify any new/changed code.

• The code style follows good practices.
• The commit message(s) follow good practices.

• The release notes have been updated if necessary.
• The documentation is still up-to-date in the doc folder.
• The dependencies are still up-to-date in pyproject.toml.

[john-science]

I like the change. But what I would REALLY like is a two test cases, one that hit each version of this exception. Just to be clear about what we expect each type of input to do.

Is that too much work?

[keckler]

But what I would REALLY like is a two test cases, one that hit each version of this exception. Just to be clear about what we expect each type of input to do.

Yes, definitely. I actually thought I wrote some tests here, but I don't seem them in my local copy... I guess I was probably just doing one-off testing.

Yes, I will write some tests.

[keckler]

I like the change. But what I would REALLY like is a two test cases, one that hit each version of this exception. Just to be clear about what we expect each type of input to do.

@john-science I added a unit test to the PR that catches the new scenario where the specified material modification is of the wrong type. Specifically, it catches this part:
https://github.com/terrapower/armi/pull/2046/files#diff-adf715a7067ab05bf0ada9c5401f6b7a9b75ffd67dddb7b767550af593175ad6R381-R385

The other part (where the error message would have resulted from a material modification with the wrong name being applied to a component) is already going to be caught by an existing test:

armi/armi/reactor/blueprints/tests/test_materialModifications.py

Lines 302 to 348 in ee691ab

	def test_matModsUpTheMRO(self):
	"""
	Make sure that valid/invalid material modifications are searched up
	the MRO for a material class.
	"""
	_a = self.loadUZrAssembly(
	"""
	material modifications:
	ZR_wt_frac: [1]
	class1_wt_frac: [1]
	class1_custom_isotopics: [dummy]
	class2_custom_isotopics: [dummy]
	by component:
	fuel2:
	ZR_wt_frac: [0]
	class1_wt_frac: [1]
	class1_custom_isotopics: [dummy]
	class2_custom_isotopics: [dummy]
	custom isotopics:
	dummy:
	input format: mass fractions
	density: 1
	U: 1
	"""
	)
	with self.assertRaises(ValueError):
	_a = self.loadUZrAssembly(
	"""
	material modifications:
	ZR_wt_frac: [1]
	klass1_wt_frac: [1]
	klass1_custom_isotopics: [dummy]
	klass2_custom_isotopics: [dummy]
	by component:
	fuel2:
	ZR_wt_frac: [0]
	klass1_wt_frac: [1]
	klass1_custom_isotopics: [dummy]
	klass2_custom_isotopics: [dummy]
	custom isotopics:
	dummy:
	input format: mass fractions
	density: 1
	U: 1
	"""
	)

So I think that this PR is good to go, but me know what you think.