Mailman 3 April 2014 - yt-dev

Issue #831: 'kamae' colormap raises IndexError in matplotlib (yt_analysis/yt)
by Kacper Kowalik 22 Apr '14

22 Apr '14

New issue 831: 'kamae' colormap raises IndexError in matplotlib https://bitbucket.org/yt_analysis/yt/issue/831/kamae-colormap-raises-indexe… Kacper Kowalik: Following script: ``` #!python from yt.mods import load, SlicePlot pf = load("IsolatedGalaxy/galaxy0030/galaxy0030") slc = SlicePlot(pf, 2, "density") slc.set_cmap("density", "kamae") slc.save() ``` yields: ``` #!text Traceback (most recent call last): File "ala.py", line 8, in <module> slc.save() File "/home/xarth/codes/yt-my/yt/visualization/plot_container.py", line 443, in save names.append(v.save(n, mpl_kwargs)) File "/home/xarth/codes/yt-my/yt/visualization/base_plot_types.py", line 84, in save canvas.print_figure(name, **mpl_kwargs) File "/usr/lib64/python2.7/site-packages/matplotlib/backend_bases.py", line 2220, in print_figure **kwargs) File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 505, in print_png FigureCanvasAgg.draw(self) File "/usr/lib64/python2.7/site-packages/matplotlib/backends/backend_agg.py", line 451, in draw self.figure.draw(self.renderer) File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper draw(artist, renderer, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/matplotlib/figure.py", line 1034, in draw func(*args) File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper draw(artist, renderer, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/matplotlib/axes.py", line 2086, in draw a.draw(renderer) File "/usr/lib64/python2.7/site-packages/matplotlib/artist.py", line 54, in draw_wrapper draw(artist, renderer, *args, **kwargs) File "/usr/lib64/python2.7/site-packages/matplotlib/image.py", line 364, in draw im = self.make_image(renderer.get_image_magnification()) File "/usr/lib64/python2.7/site-packages/matplotlib/image.py", line 588, in make_image transformed_viewLim) File "/usr/lib64/python2.7/site-packages/matplotlib/image.py", line 204, in _get_unsampled_image x = self.to_rgba(self._A, bytes=False) File "/usr/lib64/python2.7/site-packages/matplotlib/cm.py", line 261, in to_rgba x = self.cmap(x, alpha=alpha, bytes=bytes) File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 542, in __call__ self._init() File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 724, in _init self.N, self._segmentdata['red'], self._gamma) File "/usr/lib64/python2.7/site-packages/matplotlib/colors.py", line 449, in makeMappingArray if len(shape) != 2 and shape[1] != 3: IndexError: tuple index out of range ``` with ``` #!text $ yt instinfo yt module located at: /home/xarth/codes/yt-my The current version and changeset for the code is: --- Version = 3.0-dev Changeset = 71196d4289bf --- This installation CAN be automatically updated. Could not determine when yt stack was last updated. $ python -c 'import matplotlib; print matplotlib.__version__' 1.3.0 ```

1 0

Issue #830: Number density is only defined for multispecies datasets (yt_analysis/yt)
by Nathan Goldbaum 21 Apr '14

21 Apr '14

New issue 830: Number density is only defined for multispecies datasets https://bitbucket.org/yt_analysis/yt/issue/830/number-density-is-only-defin… Nathan Goldbaum: Right now querying the `number_density` field raises an IndexError in the field definition for a single fluid/color dataset. The following diff fixes the issue for me and my enzo datasets, but clearly isn't the correct solution for all supported codes: ``` #!diff diff -r 71196d4289bf yt/fields/fluid_fields.py --- a/yt/fields/fluid_fields.py Sat Apr 19 20:14:16 2014 -0400 +++ b/yt/fields/fluid_fields.py Sun Apr 20 19:58:45 2014 -0700 @@ -164,15 +164,18 @@ units="g") def _number_density(field, data): - field_data = np.zeros_like(data["gas", "%s_number_density" % \ - data.pf.field_info.species_names[0]]) - for species in data.pf.field_info.species_names: - field_data += data["gas", "%s_number_density" % species] + try: + field_data = np.zeros_like(data["gas", "%s_number_density" % \ + data.pf.field_info.species_names[0]]) + for species in data.pf.field_info.species_names: + field_data += data["gas", "%s_number_density" % species] + except IndexError: + field_data = data["gas", "density"] / (mh * data.pf.parameters['Mu']) return field_data registry.add_field((ftype, "number_density"), function = _number_density, units="cm**-3") - + def _mean_molecular_weight(field, data): return (data[ftype, "density"] / (mh * data[ftype, "number_density"])) registry.add_field((ftype, "mean_molecular_weight"), ``` Do we have some way of signaling whether a dataset is multispecies? I could see modifying the `setup_species_fields` function in the enzo frontend to handle this for the case `ds.parameters['MultiSpecies'] == 0`, but I don't think there is yet a frontend-independent way to handle the mean molecular weight. @brittonsmith @MatthewTurk what do you guys think?

1 0

parallel_objects not freeing communicators?
by Josh Moloney 19 Apr '14

19 Apr '14

I have a script that I'm using to perform various analysis functions on halos from an Enzo simulation. In this script I'm using parallel_objects to split the halos up among multiple processors. for sto, halo in parallel_objects(halos, num_procs, storage=halo_props): sto.result_id = halo.id sto.result = analyze_halo(pf, halo, radius, old_time, current_time, f_ej) within analyze_halo I use WeightedAverageQuantity on a region containing each halo, which from what I understand also uses parallel_objects. reg = pf.h.sphere(halo.center_of_mass(),radius) properties = {'metallicity': (reg.quantities['WeightedAverageQuantity'] ('metallicity','Density')).in_units('Zsun')} This works fine for a while, but after the script has analyzed several thousand halos it eventually crashes with an MPI exception 'Too many communicators'. I took a quick look at the code in parallel_analysis_interface, and it seems like parallel_objects creates new communicators with every call but never explicitly frees them. Does anyone know if this is actually the case, or is it an issue with my script or the mpi libraries on my machine? I'm using the experimental branch of yt-3.0. I should be able to get this script working fairly easily by just calculating my weighted average directly rather than calling quantities (and I probably don't want this being done in parallel anyways since I'm only looking at small regions), but if parallel_objects is actually leaking communicators then it should be fixed at some point. - Josh

