Check influence of the step size controller on performance for SSPRK43 elixirs

[ranocha]

The default controller with SSPRK43() in OrdinaryDiffEq.jl is a PIController with effective parameters beta1 = 0.70, beta2 = -0.40. However, this controller is not step size control stable. We should check the difference between this standard controller and the one of Ranocha, Dalcin, Parsani, Ketcheson (2021), i.e., controller = PIDController(0.55, -0.27, 0.05).

• [x] examples/p4est_2d_dgsem/elixir_euler_double_mach_amr.jl with tspan=(0.0, 0.02)
  • PIController: Time steps: 2993 (accepted), 3074 (total), 2.99k AMR, 12.3k rhs!
  • PIDController(0.55, -0.27, 0.05): Time steps: 1904 (accepted), 1904 (total), 1.90k AMR, 7.62k rhs!
  • Visually, the solutions at the final time look very much the same (but we cannot really see something anyway)
  • 
  • 
• [x] examples/p4est_2d_dgsem/elixir_euler_forward_step_amr.jl with tspan=(0.0, 0.01)
  • PIController: Time steps: 5381 (accepted), 5495 (total), 1.08k AMR, 22.0k rhs!
  • PIDController(0.55, -0.27, 0.05): Time steps: 3612 (accepted), 3685 (total), 722 AMR, 14.7k rhs!
  • Visually, the solutions at the final time look very much the same (but we cannot really see something anyway)
  • 
  • 
• [x] examples/p4est_2d_dgsem/elixir_euler_supersonic_cylinder.jl with tspan=(0.0, 0.1)
  • PIController: Time steps: 3949 (accepted), 4009 (total), 3.95k AMR, 16.0k rhs!
  • PIDController(0.55, -0.27, 0.05): Time steps: 2408 (accepted), 2432 (total), 2.41k AMR, 9.73k rhs!
  • Visually, the solutions at the final time look very much the same
  • 
  • 
• [x] examples/tree_2d_dgsem/elixir_euler_astro_jet_amr.jl
  • PIController: Time steps: 7020 (accepted), 8809 (total)
  • PIDController(0.55, -0.27, 0.05) with dt=1.0e-12 (does not work with default settings): Time steps: 6047 (accepted), 7618 (total)
  • Visually, the solutions at the final time look very much the same
  • 
  • 
• [x] examples/tree_2d_dgsem/elixir_euler_colliding_flow_amr.jl
  • PIController: Time steps: 6815 (accepted), 7513 (total)
  • PIDController(0.55, -0.27, 0.05): Time steps: 6398 (accepted), 6510 (total)
  • Visually, the solutions at the final time look reasonably similar
  • 
  • 
• [x] examples/tree_2d_dgsem/elixir_euler_colliding_flow.jl
  • PIController: Time steps: 2341 (accepted), 2565 (total)
  • PIDController(0.55, -0.27, 0.05): Time steps: 2039 (accepted), 2053 (total)
  • Visually, the solutions at the final time look reasonably similar
  • 
  • 
• [x] examples/tree_2d_dgsem/elixir_kpp.jl
  • PIController: Time steps: 857 (accepted), 864 (total)
  • PIDController(0.55, -0.27, 0.05): Time steps: 580 (accepted), 583 (total)
  • Visually, the solutions at the final time look very much the same
  • 
  • 
• [x] examples/unstructured_2d_dgsem/elixir_euler_periodic.jl with tspan = (0.0, 100.0)
  • PIController: Time steps: 5282 (accepted), 5283 (total)
  • PIDController(0.55, -0.27, 0.05): Time steps: 5281 (accepted), 5283 (total)
  • Errors of the same order of magnitude (but different, slightly worse for the PIDConrtoller)

[andrewwinters5000]

When I try this PIDController with the supersonic cylinder test it crashes due to a very small negative value in a square root during max_abs_speed_naive at around time 3.6486. I attached the complete log file. Cylinder_pidcontroller.txt

[andrewwinters5000]

Here is a full run and comparison of the double Mach reflection test case. examples/p4est_2d_dgsem/elixir_euler_double_mach_amr.jl with tspan=(0.0, 0.2)

• PIController: Time steps: 34009 (accepted), 35786 (total), 34.0k AMR, 143k rhs!
• PIDController(0.55, -0.27, 0.05): Time steps: 16662 (accepted), 16667 (total), 16.7k AMR, 66.7k rhs!
• Zoom in of the triple point regions for both. Visually, the solutions are quite similar.

[andrewwinters5000]

supersonic cylinder test it crashes due to a very small negative value in a square root

I suspect this can be fixed by monkeying with the positivity limiter. This test case is just very sensitive

[ranocha]

Yeah, that might be true...

[ranocha]

CC @ketch (since you might be interested in this)

[ketch]

Looks like some very nice and consistent evidence in favor of the optimized controller designed by @ranocha .