Mailman 3 November 2010 - yt-dev

Transaction Abort on main hg repo
by Matthew Turk 23 Nov '10

23 Nov '10

Hi all, Just as a quick note, we've been seeing periodic aborts of cloning from the main yt repository. I'm trying to track this down, but as a workaround I have placed some debugging commands into the install script. If you see this problem when re-cloning, please rerun with: hg --debug --verbose --traceback clone ... to see the traceback, and send it to me off-list. I think it might have been related to the debugging command I placed into the server launcher two weeks ago while debugging some issues, but I'm not entirely sure. As a quick hack I've increased a couple timeouts, but I'm not sure what the problem is. In the new year sometime I may be able to move us to a different server to handle this better. -Matt

1 0

Re: [Yt-dev] Yt-dev Digest, Vol 23, Issue 9
by Wolfram Schmidt 23 Nov '10

23 Nov '10

-----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(a)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(a)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(a)lists.spacepope.org http://lists.spacepope.org/listinfo.cgi/yt-dev-spacepope.org >> >> > ------------------------------ > _______________________________________________ > Yt-dev mailing list > Yt-dev(a)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-----

1 0

wired problem with plotting slices from an AMR simulation
by Wolfram Schmidt 22 Nov '10

22 Nov '10

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.9 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iEYEARECAAYFAkzqmowACgkQTMDJfdKHpAtEzQCfSfH5kUYuMtMJqQowBRxqMia6 w5AAoJFDOFac26y7n8/Fh5MH86d+cn8r =CKlc -----END PGP SIGNATURE-----

2 1

Re: [Yt-dev] Configuration reorg call for testing
by Stephen Skory 21 Nov '10

21 Nov '10

Hi Matt, I've looked around and it looks like I don't have any custom config files. Which isn't very helpful to you, sorry. Also, thanks John for the pointer! Stephen Skory stephenskory(a)yahoo.com http://stephenskory.com/ 510.621.3687 (google voice)

3 5

powmes
by Tom Abel 19 Nov '10

19 Nov '10

Hi All, what do you think of wrapping http://www.projet-horizon.fr/www.projet-horizon.fr/article345.html into yt ? Would this be difficult ? I think it potentially would have lots of users, don't you think? Best, Tom Tom Abel Associate Professor of Physics Kavli Institute for Particle Astrophysics and Cosmology, Stanford University tabel(a)stanford.edu

2 1

Re: [Yt-dev] Configuration reorg call for testing
by Stephen Skory 17 Nov '10

17 Nov '10

Matt, > I've attached a bundle of changesets, Pardon my ignorance, but I don't know what to do with the "new_config.hg" file. Is it used like a patch? It's binary, so I can't make heads or tails of it. Stephen Skory stephenskory(a)yahoo.com http://stephenskory.com/ 510.621.3687 (google voice)

2 1

yt method paper on the arXiv
by Matthew Turk 17 Nov '10

17 Nov '10

Hi all, I just wanted to let you know that we posted a yt method paper on the arXiv today, which may be of some interest. http://arxiv.org/abs/1011.3514 Best, Matt

2 1

Configuration reorg call for testing
by Matthew Turk 16 Nov '10

16 Nov '10

Hi all, I wrote up a mechanism for consolidating all the different options in the ~/.yt/config file into a single section, which should make everything much more straightforward. I've made a pass at having the config module auto-upgrade, but I was hoping to have a couple people test this -- specifically, it'd be great if Britton, Dave, Jeff and Stephen (people I know who've used the config file in fun and/or fancy ways in the past, or whose code I think touches the config file in a couple places) could test it. I've attached a bundle of changesets, which include the auto-upgrader and modifications to make it use a single config section. When it auto-upgrades, it will move ~/.yt/config to ~/.yt/config.old. If you get a chance, I would appreciate running yt with this, maybe on Kraken or some pathologically weird location, maybe with your own custom ~/.yt/config, or whatever. Any bugs or suggestions would be greatly appreciated. It'll only auto-convert *once*, so feel free to test by copying ~/.yt/config.old back to ~/.yt/config to re-run the upgrade process. Once this can be applied, instead of having ill-defined [yt], [lagos], [raven], etc sections in the config file, there'll only be the single section [yt] where everything will go. Thanks for any feedback. -Matt

1 0

Upgrading the stable version of yt to new module names
by Matthew Turk 15 Nov '10

15 Nov '10

Hi all, I'm writing about upgrading the "stable" version of yt to the a new naming scheme. Before I say anything else, let me start out and say that because of the potentially disruptive nature of this change, you should feel free to either refrain from upgrading your yt installation or emailing me directly (off-list) to get assistance with the upgrade process. We're planning on moving the "stable" version of the code to be the 2.0 API in the next few weeks, where we have removed the names lagos, raven, etc, in favor of more informative names like visualization, data_objects, and so on. This change was described by Jeff in an email to the list a few months ago, which has been summarized here: http://yt.enzotools.org/wiki/yt-2.0 . I would like to encourage you to upgrade now, rather than later, so that we can try to work out any potential issues in advance of the upgrade of the title "stable." Documentation is almost completely update and will be done before the "stable" branch reflects the new API. I've updated the homepage to now encourage new users to use the development version, which features the new module names, etc. If you would like to continue using the version you are on, you should be able to continue to do so by not upgrading. If you would like to upgrade, a new installation may be the easiest way, or otherwise you should be able to get the directory name of the current yt installation from "yt instinfo" and execute: "hg pull ; hg up -C yt ; hg purge ; python2.6 setup.py develop" in that directory. I'm working on updating the documentation to reflect this, but the upshot of all of the API changes is that *everything* that is needed to do all the standard analysis tasks is still available just with the command: from yt.mods import * If you are executing anything that requires directly calling "lagos" or "raven", please contact me directly (off-list) and I will assist you with the upgrade of your scripts. If you think it's a relatively broad concern about module naming and so on, feel free to email the list. Thanks very much, Matt

1 0

Ticket Triage
by Matthew Turk 09 Nov '10

09 Nov '10

Hi all, I am going through pruning some tickets today (while waiting for hsi to do its thing on Kraken :) and trying to close ones we don't need to worry about, as well as ping people about things. If any of the following sound like something appropriate for you, would you mind either leaving a brief comment on the ticket or shuffling it to 2.1? (Recall your login is the same as hg) Here's the full list of open tickets for 2.0: http://yt.enzotools.org/report/12 The ones I don't know how to fix are these: http://yt.enzotools.org/ticket/159 Orion particle support http://yt.enzotools.org/ticket/256 Answer testing: I don't have a machine to do this on, but I have the setup for Hudson CI http://yt.enzotools.org/ticket/262 Plot Window - note that #151, #219 and hopefully #274 will both be obviated by this http://yt.enzotools.org/ticket/247 Estimates of resources; can somebody who runs large parallel stuff help out with this? I think adding it to the parallelism section of the docs as a table or just a paragraph would be very helpful. http://yt.enzotools.org/ticket/237 iyt doesn't work properly with engines/threading http://yt.enzotools.org/ticket/254 Typenames should be stripped from the names of MPI functions http://yt.enzotools.org/ticket/269 kD-tree rendering Thanks everyone, Matt

1 0