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 https://bitbucket.org/yt_analysis/yt/src/b8a09cd382dd34f386ce3634e7f78df3f5d9401d/yt/analysis_modules/halo_analysis/halo_catalog.py?at=yt&fileviewer=file-view-default#halo_catalog.py-453 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/b8a09cd382dd34f386ce3634e7f78df3f5d9401d/yt/frontends/halo_catalog/data_structures.py?at=yt&fileviewer=file-view-default#data_structures.py-78 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/b8a09cd382dd34f386ce3634e7f78df3f5d9401d/yt/frontends/halo_catalog/fields.py?at=yt&fileviewer=file-view-default#fields.py-21 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