Update gamer frontend in yt to support integer particle attributes

[hyschive]

Tasks

• Add integer attribute of particle #348 introduces support for integer particle attributes. However, these attributes are still interpreted as floating-point data after being loaded into yt, which could cause issues, such as tracking particles by their IDs.

Questions

• Does yt (or the unyt package it uses for handling units) support integer data types? I tested the particle_type field in the art code using the D9p_500 dataset available here. According to the code reference, this field should be int64, but it is still recognized as float64.

Here’s an example code snippet demonstrating the issue:

% load the `D9p_500 dataset` by `yt load 10MpcBox_HartGal_csf_a0.500.d` first
In [1]: dd = ds.all_data()
In [2]: dd[("all", "particle_type")][0].dtype
Out[2]: dtype('float64')

[ChunYen-Chen]

Related issue: yt-project/yt#4995
Related PR: yt-project/yt#4996

My question on yt Slack:

Hi, I am trying to access the integer field of the dataset, but the result is unexpected.

I did a simple test of the integer field using the D9p_500 dataset from this link. According to the source code here, the particle_type field should be an integer type int64. However, it recognized as float64.
How do I access the integer field correctly?
Thank you in advance for your help!

Simple script:

import yt

filename = "./D9p_500/10MpcBox_HartGal_csf_a0.500.d"
ds = yt.load( filename )
ptype = ds.r["specie0", "particle_type"]
print(ptype)
print(ptype[0].dtype)

Results:

[0. 0. 0. ... 0. 0. 0.] dimensionless
float64

Expected:

[0 0 0 ... 0 0 0] dimensionless
int64

From Corentin:

For technical reasons, all fields are cast to float64 internally. You should be able to cast back to int64 by just doing ptypt.astype(np.int64)

From Chris:

i did do some initial work on preserving the int type for the particle index (yt-project/yt#4996). That PR needs a refresh and a bit more testing... but I suspect it should be possible to handle the particle_type in a similar way (whether or not its possible in a simple way depends on whether the fields are ever passed down to cython routines that are typed for float fields).
And just a bit more info: Chun-Yen Chen even though the code you link does maintain the int64 dtype initially, that array will end up stored in a unyt array in such a way that converts it to float64. So ya, right now you have to convert back to int64 like Corentin says.

[hyschive]

I prefer preserving integer types throughout (i.e., avoiding conversion to floating-point types at any stage) to prevent potential rounding errors.

[hyschive]

Here is the thread that @ChunYen-Chen posted on yt Slack.

[jzuhone]

I'm going to see how we can get yt-project/yt#4996 through to help address this.