Remove grav_source_type and rot_source_type parameters #580
Conversation
The current default values (4 for both; the conservative energy formulation) are now the only option. Closes #156
|
I would like to actually do this because it is my goal to implement fully conservative gravity and rotation options that are applied directly to the fluxes (for both momentum and energy). When I originally did the analysis of these source terms, I didn't see much benefit from doing it this way in terms of conservation properties, but I think it will be much better for code maintainability. |
|
|
|
For constant gravity, the source term is very similar in both cases, except that the energy source term evaluates the time-centered (rho * v * g) at zone edges rather than zone centers. The main case in which they would differ substantially is at a symmetry boundary, because the contribution on the boundary is zeroed out, as the fluxes are zeroed out. |
|
Note that the MOL and SDC options still use an explicit source term, not the conservative flux-based approach. Also, it is not clear how to do this conservative approach to 4th order accuracy. |
|
grav_source_type == 4 only matters for the corrector source, this shouldn't change anything for MOL/SDC. |
|
agreed, but it should be possible to do this for MOL/SDC second-order, since we have the fluxes at the time we need the source. |
|
Yes. That is one of the things I will pursue in a later PR. |
|
so Is this conservative formulation axisymmetric-aware? |
|
I suspect the problem here is the hydrostatic boundary. We need to figure out how to do an HSE boundary condition with conservative gravity. |
|
Yes, the conservative formulation works for axisymmetric/spherical geometries. |
|
@zingale can you provide a specific reproducer for the flame_wave issue? |
|
Running Works fine with |
|
I was able to reproduce this after 3234 steps with The code is crashing because of CFL violations on the fine grids. They are so large that the default number of retry subcycles cannot handle it, hence the abort. Examining the plotfile at the end of the previous step shows that all of the velocities are reasonable. The large velocity is not present there on any level. Rather, the large velocity is being generated during a regrid. Unfortunately this is diffcult to avoid: even if the regrid step is extremum-preserving, the extrema preserved are the momenta and density, not velocity (which is not a state variable), and so it's still possible to generate a large velocity as a result of an unlucky combination of (rho u) and (rho). I verified that if I set My recommendation is that you use I don't know for sure why this happens only with grav.source_type = 4. But it's most likely just bad luck; this could happen regardless of other parameters, and it's the reason I have had |
|
There are still issues with flame_wave. Using the above dt fix, the problem runs out longer but eventually hits a dt of 9e-15 (sometime after 27000 steps). |
|
The removal of the But the timestep is still about 4x smaller than the |
|
tests: http://groot.astro.sunysb.edu/Castro/test-suite/gfortran/2022-05-27-002/index.html |
|
we still have the timestep issue with this change for |
|
Here's a comparison of the flame_wave with different
The biggest difference appears to be in the temperature structure at the top of the atmosphere. This is where the density is going toward 0, so it makes sense that the mass fluxes might be doing something odd here which changes the energy. |
|
The |
|
Note this is with CFL = 0.8, so the timestep validity retries are not unexpected. |
PR summary
The current default values (4 for both; the conservative energy formulation) are now the only option.
Closes #156
PR checklist