Interp irregulars fix

[alhom]

Well, here's a draft of using radial basis functions for interpolation over irregular regions (or wherever!). There are some hitches: calling point-wise irregular interpolation doesn't exactly match the vectorized version. Still better than then previous interpolators.

This introduces a new function for interpolation on the AMR grid: read_interpolated_variable_irregular

If called with a list of coordinates, the old read_interpolated_variable will check if those coordinates lie at the refinement boundaries and uses the irregular variant at those points. Pointwise the function works as before (ie. badly at the ref boundaries).

Feel free to pick apart/up!

[alhom]

For some notes, an interpolated curve. Regular goes bonkers, RBF-singular (so, pointwise) does a weird wiggle still, but wholly-RBF (RBF batch+) does well, while the one using trilinear at regular grid and RBF at the intersection (batch+) has small discontinuities.

Not a fan of getting (slightly) diverging results, but barring a proper dual-mesh setup (with plenty of things to implement) I guess something like this is the way to go.

[markusbattarbee]

So can this enfore interpolation using RBF batch+, any downsides to it?

[alhom]

So can this enfore interpolation using RBF batch+, any downsides to it?

We can, but there's still an issue of fixing the neighborhood search to always get the same result - the RBF-singular should be equal to RBF batch+, but it is getting some of the neighbour selection issues like in the old method. Batch-interpolation gets a fuller neighborhood, still..

[alhom]

Trilinear interpolation in a general manner - least wrong yet!

[alhom]

Similar test in 2D with the trilinear interp on dual cells. I like this, and the interpolant's behaviour doesn't really have free parameters (unlike RBF). Would this be good enough for SpatialGrid->fsgrid to replace filtering?

[alhom]

Dual mesh handling for neighbors for RBF smooths out the large discontinuities, but introduces more small-scale jumps. Increased the number of neighbors used as well for this plot, but that would be quite slow. Also, for this sort of an interpolation, the dual-trilinear is fast enough as-is.

[alhom]

This could use now some fresh eyes on how to refactor this into a neater package, and I think the dual-mesh interpolator is good-enough to enable as a default as-is. At least it'd finally enable passable interpolation for AMR meshes.

[alhom]

A well-defined test here, as well: compare r^2 stored in vlsv file and interpolated versus r^2 for each coordinate.