Mailman 3 February 2014 - yt-dev

Issue #779: Iterating over a time series is substantially slower in unitrefactor (yt_analysis/yt)
by Nathan Goldbaum Feb. 11, 2014

Feb. 11, 2014

New issue 779: Iterating over a time series is substantially slower in unitrefactor https://bitbucket.org/yt_analysis/yt/issue/779/iterating-over-a-time-series… Nathan Goldbaum: This came up when I noticed time series iteration seemed slow. The script I'm using to test this is here: It loops over a list of enzo outputs, finds an active particle, and prints out its mass. I've attached the raw cProfile traces to this issue and have uploaded pyprof2html visualizations of the data to my … [View More]

1 0

Reason, PlotCollection and yt-3.0
by Nathan Goldbaum Feb. 10, 2014

Feb. 10, 2014

Hi all, I want to raise the possibility of removing the PlotCollection and Reason code from yt before the 3.0 release. I haven't checked recently but given the changes in yt since they were last updated, both features likely do not work correctly right now. Given the move to notebooks* and PlotWindow-style plotting going forward, I think now is the time to rip off the bandage and remove the code. It's likely some of the gui code can be repurposed for a widget, but that doesn't mean reason as … [View More]

7 7

Announcement: 2014 UC-HIPACC yt workshop, March 23-25
by Matthew Turk Feb. 10, 2014

Feb. 10, 2014

Dear Colleagues, We are proud to officially announce the upcoming 2014 yt developer workshop. This three day event, to be held on the campus of the University of California, Santa Cruz on Sunday March 23rd through Tuesday March 25th, will bring together a diverse group of students, researchers, and developers. While past workshops have been broad in scope, this workshop will be focused on advancing the goals of yt 3.0 in tandem with the goals of the AGORA project. The four primary goals of … [View More]

1 0

Merging the unit refactor
by Matthew Turk Feb. 10, 2014

Feb. 10, 2014

Hi everyone, I've done a lot of thinking and talking with people about the idea of merging the units stuff into the mainline yt 3.0 branch. There are clear advantages to doing this: people who want to use SPH smoothing would be able to get it from the primary repository, PRs could be done through that repository, and the access to new things would be considerably easier. More public development and review could happen; while the development already *is* public, it's out of view in my fork of … [View More]yt. This is not productive. But the development of yt is not the point of yt. Using yt to enable scientific discovery is the point of yt. In many ways, the units refactor will enable more scientific discovery. But it's not ready. There are people using yt-3.0 *already* (prime example: http://nickolas1.com/d3test2/ ) to do really cool science in ways that they can't with 2.x. And they're doing this with a yt that *mostly* works like the 2.x branch, with the same field names and units and all of that, so the docs *mostly* apply. The units refactor, if merged in, would pull the rug *completely* out from under them. And there's no safety net. There's a web of YTEPs and PR comments and notebooks posted to mailing lists, but there's no place they can go and see, "Hey, this worked before, why isn't it now?" And that's not okay. I've long put off writing documentation, and honestly, I could come up with lots more reasons to put it off. But I started on Wednesday actually writing things down in earnest, and I think that needs to be the next big push, which I am committed to doing. Yeah, it's not that fun always. Especially since things *are* still changing. But it's not fair -- and it is certainly not in the spirit of *extreme empathy* -- to just change things. But I also want new development to continue. And so I want a balance to be struck. I'd like to enumerate the items that are necessary for documentation so that we can merge it in. I think these are as follows: * All notebooks should be ported to the 3.0 docs and unit-refactor style * API documentation has to be able to be compiled * At a *bare* minimum, a list of stumbling blocks has to be included for moving to 3.0. Britton and I have started on this and made very good progress. * We need a bookmark or tag to be included in the repo *pre*-refactor. * Cookbook recipes must work (I think they mostly do now) Things I don't think we need to do before merging: * Completely update 100% of the narrative docs * Document how to add smoothing fields, as I believe this API is in flux * Describe the underlying methods in great, extensive detail for the new frontends * A full, complete review of the docs like we did in advance of 2.6 As a thought, why don't we treat documentation the way we treat code? Within the project, it seems we're comfortable committing and submitting work-in-progress code, but not docs. In the past, perhaps this was because the PRs and repos were separate. They aren't anymore. How does this proposal for the merge sound? Please render an opinion, as I'd like to have this settled before the early part of next week. Thanks everyone, Matt [View Less]

