Confusion about AMReX_RKIntegrator.H and AMReX_RungeKutta.H

[FR13ndSDP]

I see that in Src/Base there are two files related to RK integrator, where AMREX_RungeKutta.H implements AmrLevel::RK and it fills ghost cells correctly for high order RK methods when subcycling is used according to this pull request. Does it mean that RK methods implemented in AMRex_RKIntegrator.H is probably incorrect when it comes to high order methods? Should we use with care for the same situation using SUNDIALS integrator?

Thanks.

[WeiqunZhang]

AMReX_RKIntegrator.H is not wrong. It is an ODE solver that relies on the user to provide the correct RHS. When it is used to solve PDEs on AMR grids, one must fill the coarse/fine boundary correctly. For some high-order RK methods, it's non-trivial to fill the coarse/fine boundary correctly, because the intermediate RK stages do not exactly have a time associated with it. (See https://arxiv.org/abs/0810.2517v1 and https://msp.org/camcos/2011/6-1/p01.xhtml) Again, AMReX_RKIntegrator.H is not wrong. However, it would require the user to do a lot of work. That was why we implemented AMReX_RungeKutta and AMReX_FillPatcher. For AmrLevel based code, one can use it like this

amrex/Tests/GPU/CNS/Source/CNS_advance.cpp

Line 34 in 084165c

RK(rk_order, State_Type, time, dt, iteration, ncycle,

.

As for SUNDIALS integrators, I am not very familiar. I guess it depends. I know spectral deferred correction methods usually do not have such issues. (See for example, https://arxiv.org/abs/1806.10718)

[FR13ndSDP]

Thanks for your helpful information! If I understand correctly, AMReX_RungeKutta is an out-of-the-box solution for AmrLevel based code, while AMReX_RKIntegrator is a pure RK solver that provides the user with more flexibility.

Thanks again for your help.