On 12.07.2014 20:48, John Zuhone wrote:
I have a work-in-progress PR in the hopper regarding GDF reading and writing:
What it does is implement direct writing of covering grids to GDF files (something I've been using in my research, to work with the resulting files directly in yt) and clobbering existing files with the same path if the user allows for it.
However, when fiddling around with this I determined that it was necessary to make GDF more unit-aware. Ultimately, I determined that changes were needed that would break the standard that we had determined for the files (http://yt-project.org/gdf.txt...).
The two main changes are:
1) Remove "field_to_cgs", and allow the fields to be in whatever units we wish them to be in the file (which are specified as HDF5 attributes).
2) Add a new top-level group containing the information for "length","mass", and "time" units. These will be used when the file is opened up in yt to determine the units.
Since (for now) we do automatic conversion to cgs, that is something that is still left unimplemented, but otherwise I think this is all to do for now.
I'm writing the email in case anyone has any suggestions or objections to the format changes--particularly Jeff or Kacper. We'll obviously need to document them if they are accepted.
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.
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.
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"