Mailman 3 January 2014 - yt-dev

Dev hangout summary
by Matthew Turk 16 Jan '14

16 Jan '14

Hi all, Here are the things we talked about at the hangout, and where we left them: * There are two big things codewise for 3.0 -- the rebranding, and the unit refactor. We decided it would make the most sense to land the unit refactor first, wait a couple weeks, then land the rebranding. Neither are yet done, so this is still in the future a bit. * Documentation is widely viewed as the biggest impediment to 3.0 adoption. * Nathan is going to be sending around some info about a manuscript. * We will aim for a yt 3.0 paper sometime this calendar year, but there is support for individuals to write their own papers on their own work that do not need to have lengthy author lists -- i.e., a reference paper versus a development paper. * Near-term for me: SPH, documentation, unit-refactoring. We should probably do more of these hangouts. Thanks to everybody who came! -Matt

1 0

Issue #763: Covering grid does not get filled out for a tightly nested AMR dataset (yt_analysis/yt)
by Nathan Goldbaum 16 Jan '14

16 Jan '14

New issue 763: Covering grid does not get filled out for a tightly nested AMR dataset https://bitbucket.org/yt_analysis/yt/issue/763/covering-grid-does-not-get-f… Nathan Goldbaum: While I was helping Alex Bogert out with a visualization of my galaxy dataset, we noticed some odd behavior in the covering grid. This is exposed in the HiResIsolatedGalaxy dataset on yt-project.org/data using the following script: ``` #!python from yt.mods import * pf = load('HiResIsolatedGalaxy/DD0044/DD0044') cgrid = pf.h.covering_grid(5, np.array([0.53, 0.53, 0.53]), np.array([256]*3)) print cgrid['Density'] ``` On the current 3.0 tip, this prints: ``` [[[ 4.14182811e-25 1.75059046e-28 1.29468963e-28 ..., 1.29245039e-30 1.29245039e-30 0.00000000e+00] [ 1.13112951e-24 1.50869295e-28 1.00778753e-28 ..., 1.29245039e-30 1.29245039e-30 0.00000000e+00] [ 5.55295171e-25 1.26780190e-28 7.13453664e-29 ..., 1.29245039e-30 1.29245039e-30 0.00000000e+00] ..., ``` (cut off for clarity) The zero values should not be there since this is an AMR dataset with valid data over the region covered by the covering grid. One possibly weird property of this dataset is that it's quite tightly nested, particularly near the maximum refinement level, as you can clearly see in this image: http://i.imgur.com/7kSwXJk.png No idea if the nesting is important - would love some input from someone who is more familiar with the covering grid code. FWIW, this issue only appears to be reproducible for this one dataset, I see no similar issue for `IsolatedGalaxy`, another nested AMR sim.

1 0

Issue #762: Clump finder particles issue (yt_analysis/yt)
by Caroline Van Borm 14 Jan '14

14 Jan '14

New issue 762: Clump finder particles issue https://bitbucket.org/yt_analysis/yt/issue/762/clump-finder-particles-issue Caroline Van Borm: When I try to run the clump finder on my Enzo dataset (using a script that mostly follows the find_clumps.py from the yt docs, but using a function to select gravitationally bound clumps), I get an error (see http://pastebin.com/bhmRs2R4). It seems that the clump finder is assuming there are particles in the simulation, even though there shouldn't be any. Any help on this is much appreciated! (Also, my yt version is b118390aa42c.)

1 0

Hangout on Monday, January 13
by Matthew Turk 13 Jan '14

13 Jan '14

Hi all, I'going to set up a (very low-key) hangout on Monday at 2PM EST just to have a brief catch-up on these topics: * Units * SPH * Scalability * State of documentation * My personal roadmap for next few weeks/months * Pending YTEPs and PRs * Other business For the most part, I plan to use this time to update others on my own progress on various things we've talked about here and elsewhere; I know that some other projects are blocked on my own progress, and I want to update people on that. If you don't think you can make it, don't move heaven and earth to do so! But if you can, it'd be good to catch up. -Matt

