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 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 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>

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,

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 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.eduwrote:

...

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 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

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>