2 1

covering_grid and BCs
by Michael Zingale 18 Apr '14

18 Apr '14

If I create a covering_grid for a full domain that is not triply-periodic, the code will abort when I try to access the data in the covering grid with an error generated by selection_routines.pyx that is looking to make sure that the boundary conditions are supported. I understand that this support is not yet in place, but I don't think that it should be an issue for a covering_grid. The covering grid procedure itself should not ever need boundary conditions, if I understand what it intends to do. If you are just sampling the coarse data (or averaging the overlying fine data) into your zone, there is no need to do any interpolation that would require BCs. For the SmoothedCoveringGrid stuff, I understand that BCs should come into play. Am I missing something? or should this check on the BCs be considered a bug in this case? Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

2 7

power spectra in yt
by Michael Zingale 17 Apr '14

17 Apr '14

Dear yters, I am interested in using yt to do power spectra for analyzing turbulence in our simulations. I quickly coded up a script to do this (warning: I haven't verified this, so some of the normalization may be wrong, but it doesn't assume a cubic domain, and it looked ok by eye): http://paste.yt-project.org/show/4528/ The caveat is that we need to put this onto a uniform grid to do the FFT, but then we can use the numpy FFT routines. I think that it would be nice to have some sort of power spectrum functionality built into yt. One thing that I don't know is what sort of things do people in other fields look at? For our work, we look at the power spectrum of a density-weighted velocity field (rho**1/3 U for stratified flows gives the expected Kolmogorov scaling). The other thing is what sort of interface and where should this live in yt? Ideally we'd compute some other properties (integral scales, etc.), but it would be nice to have some discussion about what people use and then we can start woth some basic functionality. Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

5 6

TipsyDataset Will Not Load, and Requires Parameter File
by Cameron Hummels 17 Apr '14

17 Apr '14

Hi everyone, I was trying to use yt 3.0 with the Gasoline sample dataset that we have available on http://yt-project.org/data , and it fails in two ways: 1) yt cannot figure out what the dataset is using the simple "load" command as in: from yt.mods import * ds = load(filename) ... yt.utilities.exceptions.YTOutputNotIdentified: Supplied ('agora_1e11.0040',) {}, but could not load! 2) When I manually ask it to see the file as a TipsyDataset, it also fails, as it expects parameters to be set: from yt.mods import * ds = TipsyDataset(filename) ... File "/Users/chummels/src/yt-i386/src/yt-hg/yt/frontends/sph/data_structures.py", line 396, in __init__ self.parameters['nbodies'], AttributeError: 'TipsyDataset' object has no attribute 'parameters' This seems like a bug. Any ideas as to a solution? This dataset did not come with a parameter file for it. Cameron -- Cameron Hummels Postdoctoral Researcher Steward Observatory University of Arizona http://chummels.org

2 4

Python 3 PR part 1
by Matthew Turk 17 Apr '14

17 Apr '14

Hi all, Here's part one of getting yt to run on Python 3. Reviews welcome! https://bitbucket.org/yt_analysis/yt/pull-request/828/python-3-compatibilit… Once this is accepted, we should also pull in a no-op merge. I started my efforts on yt-2.x, but then moved to yt-3.0 today. -Matt

1 0

Cheatsheet link 404s
by B.W. Keller 17 Apr '14

17 Apr '14

Hey all, The link to the yt cheatsheet on the main webpage is dead. Is a new one being made or something? Ben

2 4

Orientation, coordinate systems
by Matthew Turk 15 Apr '14

15 Apr '14

Hi all, I'd like to open up the discussion of "fixing" the yt coordinate systems, as we move nearer and nearer on 3.0. Jeff, Nathan and Britton have brought this up a couple times, that the x/y/z ordering is not consistent with what they expect, and I'd like to figure out if we can fix that now -- it's as good a time as any for bandaid ripping. It may just be a matter of the transposition of buffers and the x_dict and y_dict, or it might be more complex, although I suspect it won't be much more than fixing those two items. -Matt

6 13

problem with non-periodic domain and rendering
by Michael Zingale 15 Apr '14

15 Apr '14

Recently I made the Maestro BoxLib frontend set the correct boundary periodicity for a data set, and I can confirm this when I load the data in yt and look at periodicity. However, when I try to volume render, with no_ghost=False, I get an error in the non-periodic direction (we are periodic in x and y, and non-periodic in z). The error is: Error: bad Region in non-periodic domain: -24.0 code_length 0.0 code_length 408.0 code_length 4608.0 code_length for reference, the domain size is: Parameters: domain_left_edge = [ 0. 0. 0.] Parameters: domain_right_edge = [ 1536. 1536. 4608.] (aside, these should be cm, but the error reports them as code_length -- should I be setting that somwhere in the frontend? we are always CGS). Any thoughts on what I may be missed setting up for non-periodic BCs is appreciated. Mike -- Michael Zingale Associate Professor Dept. of Physics & Astronomy * Stony Brook University * Stony Brook, NY 11794-3800 *phone*: 631-632-8225 *e-mail*: Michael.Zingale(a)stonybrook.edu *web*: http://www.astro.sunysb.edu/mzingale

3 4