Hi everyone,
I've put in support for 1D and 2D data in yt/trunk. It's currently
not well-documented, or documented at all, but you should be able to
slice along axis '2' for 2D data and you should be able to
add_ortho_ray to a PlotCollection for 1D data. Additionally, support
for dx!=dy!=dz has been shored up, and support for non-cubic domains
has also been improved. There may still be funniness there.
The biggest change, though, is the generalized field containers. This
probably won't mean much to you unless you do a lot of work with your
own custom fields; it should be completely compatible with what you
currently do, but if there are problems, let me know. The new
generalized field containers allow for different sets of fields based
on the type of StaticOutput and Hierarchy created; if you have a
particular set of fields you are always adding, or modifying existing
fields, it might be worth your time to subclass EnzoStaticOutput and
set up your own field container.
Again, this is mainly just a feature enhancement notice, but if you
are running off trunk and you run into problems with fields, let me
know. If you're running off yt-1.0, which you are if you installed
from the Enzo 1.5 sources, then none of this should affect you.
-Matt
Hi there!
The installation script has changed a bit; we now rely more on
easy_install, which helps keep us up-to-date with bug fixes and
whatnot. (You can find more information about easy_install here:
http://peak.telecommunity.com/DevCenter/EasyInstall ) One of the side
effects is that the numpy installation is a bib slower, with less
information. How long did you wait before killing it? It can take a
while! (I will put a note in the script to this effect shortly.)
-Matt
PS You might also note that I've turned off the INST_WXPYTHON variable
too -- it was causing too many problems at large-scale supercomputer
installations to be on by default. Sorry about that!
On Sun, Nov 9, 2008 at 6:00 PM, rsoares <dlleuz(a)xmission.com> wrote:
> Hi,
>
> Enzo 1.5 works fine but yt won't install from within it (enzo/src/yt).
> It hangs at numpy. I've installed yt before but had to hand install
> several other things for wxPython, for gtk++ etc. Is the yt included in
> this installation any different then?
>
> Thanks for your time.
>
> R.Soares
>
> _______________________________________________
> yt-users mailing list
> yt-users(a)lists.spacepope.org
> http://lists.spacepope.org/listinfo.cgi/yt-users-spacepope.org
>
Hi,
Enzo 1.5 works fine but yt won't install from within it (enzo/src/yt).
It hangs at numpy. I've installed yt before but had to hand install
several other things for wxPython, for gtk++ etc. Is the yt included in
this installation any different then?
Thanks for your time.
R.Soares
Hi guys,
I've changed the policy in trunk. After talking with Stephen Skory
about this, and going back and forth, it became obvious that the
original policy of running in parallel "whenever possible" via
autodiscovery of the mpi4py module & job size was not a viable option.
You now have to use the executable 'mpi4py' instead of the standard
'python' if you want to notify yt to run in parallel. (The executable
mpi4py is part of the mpi4py distribution, and is available by running
the 'install_exe' task on their setup.py.)
So, instead of:
mpirun -np 4 python2.5 some_script.py
you'd run:
mpirun -np 4 mpi4py some_script.py
By avoiding global variables, we are able to preserve the usage of
identical scripts in parallel and in serial. (From the yt
perspective.)
I'm still working on parallelizing other objects (slices & cutting
planes) besides projections, quantities & profiles; Stephen Skory has
begun work on parallelizing HOP, which would be a pretty awesome
addition. More updates as they come.
-Matt
Hi there,
After talking it over with some of the other developers, it is
becoming increasingly clear that YT is getting a bit unwieldy in its
current organization scheme. Over the next couple months we're going
to explore new ways to lay out the package structure, which will
ultimately result in something with names that might have more meaning
to a user, rather than the (admittedly) obtuse names that make up
subpackages as they stand right now. (I honestly do not foresee any
changes in the near future -- it is rather more likely that any
changes would occur sometime in late December or mid-January.)
To that end, I am writing to encourage everyone to start using (or
continue using, if you already are) the following idiom for gaining
access to YT:
--
from yt.mods import *
--
This will import into your local namespace all of the main objects one
typically needs within YT, as well as the (current) subpackages
'lagos' and 'raven.' This idiom will be *future compatible*, and as
such if you are using it now, your scripts should not have to be
changed once we reorganize. Of course the 'iyt' entry point will be
updated appropriately.
The reason for the change is a happy one -- we are currently getting
more and more contributions, of both analysis pipelines and new means
of data exploration. Right now, the import structure is rather
sticky, which makes it difficult to import individual subpackages as
well as deal with cross-subpackage imports, but with a suitable
reorganization this will be addressable. (We're looking at lightcone
generation, halo analysis, profiling of finely-grained timeseries
data, rotating slice movies, and on and on.) Dealing with this
head-on will help facilitate future contributions.
So, the summary: tons of cool stuff is coming (from inside and outside
of the main dev team) and to accommodate that stuff, we'll have to
move some things around, but if you use "from yt.mods import *" you
should be set.
I definitely welcome any comments or suggestions!
-Matt
