Parabolic AMR: Open discussions

[DanielDoehring]

To summarize the discussions in #1629 I list some open points:

• Outer datastructures for non-internal variables in ViscousContainers:
  

  Trixi.jl/src/solvers/dgsem_tree/container_viscous_2d.jl

  Lines 3 to 15 in 4744105

  	# Using an outer fixed-size datastructure leads to nasty implementations,
  	# see https://github.com/trixi-framework/Trixi.jl/pull/1629#discussion_r1355293953.
  	# Also: This does not result in speed up compared to using tuples for the internal
  	# datastructures, see
  	# https://github.com/trixi-framework/Trixi.jl/pull/1629#discussion_r1363352188.
  	gradients::Vector{Array{uEltype, 4}}
  	flux_viscous::Vector{Array{uEltype, 4}}
  	# internal `resize!`able storage
  	_u_transformed::Vector{uEltype}
  	# Use Tuple for outer, fixed-size datastructure
  	_gradients::Tuple{Vector{uEltype}, Vector{uEltype}}
  	_flux_viscous::Tuple{Vector{uEltype}, Vector{uEltype}}

  
  Usage of Tuple also for noninternal datastructures?

• Different reinitialize_containers! for parabolic cache (?) to avoid the if in

  Trixi.jl/src/solvers/dgsem_tree/containers.jl

  Lines 31 to 35 in 4744105

  	if hasproperty(cache, :mortars) # cache_parabolic does not carry mortars
  	@unpack mortars = cache
  	resize!(mortars, count_required_mortars(mesh, leaf_cell_ids))
  	init_mortars!(mortars, elements, mesh)
  	end

• Alternative to specialization via flux_viscous?

  Trixi.jl/src/solvers/dgsem_tree/dg_2d_parabolic.jl

  Lines 518 to 523 in dc0dc1d

  	# `cache` is the hyperbolic cache, i.e., in particular not `cache_parabolic`.
  	# This is because mortar handling is done in the (hyperbolic) `cache`.
  	# Specialization `flux_viscous::Vector{Array{uEltype, 4}}` needed since
  	#`prolong2mortars!` in dg_2d.jl is used for both purely hyperbolic and
  	# hyperbolic-parabolic systems.
  	function prolong2mortars!(cache, flux_viscous::Vector{Array{uEltype, 4}},

[DanielDoehring]

Corresponding PR: #1754