Provide plugin hook getAxialExpansionChanger

[drewj-tp]

What is the change?

Plugins are now able to implement the getAxialExpansionChanger hook to provide their own class responsible for
performing the initial thermal axial expansion of assemblies. The default implemented hook, brought by the ReactorPlugin, exposes the armi.reactor.converters.axialExpansion.AxialExpansionChanger class.

Why is the change being made?

This allows plugins to bring their own machinery for thermal axial expansion during the blueprints construction stage. Plugins can even opt to make a subclass that does not perform axial expansion at all.

Closes #1843

Todo

• Release notes (need pr number to edit release notes)
• Testing (need to prove only the first such class is returned)
  • Local dev experience indicates this is the case, but tests will be needed to prove this and prevent future problems

---

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.

[albeanth]

This looks great to me. Just some feedback on the comments for clarity and posterity/long-term maintenance.

[john-science]

I only have two small things on this PR. Take a look.

So... the purpose of this design is two-fold?

1. Developers can now drop in their own AxialExpansionChanger subclasses.
2. Developers can now opt to not have an AxialExpansionChanger changer at all, by just not having this plugin hook in any of their plugins?

Do I have the goals right?

IF I do, I guess I have some questions:

1. What happens if you use this plugin hook in more than one plugin?
   • I assume this has to fail, right?
   • Have you tested that?
   • How does it fail?
2. Does ARMI run if zero plugins implement this hook?
   • I want to make sure this change doesn't break for reactors with no assemblies.

[drewj-tp]

I only have two small things on this PR. Take a look.

So... the purpose of this design is two-fold?

1. Developers can now drop in their own AxialExpansionChanger subclasses.
2. Developers can now opt to not have an AxialExpansionChanger changer at all, by just not having this plugin hook in any of their plugins?

Do I have the goals right?

Goal 1 is correct. Any application can drop in their own AxialExpansionChanger subclass.

Goal 2 is slightly incorrect. The default ReactorPlugin implements this hook that brings the current AxialExpansionChanger. If an application does not register any plugin that implement this hook, the "default" state is to bring the existing expansion changer into the mix. To put it another way, this plugin hook is always implemented, but applications can circumvent the default expander by implementing the hook.

And, if somehow you do not register the ReactorPlugin and find yourself in a situation where no plugin registered implements this hook, I have no idea what pluggy will do. It may return None and then get some attribute errors trying to call None.expandColdDimsToHot as if it were an expander class?

IF I do, I guess I have some questions:

1. What happens if you use this plugin hook in more than one plugin?

   • I assume this has to fail, right?
   • Have you tested that?
   • How does it fail?

@albeanth had this same question. If multiple plugins implement this hook, the first non-None result will be "selected" and used. The goal is there should be at most two plugins that implement this hook and registered with the application

1. Default ReactorPlugin.getAxialExpanderClass
2. Some other plugin deemed responsible of owning axial expansion.

The ReactorPlugin.getAxialExpanderClass hook implementation is marked with trylast=True so, regardless of the plugin registration ordering, it should be the last such hook to be called.

The test I added covers two plugins implementing this hook and showing the behavior of the trylast marker.

1. No new plugin -> call plugin hooks -> default AxialExpansionChanger fetched from ReactorPlugin
2. Register a different plugin that implements the hook -> call plugin hooks hooks -> expansion changer from second plugin is registered

armi/armi/tests/test_plugins.py

Lines 110 to 120 in b1270c9

	def test_axialExpansionHook(self):
	"""Test that plugins can override the axial expansion of assemblies via a hook."""
	pm = self.app.pluginManager
	first = pm.hook.getAxialExpansionChanger()
	# By default, make sure we get the armi-shipped expansion class
	self.assertIs(first, AxialExpansionChanger)
	pm.register(SillyAxialPlugin)
	second = pm.hook.getAxialExpansionChanger()
	# Registering a plugin that implements the hook means we get
	# that plugin's axial expander
	self.assertIs(second, SillyAxialExpansionChanger)

2. Does ARMI run if zero plugins implement this hook?

   • I want to make sure this change doesn't break for reactors with no assemblies.

One plugin already implements and registers this hook - ReactorPlugin.getAxialExpanderClass. And that performs the current behavior. So reactors with no assemblies should not see any changes if they do not implement this hook.

However, such applications could implement this hook on a plugin that produces a do-nothing expander class. That is (potentially, untested) way to skip axial expansion beyond setting Tinput=Thot

[john-science]

After CI passes, I think this is ready for show time, if you guys do.

[albeanth]

After CI passes, I think this is ready for show time, if you guys do.

This is apart of a larger downstream slough of changes, so let's hold tight till those are ready?