depth keyword in off-axis projections with sph particles has no effect? about yt HOT 4 OPEN

note: thanks to @y-samuel-lu for raising the issue on slack!

from yt.

I believe you're right. My recollection is that for on-axis projections, axis aligned bounding boxes (AABB) are used, but this was not implemented here. I think that it would be the appropriate thing to do to use the transformed z coordinates.

from yt.

Hi, I'm pretty new to YT, but I have been looking into SPH data projections for a different issue (#4788) that involves the pixelize_sph_kernel_projection function. The approach sounds reasonable enough to me. I'd suggest doing a simple cut on SPH particle positions in the z direction; the kernel interpolation table won't work for integrating through only partway through the smoothing-length-diameter sphere, and I figure this is one of those things that's good enough.

One issue I do want to point out involves periodic datasets. Now, I think we can reasonably get away with ignoring cases (or raising errors) if someone analyzing a periodic volume wants to make a slice through the whole volume that wraps back around, where the slice width is larger than the box size (e.g. ASCII sketch below).

+--------------------+
|       \.     \     |
|.       \.     \    |
|.        \.     \   |
|.   \     \         |
|.    \     \        |
+--------------------+

However, I can imagine a case where someone analyzing e.g., a cosmological volume wants to make an image of a galaxy overlapping the periodic boundary, aligned with the galaxy edge-on/face-on direction. To handle that, I'd suggest re-centering the output coordinates on zero, or half the box size, then applying any periodicity adjustments in the output arrays, before rotating them. (It would probably make the most sense to do that in the same loop as the rotation.) We can then output the rotated bounds as (0.5 * boxsize -0.5 * width, 0.5 * boxsize + 0.5* width, etc.) to match the adjusted coordinates. (This is possible in numpy using float modulo division, but I don't know how efficient that is.)

from yt.

Thanks for the suggestions! I need to look back at where my PR stalled...

One issue I do want to point out involves periodic datasets.

If I remember right, the current state does not handle periodcitiy at all for off-axis projections and particles but I may be remembering incorrectly. In any case, yes, it'd be good to properly handle periodicity.

from yt.