Re: [yt-dev] [Bug] Halo Catalog units

Hi all,

Greg and I found a bug involving halo catalog unit handling:

The halos_ds mixes up cm and code_length units when the HaloCatalog object is created from a saved halo catalog. The halo catalog values are saved in code_length, but the HaloCatalog object assumes they are in cm.

Here https://bitbucket.org/yt_analysis/yt/src/b8a09cd382dd34f386ce3634e7f78df3f5d... is where the code_length units are written out after halo-finding is done (this is confirmed with an h5ls). Here is where the halos_ds https://bitbucket.org/yt_analysis/yt/src/b8a09cd382dd34f386ce3634e7f78df3f5d... for the HaloCatalog is created. The length unit is set in cm -- the catalog is assumed to be in cgs. The HaloCatalog fields https://bitbucket.org/yt_analysis/yt/src/b8a09cd382dd34f386ce3634e7f78df3f5d... also assume cgs.

In theory, the HaloCatalog could just parse the code_length units of the halos_ds, but this isn't necessarily known at the time of creation, so the ideal fix may be to save the halo catalog length units in cm instead of in code_length. Then the assumptions that are made about length being in cm when creating a HaloCatalog object from a halo catalog would be correct. Any thoughts on this approach or other approaches?

It would probably be better just to save the unit registry into the hdf5 file. You might find the UnitRegistry.to_json() and UnitRegistry.from_json() to be useful here - the json data could be saved in the HDF5 output file as a string dataset.

Thanks,

Rasmi

yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org