Add radiation-driven shell to regression tests

[BenWibking]

Description

Adds this problem to the nightly regression test suite. There was also a bug in the initial conditions in the radiation flux in converting from spherical to Cartesian flux components (now fixed).

At late times, the simulation still has a slightly discrepancy w.r.t. the semi-analytic solution (similar to that shown in the original code paper). This is most likely due to initial shell thickness being quite significant. (There is not an easy solution to this, since there is no steady-state solution that satisfies the M1 closure for sufficiently thin shells.)

movie_large.mov

Related issues

Closes #743.

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 (if applicable; see above).
• I have read the Contributing Guide.
• I have added tests for any new physics that this PR adds to the code.
• (For quokka-astro org members) I have manually triggered the GPU tests with the magic comment /azp run.

[BenWibking]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[BenWibking]

Hmm, it looks like there is a global variable that is misbehaving:

pure virtual method called
terminate called without an active exception
[moth:2945339] *** Process received signal ***
[moth:2945339] Signal: Aborted (6)
[moth:2945339] Signal code:  (-753879392)

Will fix.

[BenWibking]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[BenWibking]

@markkrumholz @chongchonghe I would appreciate a review of this from both of you, if you have time.

[markkrumholz]

Code changes look fine. As to why we're not exactly preserving the analytic solution, one thing I might check is whether the shell is really very thin -- the analytic solution assumes an infinitely thin shell, and if that assumption is not fully satisfied, then we shouldn't expect to match the solution exactly. It may be necessary to tweak test parameters to reduce shell thickness, for example by reducing the sound speed so that pressure support becomes less important.

[chongchonghe]

The RadShell test on GPU failed. Even if you fix the bug, I speculate it will take too long to run. I would recommend reducing max_timesteps, which is currently set to 5000. With $128^3 = 2M$ cells, suppose a performance of 10 Mzone/s/GPU, that implies 5 steps/s. It will take 1000 seconds to run 5000 timesteps.

EDIT: the run time is also determined by stopTime_, which is set to 0.125 * t0_hydro. I guess that is bigger than 5000 steps?

[BenWibking]

@chongchonghe The error is this:

Coarse STEP 3203 at t = 7.844071263e+12 (81.33839288%) starts ...
	>> Using global timestep on this coarse step (estimated work ratio: 1).
[Level 0 step 3203] ADVANCE with time = 7.8440712630e+12 dt = 5.5257787970e+07
	>> CFL violation detected on level 0 with dt_lev = 55257787.97 and dt_cfl = 48548760.42
	   max_signal = 993202495.4
	>> WARNING: Hydro advance failed on level 0
	>> Re-trying hydro advance at level 0 with reduced timestep (nsubsteps = 2, dt_new = 27628893.98)
	Radiation substeps: 1	dt: 55257787.97
amrex::Abort::0::Newton-Raphson iteration for matter-radiation coupling failed to converge! !!!
SIGABRT
See Backtrace.0 file for details

I think this indicates our current method is not robust enough.

Edit: Ok, nvm. Something has gone wrong. The timestep is too small here anyway.

Somehow it works on AMD GPU, though...

      Start 34: RadhydroShell
34/52 Test #34: RadhydroShell ......................   Passed  465.20 sec

[BenWibking]

Code changes look fine. As to why we're not exactly preserving the analytic solution, one thing I might check is whether the shell is really very thin -- the analytic solution assumes an infinitely thin shell, and if that assumption is not fully satisfied, then we shouldn't expect to match the solution exactly. It may be necessary to tweak test parameters to reduce shell thickness, for example by reducing the sound speed so that pressure support becomes less important.

Ah, right. The shell is initially quite thick. This is necessary because there is no steady-state solution of the radiation moment equations for a sufficiently-thin shell under the M1 closure. But that probably means we shouldn't expect exact agreement...

[BenWibking]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[sonarqubecloud]

Quality Gate passed

Issues
2 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[BenWibking]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[BenWibking]

@chongchonghe I added a density floor, so it now works for 128^3, which is tested in the nightly regression tests. The 64^3 version is used for the /azp run tests for each PR.