6 10

Issue #778: Progressbar can be a bit heavy in the notebook (yt_analysis/yt)
by Matthew Turk Feb. 9, 2014

Feb. 9, 2014

New issue 778: Progressbar can be a bit heavy in the notebook https://bitbucket.org/yt_analysis/yt/issue/778/progressbar-can-be-a-bit-hea… Matthew Turk: I think the progressbar, particularly for lightweight operations, can be a bit heavy in the notebook. Additionally, because of how widgets work, it can leave a *lot* of data in the notebook itself once it has concluded. To see this in action, the time series calculations in the bootcamp are a good example. In the past, we've put a minimum … [View More]

1 0

Issue #777: Halo objects are not unit-aware (yt_analysis/yt)
by Matthew Turk Feb. 8, 2014

Feb. 8, 2014

New issue 777: Halo objects are not unit-aware https://bitbucket.org/yt_analysis/yt/issue/777/halo-objects-are-not-unit-aw… Matthew Turk: Things like the center-of-mass computation are not unit aware and currently break. Responsible: MatthewTurk

1 0

Loading data in spherical polar coordinates
by Mani Chandra Feb. 8, 2014

Feb. 8, 2014

Hi Everyone, I have data which is in spherical polar coordinates, so basically rho(r, theta, phi) and I can't seem to find an appropriate interface in yt to load the data with. Is there a function that can do that? If not, is there a function that takes in as an argument the (x,y,z) coordinate for each data point that I want to plot? i.e. take in as an argument, a 3D array which is the full grid. The current interface only seems to take in the bounding box. Thanks, Mani

3 2

Issue #776: Getting things into units is not easy (yt_analysis/yt)
by Matthew Turk Feb. 7, 2014

Feb. 7, 2014

New issue 776: Getting things into units is not easy https://bitbucket.org/yt_analysis/yt/issue/776/getting-things-into-units-is… Matthew Turk: We should have an easier way to get things into units. This currently fails (which is an actual bug): ``` #!python UnitFulObject - 1.0 * UnitFulObject.units ``` But in general, we need an easier way to manage times where the units are tricky, or nasty, or whatever. It would be nice to have something *like* dimensionless that is a "passthrough unit.… [View More]

1 0

Metallicity units
by Nathan Goldbaum Feb. 7, 2014

Feb. 7, 2014

Hi all, I've updated the metallicity units PR: https://bitbucket.org/MatthewTurk/yt/pull-request/38/fixing-cgs-unit-conver… I ended up deciding that metallicity doesn't really make much sense as a dimension in the unit system. Instead, I've made it so the `code_metallicity` and `Zsun` units are dimensionless. Here's an example run using the tip of the PR which illustrates why this is a nice choice: First, load the data: >>> pf = load('HiResIsolatedGalaxy/DD0044/DD0044') >>&… [View More]

2 1

Speeding up isocontour flux extraction
by Nathan Goldbaum Feb. 7, 2014

Feb. 7, 2014

Hi all, I'm curious if there might be a way to speed up isocontour flux extraction for my dataset. Profiling my isocontour extraction script, it seems about 2/3 of the time is spent generating ghost zones, with the rest in march_cubes_grid_flux. This dataset might be suboptimal for this sort of thing as there is a large number of relatively small grids, so any operation that loops over grids or generates ghost zones is going to be a bit slow. Would generating a covering grid and then doing … [View More]

1 0