Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Line cooling and cosmic ray heating #773

Open
wants to merge 49 commits into
base: development
Choose a base branch
from

Conversation

chongchonghe
Copy link
Contributor

@chongchonghe chongchonghe commented Oct 11, 2024

Description

This pull request implements line cooling and cosmic ray heating. The key changes include:

  • Added line cooling to the single-group and multi-group radiation solvers when enable_dust_gas_thermal_coupling_model = true . Line cooling is enabled by defining DefineNetCoolingRate and DefineNetCoolingRateTempDerivative in the problem file.
  • Implemented cosmic ray heating in all solvers, which is enabled by defining DefineCosmicRayHeatingRate in the problem file.
  • Added tests for the new line cooling and cosmic ray heating functionality.
    • RadLineCooling: test line cooling + CR heating + PE heating for single-group radiation system.
    • RadLineCoolingMG: test line cooling + CR heating + PE heating for multi-group radiation system, for both well-coupled and decoupled gas-dust systems.

This is the last feature I have finished implementing a while ago and I want to merge into the development branch before we move to Microphysics. In the next PR, I'll try to structure the code in the format of actual_rhs(), actual_jac(), andbackward_euler_integrator() so that we can readily start to use Microphysics API.

Test problems

RadLineCooling

Initial conditions: uniform static gas with a temperature $T_0 = 1$ and $C_V = 1$; the radiation energy density is 0. The dust opacity is 0. The line cooling rate is $\Lambda_{\rm line} = C_{\Lambda} T$, where $C_{\Lambda} = 0.1$, and the CR heating rate is $\Gamma_{\rm cr} = 0.03$. As the gas cools down, its temperature follows the following ODE:

$$ C_V \frac{d T}{d t} = - C_{\Lambda} T + \Gamma_{\rm cr} $$

The solution is

$$\begin{gather} T(t) = C_{\Lambda}^{-1} e^{-\frac{C_{\Lambda }}{C_V} t} \left(\Gamma _{\text{cr}} e^{\frac{C_{\Lambda}}{C_V} t}+ T_0 C_{\Lambda }-\Gamma_{\text{cr}}\right) \\\ E_{\rm rad}(t) = -(C_V T(t) - C_V T_0 - \Gamma_{\rm cr} t) \end{gather}$$

In the end of the test, the numerical results of $T(t)$ and $E_{\rm rad}(t)$ are checked against the exact analytical solution.

RadLineCoolingMG

The initial condition is the same as that of RadLineCooling, except

  1. There are four radiation bins. The first bin is the line emission and the last bin is photoelectric heating (FUV).
  2. The initial radiation energy density is 1 in the last bin and 0 in all other bins. The opacity is 0 in all bins.
  3. PE heating is enabled and $\Gamma_{\rm pe} = 0.02 E_{\rm FUV} = 0.02$.
    The ODE is

$$ C_V \frac{d T}{d t} = - C_{\Lambda} T + \Gamma_{\rm cr} + \Gamma_{\rm pe} $$

and the solution is the same as the previous one with two differences: (1) $\Gamma_{\rm cr}$ is replaced with $\Gamma_{\rm cr} + \Gamma_{\rm pe}$; (2) $E_{\rm rad}$ represents the energy density of the first bin.

This test is run twice, one with well-coupled gas-dust model and one with decoupled gas-dust model.

Related issues

Are there any GitHub issues that are fixed by this pull request? Add a link to them here.

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.

@dosubot dosubot bot added the size:XXL This PR changes 1000+ lines, ignoring generated files. label Oct 11, 2024
@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link

sonarcloud bot commented Oct 11, 2024

src/problems/RadLineCooling/test_rad_line_cooling.cpp Dismissed Show dismissed Hide dismissed
src/problems/RadLineCooling/test_rad_line_cooling.cpp Dismissed Show dismissed Hide dismissed
sim.evolve();

// read output variables
auto [_, values] = fextract(sim.state_new_cc_[0], sim.Geom(0), 0, 0.0);

Check notice

Code scanning / CodeQL

Unused local variable Note test

Variable values is not used.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please either fix or NOLINT this.

src/problems/RadLineCoolingMG/test_rad_line_cooling_MG.cpp Dismissed Show dismissed Hide dismissed
src/problems/RadLineCoolingMG/test_rad_line_cooling_MG.cpp Dismissed Show dismissed Hide dismissed
const bool is_coupled = sim.dustGasInteractionCoeff_ > 1.0;

// read output variables
auto [_, values] = fextract(sim.state_new_cc_[0], sim.Geom(0), 0, 0.0);

Check notice

Code scanning / CodeQL

Unused local variable Note test

Variable values is not used.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Again, please fix or NOLINT

@chongchonghe
Copy link
Contributor Author

@markkrumholz This PR is ready for your review.

@markkrumholz
Copy link
Collaborator

@markkrumholz This PR is ready for your review.

Will get to it ASAP, but it may be a few days.

@@ -108,6 +108,9 @@ void interpolate_arrays(double *x, double *y, int len, double *arr_x, double *ar
/* Note: arr_x must be sorted in ascending order,
and arr_len must be >= 3. */

// check if x is within the range of arr_x
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You should change this to one of the AMReX assert macros so that it functions properly on GPU or GPU, and in parallel. See https://amrex-codes.github.io/amrex/doxygen/AMReX__BLassert_8H.html


const double max_time = 10.0;

template <> struct SimulationData<PulseProblem> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe call this something other than PulseProblem, since it appears to be unrelated to the actual radiation pulse problem described in our papers?

const double CR_heating_rate = 0.03;
const double PE_rate = 0.02;

template <> struct SimulationData<PulseProblem> {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same comment about the name of this test as with the non-multigroup version -- call it something more usefully descriptive.


auto problem_main() -> int
{
// This problem is a *linear* radiation diffusion problem, i.e.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this comment does not apply to this problem, and is left over from the problem you cloned. Please correct or delete.

@@ -138,6 +139,10 @@ template <typename problem_t> struct FluxUpdateResult {
amrex::GpuArray<amrex::GpuArray<amrex::Real, Physics_Traits<problem_t>::nGroups>, 3> Frad; // radiation flux
};

// template <typename problem_t> struct SingleVariableState {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to keep this commented-out code, or can it be deleted?

Copy link
Collaborator

@markkrumholz markkrumholz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have left some comments on individual bits of code that you can look at, but there is also an overall design issue, which is the way you're using number density. The problem is that you don't specify the number density of what -- number of H nuclei, number of atomic H, number of H2, etc. -- and so this code becomes ambiguous and potentially incorrect as soon as we have chemistry. I think any time we need a number density, we need to be extremely careful to specify number density of which species, and we need to encapsulate the process of deriving the number density of that species from the density and mass scalars inside a function that can be swapped in or out depending on the chemistry network. Thus for example the current code that does things like num_density = rho / mean_molecular_weight could be encapsulated in a function called derive_num_density_H0 which derives the number density of neutral hydrogen from the density and mass scalar array. If the chemistry trait you have then selects the network to be none, then the current implementation is turned on, but if another chemistry network is selected then this handled differently, depending on the species in that network.

What we don't want to do, though, is hardwire in a solution that works only when chemistry is off, and then have it break in subtle and hard-to-detect ways if anyone tries to use it with chemistry turned on.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:XXL This PR changes 1000+ lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants