[Yt-dev] Yt-dev Digest, Vol 23, Issue 9

[Wolfram Schmidt]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Matt,

thanks a lot, this was exactly the problem! With

pc = PlotCollection(pf, [0.5, 0.5, 0.5])

the rendering of the slices works.

Best,
Wolfram

yt-dev-request at lists.spacepope.org wrote:
> 
> Hi Wolfram,
> 
> (First off, those are gorgeous images, despite the boundary condition errors!)
> 
> The issue I think is in the creation of the plot collection.  This line:
> 
> pc = PlotCollection(pf)
> 
> will default to identifying the location of maximum density in the
> simulation, and centering the subsequent affiliated plots on that
> location.  To override this, what you likely want to do is manually
> specify the center you'd like for your plots:
> 
> pc = PlotCollection(pf, [0.5, 0.5, 0.5])
> 
> This should also eliminate the need for the "coord=0.5" argument to add_slice.
> 
> The reason behind this is that, once upon a time, yt was used mainly
> by me and a couple other people doing collapse simulations -- where it
> was simply easier to shorthand the creation of a plot collection to be
> the point of maximum density.  But now that it's moved well beyond
> that initial use case, it may be time to revisit that -- so that
> problems like this can be avoided.  I'll bring this up on the dev
> mailing list in the near future, to see if it would be a good decision
> to change it.
> 
> If you give the new options, can you let me know if it fixes the problem?
> 
> Best,
> 
> Matt
> 
> On Mon, Nov 22, 2010 at 11:30 AM, Wolfram Schmidt
> <schmidt at astro.physik.uni-goettingen.de> wrote:
> Hi everyone,
> 
> rendering slices from an Enzo simulation with an inflow boundary
> condition, I noticed something strange (see attached pictures
> MSC_0050_Slice_y_*.png): It looks like a piece of the domain is chopped
> off at the right and attached at the left. First I thought that
> something was wrong with the inflow boundary condition (left edge in the
> pictures), but then I realized that this would be unlikely because the
> piece on the left matches at the right edge.
> 
> Indeed, visualizing the same data with visit, the slices appear to be ok
> (see MSC_0500_*_visit.png).
> 
> Has anyone an idea what is going on here?
> 
> The data are from a 3D AMR simulation with two levels of refinement,
> inflow on one face and outflow on the other faces.
> 
> I used the following yt script to produce the slices:
> 
> #!/home/h/nipschul/yt/yt-x86_64/bin/python2.6
> # importing modules
> from yt.mods import * # set up our namespace
> import yt.extensions.volume_rendering as vr
> #import pylab
> 
> pf =load("064amr2x2_vort+comp/DD0050/MSC_0050")
> pc = PlotCollection(pf)
> pc.add_slice("x-velocity",1,coord=0.5)
> pc.save()
> 
> If it helps, I can provide the dataset (its about 140 MB as a zipped
> archive).
> 
> Best regards,
> Wolfram
>>
_______________________________________________
Yt-dev mailing list
Yt-dev at lists.spacepope.org
http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org
>>
>>

> ------------------------------

> _______________________________________________
> Yt-dev mailing list
> Yt-dev at lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org


> End of Yt-dev Digest, Vol 23, Issue 9
> *************************************


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iEYEARECAAYFAkzruEAACgkQTMDJfdKHpAtN7wCfb4AURbhqwQIUG/9+v+DJYZFA
+ZIAoK0VIWiYEzXjGm6NRkyR2tC78iZr
=AhV4
-----END PGP SIGNATURE-----