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

Clean up code for single-group radiation #684

Merged
merged 21 commits into from
Jul 30, 2024

Conversation

chongchonghe
Copy link
Contributor

@chongchonghe chongchonghe commented Jul 25, 2024

Description

This PR updates the code structure for single-group radiation so that functions like ComputePlanckOpacity return a double. This change enforces the use of the correct opacity models (i.e., piecewise_constant_opacity or PPL_opacity_fixed_slope_spectrum, or PPL_opacity_full_spectrum) when dealing with multiple radiation groups. The previous code provides an option to naively extend the single-group formulation in the IMEX paper to the multigroup case, i.e. replacing $\kappa_P$ and $\kappa_F$ with $\kappa_g$. However, that method does not correctly describe multigroup radiation transport and should be removed, because it misses the important delta term in the flux equation. See Equation 16 of the multigroup paper and the discussion thereafter.

In summary, here's how you should define gas opacity in a problem:

  • Single-group opacity definition:
    • Define ComputePlanckOpacity and optionally ComputeFluxMeanOpacity and ComputeEnergyMeanOpacity. By default, the latter two are set equal to the first.
  • Multigroup opacity definition:
    • Choose an opacity model by setting opacity_model in RadSystem_Traits to one of the following: piecewise_constant_opacity, PPL_opacity_fixed_slope_spectrum, or PPL_opacity_full_spectrum
    • Define DefineOpacityExponentsAndLowerValues. See the example in RadhydroShockMultigroup.

Bug fix:

  • fixed bug related to multigroup opacity in ComputeCellOpticalDepth. This function is only used when you turn on wave speed correction by hand and is not turned on by default. We can't have a regression test for this because it is controlled by use_wavespeed_correction inside radiation_system.hpp and we don't have a way to turn it on for a specific problem. I tested it on my computer and it worked as expected.

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 size:L This PR changes 100-499 lines, ignoring generated files. enhancement New feature or request labels Jul 25, 2024
@dosubot dosubot bot added size:XL This PR changes 500-999 lines, ignoring generated files. and removed size:L This PR changes 100-499 lines, ignoring generated files. labels Jul 25, 2024
@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@BenWibking
Copy link
Collaborator

We could createa new version of an existing test that uses the wavespeed correction in the Riemann solver to test this. I think that would help avoid this problem.

@chongchonghe
Copy link
Contributor Author

We could createa new version of an existing test that uses the wavespeed correction in the Riemann solver to test this. I think that would help avoid this problem.

The issue is, you can't turn it on for any specific problem. It's controlled by use_wavespeed_correction which is not in any traits. You have to change radiation_system.hpp to turn it on. I can, of course, add another parameter in the Radiation Trait, but I think it adds another fuss to the user and it's not worth it since we will almost never use it.

@BenWibking
Copy link
Collaborator

We could createa new version of an existing test that uses the wavespeed correction in the Riemann solver to test this. I think that would help avoid this problem.

The issue is, you can't turn it on for any specific problem. It's controlled by use_wavespeed_correction which is not in any traits. You have to change radiation_system.hpp to turn it on. I can, of course, add another parameter in the Radiation Trait, but I think it adds another fuss to the user and it's not worth it since we will almost never use it.

We could do this: AMReX-Codes/amrex#2954

@chongchonghe
Copy link
Contributor Author

We could createa new version of an existing test that uses the wavespeed correction in the Riemann solver to test this. I think that would help avoid this problem.

The issue is, you can't turn it on for any specific problem. It's controlled by use_wavespeed_correction which is not in any traits. You have to change radiation_system.hpp to turn it on. I can, of course, add another parameter in the Radiation Trait, but I think it adds another fuss to the user and it's not worth it since we will almost never use it.

We could do this: AMReX-Codes/amrex#2954

That feature is interesting. Have you tried it? Is there any example in Quokka? I'm not sure how to set runtime_option in problem.cpp.

@BenWibking
Copy link
Collaborator

That feature is interesting. Have you tried it? Is there any example in Quokka? I'm not sure how to set runtime_option in problem.cpp.

No, it's not currently used in Quokka.

In the code below, you can set runtime_option just like any other variable in the code. You could initialize its value by querying the ParmParse database, for instance, so that it's set from a command-line parameter.

    int runtime_option = ...; // set this based on the value of any variable, read it from an input file, read it from the command-line, do whatever you want
    enum All_options : int { A0, A1, A2, A3};
    // Four ParallelFors will be generated.
    ParallelFor(TypeList<CompileTimeOptions<A0,A1,A2,A3>>{}, {runtime_option},
                box, [=] AMREX_GPU_DEVICE (int i, int j, int k, auto control)
    {
        ...
        if constexpr (control.value == A0) {
            ...
        } else if constexpr (control.value == A1) {
            ...
        } else if constexpr (control.value == A2) {
            ...
        else {
            ...
        }
        ...
    });

@chongchonghe chongchonghe disabled auto-merge July 28, 2024 03:25
@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@chongchonghe
Copy link
Contributor Author

@BenWibking Can you review this PR?

@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

Copy link
Collaborator

@BenWibking BenWibking left a comment

Choose a reason for hiding this comment

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

I am confused. Can you explain more explicitly what opacity functions should be used by gray problems and what opacity functions should be used (and how) by multi-group problems?

src/radiation_system.hpp Outdated Show resolved Hide resolved
src/radiation_system.hpp Outdated Show resolved Hide resolved
src/RadhydroPulseMGint/test_radhydro_pulse_MG_int.cpp Outdated Show resolved Hide resolved
@chongchonghe
Copy link
Contributor Author

I am confused. Can you explain more explicitly what opacity functions should be used by gray problems and what opacity functions should be used (and how) by multi-group problems?

I updated the PR comments to better explain this.

@chongchonghe
Copy link
Contributor Author

/azp run

Copy link

Azure Pipelines successfully started running 2 pipeline(s).

@dosubot dosubot bot added the lgtm This PR has been approved by a maintainer label Jul 30, 2024
@chongchonghe chongchonghe enabled auto-merge July 30, 2024 02:51
@chongchonghe chongchonghe added this pull request to the merge queue Jul 30, 2024
Merged via the queue into development with commit 8d855a1 Jul 30, 2024
19 checks passed
@chongchonghe chongchonghe deleted the chongchong/cleanup-single-group branch July 31, 2024 08:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request lgtm This PR has been approved by a maintainer size:XL This PR changes 500-999 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants