On 12.07.2014 23:46, John ZuHone wrote:It certainly wasn't. I was merely suggesting an extension to the
> 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.
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.
OK, that makes sense.
>> 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.
> yt-dev mailing list
yt-dev mailing list