[WIP] add depth-limiting to off-axis sph particle projections

[chrishavlin]

Closes #4711

The initial push does indeed work for sph particle projections, but I intend to refactor...

that said,

import yt  
import numpy as np

ds = yt.load_sample("gizmo_64")  

z_hat_original = ds.arr([0.3, 0.3, 0.3], 'kpc')
y_hat_original = ds.arr([1., 0., 0.], 'kpc')

for d in [2, 20]: 
    prj = yt.ProjectionPlot(ds, - z_hat_original, 
                                       center = ds.domain_center, 
                                       fields=('gas', 'density'),                   
                                       depth = (d, 'Mpc'), 
                                       north_vector = - y_hat_original, 
                                       )
    prj.save(f"depth_{str(d).zfill(2)}_proj.png")

returns

and

which seems to make sense (first image is 2 Mpc depth, second is 20 Mpc depth).

Still to do:

• consider default behavior... i'm expecting answer tests to fail because the default depth in OffAxisProjectionPlot is (1, '1') instead of None, so it may drop some particles, changing what the plots with default values look like? UPDATE: didn't actually break tests, but that may be a function of test coverage and there could be a change in behavior introduced here?
• make sure I'm not introducing confusing or diverging behavior between the particle and non-particle projections (which both use the same OffAxisProjectionDummyDataSource). I think it's fine, but want to double check... UPDATE: I think I'm coming back around on this ... now thinking that it'd be better to simply always apply the depth limitation, following how the off axis projection for gridded data works. Will marinate on this for a bit ....
• refactor: in the initial push I created new versions of the pixelation routines based on the existing pixelize_sph_kernel_projection and rotate_particle_coord and introduced a ton of code duplication in the process. I mainly wanted to avoid creating extra arrays for the rotated z coordinates and running extra checks on z bounds in the case where it's not limiting by z, so started off by simply creating separate functions... but will go back and refactor this now that I have it nominally working.
• add tests
• add note in docs

[matthewturk]

I like this. Thank you! I've left some comments.

[matthewturk]

I think you got this code from elsewhere, but I will say that it definitely confused me. I at first thought this was a string, but now I see it's either a numpy array or none. Yowza!

[chrishavlin]

indeed! copied directly from pixelize_sph_kernel_projection. Up in the python somewhere there's a weight that is a string, so definitely confusing. Could rename this variable to weight_array (and also rename in pixelize_sph_kernel_projection).

[matthewturk]

I have a sneaking suspicion it's to avoid a race condition, but I think a long time ago we were supposed to be able to declare variables inside a parallel block to get them to be thread-local. No changes needed.

[chrishavlin]

helpful context! I was confused by why this was needed.

[matthewturk]

does this also need to happen inside the parallel context?

[chrishavlin]

hard to tell with the github interface, but these lines are all within the

with nogil, parallel():

block way up top.

[matthewturk]

So I think this function looks right. What I'm wondering is if it needs to be in Cython as-is. I think it could potentially take advantage of being in cython by consolidating the matmul stuff with the copying of coordinates -- i.e., iterating over the particles one-by-one and avoiding temporary arrays. I'm not 100% sure that it's necessary, but it could potentially eliminate some allocations.

[chrishavlin]

ya, I agree -- it could be written with just numpy matrix operations at the python level or rewritten with a different loop control.

Also, could actually cut out an entire loop over the particles by calculating the rotated particle positions as needed within pixelize_sph_kernel_projection_with_depth_check (and pixelize_sph_kernel_projection)?

[matthewturk]

We shouldn't fix this here, but is this a case where something like a named tuple or simple data class could simplify our code?

[chrishavlin]

yes, I do think that would help. it might be worth fixing here too :) I think it could cut down on some of the code duplication I'm introducing.