New slicing backend (nearest neighbors interpolation) for use with moving mesh

[yuyttenhove]

I implemented a new slicing backend (similar to how there are multiple backend for the projection) which uses nearest neighbor interpolation of the quantities as this is more suitable for moving mesh hydrodynamics.

All tests pass and I modified the relevant ones to also test the new backend. All features of the original slicing method (now still the default and dubbed "sph") should be supported by the new "nearest_neighbors" backend. No default behaviour has changed, so this should be fully backwards compatible.

I also added a few sentences to the documentation.

Do you think this is suitable for including in swiftsimIO? Do you have any remarks/wishes?

[yuyttenhove]

As a simple comparison of the 2 backends:

"sph"	"nearest_neighbors"

[JBorrow]

Amazing! Love it. Thank you for this contribution; we should definitely include this. Thank you also for so carefully working within the existing framework.

[yuyttenhove]

Thanks for the comments! I resolved most of them and left some questions.

[yuyttenhove]

That should be it then, I think?

[JBorrow]

Looks good. We will need to release a new version (v8.0.0) as this contains api breaking changes.

[yuyttenhove]

I just pushed another commit in which I adjusted the spelling of "neighbors" to "neighbours" (like it was already used in generate_smoothing_lengths)

[yuyttenhove]

It turns out np.cbrt is actually not supported by unyt_arrays (and hence cosmo_arrays). I opened a pull request to add support for it in unyt and changed the get_hsml implementation in the meantime.

[JBorrow]

Code needs to be formatted.

[JBorrow]

Not required for this PR, but you could imagine actually not even needing a tree for this. For densely populated areas, you can just find the particle nearest to the pixel center by looping through all the particles, and for the sparsely populated areas a flood fill after that first procedure would work...

[yuyttenhove]

Not required for this PR, but you could imagine actually not even needing a tree for this. For densely populated areas, you can just find the particle nearest to the pixel center by looping through all the particles, and for the sparsely populated areas a flood fill after that first procedure would work...

Yeah, I did consider that actually, as it will probably be faster, but ended up using the tree method, since I already used it outside swiftwimio and hence was very easy to implement. Something to keep in mind for later probably though.

[JBorrow]

Thank you so much for this contribution!