Provide interpolation function `f(x, y)` for user-driven postprocessing of results

[sloede]

@torrilhon pointed out that it would be nice for us to provide some sort of universal interpolation function that accepts a coordinate tuple and returns the solution state at that point, e.g., f(x, y) or f(x, y, z). This would allow users to do their own postprocessing of the results in an interactive way, i.e., create plots over line, do surface plots or contour plots etc. Based on his own experience, he suggested to use triangulation for this purpose, i.e., internally store the solution on triangles for fast interpolation.

[ranocha]

This is basically https://github.com/trixi-framework/Trixi.jl/issues/199.

to use triangulation for this purpose, i.e., internally store the solution on triangles for fast interpolation.

That's something we need to discuss. Since we can interpret DG methods as using polynomial approximations, it can appear doubtful to not use the values of these polynomials.

[gregorgassner]

This is a very difficult issue to get right for general setups as postprocessing in my opinion. Just think about an AMR grid for instance, or also in a curvilinear grid.

What might be an option is to have something like a record point (or a colloction of points) that you can specify in the beginning of the simulation, that then records the solution...this not so easy to do.

As always for such a feature, I would say that we need a particular use case to start, where it is justified to invest resources.

[torrilhon]

This is a combination of two issues, I had in mind. Ultimately, both issues are about actual usability of the simulation result (beyond convergence and parallel scaling, sorry :-))
(1) provide a f(x,y) evaluation for the solution Julia-internally. (2) write out the result in a (more) simple and versatile format for external processing. About (1): As a starting point it would make sense to provide such a function purely based on the DG result, that is, evaluate the polynomial in the respective cell at (x,y). For the time being this might be enough. Let's see what can be done with it. About (2): For post-processing many normal users (like me) have their own ideas, would prefer to do this outside Julia, and work with a continuous representation of the solution. I am aware of the subtleties of high order DG results, but I would not care at this point. It is relatively easy to triangulate the AMR grid and provide the solution at the vertices (simple/fast: averaging the results for the adjacent cells, fancy/slow: L2-project the neighborhood). This ignores many high order features, but actually still encodes significant high order polynomial information. The result (triangular connectivity + vertex solution values) is arguably the most widely used format for unstructured grid-data and would offer a zero threshold to use any Trixi-result right away. I actually tried this for a Trixi advection solution, see attached, and I am happy to discuss my approach.