Hi all,

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

>>> halo.quantities['particle_position_x']
0.495074982741 cm
>>> halo.quantities['particle_position_x'].in_units('code_length')
0.495074982741 code_length
>>> halo.quantities['particle_position_x'].in_units('cm')
0.495074982741 cm
>>> ds.unit_registry['code_length']
(9.195880139956267e+25, (length))
>>> halos_ds.unit_registry['code_length']
(1.0, (length))

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 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 for the HaloCatalog is created. The length unit is set in cm -- the catalog is assumed to be in cgs.

The HaloCatalog fields 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?

Thanks,

Rasmi