Add OpenMC label to ThermalScattering

[AidanMcDonald]

What is the change?

Added support for thermal scattering data labels in OpenMC's syntax (usually something like "c_H_in_H2O") analogous to current support for ENDFB8 and ACE labels. Also added tests similar to the existing ENDFB8 and ACE label tests. The label generator does not currently work for all thermal scattering data available to OpenMC (for example "c_O_in_H2O_solid" or "c_ortho_H"), but it works for all thermal scattering laws used in ARMI in thermalScattering.byNbAndCompound.

Why is the change being made?

An OpenMC label generator is necessary to use thermal scattering data in the ARMI OpenMC plugin, and it is simpler to include it in ARMI's thermal scattering module rather than in the plugin itself.

---

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.

[jakehader]

Hi @AidanMcDonald - would it be possible to implement this in the OpenMC plugin directly or can we think about ways to abstract the thermal scattering laws implementation so that specific code-based names and attributes aren't added to the code base? I think this would be a more robust way of handling the framework for "n" codes and so that if OpenMC changes the naming it doesn't impact the framework design.

[jakehader]

See general comment above. I see your comment on it being easier to implement in the framework, but maybe we can make the framework easier to subclass.

[AidanMcDonald]

@jakehader , thanks for the feedback. Here's my reasoning for implementing it this way:

My intention is to implement the OpenMC label generator in the same way as the current ENDFB8 and ACE label generators since the generation and use is almost identical. I agree that adding specific names isn't ideal, but just like with the ENDF and ACE label generators, some of the labels don't follow logical rules and must be hard-coded. Since that is the case, I think it makes sense to keep the hard-coded ENDF, ACE, and OpenMC labels together like the hard-coded ENDF and ACE labels are now.

With that said, I have made a function in the OpenMC plugin that will work for now (featuring a lot of if statements for the "hard-coded" labels) if that's the direction you want to go.

[AidanMcDonald]

Moving discussion to #1804 and closing for now. I will keep the branch in my fork just in case.