Dear all,
I have to create a plot in the following way:
1) create a 2D phase plot;
2) add a line on the same plot;
3) setting limits on the colorbar.
Points 1) and 2) only are possible, and so also 1) and 3) only, but the
combination 1+2+3 fails. I am sure that, with some previous version, I could
add to my script set_zlim, too (I have old plots done in this way), but now
it does not work, both with yt 2.0 and the development version.
I attach a sample script which illustrates my problem.
Thanks in advance for your suggestions,
Luigi
--
---------------------------------------------------------------
Luigi Iapichino
Zentrum fuer Astronomie der Universitaet Heidelberg
Institut fuer Theoretische Astrophysik
Albert-Ueberle-Str. 2, D-69120 Heidelberg, Germany
Tel: +49 6221 548983, Fax: +49 6221 544221
e-mail: luigi(a)ita.uni-heidelberg.de
URL: http://www.ita.uni-heidelberg.de/~luigi/

Hi
In the new yt2.0 online documentation, the field_list page
(http://yt.enzotools.org/doc/reference/field_list.html) no longer
contains a list of just the field names. In the old 1.7 documentation
there was a column on the left hand side that contained such a list with
an in-page link to the more detailed descriptions. I found that to be
very useful for quickly looking up what kind of fields are available in
yt. Any chance we could bring such a list back?
Mike
--
*********************************************************************
* *
* Dr. Michael Kuhlen Theoretical Astrophysics Center *
* email: mqk(a)astro.berkeley.edu UC Berkeley *
* cell phone: (831) 588-1468 601 Campbell Hall *
* skype username: mikekuhlen Berkeley, CA 94720 *
* *
*********************************************************************

Geoffrey,
> Stephen is the expert for YT on Kraken, something about the scratch disk
> cannot see the home directories when running jobs and requires static
> linked libraries.
That is not entirely correct anymore, and I don't think that is what Britton's problem is. Yes, the compute nodes cannot see the home disk, but I think Britton is building things using a login node. So disk visibility should not be his problem. Also, Kraken now supports shared object loading, so the static build option that I am renowned for (?!) isn't necessary unless you want to run python/yt inline, which is what Britton is trying to do. As to Britton's problem, I don't know what is going on, sorry!
Stephen Skory
stephenskory(a)yahoo.com
http://stephenskory.com/
510.621.3687 (google voice)

Greetings,
I'm trying to install yt on kraken using the install_script. I have done a
'module swap PrgEnv-pgi PrgEnv-gnu' to switch to gnu compilers. I have also
done 'module unload mercurial' and 'module unload python' to remove the
system mercurial and python2.6 installs. Finally, I have added
--enable-shared to the Python configure line in the install script, since I
will try to build enzo with inline yt enabled.
The build is failing on numpy with the following error:
C compiler: gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall
-Wstrict-prototypes -fPIC
compile options: '-Inumpy/core/include
-Ibuild/src.linux-x86_64-2.6/numpy/core/include/numpy
-Inumpy/core/src/private -Inumpy/core/src -Inumpy/core
-Inumpy/core/src/npymath -Inumpy/core/src/multiarray -Inumpy/core/src/umath
-Inumpy/core/include -I/lustre/scratch/britton/yt-embedded/include/python2.6
-Ibuild/src.linux-x86_64-2.6/numpy/core/src/multiarray
-Ibuild/src.linux-x86_64-2.6/numpy/core/src/umath -c'
gcc -pthread -shared
build/temp.linux-x86_64-2.6/build/src.linux-x86_64-2.6/numpy/core/src/_sortmodule.o
-L. -Lbuild/temp.linux-x86_64-2.6 -lm -lpython2.6 -o
build/lib.linux-x86_64-2.6/numpy/core/_sort.so
/usr/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
/usr/bin/ld: cannot find -lpython2.6
collect2: ld returned 1 exit status
Because I can see the error is that it can't find the python library, I
tried adding
/lustre/scratch/britton/yt-embedded/lib/python2.6/config/:/lustre/scratch/britton/yt-embedded/lib
to my $LD_LIBRARY_PATH, and restarting the install, but I get the same
error. I have also added the appropriate paths to PATH and PYTHONPATH and
that has not helped either.
Does anyone have any ideas?
Britton

Hello,
I am wondering if anyone else sees behavior like the following:
I run the halo profiler on TACC ranger, and do Hop, radial profiles
and projections of all the halos. When running in the queue in
parallel, everything appears to run normally, but none of the
projection outputs appear in the projections directory. If I then run
in serial (interactively) the same routine, all the projections are
generated as normal in the correct directory. This happens however I
do the parallel run. Really I'm only running the parallel version for
hop in any case. I have not yet tested whether running in serial on
one node of ranger gives the same issue.
I thought I would check and see if this is a known issue.
Thanks.
Eric Hallman
Google Voice: (774) 469-0278
hallman13(a)gmail.com

Hi everyone,
tl;dr summary: In the unstable branch, Cython is now required, but it
should be auto-installed, and email me directly and off-list if you
run into any problems.
Longer:
I've just pushed a change (8e477b655c96) to the development branch,
but not the stable branch, that changes the way Cython code is handled
in yt. Cython is a Python-like dialect that compiles down to C code.
It understands NumPy arrays and Python objects natively, and can
produce code that operates at speeds competitive with raw,
hand-written C code. We use it in yt to write things like the volume
renderer, fast interpolation, level set identification, PNG writing,
and so on. You can see most of the Cython code in
yt/utilities/_amr_utils/*.pyx .
In the past, the Cython code was converted to C before being put into
the repository. This is visible in yt/utilities/amr_utils.c. If you
take a second to open this up, you'll note a couple things about it.
The first is that it's generated code: notoriously awful to read, and
100% impossible to maintain. That's why it's never touched directly,
and only generated by Cython. But, the problem with that is that if
we want to make small changes, they cascade into ridiculously long
changesets and diffs, which end up growing the size of the mercurial
repository by far more than is appropriate.
To get around this, I have added an install-time dependency on the
Cython package. To ensure that this will cause no problems during the
transition, installation of Cython was added to the install script a
while ago, and I have additionally added a check to setup.py. If
Cython is not found, it should install it. The only cases where this
should cause a problem are those where yt was installed with elevated
(sudo) permissions. Now, every time yt is rebuilt, the C code that
was previously in yt/utilities/amr_utils.c is regenerated from the
Cython code in yt/utilities/_amr_utils/*.pyx. This means that we no
longer need to update amr_utils.c in the mercurial repository.
Adding Cython brings with it a number of interesting things we can do;
these include much faster iteration on improvements to, say, the
volume renderer. Additionally, there are some other very interesting
things one can do with the speed improvements Cython brings, which
hopefully we can explore in the future.
Please email me directly if you have any problems.
For a bit more about this, and where we discussed it, you can see the
yt-dev mailing list thread about it:
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2011-January/00...
For more about Cython:
http://www.cython.org/
Best,
Matt

Hello all,
It appears from a cursory look at the source code that CICDeposit_3 does not automatically convert the mapped "mass" to a density itself... that the volume must be divided by after the fact. Is this correct?
Best,
John Z