[yt-dev] Data selection issue in yt 3.0

[Casey W. Stark]

Hey Matt, Nathan.

So I agree with Matt's fix of field before axis. I'm no authority on this,
so others should speak up too if that seems strange. To me, the field has
more priority than the direction, but this is probably cosmology biased!

- Casey


On Tue, Nov 27, 2012 at 10:13 AM, Matthew Turk <matthewturk at gmail.com>wrote:

> Casey, what do you think?  How should we set up slices, projections to
> be ordered in their arguments?
>
> On Tue, Nov 27, 2012 at 12:53 PM, Nathan Goldbaum <nathan12343 at gmail.com>
> wrote:
> > Thanks for fixing it Matt!  I'm glad it was simple.
> >
> > With regards to the projection arguments, we've now sort of reversed the
> problem - PlotWindow plots get created like projections used to.
> >
> > -Nathan
> >
> > On Nov 27, 2012, at 2:39 AM, Matthew Turk wrote:
> >
> >> Hi Nathan,
> >>
> >> On Mon, Nov 26, 2012 at 10:53 PM, Nathan Goldbaum <goldbaum at ucolick.org>
> wrote:
> >>> Hi all (specifically Matt, I suspect),
> >>>
> >>> I'm running into an odd issue in yt 3.0.  I'm using the following
> script:
> >>> http://paste.yt-project.org/show/2905/.  This refers to a
> non-axissymmetric
> >>> dataset I generated with enzo:
> >>> http://ucolick.org/~goldbaum/files/DD0000.tgz.
> >>>
> >>> The issue is that when I run this script with yt-3.0, I only get back
> the
> >>> 'z' projection, even in the cases where I ask it for the 'x' and 'y'
> >>> projection.
> >>
> >> Yup, it was a typo.  I've fixed it here:
> >>
> >>
> https://bitbucket.org/yt_analysis/yt-3.0/changeset/df11c944851c229698721513fb2bb2f4b6fb61db
> >>
> >> Thanks for catching this!  It also reminds me that in the Chunking
> >> YTEP I should mention the fcoords, icoords and fwidth properties of
> >> chunks.
> >>
> >>>
> >>> Since the signature of __init__ for the projection object is slightly
> >>> different in 3.0, you'll need to manually choose the line in the
> script that
> >>> creates the projection object depending on which version of yt you're
> >>> running.  As a side note, is there a reason for this change in the API?
> >>
> >> The reason was based on outstanding issues in the way that projections
> >> were different from everything else.  Here's the ticket, filed about a
> >> year and a half ago, where this got talked about:
> >>
> >>
> https://bitbucket.org/yt_analysis/yt/issue/292/consistent-projection-arg-order
> >>
> >> At this time I'm no longer certain that changing is the right thing,
> >> since I believe part of the original motivation was for plot
> >> collections to match the projection API.
> >>
> >> Thanks for catching the bug; while we do run tests on yt 3.0, it seems
> >> this slipped through.
> >>
> >> -Matt
> >>
> >>>
> >>> Nathan Goldbaum
> >>> Graduate Student
> >>> Astronomy & Astrophysics, UCSC
> >>> goldbaum at ucolick.org
> >>> http://www.ucolick.org/~goldbaum
> >>>
> >>> _______________________________________________
> >>> 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
> _______________________________________________
> 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/20121127/8630474e/attachment.html>