j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On 12.07.2014 23:46, John ZuHone wrote:
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.
However, now I
think that with YTArray around we can go one step further
and just directly feed constructor with
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
yt-dev mailing list email@example.com http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org