Better way to subclass thermal scattering labels for plugins

[AidanMcDonald]

To use thermal scattering data in the ARMI OpenMC plugin, the labels for the thermal scattering data in OpenMC's syntax need to be generated somewhere. I recently submitted pull request #1792 in which I generate these labels with ARMI's existing ENDF and ACE label generators. However, @jakehader made a good point that this involves introducing some semi-hardcoded names into the framework and it's safer to keep these labels with the plugin that uses them.

Implementing these labels directly in the plugin misses out on many of the features of the ARMI ThermalScattering object. The best long-term solution from the plugin side would be a way to store the labels themselves in the plugin but have them behave like the existing ENDF and ACE labels (present in the material library in the ThermalScattering objects in armi.material.thermalScatteringLaws at import or configure time, accessible via armi.nucDirectory.ThermalScattering.byNbAndCompound, etc.). I don't know off the top of my head how that could work. Future physics plugins that make use of thermal scattering data will need something similar since they all use slightly difference labeling schemes.

For now, I have a temporary solution in the OpenMC plugin, so I think it makes sense to close the pull request and move the discussion here.

[john-science]

@AidanMcDonald

For now, I have a temporary solution in the OpenMC plugin

Can you point me at your solution? I'd like to ponder it, so I can decide if this should be "purely" in a Plugin, or if ARMI should provide some sort of support for it.

Thanks!

[AidanMcDonald]

@john-science, here's what I've been using. It has turned out to not be as cumbersome as I expected. I can still use the armi.material.thermalScatteringLaws objects like I want and generate the labels only immediately before they're used. The downside is a handful of unsightly if statements to handle the labels that the other rules don't cover. My only remaining complaint is that the OpenMC labels are implemented differently than the ENDF and ACE labels, but I'm now thinking that, if anything, it would make more sense to move the ENDF and ACE label generation out to plugins where they're used rather than moving the OpenMC labels in.

https://github.com/terrapower/armicontrib-openmc/blob/908c5e29ebfd140ec28bb0de4c9f898001ef6823/armicontrib/armiopenmc/inputWriters.py#L867-L889