Notes on parabolic terms

[ranocha]

This is basically taken from #1136. Currently, our idea is to merge the DGMulti setup from that PR into dev, draft a corresponding TreeMesh & DGSEM version in another PR, and see how it looks for Navier-Stokes. When that's okay, we can go ahead and merge dev into main to finally get support for parabolic terms in Trixi.jl.

• TreeMesh version with DGSEM
  • BR1
  • LDG Add ViscousFormulationLDG support to TreeMesh #2333
  • Mortars
  • AMR for TreeMesh
  • AMR for P4estMesh
  • 1D
  • 2D
  • 3D Compressible Navier-Stokes on TreeMesh3D #1239
• P4estMesh
  • LDG
    • Interfaces LDG for interfaces P4estMesh #2689
    • Mortars
• StructuredMesh
• Navier-Stokes
  • Decide on which non-dimensional scaling to use.
• Add a parabolic solver field (or at least a way to specify parabolic numerical parameters)
  • Add parabolic penalty terms which depend on jump(u)
  • Where should penalty terms live: equations, solver, or the elixir itself? These terms will probably need to be specialized for every single equation.
• Should we have "default" BC behavior (e.g., "boundary_condition_use_inner_state / boundary_condition_do_nothing")? Answer: no. The user should be required to specify this explicitly.
• Should the viscous flux depend on orientation (i.e., compute x and y components separately)?
• Decide how general we want the BCs to be
  • What data should be made available to parabolic BCs? Solution values? Gradient values? Viscous flux values?
  • Right now, we keep it simple for now, just pass in solution values
• Docstrings
• Documentation, examples, tutorial
  • Explain Gradient/Divergence boundary conditions in docs
  • Add a Literate tutorial for compressible Navier-Stokes
• Naming things
  • grad_u (current) vs. gradients or gradients_u
  • no_boundary_condition (current) vs. boundary_condition_do_nothing or something else (what?). Answer: boundary_condition_do_nothing
  • Types for viscous methods like BR1, LDG? Current naming is ViscousFormulation*** but this gets pretty long.
• Gradient variables
  • Keep track of number of gradient variables and output which gradient variables are used from the parabolic equations constructor.
  • Address potential inefficiencies of converting back and forth the gradient variables (see also here)
  • Avoid need for defining diffusivity through global functions Initial condition for parabolic terms requires defining diffusivity as global function #1503
• Add an "enstrophy" callback as a proof of concept issue with "combined" equations. Compressible Navier-Stokes on TreeMesh3D #1239
• Add experimental notes to all exported and/or docstring'd methods/types.
• Rename elixir_navier_stokes_xxx.jl to elixir_navierstokes_xxx.jl for consistency (e.g., with elixir_shallowwater_xxx.jl).
• StepsizeCallback with viscous CFL condition
  • TreeMesh
    • 1D Viscous CFL: TreeMesh{1} #2035
    • 2D/3D Viscous CFL 2D 3D TreeMesh #2586
  • P4estMesh Diffusive CFL P4est #2696

[andrewwinters5000]

Regarding the analysis callback, when we call, e.g.,

Trixi.jl/src/callbacks_step/analysis_dg2d.jl

Line 198 in db25cc3

function analyze(::typeof(entropy_timederivative), du, u, t,

is the du here only the rhs from the hyperbolic solver or would it already contain the sum of hyperbolic and parabolic?

[ranocha]

du is set as

Trixi.jl/src/callbacks_step/analysis.jl

Line 222 in db25cc3

@notimeit timer() rhs!(du_ode, integrator.u, semi, t)

so it should be the combined RHS, I think.

[ranocha]

The analysis callback reports the hyperbolic equation as the system being used, e.g.,

 Simulation running 'CompressibleEulerEquations2D' with DGSEM(polydeg=3)

This should be specialized.