Hi, I did some simple volume rendering with the following script: volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j)) I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores. Your help at your earliest convenience is appreciated. Best, Renyue
Hi Renyue, I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone. Additionally, can you try the following at the end of your script: im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False) I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible. Sorry for the trouble, Sam On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
Hi Sam, I am using the version that John installed on Pleiades. I got some other unrelated problems with profiling before and John was kind enough to revert back to an older version (I think). Anyway, this is what I got: /u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg Separately, I will try your transpose fix and will let you know. But the KDTree was really smoking fast (50-100 times compared to without) that makes things very efficient. I would like to thank you for that. Thanks very much, Renyue On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote: Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi Renyue, Yes, I reverted it back to v2.4 a few weeks ago. I can update yt to the latest version to see if it helps with these problems. John On 01/08/2013 11:38 AM, Renyue Cen wrote:
Hi Sam,
I am using the version that John installed on Pleiades. I got some other unrelated problems with profiling before and John was kind enough to revert back to an older version (I think). Anyway, this is what I got:
/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg
Separately, I will try your transpose fix and will let you know.
But the KDTree was really smoking fast (50-100 times compared to without) that makes things very efficient. I would like to thank you for that.
Thanks very much, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu <mailto:cen@astro.princeton.edu>> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
Hi John, I am testing Sam's transpose fix now to see if that changes things. I will let you know very shortly when I am done that and you may then upgrade to the latest version. Thanks, Renyue On Jan 8, 2013, at 11:56 AM, John Wise wrote:
Hi Renyue,
Yes, I reverted it back to v2.4 a few weeks ago. I can update yt to the latest version to see if it helps with these problems.
John
On 01/08/2013 11:38 AM, Renyue Cen wrote:
Hi Sam,
I am using the version that John installed on Pleiades. I got some other unrelated problems with profiling before and John was kind enough to revert back to an older version (I think). Anyway, this is what I got:
/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg
Separately, I will try your transpose fix and will let you know.
But the KDTree was really smoking fast (50-100 times compared to without) that makes things very efficient. I would like to thank you for that.
Thanks very much, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu <mailto:cen@astro.princeton.edu>> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
Hi Sam, your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, Best, Renyue On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote: Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi Renyue, That's great news. If it's okay with you, I'll update yt to the latest version on pleiades, and you can test whether you get the same results after the update. Thanks, John On 01/08/2013 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu <mailto:cen@astro.princeton.edu>> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech
Hi Renyue, John, Yeah, so that seems like it is the problem. If you update to the latest yt your original scripts should work without any transpose=False flags. Glad to hear the kdtree provided a speedup. I think it is primarily the le= and re= flags that help out. There are even more enhancements coming soon! Best, Sam On Tue, Jan 8, 2013 at 9:20 AM, John Wise <jwise@physics.gatech.edu> wrote:
Hi Renyue,
That's great news. If it's okay with you, I'll update yt to the latest version on pleiades, and you can test whether you get the same results after the update.
Thanks, John
On 01/08/2013 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu <mailto:cen@astro.princeton.**edu <cen@astro.princeton.edu>>> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"]**, no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-**DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-**000.png>
-- John Wise Assistant Professor of Physics Center for Relativistic Astrophysics, Georgia Tech ______________________________**_________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/**listinfo.cgi/yt-users-**spacepope.org<http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org>
Hi Sam, I have succeeded in volume rendering regions around some galaxies with the transpose=false fix. But, occasionally, for some reason, the exact same piece of yt code on some galaxies failed with the following error: AttributeError: 'NoneType' object has no attribute 'id' Building kd-Tree 0% | | ETA: --:--:-- ^MTraceback (most recent call last): File "test.py", line 318, in <module> le=c-0.5*WW, re=c+0.5*WW) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 376, in __init__ self._build(root_grids, None, self.domain_left_edge, self.domain_right_edge) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 1059, in _build set_leaf(current_node, current_node.parent_grid, current_node.l_corner, current_node.r_corner) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 154, in set_leaf thisnode.grid = grid_id.id AttributeError: 'NoneType' object has no attribute 'id' I am not sure what is causing this. Thanks very much, Renyue On Jan 8, 2013, at 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, <test1.png><test2.png> Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote: Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi, Where is the list of available colormaps located so I can see their colors? Thanks, Renyue
Hi Renyue, This list shows all of the colormaps available for anything that uses matplotlib (such as projections, profiles, but not anything that uses write_image or write_png or snapshot): http://www.scipy.org/Cookbook/Matplotlib/Show_colormaps You can also use these colormaps anywhere: algae (default) kamae black_green cubehelix There are also a whole bunch of IDL and other colormaps that are accessible, although I have not used them, which you can see a list of by doing: from yt.visualization._colormap_data import color_map_luts print "\n".join(sorted(color_map_luts)) -Matt On Fri, Jan 11, 2013 at 11:17 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
Where is the list of available colormaps located so I can see their colors?
Thanks, Renyue
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt, Thanks for your prompt reply. I was using imshow in conjunction with tf = ColorTransferFunction((lim1,lim2)) and tf.add_layers(8,colormap=mycmap,w=widt,alpha=alpha), for which I can use mycmap=cm.spectral or cm.spectral to mention a few, but when I try cm.jet, it does not seem to exist, and I am still trying to find a suitable colormap for this application. Thanks, Renyue On Jan 11, 2013, at 11:21 AM, Matthew Turk wrote:
Hi Renyue,
This list shows all of the colormaps available for anything that uses matplotlib (such as projections, profiles, but not anything that uses write_image or write_png or snapshot):
http://www.scipy.org/Cookbook/Matplotlib/Show_colormaps
You can also use these colormaps anywhere:
algae (default) kamae black_green cubehelix
There are also a whole bunch of IDL and other colormaps that are accessible, although I have not used them, which you can see a list of by doing:
from yt.visualization._colormap_data import color_map_luts print "\n".join(sorted(color_map_luts))
-Matt
On Fri, Jan 11, 2013 at 11:17 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
Where is the list of available colormaps located so I can see their colors?
Thanks, Renyue
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Renyue, I'm not sure what cm is in this context, but if you use the string key "jet" instead of cm.jet, it should work. (It does for me.) -Matt On Fri, Jan 11, 2013 at 11:27 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Matt,
Thanks for your prompt reply.
I was using imshow in conjunction with tf = ColorTransferFunction((lim1,lim2)) and tf.add_layers(8,colormap=mycmap,w=widt,alpha=alpha), for which I can use mycmap=cm.spectral or cm.spectral to mention a few, but when I try cm.jet, it does not seem to exist, and I am still trying to find a suitable colormap for this application.
Thanks, Renyue
On Jan 11, 2013, at 11:21 AM, Matthew Turk wrote:
Hi Renyue,
This list shows all of the colormaps available for anything that uses matplotlib (such as projections, profiles, but not anything that uses write_image or write_png or snapshot):
http://www.scipy.org/Cookbook/Matplotlib/Show_colormaps
You can also use these colormaps anywhere:
algae (default) kamae black_green cubehelix
There are also a whole bunch of IDL and other colormaps that are accessible, although I have not used them, which you can see a list of by doing:
from yt.visualization._colormap_data import color_map_luts print "\n".join(sorted(color_map_luts))
-Matt
On Fri, Jan 11, 2013 at 11:17 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
Where is the list of available colormaps located so I can see their colors?
Thanks, Renyue
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi, I think I am unclear about the orientation in pf.h.camera(c,W,L, ..., north=vec, ...). I got some nice looking pictures but don't know what north means in this case, because when I switch north=vec to north=reverse of vec, the image rotates along the vertical direction, so it seems like north is pointing to either left or right. It is very desirable for me to be able to make sure which direction vec points to (vec is the vec in north=vec) in the final rendered plot. Thanks in advance for help, Renyue
Hi Renyue, It depends a bit on how you are saving the image, unfortunately. If you are using a recent changeset of yt (after 2.4 where the transpose causes symmetric images on some compilers/machines), and you save with: cam.snapshot('image1.png') Then image1.png will have north pointing up. If you did: im = cam.snapshot() write_bitmap(im, 'image2.png', tranpose=False) Then image2.png will have north pointing right. If you did im = cam.snapshot() write_bitmap(im, 'image3.png', transpose=True) Then image3.png will have north pointing up. I am working on ways to make sure that it always points up by using the new ImageArray class, but have not come up with the full solution yet. I hope that description helps. Sam On Sat, Jan 12, 2013 at 8:12 PM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
I think I am unclear about the orientation in pf.h.camera(c,W,L, ..., north=vec, ...). I got some nice looking pictures but don't know what north means in this case, because when I switch north=vec to north=reverse of vec, the image rotates along the vertical direction, so it seems like north is pointing to either left or right. It is very desirable for me to be able to make sure which direction vec points to (vec is the vec in north=vec) in the final rendered plot.
Thanks in advance for help, Renyue
Hi Sam, I am using option (2) below without transpose (per your suggestion to fix the symmetric image problem) and it does seem to point to the right (I have a bit trouble to decide exactly at which direction the galaxy is traveling even though I have its peculiar velocity, because I do not have information about the velocity of the volume it is in). Thanks, Renyue On Jan 14, 2013, at 10:17 AM, Sam Skillman wrote:
Hi Renyue,
It depends a bit on how you are saving the image, unfortunately. If you are using a recent changeset of yt (after 2.4 where the transpose causes symmetric images on some compilers/machines), and you save with:
cam.snapshot('image1.png') Then image1.png will have north pointing up.
If you did: im = cam.snapshot() write_bitmap(im, 'image2.png', tranpose=False) Then image2.png will have north pointing right.
If you did im = cam.snapshot() write_bitmap(im, 'image3.png', transpose=True) Then image3.png will have north pointing up.
I am working on ways to make sure that it always points up by using the new ImageArray class, but have not come up with the full solution yet. I hope that description helps.
Sam
On Sat, Jan 12, 2013 at 8:12 PM, Renyue Cen <cen@astro.princeton.edu> wrote: Hi,
I think I am unclear about the orientation in pf.h.camera(c,W,L, ..., north=vec, ...). I got some nice looking pictures but don't know what north means in this case, because when I switch north=vec to north=reverse of vec, the image rotates along the vertical direction, so it seems like north is pointing to either left or right. It is very desirable for me to be able to make sure which direction vec points to (vec is the vec in north=vec) in the final rendered plot.
Thanks in advance for help, Renyue
Hi Renyue, If you can describe the galaxy using a data object (sphere, disk, etc), you could then do something like galaxy_object.quantities['BulkVelocity']() to get the motion of just that piece of the data. I'm not sure if that is helpful for you or not. I would say that it would be best to get on a more recent version of yt, where you will be able to use the tranpose, and the north vector will make more sense with option 1 or 3. Sam On Mon, Jan 14, 2013 at 7:25 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Sam,
I am using option (2) below without transpose (per your suggestion to fix the symmetric image problem) and it does seem to point to the right (I have a bit trouble to decide exactly at which direction the galaxy is traveling even though I have its peculiar velocity, because I do not have information about the velocity of the volume it is in).
Thanks, Renyue
On Jan 14, 2013, at 10:17 AM, Sam Skillman wrote:
Hi Renyue,
It depends a bit on how you are saving the image, unfortunately. If you are using a recent changeset of yt (after 2.4 where the transpose causes symmetric images on some compilers/machines), and you save with:
cam.snapshot('image1.png') Then image1.png will have north pointing up.
If you did: im = cam.snapshot() write_bitmap(im, 'image2.png', tranpose=False) Then image2.png will have north pointing right.
If you did im = cam.snapshot() write_bitmap(im, 'image3.png', transpose=True) Then image3.png will have north pointing up.
I am working on ways to make sure that it always points up by using the new ImageArray class, but have not come up with the full solution yet. I hope that description helps.
Sam
On Sat, Jan 12, 2013 at 8:12 PM, Renyue Cen <cen@astro.princeton.edu>wrote:
Hi,
I think I am unclear about the orientation in pf.h.camera(c,W,L, ..., north=vec, ...). I got some nice looking pictures but don't know what north means in this case, because when I switch north=vec to north=reverse of vec, the image rotates along the vertical direction, so it seems like north is pointing to either left or right. It is very desirable for me to be able to make sure which direction vec points to (vec is the vec in north=vec) in the final rendered plot.
Thanks in advance for help, Renyue
Hi Sam, Thanks for the suggestion, I think it could work if I choose an appropriate size for the embedding sphere. For not using yt ver 2.5 it is because when I use yt 2.5, I got this error: AttributeError: 'AMRSmoothedCoveringGrid' object has no attribute 'NumberOfParticles' so John switched back to yt2.4 with the transpose=False fix, which worked most of the time. Best, Renyue On Jan 14, 2013, at 10:27 AM, Sam Skillman wrote:
Hi Renyue,
If you can describe the galaxy using a data object (sphere, disk, etc), you could then do something like galaxy_object.quantities['BulkVelocity']() to get the motion of just that piece of the data. I'm not sure if that is helpful for you or not.
I would say that it would be best to get on a more recent version of yt, where you will be able to use the tranpose, and the north vector will make more sense with option 1 or 3.
Sam
On Mon, Jan 14, 2013 at 7:25 AM, Renyue Cen <cen@astro.princeton.edu> wrote: Hi Sam,
I am using option (2) below without transpose (per your suggestion to fix the symmetric image problem) and it does seem to point to the right (I have a bit trouble to decide exactly at which direction the galaxy is traveling even though I have its peculiar velocity, because I do not have information about the velocity of the volume it is in).
Thanks, Renyue
On Jan 14, 2013, at 10:17 AM, Sam Skillman wrote:
Hi Renyue,
It depends a bit on how you are saving the image, unfortunately. If you are using a recent changeset of yt (after 2.4 where the transpose causes symmetric images on some compilers/machines), and you save with:
cam.snapshot('image1.png') Then image1.png will have north pointing up.
If you did: im = cam.snapshot() write_bitmap(im, 'image2.png', tranpose=False) Then image2.png will have north pointing right.
If you did im = cam.snapshot() write_bitmap(im, 'image3.png', transpose=True) Then image3.png will have north pointing up.
I am working on ways to make sure that it always points up by using the new ImageArray class, but have not come up with the full solution yet. I hope that description helps.
Sam
On Sat, Jan 12, 2013 at 8:12 PM, Renyue Cen <cen@astro.princeton.edu> wrote: Hi,
I think I am unclear about the orientation in pf.h.camera(c,W,L, ..., north=vec, ...). I got some nice looking pictures but don't know what north means in this case, because when I switch north=vec to north=reverse of vec, the image rotates along the vertical direction, so it seems like north is pointing to either left or right. It is very desirable for me to be able to make sure which direction vec points to (vec is the vec in north=vec) in the final rendered plot.
Thanks in advance for help, Renyue
Hi, When I do plotdata=pc.add_phase_object(source,["FieldX","FieldY","QuantityZ"],weight = None,..) plotdata.data_write_out(filename) It seems that the QuantityZ written out in file filename is transposed with respect to x-y plane of the plot plotted by pc.add_phase_object(). Has anyone encountered this? If anyone wants script and actual file to help me, I can send to you. Thanks, Renyue
Hi Renyue, Yup, it's column/row switched from what one might expect. But, the bins written out should correspond. -Matt On Sun, Aug 25, 2013 at 10:38 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
When I do plotdata=pc.add_phase_object(source,["FieldX","FieldY","QuantityZ"],weight = None,..) plotdata.data_write_out(filename)
It seems that the QuantityZ written out in file filename is transposed with respect to x-y plane of the plot plotted by pc.add_phase_object().
Has anyone encountered this? If anyone wants script and actual file to help me, I can send to you.
Thanks, Renyue
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
Hi Matt, so if I just read in data filename like: do j=1,50 do i=1,50 read(1,*)column(i),row(j),Z(j,i) enddo enddo will that correct Z exactly? Renyue On Aug 25, 2013, at 12:28 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Renyue,
Yup, it's column/row switched from what one might expect. But, the bins written out should correspond.
-Matt
On Sun, Aug 25, 2013 at 10:38 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
When I do plotdata=pc.add_phase_object(source,["FieldX","FieldY","QuantityZ"],weight = None,..) plotdata.data_write_out(filename)
It seems that the QuantityZ written out in file filename is transposed with respect to x-y plane of the plot plotted by pc.add_phase_object().
Has anyone encountered this? If anyone wants script and actual file to help me, I can send to you.
Thanks, Renyue
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
I usually use something similar to http://paste.yt-project.org/show/3816/ to use yt to bin the data then use matplotlib to make the plot of the 2D profile for more customization options. If you compare the test1.....png and test2.png, you should see they are using the same data range, the 2D profile is transposed to switch x,y and origin set at (0,0). hope it's something you can use. From G.S. On Sun, Aug 25, 2013 at 9:34 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Matt,
so if I just read in data filename like:
do j=1,50 do i=1,50 read(1,*)column(i),row(j),Z(j,i) enddo enddo
will that correct Z exactly?
Renyue
On Aug 25, 2013, at 12:28 PM, Matthew Turk <matthewturk@gmail.com> wrote:
Hi Renyue,
Yup, it's column/row switched from what one might expect. But, the bins written out should correspond.
-Matt
On Sun, Aug 25, 2013 at 10:38 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi,
When I do
plotdata=pc.add_phase_object(source,["FieldX","FieldY","QuantityZ"],weight = None,..)
plotdata.data_write_out(filename)
It seems that the QuantityZ written out in file filename is transposed with respect to x-y plane of the plot plotted by pc.add_phase_object().
Has anyone encountered this? If anyone wants script and actual file to help me, I can send to you.
Thanks, Renyue
_______________________________________________ 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
Hi Sam, This problem that I mentioned in the attached email sent earlier appears to be a bit more common that I thought. I mean, it occurs for multiple galaxies at different redshifts. The data files appear ok in that I could make projection plots in the same regions just fine without using the AMTKDTree, and a same data file looks ok for AMRKDTree for a different galaxy at a different location. This is a bit critical for me because I need to be able to analyze all these galaxies to gain a full physical understanding. Your help is appreciated, Best, Renyue On Jan 9, 2013, at 10:57 PM, Renyue Cen wrote:
Hi Sam,
I have succeeded in volume rendering regions around some galaxies with the transpose=false fix. But, occasionally, for some reason, the exact same piece of yt code on some galaxies failed with the following error:
AttributeError: 'NoneType' object has no attribute 'id' Building kd-Tree 0% | | ETA: --:--:-- ^MTraceback (most recent call last): File "test.py", line 318, in <module> le=c-0.5*WW, re=c+0.5*WW) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 376, in __init__ self._build(root_grids, None, self.domain_left_edge, self.domain_right_edge) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 1059, in _build set_leaf(current_node, current_node.parent_grid, current_node.l_corner, current_node.r_corner) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 154, in set_leaf thisnode.grid = grid_id.id AttributeError: 'NoneType' object has no attribute 'id'
I am not sure what is causing this.
Thanks very much, Renyue
On Jan 8, 2013, at 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, <test1.png><test2.png> Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote: Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi Renyue, I've been travelling all over the place and have had flaky (at best) internet, so sorry for the delay. Unfortunately that error means that the AMRKDTree is failing for some of it's constructions, which is a fairly difficult problem to track down. The most robust way to fix the problem is to build the full volume and even though it will be much slower, it will fix the problem. There are improvements in an outstanding pull request for the new AMRKDTree that will fix this, but for now (until I'm done travelling at the end of this week) the best solution is to just hand it the full volume. Note that if you can automate through each of the galaxies and only build the volume once, you can then switch the camera positions to go look around at all the galaxies. The only other option I can think of is to force le= and re= equal to root grid cell boundaries. So if you had your original LE= c-0.5*WW and RE = c+0.5*WW Then I would do: le = np.int(LE*pf.domain_dimensions) * pf.domain_width / pf.domain_dimensions re = (np.int(RE*pf.domain_dimensions)+1) * pf.domain_width / pf.domain_dimensions I'm not positive that it will fix the problem, so if that doesn't work then please go back to the full domain (not specifying le, re). Sorry for the trouble. Sam On Mon, Jan 14, 2013 at 6:47 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Sam,
This problem that I mentioned in the attached email sent earlier appears to be a bit more common that I thought. I mean, it occurs for multiple galaxies at different redshifts. The data files appear ok in that I could make projection plots in the same regions just fine without using the AMTKDTree, and a same data file looks ok for AMRKDTree for a different galaxy at a different location.
This is a bit critical for me because I need to be able to analyze all these galaxies to gain a full physical understanding.
Your help is appreciated,
Best, Renyue
On Jan 9, 2013, at 10:57 PM, Renyue Cen wrote:
Hi Sam,
I have succeeded in volume rendering regions around some galaxies with the transpose=false fix. But, occasionally, for some reason, the exact same piece of yt code on some galaxies failed with the following error:
AttributeError: 'NoneType' object has no attribute 'id' Building kd-Tree 0% | | ETA: --:--:-- ^MTraceback (most recent call last): File "test.py", line 318, in <module> le=c-0.5*WW, re=c+0.5*WW) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 376, in __init__ self._build(root_grids, None, self.domain_left_edge, self.domain_right_edge) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 1059, in _build set_leaf(current_node, current_node.parent_grid, current_node.l_corner, current_node.r_corner) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 154, in set_leaf thisnode.grid = grid_id.id AttributeError: 'NoneType' object has no attribute 'id'
I am not sure what is causing this.
Thanks very much, Renyue
On Jan 8, 2013, at 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, <test1.png><test2.png> Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi Sam, Constructing KDTree for the whole box apparently take a much much longer time (first it ran out of memory so I increased the RAM/CPU ratio): it used to take about 1 min and the test run I put in has taken 80 mins and is still in the KDTree building phase, so it might not be practical for me with this approach. Best, Renyue On Jan 14, 2013, at 10:01 AM, Sam Skillman wrote:
Hi Renyue,
I've been travelling all over the place and have had flaky (at best) internet, so sorry for the delay.
Unfortunately that error means that the AMRKDTree is failing for some of it's constructions, which is a fairly difficult problem to track down. The most robust way to fix the problem is to build the full volume and even though it will be much slower, it will fix the problem. There are improvements in an outstanding pull request for the new AMRKDTree that will fix this, but for now (until I'm done travelling at the end of this week) the best solution is to just hand it the full volume. Note that if you can automate through each of the galaxies and only build the volume once, you can then switch the camera positions to go look around at all the galaxies.
The only other option I can think of is to force le= and re= equal to root grid cell boundaries. So if you had your original LE= c-0.5*WW and RE = c+0.5*WW Then I would do: le = np.int(LE*pf.domain_dimensions) * pf.domain_width / pf.domain_dimensions re = (np.int(RE*pf.domain_dimensions)+1) * pf.domain_width / pf.domain_dimensions
I'm not positive that it will fix the problem, so if that doesn't work then please go back to the full domain (not specifying le, re). Sorry for the trouble.
Sam
On Mon, Jan 14, 2013 at 6:47 AM, Renyue Cen <cen@astro.princeton.edu> wrote: Hi Sam,
This problem that I mentioned in the attached email sent earlier appears to be a bit more common that I thought. I mean, it occurs for multiple galaxies at different redshifts. The data files appear ok in that I could make projection plots in the same regions just fine without using the AMTKDTree, and a same data file looks ok for AMRKDTree for a different galaxy at a different location.
This is a bit critical for me because I need to be able to analyze all these galaxies to gain a full physical understanding.
Your help is appreciated,
Best, Renyue
On Jan 9, 2013, at 10:57 PM, Renyue Cen wrote:
Hi Sam,
I have succeeded in volume rendering regions around some galaxies with the transpose=false fix. But, occasionally, for some reason, the exact same piece of yt code on some galaxies failed with the following error:
AttributeError: 'NoneType' object has no attribute 'id' Building kd-Tree 0% | | ETA: --:--:-- ^MTraceback (most recent call last): File "test.py", line 318, in <module> le=c-0.5*WW, re=c+0.5*WW) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 376, in __init__ self._build(root_grids, None, self.domain_left_edge, self.domain_right_edge) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 1059, in _build set_leaf(current_node, current_node.parent_grid, current_node.l_corner, current_node.r_corner) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 154, in set_leaf thisnode.grid = grid_id.id AttributeError: 'NoneType' object has no attribute 'id'
I am not sure what is causing this.
Thanks very much, Renyue
On Jan 8, 2013, at 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, <test1.png><test2.png> Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png') write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote: Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
Hi Renyue, On Mon, Jan 14, 2013 at 3:23 PM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Sam,
Constructing KDTree for the whole box apparently take a much much longer time (first it ran out of memory so I increased the RAM/CPU ratio): it used to take about 1 min and the test run I put in has taken 80 mins and is still in the KDTree building phase, so it might not be practical for me with this approach.
The kD-tree is instrumented to operate in parallel; are you running this in parallel? For very large domains, I am not surprised it would take considerably longer to do the whole domain. Did you try Sam's suggestion of specifying LE/RE? That would likely be the best solution. -Matt
Best, Renyue
On Jan 14, 2013, at 10:01 AM, Sam Skillman wrote:
Hi Renyue,
I've been travelling all over the place and have had flaky (at best) internet, so sorry for the delay.
Unfortunately that error means that the AMRKDTree is failing for some of it's constructions, which is a fairly difficult problem to track down. The most robust way to fix the problem is to build the full volume and even though it will be much slower, it will fix the problem. There are improvements in an outstanding pull request for the new AMRKDTree that will fix this, but for now (until I'm done travelling at the end of this week) the best solution is to just hand it the full volume. Note that if you can automate through each of the galaxies and only build the volume once, you can then switch the camera positions to go look around at all the galaxies.
The only other option I can think of is to force le= and re= equal to root grid cell boundaries. So if you had your original LE= c-0.5*WW and RE = c+0.5*WW Then I would do: le = np.int(LE*pf.domain_dimensions) * pf.domain_width / pf.domain_dimensions re = (np.int(RE*pf.domain_dimensions)+1) * pf.domain_width / pf.domain_dimensions
I'm not positive that it will fix the problem, so if that doesn't work then please go back to the full domain (not specifying le, re). Sorry for the trouble.
Sam
On Mon, Jan 14, 2013 at 6:47 AM, Renyue Cen <cen@astro.princeton.edu> wrote:
Hi Sam,
This problem that I mentioned in the attached email sent earlier appears to be a bit more common that I thought. I mean, it occurs for multiple galaxies at different redshifts. The data files appear ok in that I could make projection plots in the same regions just fine without using the AMTKDTree, and a same data file looks ok for AMRKDTree for a different galaxy at a different location.
This is a bit critical for me because I need to be able to analyze all these galaxies to gain a full physical understanding.
Your help is appreciated,
Best, Renyue
On Jan 9, 2013, at 10:57 PM, Renyue Cen wrote:
Hi Sam,
I have succeeded in volume rendering regions around some galaxies with the transpose=false fix. But, occasionally, for some reason, the exact same piece of yt code on some galaxies failed with the following error:
AttributeError: 'NoneType' object has no attribute 'id' Building kd-Tree 0% | | ETA: --:--:-- ^MTraceback (most recent call last): File "test.py", line 318, in <module> le=c-0.5*WW, re=c+0.5*WW) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 376, in __init__ self._build(root_grids, None, self.domain_left_edge, self.domain_right_edge) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 1059, in _build set_leaf(current_node, current_node.parent_grid, current_node.l_corner, current_node.r_corner) File "/u/jhwise/local/lib/python2.7/site-packages/yt-2.4-py2.7-linux-x86_64.egg/yt/utilities/amr_kdtree/amr_kdtree.py", line 154, in set_leaf thisnode.grid = grid_id.id AttributeError: 'NoneType' object has no attribute 'id'
I am not sure what is causing this.
Thanks very much, Renyue
On Jan 8, 2013, at 12:08 PM, Renyue Cen wrote:
Hi Sam,
your transpose fix DOES change things and it indeed may working now. Here is the first images I got for comparison. I am going to make a few more pictures to see if things are all good. Thanks very much, <test1.png><test2.png> Best, Renyue
On Jan 8, 2013, at 11:25 AM, Sam Skillman wrote:
Hi Renyue,
I have actually seen this on one other system but I could never reproduce it. Could you tell me the version of yt you are using? If you run "yt instinfo" it should tell you. I haven't seen this bug for the last few months so I thought it was gone.
Additionally, can you try the following at the end of your script:
im=cam.snapshot('test1.png')
write_bitmap(im, 'test2.png', transpose=False)
I think there may have been something wrong with the transposing of the image for a short time period a few months ago. I have very sporadic and unreliable internet at AAS but I'll try to respond as quickly as possible.
Sorry for the trouble,
Sam
On Jan 7, 2013 10:11 AM, "Renyue Cen" <cen@astro.princeton.edu> wrote:
Hi,
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"], no_ghost=False, tree_type="domain", le=c-0.5*WW, re=c+0.5*WW) cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False, north_vector=L, steady_north=True) cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty sure can not be true. I attach the obtained plot. Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated. Best, Renyue
<C15z1600.0043_iso-DMdensity-000.png>
_______________________________________________ yt-users mailing list yt-users@lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
participants (6)
-
Geoffrey So -
John Wise -
Matthew Turk -
Renyue Cen -
Renyue Cen
-
Sam Skillman