Transaction Abort on main hg repo
by Matthew Turk
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
8 years, 4 months
Re: [Yt-dev] Yt-dev Digest, Vol 23, Issue 9
by 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(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-----
8 years, 4 months
wired problem with plotting slices from an AMR simulation
by Wolfram Schmidt
-----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-----
8 years, 4 months
powmes
by Tom Abel
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
8 years, 4 months
Configuration reorg call for testing
by Matthew Turk
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
8 years, 4 months
Upgrading the stable version of yt to new module names
by Matthew Turk
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
8 years, 4 months
