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. 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? Nathan Goldbaum Graduate Student Astronomy & Astrophysics, UCSC goldbaum@ucolick.org http://www.ucolick.org/~goldbaum
Hi Nathan, On Mon, Nov 26, 2012 at 10:53 PM, Nathan Goldbaum <goldbaum@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/df11c944851c229698721513f... 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-ord... 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@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@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/df11c944851c229698721513f...
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-ord...
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@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
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@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@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/df11c944851c229698721513f...
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-ord...
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@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
_______________________________________________ yt-dev mailing list yt-dev@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
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@gmail.com>wrote:
Casey, what do you think? How should we set up slices, projections to be ordered in their arguments?
Thanks for fixing it Matt! I'm glad it was simple.
With regards to the projection arguments, we've now sort of reversed the
On Tue, Nov 27, 2012 at 12:53 PM, Nathan Goldbaum <nathan12343@gmail.com> wrote: 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@ucolick.org>
Hi all (specifically Matt, I suspect),
I'm running into an odd issue in yt 3.0. I'm using the following
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
'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/df11c944851c229698721513f...
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
wrote: script: 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-ord...
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@ucolick.org http://www.ucolick.org/~goldbaum
_______________________________________________ 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
_______________________________________________ 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
participants (4)
-
Casey W. Stark -
Matthew Turk -
Nathan Goldbaum -
Nathan Goldbaum