Thanks Nathan!

The simplest thing to do is force a conversion to seconds when reading the data in, so the mapping to any other unit is always linear (and there's effectively no artio code_time).  The downside to this approach is it's not possible to obtain the on-disk values, which could be of some practical use.  I suppose I could list BIRTH_TIME as being dimensionless, to prevent yt from naively converting from code_time and producing incorrect results.  Thoughts?

Douglas Rudd
Scientific Computing Consultant
Research Computing Center



On Aug 8, 2014, at 6:50 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote:




On Fri, Aug 8, 2014 at 4:44 PM, Douglas Harvey Rudd <drudd@uchicago.edu> wrote:
Hi all,

I've been asked by someone who is using yt to analyze ARTIO data (yes! they exist!).  They're interested in the distribution of star particle creation times (BIRTH_TIME in the internal code nomenclature).  There is code to do a conversion to age that seems to have been borrowed from the ART frontend, but it's incomplete and incorrect for z > 0, so I'm porting over the c code that we use internally in ART(IO).  That's all fine and good, but there's still a residual issue with code_units that I don't quite understand and hoping someone can quickly point me in the right direction.

ARTIO defines an attribute time_unit, which is stored in the ARTIO fileset and is the correct code_time -> seconds unit conversion **at the redshift of the snapshot**.  The mapping from code time to physical time is non-linear, however, so a code unit defined at a different redshift cannot be simply converted to physical time in cgs using this number (which looks like what happens now).

Is there an easy way to override code_unit -> cgs (and other) unit mappings when it's a non-linear function?  I can obviously create pre-converted versions of these fields (creation_time and particle_age both defined in seconds), but that doesn't prevent someone from loading ("STAR","BIRTH_TIME") and asking yt to convert it from code units to cgs, and getting the wrong answer:


Not right now, no.  There is only one conversion for time units - whatever is associated with that dataset.

Said another way, all elements of a YTArray must have identical units and conversion factors since all elements of the array share the same unit metadata. We haven't had to deal with different elements of the same dataset having different units yet.

You could add this nonlinear conversion factor either to the i/o routine, so it is corrected inline as you read this data in, or override the creation_time field.  I'm not sure which approach makes the most sense for your application.
 
i.e.
yt.load("artio dataset").all_data()[("STAR","BIRTH_TIME")].in_cgs()
gives nonsensical values.


Douglas Rudd
Scientific Computing Consultant
Research Computing Center
drudd@uchicago.edu



_______________________________________________
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