I will be organizing the yt sprint at the 2016 SciPy conference in Austin
Texas, July 16-17. More information about the SciPy sprints is available
The main focus of this sprint will be resolving open issues for the yt 3.3
release. My hope is to be able to release yt 3.3 at the end of the sprint
or shortly afterwards.
If you are coming to the SciPy conference or are local to Austin and are
interested in participating, please feel free to drop by the sprints or
e-mail me off list with questions or concerns. We will be assigned an area
to work with tables, power outlets, snacks and coffee by the SciPy
organizers the morning of the 16th.
Even if you do not want to work on issues for yt 3.3, we're more than happy
to answer questions or offer help for contributing to yt and modifying yt
for your purposes. The conference will be happening at the AT&T conference
center on the southwest corner of the University of Texas campus.
I'd also like to encourage remote participation in this sprint. This will
proceed much like our last remote sprint - sprinters will login to the yt
slack and we will coordinate efforts there. If you would like access to the
yt slack, message me off list and I will send you an invite.
Hoping to see and hear from many of you next week :)
New issue 1245: ellipsoidal halo analysis is broken
The ellipsoidal halo analysis example in the docs does not work. It appears to be a simple a units error that can probably be fixed easily. That said, this code is untested and only exists within the yt-2.x era halo finding framework. This function needs to be ported into a recipe or callback function that works with the `HaloCatalog` if it's going to be usable. For now, I am going to leave a note in the docs that it is currently broken.
New issue 1242: SlicePlot & ProjectionPlot show all zero field
I just updated to the development tip (3.3_dev-py27_2755 as shown in conda), and suddenly the SlicePlot (and similarly the ProjectionPlot) doesn't work properly. When I run the following code:
ds = yt.load('FIRE_M12i_ref11/snapshot_600.hdf5')
dmax, dcenter = ds.find_max(('PartType0', 'Density'))
p = yt.SlicePlot(ds, 'z', ('gas', 'density'), center=dcenter, width=(1, 'Mpc'))
I get the following plot:
The code used to work with previous version of yt, so I'm wondering if it's only me or there is a bug.
New issue 1241: Installation with conda
I tried to install the development version of yt
but I failed.
The last lines of the log file are below.
+ mkdir /home/mmestre/ytProject/yt-conda/envs/_build/lib
+ cp librockstar.so /home/mmestre/ytProject/yt-conda/envs/_build/lib/
Removing old build environment
BUILD START: rockstar-1.0.0-0
source tree in: /home/mmestre/ytProject/yt-conda/conda-bld/work
number of files: 1
patchelf: file: /home/mmestre/ytProject/yt-conda/envs/_build/lib/librockstar.so
setting rpath to: $ORIGIN/.
BUILD END: rockstar-1.0.0-0
Nothing to test for: rockstar-1.0.0-0
# If you want to upload this package to anaconda.org later, type:
# $ anaconda upload /home/mmestre/ytProject/yt-conda/conda-bld/linux-64/rockstar-1.0.0-0.tar.bz2
# To have conda build upload to anaconda.org automatically, use
# $ conda config --set anaconda_upload yes
conda install /home/mmestre/ytProject/yt-conda/conda-bld/linux-64/rockstar-1.0.0-0.tar.bz2
An unexpected error has occurred, please consider sending the
following traceback to the conda GitHub issue tracker at:
Include the output of the command 'conda info' in your report.
Traceback (most recent call last):
File "/home/mmestre/ytProject/yt-conda/bin/conda", line 6, in <module>
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/cli/main.py", line 120, in main
exit_code = args_func(args, p)
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/cli/main.py", line 130, in args_func
exit_code = args.func(args, p)
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/cli/main_install.py", line 69, in execute
install(args, parser, 'install')
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/cli/install.py", line 203, in install
explicit(args.packages, prefix, verbose=not args.quiet)
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/misc.py", line 126, in explicit
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/api.py", line 22, in get_index
channel_urls = normalize_urls(channel_urls, platform, offline)
File "/home/mmestre/ytProject/yt-conda/lib/python2.7/site-packages/conda/config.py", line 250, in normalize_urls
url = urls
I'm giving a talk at SciPy on Wednesday. In prep for that, I'd like
to get some neat notebooks showing off 3.3 features on the Hub (
https://hub.yt/ ) so that people in the audience can try things out.
If you have one, or are willing to make one, let me know -- or just
upload it to the hub and send the the location. Anything sizzle-y
would be awesome. We can publicize these for the 3.3 release, as
I have a high-level issue with the volume rendering API. I think there are
some simple things that can be done to make it simpler to use, but I'm not
sure how much work it will take to get us there.
Today I was looking at issue #1234:
This refers to an example in our documentation that uses the old volume
rendering API to make a very pretty image. I wanted to retain that image,
which led me to try to make a fully customized volume rendering using the
new interface for the first time, and it left me very confused. If I was
completely unfamiliar with yt internals and not comfortable looking at the
yt source code, I don't think I would have been able to successfully
recreate the image using the new API.
To make that concrete, here's how you would construct the volume rendering
using the old interface:
And here's what I did to make the same image using the new volume rendering
Three lines of code in the old interface expand into 26 lines of code in
the new interface. I also need to do scary-looking undocumented things like
manually creating an AMRKDTree to be able to get the field logging setting
I wanted. I also need to know about what's going on under the hood in the
VolumeSource class since I wanted to avoid setting auto=True, which does a
lot of basic setup, but also does some unnecessary computation.
That said, some of the additional boilerplate constitutes an improvement in
clarity. For example, I like how I'm setting camera attributes now instead
of setting keyword arguments in the Camera initializer.
The main problem I see is that the VR interface attempts to do too much
"magic" by default. If auto=True is set when the VolumeSource is created,
an AMRKDTree is constructed, fields to render are set, whether or not the
rendering happens in log space is determined by looking at the take_log
setting in the FieldInfo, and a transfer function is created based on a
TransferFunctionHelper instance. If auto=False, it's not clear about how
one sets this stuff up without looking carefully at what happens inside the
VolumeSource code when auto=True.
It would be nice if there were a better story in the auto=False universe.
For example, the VolumeSource object could grow a way to *automatically*
create AMRKDtree instances when needed, after a user sets the field to
render and sets which fields should be rendered in log space. This is
almost possible in the current API, but the VolumeSource object would need
to grow an API that allows the user to control the field logging behavior -
right now this is only controllable at the level of the AMRKDTree object.
I'm curious whether anyone has suggestions or ideas for ways forward on
this. Is this a documentation problem (i.e. do we just need to add a ton of
examples where we do customized volume renderings in a somewhat baroque but
very explicitt style) or indicative of deeper issues with the new VR
interface? Should the issues I'm raising be dealt with before we release yt
3.3 or could we patch it afterwards?
All that said, I don't particularly want to embark on a several weeks-long
yak-shaving expedition in the volume rendering code and I can't volunteer
to lead any kind of overhaul. I am willing to make small usability
improvements, though, if that's what we decide we should do.
Hope that wasn't too much of a novel, I'd love to hear comments about this.
New issue 1240: Type issues with grids
On windows the attached YT_Check.py program fails in the 'draw_grids' call. If I force the grid coordinates to int64 it seems to work:
lines(nim.d, px.d.astype('int64'), py.d.astype('int64'), colors, 24, flip=1)
See attached email dialog with Nathan Goldbaum.