[yt-dev] [Bug] Halo Catalog units

Rasmi Elasmar re2300 at columbia.edu
Wed Jun 1 09:40:59 PDT 2016


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20160601/acc5d0ed/attachment.htm>


More information about the yt-dev mailing list