j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
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.
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.