yt-project / yt

Main yt repository
http://yt-project.org
Other
468 stars 278 forks source link

Nearest neighbor pixelizer in demeshening #1808

Open matthewturk opened 6 years ago

matthewturk commented 6 years ago

This issue is a holding area for discussion (instead of in #1807 ) about making a nearest-neighbor interpolator for data that would benefit from it -- for instance, this may be applicable to Arepo or other voronoi tesselation data.

It seems likely to me that this could be done using a modified version of the kdtree that currently pixelizes for SPH in demeshening; we would simply want to only use the very nearest particle. There may be more efficient ways to do this, but this would suitably work as a stopgap.

(For an even simpler algorithm -- if we had an upper bound for the distance between particles, we could potentially implement a deposition that tracks distance and iterated on the outer side over particles and deposited them as long as their distance to a pixel was lower than the distance being tracked. Probably not the best idea, though.)

jzuhone commented 6 years ago

@ngoldbaum @MatthewTurk here (for example) is a slice through one of our Gadget-based datasets where the smoothing length is present in the data:

https://gist.github.com/18f7919bf6e9a5177e24981230c91b08

Is there a way we can improve this or is this just a fundamental limitation given the method and the particle resolution?

ngoldbaum commented 6 years ago

It seems likely to me that this could be done using a modified version of the kdtree that currently pixelizes for SPH in demeshening

The KDTree isn't used at all for pixelizing slices right now. See:

https://github.com/yt-project/yt/blob/5fc949e84d50ba082c81e5946414c8b980ec83df/yt/geometry/coordinates/cartesian_coordinates.py#L329-L341

And:

https://github.com/yt-project/yt/blob/yt-4.0/yt/utilities/lib/pixelization_routines.pyx#L1048

The KDTree is only used right now to generate smoothing lengths for data that doesn't have them available on-disk.

ngoldbaum commented 6 years ago

improve this

What's wrong with the current visualization? They look fine to me under the assumption that we're dealing with SPH data.

In principle we could produce nicer visualizations using "gather" smoothing instead of "scatter" smoothing like we use right now. Ashley Kelley is planning on implementing "gather" smoothing this summer.

AshKelly commented 6 years ago

As Nathan said, I'm currently adding "gather" smoothing which you can see here #1828. If you want me to work on something like this then let me know. It will likely re-use some of the new code I'm writing.