Michael Zingale

`flame_wave` uses `grav_source_type = 2` currently. We need to see if the problem works well with 4. I vaguely remember there being issues with HSE, but that was a few...

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...

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.

so `castro.grav_source_type=4` crashes `flame_wave`. Too many subcycles. 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.

Running `flame_wave` with the following causes the "too many subcycles" error. Works fine with `grav_source_type = 2`. [inputs.noboost.500Hz.txt](https://github.com/AMReX-Astro/Castro/files/4004083/inputs.noboost.500Hz.txt) [probin.noboost.500Hz.txt](https://github.com/AMReX-Astro/Castro/files/4004085/probin.noboost.500Hz.txt)

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 `hard_cfl_limit = 0` option in this run resolves that timestep crash (#723) But the timestep is still about 4x smaller than the `grav_source_type = 2` version.

tests: http://groot.astro.sunysb.edu/Castro/test-suite/gfortran/2022-05-27-002/index.html lots of gravity compilation failures

we still have the timestep issue with this change for `flame_wave` -- the timestep is about a factor of 2x smaller with `castro.grav_source_type = 4` as compared with `castro.grav_source_type =...