hello,i would like to attend this workshop i talk to my my professor (joel
primack) and he said we will keep in touch with me as of what time will it
be today, i know is in room 102 usb. he also told me is not open for the
public hence i contact directly to you.
---------- Forwarded message ----------
From: "Perry Greenfield" <stsci.perry(a)gmail.com>
Date: Mar 20, 2014 1:33 PM
Subject: [astropy-dev] OT: job opening at STScI
To: <astropy-dev(a)googlegroups.com>, "Discussion of Numerical Python" <
numpy-discussion(a)scipy.org>, "SciPy Developers List" <scipy-dev(a)scipy.org>
The Science Software Branch at the Space Telescope Science Institute is
seeking a developer that enjoys and is good at digging into and
understanding the details of Python internals and its
libraries--particularly those related to scientific computing--in order to
support of our development of software tools for Python and the
astronomical community, particularly for the Hubble Space Telescope and the
next telescope under construction (JWST).
Details on the position and how to apply can be found at this link:
(applications are still being taken despite the date given...)
You received this message because you are subscribed to the Google Groups
To unsubscribe from this group and stop receiving emails from it, send an
email to astropy-dev+unsubscribe(a)googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I’m working on FLASH 3D Cartesian AMR data, and would like to define a derived field of surface density, so I can use surface density field to calculate other derived fields.
My current script does give desired results (slice_y: http://i.imgur.com/XigIYJc.png slice_z: http://i.imgur.com/kA2Fmlt.png, and the disk is cut from original data). However, it’s extremely inefficient, because I cast a ray through disk height for every cells located on x-y plane surface of each AMR block.
So is there any clever way to define surface density as a derived field in YT, as what the figures attached show? Or some way without defining surface density as a derived field, but I can get access to surface density values when computing other derived fields?
Thanks a lot!
Department of Physics
University of California, Santa Barbara
CA 93106, USA
I'm working on a script to calculate star formation rates for halos in
different mass bins from Enzo simulation ouput. As part of the script, I
need to access the dynamical_time values for all of the star particles
associated with a given halo. The halos have been previously stored to
disk, so I'm loading them with LoadHaloes and then for each halo
identifying the star particles with the typical
stars = halo["creation_time"] > 0
mask. When I try to get the associated dynamical times with
I get -99999. instead of the expected values. When I perform the same
operation on the entire dataset instead of an individual halo I get the
correct dynamical times, so the values I want do exist. I was testing out
different fields with
to see if I could find any patterns, and I noticed that for all the fields
that are actually saved to disk for the halos (creation_time,
ParticleMassMsun, particle_positions, etc.) I get values that match those
in the halo hdf5 files. However, this is not true for "particle_index",
where I get incorrect values. The values do correspond to particles in the
halo, but they aren't the indices of the star particles. I'm not sure, but
I assume this is why I'm getting incorrect values for dynamical_time which
isn't saved in the halo hdf5 files. I'm not familiar enough with the code
for the halo finder to know where to start looking for the source of this
problem. Does anyone with more experience have an idea? My version of yt is
a copy of 2.6.1 that I updated about 3 weeks ago. Thanks.
Here is the error as outputted.
gcc -fPIC -c blocksort.c
make: gcc: No such file or directory
make: *** [blocksort.o] Error 1
How can I fix this? I have OSX Mavericks 10.9.1.
I have Xcode and Command Line Tools installed. What am I doing wrong?
I'm just starting to use IPython notebooks, but I don't seem to be able
to get profile plots to show. Projection plots and phase plots show up
fine, though. This is the error I'm getting:
NameError Traceback (most recent call last)
1 p= ProfilePlot(sphere, "Radiuspc", ["NumberDensity"], weight_field="CellMassMsun")
----> 2 p.show()
--> 276 if "__IPYTHON__" in dir(__builtin__):
277 api_version= get_ipython_api_version()
278 if api_versionin ('0.10', '0.11'):
NameError: global name '__builtin__' is not defined
My yt version is ec9a5117fc08. Does anyone know what is happening here?
We have been working on some exciting new features that will be appearing
soon in the bleeding edge of yt, known as yt-3.0. For those of you that
don't know, yt-3.0 is a complete redesign of the underlying machinery to
more flexible, less astronomy-specific, and to better support more
simulation codes, such as Gadget. yt-3.0 is currently in alpha, and is
available as the "bleeding edge" install from the yt website. For those of
you more familiar with mercurial, we have also put a "development" bookmark
on this version.
In addition to this development version, we have now also added an
"experimental" bookmark. This is where brand new features will go while
they get their final polish from additional testing and documentation. The
experimental version now contains two very interesting new features:
1. *Symbolic Units*
All numeric values in yt are now aware of their units. Units are expressed
symbolically, so for example, a density can be in "g/cm**3" or
"Msun/Mpc**3", or any combination of a mass unit and three inverse length
units. Nathan Goldbaum has put together an excellent tutorial of the new
units system which can be found
With this functionality also comes an effort to generalize field names.
For example, the "Density" field should now be accessed as either
"density" or ("gas", "density"). The second example is a step toward
supporting multifluid codes. Additionally, we have restructured some of
the machinery to make it more intuitive. For example, data containers like
"sphere", which were previously accessible as pf.h.sphere, can now also be
accessed as pf.sphere.
2. *Halo Analysis*
This is a new framework for analyzing cosmological halos that will replace
the separate HaloFinder, HaloProfiler, and other halo analysis tools. This
is significantly more flexible than the existing halo analysis and will
make custom analysis much easier. For more information, see the enhancement
WE NEED YOUR HELP!
While these features have received a decent amount of testing, more is
necessary, especially for the new unit system. We particularly need to
make sure the unit system works properly with all the simulation codes.
Also, documentation is being created for these features now, but it would
be very helpful to get additional feedback. The documentation for yt-3.0
can be found here <http://yt-project.org/docs/dev-3.0/>. Please let us
know what you think!
To install the experimental version, all you have to do is go into your yt
source and do the following:
hg up experimental
python setup.py develop
We hope you like these new features and are grateful for feedback.
on behalf of the yt development team.
Is it possible to overlay a phase plot
(pp = PhasePlot(my_galaxy, "Density", "Temp", "CellMassMsun",weight_field=None))
with the contour lines? (So that if it’s printed in black and white, then it would be clearer)