2 2

Issue #761: SlicePlot ".save()" stores image in plotfile directory, not current directory (yt_analysis/yt)
by Michael Zingale 11 Jan '14

11 Jan '14

New issue 761: SlicePlot ".save()" stores image in plotfile directory, not current directory https://bitbucket.org/yt_analysis/yt/issue/761/sliceplot-save-stores-image-… Michael Zingale: When creating an image via "SlicePlot" of BoxLib data, the resulting image is stored in the plotfile directory, not the current directory. E.g.: pf = load("plt23437") SlicePlot(pf, 'x', "Density").save() creates the image "plt23437/plt23437_Slice_x_Density.png", when it should output simply to the present directory (creating the image "plt23437_Slice_x_Density.png"). This bug is likely because this part of yt doesn't recognize that BoxLib plotfiles are directories.

1 0

Refactor of the refactor
by Matthew Turk 10 Jan '14

10 Jan '14

Hi all, Nathan posted an update to YTEP-0011, where he describes some changes he's implemented in a PR to my repository to modify the unit refactor. Comments would be appreciated! https://bitbucket.org/yt_analysis/ytep/pull-request/32/updating-the-units-y… https://bitbucket.org/MatthewTurk/yt/pull-request/25/unit-system-refactor -Matt

2 1

Issue #760: Narrative docs needed for cosmology calculator (yt_analysis/yt)
by Britton Smith 06 Jan '14

06 Jan '14

New issue 760: Narrative docs needed for cosmology calculator https://bitbucket.org/yt_analysis/yt/issue/760/narrative-docs-needed-for-co… Britton Smith: A brief description of the various cosmology calculator functions should be added to the docs. Responsible: brittonsmith

1 0

Issue #759: Links to cookbook recipes are broken (yt_analysis/yt)
by Nathan Goldbaum 06 Jan '14

06 Jan '14

New issue 759: Links to cookbook recipes are broken https://bitbucket.org/yt_analysis/yt/issue/759/links-to-cookbook-recipes-ar… Nathan Goldbaum: The links to the python scripts for each of the cookbook recipes are broken. For example, this URL returns a blank page: http://yt-project.org/docs/dev/cookbook/multi_width_image.py

1 0

Issue #758: VRs are transposed relative to projections (yt_analysis/yt)
by Cameron Hummels 04 Jan '14

04 Jan '14

New issue 758: VRs are transposed relative to projections https://bitbucket.org/yt_analysis/yt/issue/758/vrs-are-transposed-relative-… Cameron Hummels: It appears that at some point the volume rendering interface underwent a transpose relative to the PlotWindow interface. When I make a simple VR with normal vector (0,0,1), that is, along the z vector, and compare it against a projection along the z vector, I get out two tranposed images. https://hub.yt-project.org/nb/gsob7g I know I have used these two different pieces of machinery together in the distant past without problems, so I guess we just got our wires crossed somewhere. I'm happy to change it in the VR interface, but I'm afraid that the reason it was swapped was for some other piece of interface to be accurate, and so this may break that...

1 0

Update on Windows
by John Zuhone 01 Jan '14

01 Jan '14

Hi all, Good news on the Windows/yt front. I'm happy to announce that as of right now only one unit test is failing. The failure is subtle, but I thought I would run it by you all to see what we should do about it. The failure in question is a comparison test in yt/utilities/tests/test_units.py, in "test_power": assert u2.cgs_value == (pc_cgs**2 * mK_cgs**4)**2 basically, the unit cgs_value is exactly the combination of these factors, so even though they are floats, one would expect that the equality should hold, and on our other platforms it does. However, on Windows, the comparison is failing on the last digit, with a relative difference of ~4e-16 between the two values. So, while I'm not inclined to be very concerned about it, I'm curious to see what you guys think about how it should be handled. Happy New Year! John Z -- John ZuHone Postdoctoral Researcher NASA/Goddard Space Flight Center jzuhone(a)gmail.com john.zuhone(a)nasa.gov

4 4