Temperature transfer using an OpenMC temperature field

[JoffreyDorville]

Hi everyone!

This PR adds a mode to transfer temperature to OpenMC via the upcoming OpenMC temperature field (openmc-dev/openmc#3734).

Because this PR needs OpenMC PR 3734 to be merged to actually work, it will remain a draft PR for the moment.

Context

I am using Cardinal to transfer temperatures to OpenMC with a custom temperature field (regular mesh + vector of temperature values) on the OpenMC side. The multiphysics coupling seems to work well with my local prototype so I am working on cleaning the different features I have to submit them as PRs:
1. OpenMC initialization action (#1302)
2. OpenMC mesh generator (#1365)
3. Temperature transfer to OpenMC temperature field (this PR)

Implementation

A new way to send temperature from the elements of the MOOSE mirror mesh to an OpenMC temperature field has been implemented. This transfer happens in OpenMCCellAverageProblem and relies on the C API function openmc_temperature_field_set_temperature() to transfer the temperature values to OpenMC. A new parameter named temperature_field_transfer has been added to OpenMCCellAverageProblem to trigger this new transfer mode when needed.

This implementation relies on a naive mapping approach (same cell ordering between MOOSE and OpenMC mesh elements) and restrictions are still needed to be implemented to guarantee temperature transfer consistency.

Limitations

It is currently limited to the regular mesh type of OpenMC.

[moosebuild]

Job Precheck, step Clang format on d824fa5 wanted to post the following:

Your code requires style changes.

A patch was auto generated and copied here
You can directly apply the patch by running, in the top level of your repository:

curl -s https://mooseframework.inl.gov/cardinal/docs/PRs/1415/clang_format/style.patch | git apply -v

Alternatively, with your repository up to date and in the top level of your repository:

git clang-format 9f003d56e80bf69edcb3901fc163b02c8e6e6e5e

[aprilnovak]

Thanks @JoffreyDorville! Since this data transfer is not using anything about cell averages, it might be time to make another derived class of OpenMCProblemBase -- e.g. OpenMCMeshProblem or something like that?

[nuclearkevin]

Something to think about if we're creating a new OpenMC problem class is that tallies and filters are entirely handled through the OpenMCCellAverageProblem at present. They will likely need to be refactored such that they're added and managed by an OpenMCProblemBase instead, with guardrails put up to prevent the addition of cell tallies when using non-OpenMCCellAverageProblems.