Hendrik Ranocha

Ah, I forgot this PR. Yeah, it would be nice to get the ability for slicing 3D solutions, but we can move it to a new package.

Sounds good to me :+1:

We have to discuss what kind of approach to reach these times we want to use, see also https://github.com/trixi-framework/Trixi.jl/issues/769#issuecomment-899454244. The default of DiffEq is to interpolate (unless you also set...

Well, a possible problem with interpolation might be to reach unphysical states (say, negative density) when using certain methods. Thus, one might wonder what the hell is going on when...

Right now, the save solution callback is basically an indirect visualization callback (via VTK). Thus, I think we should probably unify the handling of these two.

Oh, sorry, I wasn't saying that this callback is good right now - in contrast, it only implements output based on a fixed step number frequency and shall be updated...

One thing to keep in mind: Using `saveat` means that we store the full solution state in RAM (which is feasible for appropriate scales). Thus, visualization using them is definitely...

> We have a few solvers/meshes which don't yet support AMR (DGMulti, StructuredMesh2D, UnstructuredMesh2D), so we could potentially have a visualization feature which is specific only to certain solvers. That's...

> Then, plotting a different solution at another `saveat` time would just require `plot(PlotData2D(sol.u[index], semi))`. What do you think of something like this, @ranocha? Don't we already allow something like...

> This would also work for AMR if one could extract an array of the solution at different simulation times. No, it doesn't, since we would need to also store...