I ran into a minor hiccup when dealing with the field detection routines. The field detector passes in a dummy dataset to automagically determine the derived field dependencies. In the case of ARTIO code_time, however, it passes in 1.0, which is an undefined value (time is defined from (-Inf, 0]).
I've solved it with a small hack, but I'm sure there's a cleaner way of accomplishing this:
def _creation_time(field,data):
if isinstance(data,FieldDetector):
return data["BIRTH_TIME"]
return YTArray(data.ds._handle.tphys_from_tcode_array(data["BIRTH_TIME"]),"yr")
I suppose an alternative is to throw an exception if any tcode values are out of range, but I'm not sure the field detection routines will handle that properly.
Douglas Rudd
Scientific Computing Consultant
Research Computing Center
drudd@uchicago.edumailto:drudd@uchicago.edu
On Aug 10, 2014, at 1:18 PM, Nathan Goldbaum mailto:nathan12343@gmail.com> wrote:
On Sun, Aug 10, 2014 at 11:08 AM, Douglas Harvey Rudd mailto:drudd@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@uchicago.edumailto:drudd@uchicago.edu
On Aug 8, 2014, at 6:50 PM, Nathan Goldbaum mailto:nathan12343@gmail.com> wrote:
On Fri, Aug 8, 2014 at 4:44 PM, Douglas Harvey Rudd mailto: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.edumailto:drudd@uchicago.edu
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.orgmailto:yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.orgmailto:yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.orgmailto:yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
_______________________________________________
yt-dev mailing list
yt-dev@lists.spacepope.orgmailto:yt-dev@lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
