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 downloaded the example script of light cone projectoin(
to my laptop and changed the Enzo simulation parameter file and redshifts.
But when I ran it the following error occurred:
File "light_cone_projection.py", line 19, in <module>
line 158, in __init__
line 44, in __init__
File "/Users/madcpf/Documents/dev_yt/src/yt-hg/yt/convenience.py", line
131, in simulation
line 81, in __init__
line 343, in __init__
line 273, in _parse_parameter_file
param, vals = (i.strip() for i in line.split("="))
ValueError: need more than 1 value to unpack
Does the parameters "near_redshift" and "far_redshift" in LightCone need to
be the same with "CosmologyFinalRedshift" and "CosmologyInitialRedshift" in
enzo parameter file?
Does anyone know how to solve this?
Thank you all!
Hello fellow yt'ers:
I'm having some issues with some fields that I don't think are behaving the
way they should be in yt. I'm encountering a number of problems with a
simple 2D enzo dataset (x and y), so I put together a notebook
demonstrating my various issues.
To summarize the weirdness from the notebook:
1) The 'dx' field doesn't seem to be able to be displayed (i.e. when I try
to slice it), whereas the 'dy' field is fine. 'dz' even exists, but it's
just uniformly 0, as is expected from a 2D dataset.
2) When I try to produce a new field which is 2^GridLevel, I get weird
results (ignored levels and more).
3-5) I get strange behavior when trying to make a new field combining
GridLevel and 'dy', since GridLevel has twice as many indices as any of
the spatial fields (in the z direction no less). This results in some odd
behavior when I try to pair various subsets of GridLevel with 'dy'.
Any clarification of these ideas is welcome. The docs and source haven't
yet revealed what is going on here. Thanks!
University of Arizona
I noticed in the update log of yt-3.0 you can now read Gadget HDF5 format
(for OWLS project), but it is possible for Rockstar to read the exact same
formats? I have some HDF5 data and I'd like to run Rockstar on it through
yt if it has this capability in 3.0.
Are there any examples of carrying out such a process? Thanks.
Today we launched a completely redesigned yt website. It's still at
yt-project.org, but with a completely new look. One of the brand new
features is the yt Gallery (http://yt-project.org/gallery.html). The
gallery is designed to show off examples of yt in the real world and to
give new users an idea of all that's possible.
We have a few really nice contributions up there now, but we want many
more! If you have a figure made at least in part with yt that you're
particularly proud from a paper, poster, talk, press release, or just
something really cool, please consider submitting it to the gallery. To
add something to the gallery, simply fork the yt website repository here:
Then, add your image (400 pixels wide, preferably) to the directory
img/gallery, add an entry to the gallery.html file, and submit a pull
request. We will also accept embedded movies from vimeo or youtube. Make
sure to add a caption with a brief explanation of the figure, what
functionality you used to make it, and a citation if it appears in a
publication. Also, make sure to add your figure to the top of the gallery
page so it's easy to see what's new.
We look forward to seeing what amazing things people have done!
I want to divide ENZO simulation into certain regions, do some operation
and save some files in parallel. I used parallel_objects for this.
If I use openMPI and do
$mpirun -np 6 python script.py --parallel
it works fine.
But if I use MPT(a variety of MPICH, I think) and run the exact same
it ignores --parallel and just does things in serial.
Is this expected? I'm new to parallel computation, and kind of stuck here.
Thanks for your help.
I am in the process of moving most of my visualisation scripts from
PlotCollection to the PlotWindow interface. One feature that now I am not
able to find is the capability of customising the tick values in the colorbar
of a plot. Inspired by the example script found in
I was thinking about interacting with a matplotlib object directly, but I am
not able to find a suitable one. Could you please suggest me a workaround for
Thanks in advance,
Universität Heidelberg, Zentrum für Astronomie
Institut für Theoretische Astrophysik
Philosophenweg 12, D-69120 Heidelberg, Germany
Tel: +49 6221 548983, Fax: +49 6221 544221
Dear yt users,
I am running a binary star simulation with enzo, and in my box there is a
star made up of a gas envelope and a particle as core, and a secondary star
represented by a single particle (no gas).
I would like to plot the equipotential surfaces of the system on a slice
plot, hence, since the default Grav_Potential field does not include the
particles potential, I created a custom made field as follows:
* def _Total_Grav_Potential(field,data): *
* #G in cgs*
* grav_const_cgs = 6.674e-8*
* #data for gas*
* gas_grav_potential_cgs = data['Grav_Potential'] *
(length_unit1/time_unit1)**2.0 #in units of velocity^2*
* gas_position_x_cgs = data['x'] * length_unit1*
* gas_position_y_cgs = data['y'] * length_unit1*
* gas_position_z_cgs = data['z'] * length_unit1*
* #initialize the array for the total grav potential to the gas grav
* total_grav_potential_cgs = gas_grav_potential_cgs*
* #loops on the particles*
* for i in range(len(data['ParticleMassMsun'])):*
* #data of the current particle*
* current_particle_mass_cgs= data['ParticleMassMsun'][i] * mass_unit*
* current_particle_position_x_cgs = data['particle_position_x'][i] *
* current_particle_position_y_cgs = data['particle_position_y'][i] *
* current_particle_position_z_cgs = data['particle_position_z'][i] *
* #computes the array of grav potential for the current particle*
* current_particle_grav_potential_cgs = -(grav_const_cgs *
current_particle_position_x_cgs)**2.0 + (gas_position_y_cgs -
current_particle_position_y_cgs)**2.0 + (gas_position_z_cgs -
* #adds the current particle potential to the total potential*
* total_grav_potential_cgs = total_grav_potential_cgs +
* return total_grav_potential_cgs*
* #adds the field to the available yt fields*
* add_field("Total_Grav_Potential", function=_Total_Grav_Potential,
where the length unit and time unit variables have the function to convert
my quantities in cgs.
If I then call my "Total_Grav_Potential" field, I get reasonable values,
but when I try to inspect the shape of the equipotential surfaces on the
xy-plane by plotting the following:
* sp = SlicePlot(pf, 'z', "Density", width = 1.0)*
* sp.annotate_velocity(factor=16, normalize=True)*
* sp.annotate_particles(1.0, p_size=50.0, marker='o', col='black')*
* sp.annotate_text((0.7,1.05), "time = "+str(pf.current_time)+"yr") *
nothing happens, and the plot does not show any additional contour; while
if I do the same with the default "Grav_Potential" field, the gas
equipotential contours get plotted without problems.
I also tried to play with the "annotate_contour" options "ncont", "factor"
and "clim" to refine my plot but the result is always the same.
Additionally, if I do not set the "clim" option the following error shows
*ValueError: zero-size array to minimum.reduce without identity*
I would like to ask if my custom definition of the Total_Grav_Potential
field is correct from a yt coding point of view and if I should modify it
(or if there is any improvement I can do).
Also, I would like to ask if you have any idea of what could be the problem
with the plotting.
Thanks for the help,