photoelectric heating

[chongchonghe]

Description

In this PR, I implement photoelectric heating within the current gas-radiation-dust interaction framework. PE can be enabled by setting enable_photoelectric_heating = true in ISM_Traits. The prerequisite is nGroups > 1 and enable_dust_gas_thermal_coupling_model = true.

Added two test problems, RadiationMarshakDustPE-coupled and RadiationMarshakDustPE-decoupled, to test photoelectric heating in cases where gas and dust are well coupled and decoupled. These two tests share the same problem code test_radiation_marshak_dust_and_PE.cpp but use different runtime parameters.

Here is the code structure:

- AddSourceTermsMultiGroup
  - outer loop:
    - compute `v_times_F_term` 
    - solve gas-dust-radiation energy exchange:
      - if constexpr (!enable_dust_gas_thermal_coupling_model_)
        - `SolveGasRadiationEnergyExchange`:
          - The matter-radiation coupling scheme from the multigroup paper
      - else if constexpr (!enable_photoelectric_heating_)
        - `SolveGasDustRadiationEnergyExchange()`:
          - The gas-dust-radiation coupling scheme proposed in #733, which has two cases: the well-coupled case and decoupled case
      - else
        - `SolveGasDustRadiationEnergyExchangeWithPE()`:
          - Based on the gas-dust-radiation coupling scheme, but with modified Jacobian in the well-coupled case to include PE heating. In the decoupled case, PE heating is added via a forward-Euler update using the updated radiation energy density after the gas-dust-radiation step.
    - compute updated `v_times_F_term` 
    - if `v_times_F_term` has converged, break
  - `UpdateFlux()`

Related issues

A modification to #733 to include PE heating.

Checklist

Before this pull request can be reviewed, all of these tasks should be completed. Denote completed tasks with an x inside the square brackets [ ] in the Markdown source below:

• I have added a description (see above).
• I have added a link to any related issues see (see above).
• I have read the Contributing Guide.
• I have added tests for any new physics that this PR adds to the code.
• I have tested this PR on my local computer and all tests pass.
• I have manually triggered the GPU tests with the magic comment /azp run.
• I have requested a reviewer for this PR.

[chongchonghe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[markkrumholz]

OK, another stylistic question. The design here seems a bit different than our normal paradigm, in that you have the various source and exchange models protected by ifdef brackets, and you forward-declare the various exchange and solver functions is radiation_system.hpp so that even if you turn off a particular exchange model by not #define'ing the appropriate flag to turn it on, you don't get compilation errors thanks to the forward declaration. This is contrary to our style thus far of mostly using if constexpr's and templates to manage conditional compilation. The paradigm that I would think would work would be remove the forward declarations from radiation_system.hpp and the protection ifdef's from the various model files, and just #include the various model files in radiation_system.hpp, but then select which model to use at compile time with a trait in the problem file. Is there a reason not to use this paradigm here?

[chongchonghe]

OK, another stylistic question. The design here seems a bit different than our normal paradigm, in that you have the various source and exchange models protected by ifdef brackets, and you forward-declare the various exchange and solver functions is radiation_system.hpp so that even if you turn off a particular exchange model by not #define'ing the appropriate flag to turn it on, you don't get compilation errors thanks to the forward declaration. This is contrary to our style thus far of mostly using if constexpr's and templates to manage conditional compilation. The paradigm that I would think would work would be remove the forward declarations from radiation_system.hpp and the protection ifdef's from the various model files, and just #include the various model files in radiation_system.hpp, but then select which model to use at compile time with a trait in the problem file. Is there a reason not to use this paradigm here?

I also tried another paradigm and I just pushed it. In this paradigm, there are two main files in src/radiation: radiation_system.hpp and radiation_dust_system.hpp. The latter file contains all the definition of the functions used solely in dust or dust+PE models, and it includes radiation_system.hpp. Now, in most tests where there is no dust model, we include radiation_system.hpp and those functions for dust is never read by the compiler. In tests with dust, we include radiation_dust_system.hpp in the header. Does this resolve your concern?

Both of the two hpp files have to be protected by ifdef in this new paradigm.

[chongchonghe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[markkrumholz]

Thanks, that structure is much cleaner. I left a few minor stylistic comments (mostly about your comments!), but once those are resolved I'm happy to approve.

[chongchonghe]

OK. All done.

[sonarcloud]

Quality Gate passed

Issues
44 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
64.9% Duplication on New Code

See analysis details on SonarCloud

[chongchonghe]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).