ENH: avoid particle_index type cast

[chrishavlin]

This is a possible fix for #4995 which would affect all the particle frontends that don't override _read_particle_selection.

[chrishavlin]

Converting to draft because this needs some more thorough testing: namely, does this introduce any bugs in cython operations that are expecting float arrays? Only tried it out with a projection and it works (because the int field gets converted to float before the projection), but need to check other functionality.

[chrishavlin]

Assuming tests pass again, I think this is ready for review.

For reference, the following IO child classes override _read_particle_selection and always cast all fields to float64:

• IOHandlerGadgetFOFHaloHDF5
• IOHandlerChomboHDF5 (actual cast to float occurs in ._read_particles)
• IOHandlerOpenPMDHDF5

The one other IO frontend that overrides _read_particle_selection is IOHandlerOrion but it does not initialize dtypes of arrays or cast to float64. Every other fronted inherits the base _read_particle_selection so would be affected by this PR. Based on my quick read, it'd be easy enough to enable the behavior of this PR in the 3 frontends above and I can do that here after initial review or in a followup PR or I can just open an issue for future reference.

[chrishavlin]

oh, I suppose I should update the docs to mention this behavior, but I'll wait for review before doing that in case the functionality changes.

[neutrinoceros]

As I said somewhere else I'm currently unable to compile yt so I cannot review this properly at the moment. I hope someone else can step in.

[chrishavlin]

note to reviewers: this change is necessary because unit conversions on unyt arrays of int dtype always cast the result to float64. e.g., unyt.unyt_array([1, 2], "1", dtype='int').to("1") yields an array of type float64. So only converting if the units differ allow the int fields to persist through the data read.

[matthewturk]

This seems good to me as a first pass.

I want to note one other possible place we may want to update things. I think it might be too much work, but could be simplified with a broader particle type accessing refactor. (i.e., making it easier to figure out what type to make new fields, etc.)

I can see use cases for making the smoothing and deposition operations utilize integers. Specifically, if one wanted to deposit the nearest particle's index, that would be a use case we could support. But, it's not necessary for this.

I would also like to suggest that we avoid (for now) allowing 32bit floats and ints, which you've also avoided here.

[matthewturk]

One thing that came to mind, in addition -- using fused types we can make it somewhat easier to address issues in the cython code, but we could also utilize JIT's for fun in the distant future.

[chrishavlin]

I can see use cases for making the smoothing and deposition operations utilize integers. Specifically, if one wanted to deposit the nearest particle's index, that would be a use case we could support. But, it's not necessary for this.

I agree! and I think this PR opens up the possibility of doing just that.

I would also like to suggest that we avoid (for now) allowing 32bit floats and ints, which you've also avoided here.

agreed! I'll add a comment to the new _particle_dtypes attribute to reinforce that in case any frontends in the future end up overwriting the attribute.

[chrishavlin]

pre-commit.ci autofix