Dear all, I'm trying to plot the projection of a variable defined in a rather involved way, namely through an IF statement. I can use this variable for many computations and I can plot slices of it, but somehow it does not work with projections. I attach an example script which isolates the problem. I guess it can run on any standard cosmological output of Enzo (v. 1.0; I haven't worked with Enzo 1.5 yet). As I told you, if I change the pc.add_projection(... at line 65 with pc.add_slice(... everything works well. I'm using YT 1.6, and because of problems in my machine I cannot upgrade to 1.6.1 until next week, so I don't know if this issue has been already fixed by chance. Looking forward to your suggestions, Cheers, Luigi -- --------------------------------------------------------------- Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
Hi Luigi, I've looked over your code and I can't see anything specifically wrong. Can you post the error message you're getting? That might help. As a side note, you may want to replace pf['InitialTime'] on line 35 with data.pf['InitialTime']. The pf is global within your script, but if you those field functions in other files you will get an error because the function will not know about pf. Britton On Mon, Feb 15, 2010 at 6:09 AM, Luigi Iapichino < luigi@ita.uni-heidelberg.de> wrote:
Dear all,
I'm trying to plot the projection of a variable defined in a rather involved way, namely through an IF statement. I can use this variable for many computations and I can plot slices of it, but somehow it does not work with projections. I attach an example script which isolates the problem. I guess it can run on any standard cosmological output of Enzo (v. 1.0; I haven't worked with Enzo 1.5 yet). As I told you, if I change the pc.add_projection(... at line 65 with pc.add_slice(... everything works well. I'm using YT 1.6, and because of problems in my machine I cannot upgrade to 1.6.1 until next week, so I don't know if this issue has been already fixed by chance. Looking forward to your suggestions, Cheers,
Luigi
--
---------------------------------------------------------------
Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Luigi, First off, thank you very much for providing a script that isolates the problem! It made it much easier for me to dig in and replicate the issue. First I'd like to echo what Britton said about accessing the pf -- it's guaranteed to be defined as data.pf, but it's not guaranteed to be in the namespace otherwise. Additionally, I'd like to just note that "x-velocity" gets returned after having been converted via the Enzo units in the parameter file (you can see what these are by looking at pf["x-velocity"]) so you might be applying apples to oranges. I found two solutions to the issue. One is to apply a validator: add_field("EddyTurnover", function=EddyTurnover, validators=[lagos.ValidateSpatial(0)]) this mandates that the field EddyTurnover is only ever created inside grids. The field detection mechanism seems to get confused by the nested x-velocity calls and the GridLevel usage, and I'm not sure why, but I'm going to try to track it down. But, this should fix it, regardless! The other solution was to change the definition of the field to avoid using GridLevels: -- def EddyTurnover(field, data): eddy = data["x-velocity"] / data["dx"] return eddy def _convertEddyTurnover(data): return data.convert("cm")**-1.0 add_field("EddyTurnover", function=EddyTurnover, convert_function=_convertEddyTurnover) -- Note that here we've added a convert_function -- "x-velocity" will be in cgs, but "dx" is in code units, so we need to divide by "cm" in order to get it back in "seconds." I haven't included the "InitialTime" (code units) usage you had originally, but you should be able to drop it back in without trouble. I hope that helps -- let us know if there's anything else that goes wrong, or anything unclear in this. -Matt On Mon, Feb 15, 2010 at 8:00 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Luigi, I've looked over your code and I can't see anything specifically wrong. Can you post the error message you're getting? That might help. As a side note, you may want to replace pf['InitialTime'] on line 35 with data.pf['InitialTime']. The pf is global within your script, but if you those field functions in other files you will get an error because the function will not know about pf. Britton
On Mon, Feb 15, 2010 at 6:09 AM, Luigi Iapichino <luigi@ita.uni-heidelberg.de> wrote:
Dear all,
I'm trying to plot the projection of a variable defined in a rather involved way, namely through an IF statement. I can use this variable for many computations and I can plot slices of it, but somehow it does not work with projections. I attach an example script which isolates the problem. I guess it can run on any standard cosmological output of Enzo (v. 1.0; I haven't worked with Enzo 1.5 yet). As I told you, if I change the pc.add_projection(... at line 65 with pc.add_slice(... everything works well. I'm using YT 1.6, and because of problems in my machine I cannot upgrade to 1.6.1 until next week, so I don't know if this issue has been already fixed by chance. Looking forward to your suggestions, Cheers,
Luigi
--
---------------------------------------------------------------
Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Dear Matt and Britton, thanks for your help! Your suggestion about data.pf is very useful; my knowledge of python is still rather intuitive, and today I learnt something new. About "x-velocity", I'm sorry but my script was misleading: the velocity used in the full version of my analysis script is defined in a more elaborate way, so that the unit problem disappears. Moreover, I was not aware of the use of data["dx"]: it made my life much easier! I made these changes (and the validator stuff) in my script, and now it works perfectly. Cheers, Luigi Quoting Matthew Turk <matthewturk@gmail.com>:
Hi Luigi,
First off, thank you very much for providing a script that isolates the problem! It made it much easier for me to dig in and replicate the issue.
First I'd like to echo what Britton said about accessing the pf -- it's guaranteed to be defined as data.pf, but it's not guaranteed to be in the namespace otherwise. Additionally, I'd like to just note that "x-velocity" gets returned after having been converted via the Enzo units in the parameter file (you can see what these are by looking at pf["x-velocity"]) so you might be applying apples to oranges.
I found two solutions to the issue. One is to apply a validator:
add_field("EddyTurnover", function=EddyTurnover, validators=[lagos.ValidateSpatial(0)])
this mandates that the field EddyTurnover is only ever created inside grids. The field detection mechanism seems to get confused by the nested x-velocity calls and the GridLevel usage, and I'm not sure why, but I'm going to try to track it down. But, this should fix it, regardless!
The other solution was to change the definition of the field to avoid using GridLevels:
-- def EddyTurnover(field, data): eddy = data["x-velocity"] / data["dx"] return eddy
def _convertEddyTurnover(data): return data.convert("cm")**-1.0
add_field("EddyTurnover", function=EddyTurnover, convert_function=_convertEddyTurnover) --
Note that here we've added a convert_function -- "x-velocity" will be in cgs, but "dx" is in code units, so we need to divide by "cm" in order to get it back in "seconds." I haven't included the "InitialTime" (code units) usage you had originally, but you should be able to drop it back in without trouble.
I hope that helps -- let us know if there's anything else that goes wrong, or anything unclear in this.
-Matt
On Mon, Feb 15, 2010 at 8:00 AM, Britton Smith <brittonsmith@gmail.com> wrote:
Hi Luigi, I've looked over your code and I can't see anything specifically wrong. Can you post the error message you're getting? That might help. As a side note, you may want to replace pf['InitialTime'] on line 35 with data.pf['InitialTime']. The pf is global within your script, but if you those field functions in other files you will get an error because the function will not know about pf. Britton
On Mon, Feb 15, 2010 at 6:09 AM, Luigi Iapichino <luigi@ita.uni-heidelberg.de> wrote:
Dear all,
I'm trying to plot the projection of a variable defined in a rather involved way, namely through an IF statement. I can use this variable for many computations and I can plot slices of it, but somehow it does not work with projections. I attach an example script which isolates the problem. I guess it can run on any standard cosmological output of Enzo (v. 1.0; I haven't worked with Enzo 1.5 yet). As I told you, if I change the pc.add_projection(... at line 65 with pc.add_slice(... everything works well. I'm using YT 1.6, and because of problems in my machine I cannot upgrade to 1.6.1 until next week, so I don't know if this issue has been already fixed by chance. Looking forward to your suggestions, Cheers,
Luigi
--
---------------------------------------------------------------
Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
--------------------------------------------------------------- Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
Dear all, I've just found another puzzling feature. When I try to create a phase plot with a different color map, I get the correct plot, but the colorbar is wrong (it remains at default color map). I used YT 1.0 for a while for phase plots, but I do not remember any problem like this. I attach a small script about this issue. Unfortunately I have to add the same disclaimer as yesterday: I use YT 1.6, and I could not check the last upgrade. Thanks in advance for your help, Cheers Luigi --------------------------------------------------------------- Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
Hi Luigi, Thanks for your bug report! I believe I have fixed it in r1636 of both trunk and branches/yt-1.6. The patch, if you want to apply it yourself, can be seen here: http://yt.enzotools.org/changeset/1636 . However, if you aren't able to update your installation, the workaround is to call the set_cmap function on the returned plot object; you can see how to do this in my modified version of your script at: http://paste.enzotools.org/show/323 Also, to upgrade your yt installation from 1.6 to 1.6.1 or the current development branch, you should be able to cd into your yt-1.6 directory and execute: svn up python2.6 setup.py develop and it should auto-upgrade. Thanks again for the bug report, and let us know if there's anything else we can help out with! -Matt On Tue, Feb 16, 2010 at 12:50 AM, <luigi@ita.uni-heidelberg.de> wrote:
Dear all,
I've just found another puzzling feature. When I try to create a phase plot with a different color map, I get the correct plot, but the colorbar is wrong (it remains at default color map). I used YT 1.0 for a while for phase plots, but I do not remember any problem like this. I attach a small script about this issue.
Unfortunately I have to add the same disclaimer as yesterday: I use YT 1.6, and I could not check the last upgrade.
Thanks in advance for your help, Cheers
Luigi
---------------------------------------------------------------
Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt, thanks for the fix, it works perfectly! Quoting Matthew Turk <matthewturk@gmail.com>:
Also, to upgrade your yt installation from 1.6 to 1.6.1 or the current development branch, you should be able to cd into your yt-1.6 directory and execute:
svn up python2.6 setup.py develop
and it should auto-upgrade.
Yes; my problem is actually caused by my machine in Garching, and should be fixed there next week. I will let you know if I need any further support about it. Cheers, Luigi --------------------------------------------------------------- Luigi Iapichino Zentrum fuer Astronomie der Universitaet Heidelberg Institut fuer Theoretische Astrophysik Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany Tel: +49 6221 548983, Fax: +49 6221 544221 e-mail: luigi@ita.uni-heidelberg.de URL: http://www.ita.uni-heidelberg.de/~luigi/
participants (4)
-
Britton Smith -
Luigi Iapichino -
luigi＠ita.uni-heidelberg.de
-
Matthew Turk