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