Mailman 3 February 2013 - yt-users

Phase Plots --> Data Array
by Munier Azzam Salem Feb. 7, 2013

Feb. 7, 2013

Hey Guys, I'd like to take a phase diagram and convert it to a simple array to plot alongside some other nifty stuff in matplotlib. A couple questions related to this aim (feel free to ignore ones that seem dumb): 1. Since I can add a phase object to a plot collection, is there a way to convert a plot collection (or piece of it?) to a fixed resolution buffer? OR 2. Data objects made with pf.h.FUNCTION seem to be pass-able to the fixed resolution buffer function. Is there a way to create phase plots this way, instead of with plot collections? OR, maybe 3. Objects like simple line profiles have simple arrays living inside them. Is there a simple 2D array I can pull out of the phase plot object? thanks! Munier -- Munier A. Salem // 845.489.6450

2 2

errno.h
by Mark Kremenetsky Feb. 6, 2013

Feb. 6, 2013

Guys, I am using a script recommended on ENZO boot-camp page $ bash install_script.sh in order to set up all libraries needed for enzo compilation. Everything is going good and well until I got a following error: gcc -fPIC -c bzip2.c In file included from /usr/include/errno.h:36, from bzip2.c:55: /usr/include/bits/errno.h:25:26: error: linux/errno.h: No such file or directory make: *** [bzip2.o] Error 1 I checked and certainly I don't have such thing as /usr/include/linux/errno.h Any advice ? Thanks, Mark

4 6

Improved support for isolated boundary conditions
by Nathan Goldbaum Feb. 1, 2013

Feb. 1, 2013

Hi all, As you may know, yt was originally written to handle outputs from cosmological simulations produced by the Enzo code. Due to this pedigree, yt assumes internally in a number of places that the simulation box has periodic boundary conditions. In the last couple of years, we've been working on improving support for both non-cosmological simulations and datasets produced by codes besides Enzo. This effort has come a long way, but until recently the nature of the boundary conditions has received relatively little development attention. However, as yt becomes commonly used by people outside of the enzo community, the lack of proper support for general periodic or non-periodic boundary conditions is starting to be felt. A particularly nasty case is the radius field, which in the current codebase assumes periodic boundary conditions, producing incorrect results when someone tries to profile a field versus radius in a simulation that assumed some sort of isolated boundary conditions. Recently, Matt Turk came up with a summary of our strategy for improving support general boundary conditions, summarized in YTEP-0006: https://bitbucket.org/yt_analysis/ytep/src/tip/source/YTEPs/YTEP-0006.rst The main take-away points are that each of the code frontends will need to define a periodicity attribute that hangs off of each of the StaticOutput class. This way, one can check the periodicity of a parameter file by doing something like: >>> pf = load(filename) >>> print pf.periodicity (True, True, True) Here, pf.periodicity is a tuple, from which one can read off that the simulation is periodic along all three directions. We intend to fully support simulations that have arbitrary mixed periodic and isolated boundary conditions. We will then use the new periodicity attribute to modify the places in the code where we need to worry about boundary conditions. I've gone ahead and added the periodicity attribute for most of the code frontends. I've also enhanced the Radius and ParticleRadius fields to properly handle the periodicity. These modifications are included in Pull Request #410: https://bitbucket.org/yt_analysis/yt/pull-request/410/first-pass-at-ytep-6-… At this point, the PR is more or less ready to go. However, since this is a somewhat invasive change that might temporarily break code frontends if there is a bug somewhere, it would be great if some of you would check to make sure that everything works correctly for your datasets. In particular, I need help figuring out how to set the periodicity for the orion, chombo (i.e. pluto and orion2), maestro, and nyx frontends. It would also be great to hear from users who commonly work with 1D or 2D data, as these sorts of datasets have caused trouble in the past. I'll also note that if you're interested in helping out with yt development, finishing up YTEP-0006 would be an excellent starter project. If you run into trouble, please send a message to the yt-users or yt-dev mailing lists or, if you're looking for low-latency discussion, stop by on our IRC channel (#yt on freenode, or use the web chat interface: http://yt-project.org/irc.html). Cheers, Nathan Goldbaum

2 1