Thanks for all your help over the last couple of days. One more question:
- Can I plot particles on a volume rendered image?
I have stars and I want to show where they are!
Elizabeth Harper-Clark MA MSci
PhD Candidate, Canadian Institute for Theoretical Astrophysics, UofT
Sciences and Engineering Coordinator, Teaching Assistants' Training Program,
Astronomy office phone: +1-416-978-5759
Does anyone out there have a technique for getting the variance out of
a profile object? A profile object is good at getting <X> vs. B, I'd
then like to get < (X - <X>)^2 > vs B. Matt and I had spittballed the
possibility some time ago, but I was wondering if anyone out there had
successfully done it.
Sent from my computer.
I did some simple volume rendering with the following script:
volume2 = AMRKDTree(pf, fields=["Dark_Matter_Density"],
cam = pf.h.camera(c, L, W, N, tf, volume=volume2, no_ghost=False,
cam.snapshot(fn="%s_iso-DMdensity-%3.3d.png" % (filenameTHIS, j))
I got rather strange results in that the pictures look symmetric, which I am pretty
sure can not be true.
I attach the obtained plot.
Note that I am using KD tree and using 32 cores.
Your help at your earliest convenience is appreciated.
Hi yt user,
This question mostly goes to John Wise (maybe not).
I try to use eps_writer module in the yt to generate a high-quality .eps
I attempt to make four phase plot (rho-T) from four different times (i.e.
four different data output)
But, I got the following error message:
File "Phase_eps.py", line 39, in <module>
ep = eps.multiplot_yt(2,2,pc)
line 1010, in multiplot_yt
"x ncol(%d)." % (len(plot_col.plots), nrow, ncol)
TypeError: not all arguments converted during string formatting
It look that there is a problem when I over write PlotCollection object for
four different data output (or maybe not).
How can I solve the issue?
I paste my script at http://paste.yt-project.org/show/3112/ .
In addition, I would like to get more information/document about eps_writer.
For example, I would like to write the time of four phase respectively.
Where can I get the information about it?
Thank you in advance,
Jun-Hwan Choi, Ph.D.
Department of Physics and Astronomy, University of Kentucky
Tel: (859) 897-6737 Fax: (859) 323-2846
Email: jhchoi(a)pa.uky.edu URL: http://www.pa.uky.edu/~jhchoi
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,
/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 ?
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).
Hi yt Users,
I'm trying to figure out how to get yt working using an x11-based backend on my mac, so that I can forward python windows. For my non-yt python install, which is handled via macports, the trick (gleaned from http://www.astrobetter.com/remote-display-in-python-ask-astrobetter/) was to use macports to recompile the tk package so that it uses x11 rather than quartz, via the command
sudo port upgrade --enforce-variants tk -quartz +x11
This works fine. However, it is not clear to me how to force a similar change in the sandbox python install used by yt. Nor have I been able to get any other x11-based backend to work with yt's python install on my mac. The packages required for the gtk or wx backends refuse to install via pip install, and the Qt backend fails to load with the cryptic error "no module named sip".
I'd appreciate any suggestions.
I am new to yt and I am interesting in plotting a volume rendering with
output file from enzo cosmology simulation.
For the time being, I get to plot a box ; here's the result :
I would like now to plot borders of this box too like on this image :
Here's the yt script I use :
from yt.mods import *
from yt.utilities.amr_kdtree.api import AMRKDTree
from time import time
import matplotlib.colorbar as cb
# Load up your dataset
pf = load('RD00'+num+'/RedshiftOutput00'+num)
c = [0.5]*3 # Center
L = [1.0,1.0,1.0] # Viewpoint
W = na.sqrt(3) # Width
N = 768 # Pixels (512^2)
up = [0.,0.,1.]
# Get density min, max
# These might take a long time, so I'd suggest hand-coding mi, ma so
# that you don't have to find the maxima and minima each time you
# test. Note that mi, ma, should be a log value since we are
# rendering the log of density.
mi, ma = pf.h.all_data().quantities['Extrema']('Density')
mi, ma = na.log10(mi), na.log10(ma)
print mi, ma
#mi, ma = -31.0, -26.0
# Construct transfer function, pad the TF space by a bit so that
# gaussians sampling the data range don't hit the edge.
tf = ColorTransferFunction((mi-10, ma+10), nbins=1024)
# Sample transfer function with 20 gaussians. Use col_bounds keyword
# to restrict color mapping to true data range.
# Create the camera object
cam = pf.h.camera(c, L, W, (N,N), transfer_function=tf, north_vector=up,
cam.snapshot("volume_rendered%s.png" % num, clip_ratio=8.0)
Is there an option for 'camera" or "snapshot" which allows to add the
borders for this box ?
Any help would be really appreciated.
I would like to compute some spacial derivatives for FLASH4 2D cylindrical uniform grid datafile with YT.
For simplicity, I tried the example given in YT docs, although I know the derivative form is only valid for Cartesian, and this is just for code test purposes. My script are:
@derived_field(name='DivV') # I do not use ValidateSpatial… ghost_zone… because the ghost cells are not stored in FLSAH check point file
def DivV(field, data):
sl_left = slice(None,-2)
sl_right = slice(2,None)
div_fac = 2.0
ds = div_fac * data['dx'].flat
f = data["velx"][sl_right,1:-1]/ds
f -= data["vely"][sl_left ,1:-1]/ds
ds = div_fac * data['dy'].flat
f += data["velx"][1:-1,sl_right]/ds
f -= data["vely"][1:-1,sl_left]/ds
new_field = na.zeros(data["velx"].shape, dtype='float64')
new_field[1:-1,1:-1] = f
Then, if I add:
pf = load('relax_hdf5_chk_0001')
The script works, but if I use:
dd = pf.h.all_data()
and it will give error:
yt : [INFO ] 2013-01-23 21:17:01,551 Getting field dx from 256
yt : [INFO ] 2013-01-23 21:17:01,625 Getting field velx from 256
Traceback (most recent call last):
File "test.py", line 28, in <module>
File "/usr/local/yt-i386/src/yt-hg/yt/data_objects/data_containers.py", line 330, in __getitem__
File "/usr/local/yt-i386/src/yt-hg/yt/data_objects/data_containers.py", line 2607, in get_data
File "/usr/local/yt-i386/src/yt-hg/yt/data_objects/data_containers.py", line 360, in _generate_field
self[field] = self.pf.field_info[field](self)
File "/usr/local/yt-i386/src/yt-hg/yt/data_objects/field_info_container.py", line 378, in __call__
dd = self._function(self, data)
File "test.py", line 11, in DivV
f = data["velx"][sl_right,1:-1]/ds
IndexError: too many indices
Nor can I make slice plot for this field.
I would appreciate your suggestions for this issue.
I'm not having any success with off-axis projections using the
pf.h.camera() with AMRKDTree and ProjectionTransferFunction().
cam.snapshot() returns an all-zeros array, even in situations where
ColorTransferFunction() produces great images.
This script (based on the first part of amrkdtree_downsampling.py)
demonstrates the problem: http://paste.yt-project.org/show/3072/
Any ideas what's going wrong? Maybe something to do with preventing the
log'ing of the field, which I attempted to do with
Thanks for you help!
* Dr. Michael Kuhlen Theoretical Astrophysics Center *
* email: mqk(a)astro.berkeley.edu UC Berkeley *
* cell phone: (831) 588-1468 B-116 Hearst Field Annex # 3411 *
* skype username: mikekuhlen Berkeley, CA 94720 *