Matt, Sam, Eric, Britton,
Thank you for all the previous infos (projections and 2D profiles). Now I have a clearer vision of these features. Sam, you are right, the derived field is created before the radial binning.I will let you know if I have further doubts (for sure).
As I said to Matt previously, I want to extend my congratulations to all the YT developers.You are doing a great job.
Cheers,
Max
Hello,
I am having trouble using a derived field with a CoveringGrid. I am making
fields for dPhi/dx, dPhi/dy, dPhi/dz using the PotentialField from ENZO.
The derivative fields do not get passed into the CoveringGrid and get
recalculated. This leads to the derivative being zero in areas that were
originally in coarse cells.
Density and DivV fields were passed to the CoveringGrid properly. As a test
I defined a field that was Density^2 and that was passed to the
CoveringGrid properly, so I think it is a problem specific to derived
fields based on the ENZO-specific PotentialField. I have included the
source for my derivative functions.
Thank you,
Nathan Butcher
I looked back in the email archive and found this exact same problem from John ZuHone. http://lists.spacepope.org/pipermail/yt-users-spacepope.org/2011-June/00165…
I wiped all png related stuff from the build and set INST_PNGLIB to 0 but I am still getting this error. Any ideas?
Notes: OSX 10.7.4 using Apple's gcc 4.2.1
ERROR:
Traceback (most recent call last):
File "/Users/cperuta/yt-i386/bin/yt", line 9, in <module>
load_entry_point('yt==2.3', 'console_scripts', 'yt')()
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/distribute-0.6.21-py2.7.egg/pkg_resources.py", line 337, in load_entry_point
return get_distribution(dist).load_entry_point(group, name)
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/distribute-0.6.21-py2.7.egg/pkg_resources.py", line 2281, in load_entry_point
return ep.load()
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/distribute-0.6.21-py2.7.egg/pkg_resources.py", line 1991, in load
entry = __import__(self.module_name, globals(),globals(), ['__name__'])
File "/Users/cperuta/yt-i386/src/yt-hg/yt/utilities/command_line.py", line 26, in <module>
from yt.mods import *
File "/Users/cperuta/yt-i386/src/yt-hg/yt/mods.py", line 107, in <module>
from yt.visualization.api import \
File "/Users/cperuta/yt-i386/src/yt-hg/yt/visualization/api.py", line 34, in <module>
from plot_collection import \
File "/Users/cperuta/yt-i386/src/yt-hg/yt/visualization/plot_collection.py", line 26, in <module>
from matplotlib import figure
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/figure.py", line 18, in <module>
from axes import Axes, SubplotBase, subplot_class_factory
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/axes.py", line 14, in <module>
import matplotlib.axis as maxis
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/axis.py", line 14, in <module>
import matplotlib.text as mtext
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/text.py", line 31, in <module>
from matplotlib.backend_bases import RendererBase
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/backend_bases.py", line 48, in <module>
import matplotlib.textpath as textpath
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/textpath.py", line 9, in <module>
from matplotlib.mathtext import MathTextParser
File "/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/mathtext.py", line 52, in <module>
import matplotlib._png as _png
ImportError: dlopen(/Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/_png.so, 2): Symbol not found: _png_set_longjmp_fn
Referenced from: /Users/cperuta/yt-i386/lib/python2.7/site-packages/matplotlib/_png.so
Expected in: dynamic lookup
Hi everyone,
I have a question that may be more of a matplotlib question than a yt
question, but it's an issue with some yt generated figures I have, so I
thought I'd ask it here. I think there was some discussion of this on
the list a while ago but I can't find the thread.
When I output images that include colorbars in vector formats (like pdf
and eps), I get these little lines running across the color bar. It
goes away if I output the image in a rasterized format (like png). I
wanted to output my images in vector format (as pdfs) so everything
looks nice and sharp. I've figured out how to just rasterize the color
bar. However, I don't want to rasterize the color bar labels, and the
way I've implemented it, the labels get rasterized too. It seems in
figure objects (and maybe axes objects?) there is a way to specify the
order that items get drawn and/or rasterized (through the zorder and
rasterized_zorder keywords); I've played around with this but haven't
been able to get it to work. The color bar is a Colorbar object and it
doesn't seem like this class allows for adjusting the rasterization
order of things.
I've pasted an example script here:
http://paste.yt-project.org/show/2504/
I'm probably going to give up on this soon, but any advice people have
would be greatly appreciated.
Christine
Hi all,
Over the last little while, a few of us have been working to update
and improve the GUI for yt, "Reason."
These changes were pushed into the main repository this morning. They
include a visual refresh, a smaller footprint on disk, and a 3D scene
based on XTK. (The camera path editor in the 3D scene is still
awaiting some fixes, but the concept is working.) I'd encourage you,
if you're on the development branch of yt, to update and give it a
shot:
yt update
yt serve
The first time you run this it will tell you to download a package
containing the javascript necessary to run, but after that it should
run fine. This version also includes the ability to run in parallel
on an MPI cluster, but the user interface for that is still being
developed. (If you would like to test this out before it's polished
up, drop on by IRC or yt-dev.)
Any feedback you have would be appreciated. We're going to be pushing
for a stable release in the near future.
-Matt
PS This and a few other things, such as a revised plotting mechanism,
were the product of a sprint we had last weekend. The summary is
here:
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002118.…http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002112.…
Hi,
Is the field such as DivV
(or any field that uses the scheme
sl_left = slice(None,-2,None)
sl_right = slice(1,-1,None)
f = data["x-velocity"][sl_right,1:-1,1:-1]/ds
f -= data["x-velocity"][sl_left ,1:-1,1:-1]/ds
to average between adjoining cells)
valid for objects such as regions, where the cells might not
necessarily be adjoining?
I'm thinking no...
Elizabeth
Hi,
I'm trying to plot a projection of the SZ effect, and I'm not sure how the
mechanism works. If I do
.
.
.
proj = pf.h.proj(0, "SZKinetic", weight_field='Ones')
frb = FixedResolutionBuffer(proj, (0.0, 1.0, 0.0, 1.0), (imgres, imgres))
img = frb[field]
pylab.imshow( img, interpolation='nearest', origin='lower')
After some digging I found the constants defined in
yt/utilities/physical_constants.py, but I'm not sure how do I use the
convertSZKinetic to get cgs answers (is the field SZKinetic already
returned as cgs, if so what is the cgs units?), and what are the units on
0.88 in the following equation? If I know that I can figure out the cgs
units.
def _convertSZKinetic(data):
return 0.88*((sigma_thompson/mh)/clight)
From
G.S.
Hi all,
SInce last December, Sam and I have been working on and off on
threading the volume rendering system and providing a major step
forward in its speed and quality.
We've issued a pull request to finish off these efforts and move them
into the main yt core. This includes a threaded volume renderer,
transfer functions with a degree of opacity, and the ability to (in
the future) much more explicitly control the behavior of the volume
renderer on the cell-level. All of the code is now separated into
very small component pieces, and it is more maintainable. The
threading works in conjunction with both MPI parallelism and MPI
parallelism for tiling, which means in theory the yt volume renderer
now operates at three levels of parallelism. (Which is kind of neat,
I think.)
However, once this is accepted, the minimum requirements to build the
development branch of yt will be upgraded to include Cython 0.16.
This is because Cython 0.16 includes OpenMP support. The installation
script has been updated to include Cython 0.16, so if you re-run that
(or install Cython 0.16 manually with "pip install -U Cython") then
you should be set. Otherwise you may run into problems during your
next "yt update". Additionally, _amr_utils has been renamed to lib,
which I don't think will cause issues but there is an outside chance
it will.
Finally, the off-axis-projections have changed in behavior. They no
longer interpolate within a cell. The end result is that the
projections are truer to the data, but this comes at the expense of a
bit of smoothness. They are now also ~20x faster.
This will be a core component of the yt 2.4 release, scheduled for a
few weeks from now. We encourage you to test this branch and new
behavior. Also, please reply if you have any questions or comments
about any of this!
Reference info:
http://lists.spacepope.org/pipermail/yt-dev-spacepope.org/2012-June/002039.…https://bitbucket.org/yt_analysis/yt/pull-request/168/volume-rendering-refa…
example "samplers":
https://bitbucket.org/MatthewTurk/yt-refactor/src/ec374f56d5b6/yt/utilities…https://bitbucket.org/MatthewTurk/yt-refactor/src/ec374f56d5b6/yt/utilities…
-Matt
---------- Forwarded message ----------
From: Erik Tollerud <erik.tollerud(a)gmail.com>
Date: Tue, Jun 19, 2012 at 2:51 AM
Subject: [astropy-dev] ANN: Astropy v0.1
To: astropy-dev(a)googlegroups.com, astropy(a)scipy.org
Hello all,
On behalf of the Astropy team, I'm excited to announce the first
release of the Astropy core package: v0.1!
The Astropy core package is intended to provide much of the common
functionality and tools needed for performing astronomy and
astrophysics with Python.
This release should be thought of as a "developer preview" - it has
much of the packaging and data handling framework in place, but the
actual astronomy functionality and frameworks are still incomplete.
Nevertheless, you can already make use of the existing functionality,
which is fully tested. Key features include:
* Standard cosmological distance calculations (astropy.cosmology)
* Data Tables (astropy.table) including a wide variety of ASCII
formats common in astronomy (astropy.io.ascii)
* FITS File handling - formerly PyFITS (astropy.io.fits)
* VOTable parser and writer (astropy.io.vo)
* WCS representations - formerly pywcs (astropy.wcs)
* Consistent documentation style
* Utilities to ease creation of new, independent packages (affiliated packages)
* A dedicated logging system
The package can be downloaded from
http://github.com/downloads/astropy/astropy/astropy-0.1.tar.gz . More
information is available at the Astropy site ( http://astropy.org ),
the package documentation ( http://docs.astropy.org ), and the
github repository ( http://github.com/astropy/astropy ).
We also encourage developers writing new packages to begin writing the
code against this version. Packages making use of Astropy should feel
free to join up as affiliated packages and begin transitioning to the
affiliated package template
( https://github.com/astropy/package-template ). In the next version,
we hope to implement a working affiliated package installer, so it will
be worth your while!
For the Astropy developers,
Erik Tollerud
