Mailman 3 July 2016 - yt-dev

Issue #1246: Mjup/cm**3 can't be used as a unit for density (yt_analysis/yt)
by Matthew Turk July 20, 2016

July 20, 2016

New issue 1246: Mjup/cm**3 can't be used as a unit for density https://bitbucket.org/yt_analysis/yt/issues/1246/mjup-cm-3-cant-be-used-as-… Matthew Turk: This script: ``` import yt ds = yt.load("data/IsolatedGalaxy/galaxy0030/galaxy0030") p = ds.r[0.5,:,:].plot("density") p.set_unit("density", "Mjup/cm**3") ``` (`.plot()` only works in the notebook evidently) results in this traceback: ``` --------------------------------------------------------------------------- ValueError … [View More]

1 0

yt sprint at SciPy 2016: looking for in-person and remote participants
by Nathan Goldbaum July 17, 2016

July 17, 2016

Hi all, 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 here: http://scipy2016.scipy.org/ehome/146062/332969/ 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 … [View More]

1 1

Issue #1245: ellipsoidal halo analysis is broken (yt_analysis/yt)
by Britton Smith July 16, 2016

July 16, 2016

New issue 1245: ellipsoidal halo analysis is broken https://bitbucket.org/yt_analysis/yt/issues/1245/ellipsoidal-halo-analysis-… Britton Smith: 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 … [View More]

1 0

Issue #1244: Reading Gadget2 outputs with SnapFormat=2. (yt_analysis/yt)
by Erwin Tin-Hay Lau July 15, 2016

July 15, 2016

New issue 1244: Reading Gadget2 outputs with SnapFormat=2. https://bitbucket.org/yt_analysis/yt/issues/1244/reading-gadget2-outputs-wi… Erwin Tin-Hay Lau: Are there any plans to read Gadget2 outputs with SnapFormat=2? Right now it only accepts SnapFormat=1 or HDF5 format.

1 0

Issue #1243: ds.r can sometimes retain state (yt_analysis/yt)
by Matthew Turk July 13, 2016

July 13, 2016

New issue 1243: ds.r can sometimes retain state https://bitbucket.org/yt_analysis/yt/issues/1243/dsr-can-sometimes-retain-s… Matthew Turk: Still working on a repro, but it looks like the `.all_data` / `._all_data` attribute can sometimes retain state.

1 0

Issue #1242: SlicePlot & ProjectionPlot show all zero field (yt_analysis/yt)
by Bili Dong July 12, 2016

July 12, 2016

New issue 1242: SlicePlot & ProjectionPlot show all zero field https://bitbucket.org/yt_analysis/yt/issues/1242/sliceplot-projectionplot-s… Bili Dong: 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: ``` #!python import yt ds = yt.load('FIRE_M12i_ref11/snapshot_600.hdf5') dmax, dcenter = ds.find_max(('PartType0', 'Density')) p = yt.SlicePlot(… [View More]

1 0

Issue #1241: Installation with conda (yt_analysis/yt)
by Anonymous July 12, 2016

July 12, 2016

New issue 1241: Installation with conda https://bitbucket.org/yt_analysis/yt/issues/1241/installation-with-conda Anonymous: I tried to install the development version of yt but I failed. Settings: INST_CONDA=1 INST_YT_SOURCE=1 INST_ROCKSTAR=1 INST_SCIPY=1 INST_H5PY=1 INST_ASTROPY=0 INST_NOSE=1 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/… [View More]lib/ Removing old build environment BUILD START: rockstar-1.0.0-0 Package: rockstar-1.0.0-0 source tree in: /home/mmestre/ytProject/yt-conda/conda-bld/work number of files: 1 Fixing permissions patchelf: file: /home/mmestre/ytProject/yt-conda/envs/_build/lib/librockstar.so setting rpath to: $ORIGIN/. Fixing permissions 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 EXECUTING: 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: https://github.com/conda/conda/issues 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> sys.exit(main()) 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 index.update(get_index(**index_args)) 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[0] KeyError: 0 --------------------------- [View Less]

1 0

Example notebooks
by Matthew Turk July 11, 2016

July 11, 2016

Hi folks, 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 well. Thanks! -Matt

4 5

Volume Rendering API is very complicated when doing non-default things
by Nathan Goldbaum July 10, 2016

July 10, 2016

Hi all, tl;dr: 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: https://bitbucket.org/yt_analysis/yt/issues/1234/volume-rendering-example-i… This refers to an example in our documentation that uses the old volume rendering API to make a very pretty image. … [View More]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: https://bpaste.net/show/58194a5a1352 And here's what I did to make the same image using the new volume rendering interface: https://bpaste.net/show/9fba5872e532 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. -Nathan [View Less]

5 7

Issue #1240: Type issues with grids (yt_analysis/yt)
by sspickle July 9, 2016

July 9, 2016

New issue 1240: Type issues with grids https://bitbucket.org/yt_analysis/yt/issues/1240/type-issues-with-grids sspickle: 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: camera.py:326 lines(nim.d, px.d.astype('int64'), py.d.astype('int64'), colors, 24, flip=1) See attached email dialog with Nathan Goldbaum.

1 0