On Sun, Jul 13, 2014 at 12:59 AM, Kacper Kowalik
On 12.07.2014 23:46, John ZuHone wrote:
Hi Kacper,
I'm not sure I understand. Currently fields *are* stored in arbitrary units. That's why "field_to_cgs" was necessary to make yt use them in a consistent fashion.
As it stood, the GDF frontend in 3.0 was not doing anything with the units. It was returning everything as dimensionless. Also, the field units were being stored in LaTeX, so I don't know if it was able to read them.
It certainly wasn't. I was merely suggesting an extension to the existing format. I think YTArray is able to spit out nice LaTeX representation of its units (maybe Nathan will correct me here), so current function of "field_units" is redundant.
For some YTArray named arr: arr.units.latex_representation()
However, now I think that with YTArray around we can go one step further and just directly feed constructor with `field_units`. "dataset_units" would be then unnecessary and each field could have separate unit system e.g. density in cm^-3, velocity in km/s etc. "field_to_cgs" could stay for backwards compatibility sake.
Sounds good to me, but see below about "dataset_units."
This would require some additional work with things that are not pure data and also have units, like box size, current time etc. Possibly we'd need a way to define units in GDF file for all those people still using "dinosaurs" or "leagues"
But this is exactly what "dataset_units" is for, not for the fields
themselves but for those parameters. That way we can set the attributes that hang off the dataset directly, e.g., ds.length_unit.
OK, that makes sense. Cheers, Kacper
John _______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org