[yt-dev] ARTIO time mapping

[Nathan Goldbaum]

On Sun, Aug 10, 2014 at 11:08 AM, Douglas Harvey Rudd <drudd at uchicago.edu>
wrote:

>  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?
>

Mandating dimensionless units for that field is probably the simplest thing
to do that won't subtly produce incorrect results.

The yt "universal field" is creation_time, so you could override that field
definition in the artio frontend and make the mapping from "dimensionless"
BIRTH_TIME to creation_time in seconds there. You may want to add a note to
the place where you do this explaining why you had to do it this way.



>
>    Douglas Rudd
> Scientific Computing Consultant
> Research Computing Center
>  drudd at uchicago.edu
>
>
>
>  On Aug 8, 2014, at 6:50 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
>
>
>
>
> On Fri, Aug 8, 2014 at 4:44 PM, Douglas Harvey Rudd <drudd at 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 at uchicago.edu
>>
>>
>>
>> _______________________________________________
>> yt-dev mailing list
>> yt-dev at lists.spacepope.org
>> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>
>  _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
>
> _______________________________________________
> yt-dev mailing list
> yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/attachments/20140810/07c33701/attachment.html>