Allow preprocessing solution data based on coordinates in `SaveSolutionCallback`

[efaulhaber]

It is currently possible to pass something other than cons2prim to SaveSolutionCallback, so custom quantities can be visualized by Trixi2Vtk. However, in a custom cons2prim function, only the solution data is available and not the coordinates. It would be very convenient to allow preprocessing of the solution data with access to the coordinates directly from an elixir. This is, for example, useful when a simulation is done on the cubed sphere, and one wants to show the velocities in spherical coordinates.

[ranocha]

A working solution that would be backwards compatible could be to check DiffEqBase.numargs(solution_variables). If this is == 2, we can use the current branch https://github.com/trixi-framework/Trixi.jl/blob/50ba5ffb0dd9f8933b916c2271c7bcbc22122723/src/callbacks_step/save_solution_dg.jl#L27-L35 If DiffEqBase.numargs(solution_variables) == 3, we should also pass the node coordinates to solution_variables, e.g. solution_variables(u, x, equations) (order consistent with initial conditions etc.).

[ranocha]

Feel free to make a PR and ping me when you need this feature and want to use this approach. It's not 100% fail-safe (since numargs counts the number of arguments of the method with most arguments of the function passed to it), but it should work for us - this approach has worked in the DiffEq ecosystem for years.

[sloede]

Do I understand correctly, that this wouldn't allow us to define multiple cons2prim methods with different numbers of arguments, since numargs would always pick up 3. However, if one had a function, say cons2prim_spherical, it would be ok, since one would assume that cons2prim_spherical always has 3 arguments in all methods?

[ranocha]

Yes. If you define some method of cons2prim that takes 3 arguments, numargs(cons2prim) will return 3.

[ranocha]

Since this seems to be very much specialized on the cubed sphere mesh, it might also make sense to define such a function directly in the eleixir where it should be used. This would avoid any of these possible problems.

[efaulhaber]

Or should this be done in Trixi2Vtk? Or should it be possible in both? I could imagine running a long simulation and only realizing later that I want to visualize some custom quantity that I didn't save earlier.

[sloede]

My personal yardstick would be to leave as much of the postprocessing to the actual postprocessing phase, since that will not force us to make Trixi itself more complicated than necessary. But I haven't really thought this through for this particular case, whether it makes more sense one way or the other.

[ranocha]

Well, if it's possible (and not too complicated) to do this kind of postprocessing in a real postprocessing step, I would definitely prefer that.