In GitLab by @sloede on Mar 24, 2020, 13:27

created merge request !15 to address this issue

In GitLab by @sloede on Mar 24, 2020, 13:27

mentioned in merge request !15

In GitLab by @sloede on Apr 14, 2020, 10:12

To start a discussion, here are some thoughts/questions on the implementation strategy. It generally boils down to the question: Where to put the added complexity?

1. Where to store the extra "registers" required for time integration?
   Right now, we have a dg.elements.u_rungekutta to use as extra storage for the time integration. However, this does not make much sense from a implementation "hygiene" point of view, since it is never used inside the DG solver. On the other hand, re-allocating storage in timestep! each time step is also a performance problem. One way out would be a dedicated TimeStep struct, which preserves state between time steps, but which of course also adds new complexity.
2. Where to store the information specifically required for the P-ERK scheme?
   The P-ERK scheme needs in the timestep! method the information at which refinement level each element operates. In addition, in the solver it is required to store which elements/surfaces/mortars need to be updated in which stage. In the first case we have solver-specific data that is only required outside the solver. In the second case we have solver-specific data that is also very specific for the given RK scheme, which is only required inside the solver. Thus - where to store them? Right now, both are stored in the solver.
3. Where and how to trigger the (re-)calculation of the level info?
   Right now, the level information is updated in each time step. This is clearly a waste of time, since the information only needs to be updated if the element topology changes, i.e., after each AMR step. But where and how should this be triggered? If we do it as a sort of "post AMR" step in the DG solver, it requires to mix implementations for AMR, solver, and time integration. If we do it inside timestep!, we somehow need to detect if there was an AMR change, which can only be reliably tracked by storing the last time (= time step number) AMR was performed that resulted in a change. But this of course also adds more complexity.

With help of my student research assistant Warisa we now aim to bring in the P-ERK schemes from the quick & dirty implementation in https://github.com/trixi-framework/paper-2024-amr-paired-rk into Trixi.

My preliminary schedule looks like this:

• Single 2nd order P-ERK Perk p2 single ext #1908
• Single 3rd order P-ERK
• CFL computation from optimal timestep
• Document P-ERK as optimized schemes
• Partitioned RHS
  • 1D
  • 2D
  • 3D
• Multi 2nd order P-ERK
• Multi 3rd order P-ERK
• PERK AMR Callback
  • TreeMesh
  • P4estMesh
• Document Multirate Time Integration with P-ERK
• Single 4th order P-ERK
• Multi 4th order P-ERK
  • StructuredMesh
  • TreeMesh
  • P4estMesh
• Document 4th order