Mailman 3 February 2013 - yt-dev

Emails from BitBucket about Pull Requests
by Matthew Turk 25 Feb '13

25 Feb '13

Hi everyone in yt and Enzo lands, BitBucket just changed how notifications are handled: http://blog.bitbucket.org/2013/02/25/pull-requests-now-with-reviewers-and-s… This seems like a good step in the right direction. So, if you've been getting *too many* emails about pull requests, or if you've been getting *not enough* emails, this change will help. -Matt

1 0

[yt_analysis/yt] SlicePlot fails in parallel with multiple fields when one of which is a derived fields (issue #511)
by Sam Skillman 23 Feb '13

23 Feb '13

--- you can reply above this line --- New issue 511: SlicePlot fails in parallel with multiple fields when one of which is a derived fields https://bitbucket.org/yt_analysis/yt/issue/511/sliceplot-fails-in-parallel-… Sam Skillman: If I only do ['Density'], or ['Pressure'], or even ['Density', 'Temperature'], this is fine. Something seems messed up with the derived field. FWIW, ProjectionPlot works fine. mpirun -np 2 python script.py --parallel ``` #!python from yt.mods import * pf = load('IsolatedGalaxy/galaxy0030/galaxy0030') field = ['Density','Pressure'] slc = SlicePlot(pf, 'z', field) slc.save() ``` gives: ``` #!text P001 yt : [DEBUG ] 2013-02-23 15:55:18,394 Appending object to galaxy0030 (type: <class 'yt.data_objects.hierarchy.AMRSlice'>) Traceback (most recent call last): File "dummy_script.py", line 6, in <module> slc = SlicePlot(pf, 'z', field) File "/home/skillman/local/src/yt-hg/yt/visualization/plot_window.py", line 1134, in __init__ Traceback (most recent call last): File "dummy_script.py", line 6, in <module> slc = SlicePlot(pf, 'z', field) File "/home/skillman/local/src/yt-hg/yt/visualization/plot_window.py", line 1134, in __init__ slc = pf.h.slice(axis, center[axis], center=center, fields=fields, **field_parameters) File "/home/skillman/local/src/yt-hg/yt/data_objects/data_containers.py", line 1049, in __init__ self._refresh_data() File "/home/skillman/local/src/yt-hg/yt/data_objects/data_containers.py", line 318, in _refresh_data self.get_data() File "/home/skillman/local/src/yt-hg/yt/data_objects/data_containers.py", line 845, in get_data slc = pf.h.slice(axis, center[axis], center=center, fields=fields, **field_parameters) File "/home/skillman/local/src/yt-hg/yt/data_objects/data_containers.py", line 360, in _generate_field self._refresh_data() File "/home/skillman/local/src/yt-hg/yt/data_objects/data_containers.py", line 318, in _refresh_data self[field] = self.pf.field_info[field](self) File "/home/skillman/local/src/yt-hg/yt/data_objects/field_info_container.py", line 393, in __call__ self.get_data() File "/home/skillman/local/src/yt-hg/yt/data_objects/universal_fields.py", line 216, in _Pressure data["Density"] * data["ThermalEnergy"] ValueError: operands could not be broadcast together with shapes (19686) (40177) ``` -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[yt_analysis/yt] Switch docs theme (issue #510)
by Matthew Turk 23 Feb '13

23 Feb '13

--- you can reply above this line --- New issue 510: Switch docs theme https://bitbucket.org/yt_analysis/yt/issue/510/switch-docs-theme Matthew Turk: The docs theme currently has poor information density. Something like the bootstrap theme should help with this. Responsible: MatthewTurk -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

Thoughts on docs theme?
by Matthew Turk 23 Feb '13

23 Feb '13

Hi all, I've been working on the docs a bit, and I was wondering if I could take a pulse of the group on the theme. I think the fonts are a bit too big, and that poses a challenge to reading the docs. http://yt-project.org/docs/2.5/ I have been experimenting with a couple other themes. I uploaded the bootstrap theme here: http://yt-project.org/docs/dev/ The logo and paragraph symbols aside, I think the fonts look a lot nicer here, easier to read, easier to skim, etc. Some particular pages: http://yt-project.org/docs/dev/cookbook/simple_plots.html http://yt-project.org/docs/2.5/cookbook/simple_plots.html [+-]1 on this theme? I figure we could maybe make the navbar green to match the color. There are a bunch of other themes on pypi.python.org , if you search "sphinx." I think I'm just unsatisfied with the information density and style of the current documentation, so anything could potentially be an improvement. -Matt

9 10

[yt_analysis/yt] Unit and answer tests should be parallel safe (issue #509)
by Kacper Kowalik 22 Feb '13

22 Feb '13

--- you can reply above this line --- New issue 509: Unit and answer tests should be parallel safe https://bitbucket.org/yt_analysis/yt/issue/509/unit-and-answer-tests-should… Kacper Kowalik: Goal is to make the testsuite much faster than it's now. The most demanding tests should be identified and rewritten if necessary. Tentative plan is to achieve less than 5 minutes for total time. Responsible: xarthisius -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

pmods
by Stephen Skory 22 Feb '13

22 Feb '13

Hi all, I think I've found a hacky way to get around the pmods import problem we've been seeing. Since it's so hacky, I'm not going to issue a PR until somone else lays eyes on it and tries it and lets me know if it's A) too hacky, B) just hacky enough, or C) what? here's the diff http://paste.yt-project.org/show/3201/ Thanks! -- Stephen Skory s(a)skory.us http://stephenskory.com/ 510.621.3687 (google voice)

2 3

[yt_analysis/yt] bug with volume rendering function draw_grids (issue #508)
by Cameron Hummels 21 Feb '13

21 Feb '13

--- you can reply above this line --- New issue 508: bug with volume rendering function draw_grids https://bitbucket.org/yt_analysis/yt/issue/508/bug-with-volume-rendering-fu… Cameron Hummels: the function currently draws grids from the entire simulation volume, even if the user specifies a subregion to render. need to limit to just overplotting grids in the subregion if specified. Responsible: chummels -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

[yt_analysis/yt] Plot window sizes should be adjustable (issue #507)
by John Wise 21 Feb '13

21 Feb '13

--- you can reply above this line --- New issue 507: Plot window sizes should be adjustable https://bitbucket.org/yt_analysis/yt/issue/507/plot-window-sizes-should-be-… John Wise: Plots made with the PlotWindow infrastructure are not easily adjustable and are fixed at 10 inches and 800 pixels. Also the fontsize arguments are not functional. Responsible: jwise77 -- This is an issue notification from bitbucket.org. You are receiving this either because you are the owner of the issue, or you are following the issue.

1 0

Spatial fields for Octrees in 3.0
by Matthew Turk 21 Feb '13

21 Feb '13

Hi all, Octree support in 3.0 is coming along quite well. The main stumbling block is in support seems to be related to spatial fields. In particular, fields that rely on being passed 3D arrays of data. Many of these fields (such as DivV) rely on ghost zone information. Following on this, we need to be able to place particles inside individual Octs. In the past, I've assumed that the overhead of a function call being called on many, many small arrays (2x2x2) would outweigh the gain from vectorized numpy arithmetic. This morning, after testing, it seems the situation is a bit more complex. Here's a sample script: http://paste.yt-project.org/show/3184/ The results: http://paste.yt-project.org/show/3183/ Now, what this is doing is simulating the process of going from one big grid down to many small grids, such that at the end we're doing 2x2x2 grid objects, for a relatively complex field (RadiusCode). These results are not at *all* what I expected -- doing this grid-by-grid for octs outperforms doing it for the big array. My first guess at why this is is that the RadiusCode field likely performs a number of copies. Now, if we do this instead with DensitySquared (which is a flop-light routine) we see: http://paste.yt-project.org/show/3185/ (Here I've also upped to a 512^3 domain dimensions) Again, the Octs perform pretty well, out-performing everything else. I assume, perhaps incorrectly, this is related to memory allocation patterns or something. Regardless, it seems that what I had previously discounted as too costly (iterating over octs) is not so costly after all. I'd like to propose -- pending input from at least Doug, Sam and Chris -- that the spatial chunking for Octrees be constructed like so: * When a chunk_spatial call is made, iterate over io chunks. This will enable management based on IO, delegated to the individual OctGeometryHandler. (If number of requested ghost zones > 0, we can also build that information in here, as well.) * Inside the iteration of io chunks, read as much as is necessary from each (without child masking, as is usually the case for spatial data). yield either an Oct singleton or a dict pre-filled with the field data needed. (At this time we will know which fields must be read from disk and which must be generated.) * Back at top level, where the spatial chunking was called, fill back into the original data selector. This will likely require a new per-geometry handler function that accepts a spatial iterator and then fills a flat, non-spatial selector. I think this is reasonable, and I can have a pass at implementing it. I'll update the YTEP once it's done. However, it's also brought up the point that during the workshop we absolutely need to figure out a distributed memory octree approach. Before we implement such a thing, we also need rigorous testing of the three Octree codes that are included in 3.0. I believe this strategy for spatial fields in Octrees will also work for particle fields; you should be able to read a particle field and use it to generate a fluid field. For instance, the CICDeposit functions. Any feedback would be appreciated, but I think modulo strong objections I want to get started on this early next week, once my schedule lightens up a bit. Also, this should be fun for the workshop! :) -Matt

2 2

YTEP: Automatic Pull Requests’ validation
by Kacper Kowalik 21 Feb '13

21 Feb '13

Hi all, My YTEP-0007 on Automatic Pull Requests’ validation was just accepted (Thanks Matt!) https://yt.readthedocs.org/projects/ytep/en/latest/YTEPs/YTEP-0007.html It's now target only at 2.x branch, but I hope we will extend it to 3.0 soon. If you have any further suggestions or enhancements please reply to this mail. TIA! Best, Kacper

1 0