Spurious lines at CPU boundaries

[cphyc]

Bug report

Bug summary

Spurious results for RAMSES particle projection plots at CPU boundaries. The dataset for the simulation is quite large, so I didn't find anywhere to upload it (2.4GiB). If you have any suggestion, tell me.

Code for reproduction

import yt
def _tracer(pfilter, data):
    return data[(pfilter.filtered_type, "particle_family")] == 100
yt.add_particle_filter("tracer", _tracer, requires=['particle_family'],
                               filtered_type='all')
ds = yt.load('output_00016/info_00016.txt', extra_particle_fields=[('particle_metallicity', 'd'), ('particle_age', 'd'), ('particle_family', 'i')])
ds.add_particle_filter("tracer")
p = yt.ProjectionPlot(ds, 'z', 'tracer_cic')
p.save()

import matplotlib.pyplot as plt
x, y, z = ds.r['particle_position'].T
plt.hist2d(x, y, bins=256)
plt.savefig('projection.png')

One thing that may be the reason is that the particles in this output are exactly located at leaf cell centers

Actual outcome

Expected outcome

As you can see

Version Information

• Operating System: Arch Linux x64
• Python Version: 3.6.2 (conda)
• yt version: 3.5.dev0
• Other Libraries (if applicable): Installed via git.

[ngoldbaum]

You can upload it using the yt curldrop, see docs.hub.yt.

[cphyc]

I've found another dataset 10x smaller, I'm uploading it.

[cphyc]

Here's a not working dataset http://use.yt/upload/5481f7cb.

[ngoldbaum]

Are there still lines if you use NGP rather than CIC deposition? I know for grid data (see #917) yt can introduce artifacts at grid and level boundaries because the deposition is done in a manner fully local to each grid. Worse, the deposition operation can't be nonlocal due to #918. I'm not sure offhand how CIC is implemented for octree data, so this warning might be off-base.

[cphyc]

It looks like depositing using all_count, all_mass and all_density gives the same issue. I don't have the option for NGP deposition field though.

[cphyc]

Btw, what do you mean by "fully local to each grid"?

[ngoldbaum]

Unfortunately I'm not able to reproduce this using the script in the description and the dataset that got uploaded. I'm moving this to the 4.0 milestone so it doesn't delay the release of 3.5, but I'm happy to look at this closer if we can get a script/dataset combo that triggers this issue.