Mailman 3 May 2013 - yt-dev

Issue #570: Healpix volume rendering produces garbled, artifacted images (yt_analysis/yt)
by Nathan Goldbaum 17 May '13

17 May '13

New issue 570: Healpix volume rendering produces garbled, artifacted images https://bitbucket.org/yt_analysis/yt/issue/570/healpix-volume-rendering-pro… Nathan Goldbaum: Using the sample script from the docs: ``` #!python from yt.mods import * import yt.visualization.volume_rendering.camera as camera pf = load("IsolatedGalaxy/galaxy0030/galaxy0030") image = camera.allsky_projection(pf, [0.5,0.5,0.5], 100.0/pf['kpc'], 64, "Density") camera.plot_allsky_healpix(image, 64, "allsky.png", "Column Density [g/cm^2]") ``` Produces the following image: ![](http://i.imgur.com/5wskzay.png) I also tried the manual method described further down in the docs: ``` #!python rom yt.mods import * import yt.visualization.volume_rendering.camera as camera Nside = 32 pf = load("IsolatedGalaxy/galaxy0030/galaxy0030") cam = camera.HEALpixCamera([0.5,0.5,0.5], 0.2, Nside, pf = pf, log_fields = [False]) bitmap = cam.snapshot() import yt.utilities.lib as au from numpy import pi phi, theta = np.mgrid[0.0:2*pi:800j, 0:pi:800j] pixi = au.arr_ang2pix_nest(Nside, theta.ravel(), phi.ravel()) img = np.log10(bitmap[:,0,0][pixi]).reshape((800,800)) import matplotlib.figure import matplotlib.backends.backend_agg fig = matplotlib.figure.Figure((10, 5)) ax = fig.add_subplot(1,1,1,projection='mollweide') image = ax.imshow(img, extent=(-pi,pi,-pi/2,pi/2), clip_on=False, aspect=0.5) cb = fig.colorbar(image, orientation='horizontal') cb.set_label(r"$\mathrm{Column}\/\mathrm{Density}\/[\mathrm{g}/\mathrm{cm}^2]$") canvas = matplotlib.backends.backend_agg.FigureCanvasAgg(fig) canvas.print_figure("allsky.png") ``` Note that I had to update this a bit since amr_utils was renamed a while back. This produces the following image: ![](http://i.imgur.com/Jax1sYB.png) While this looks more sensible, it's not clear to me that it is correct.

3 3

reorganizing YTEPs
by Britton Smith 17 May '13

17 May '13

Hi all, One of the things that came out of the yt strategy meeting last week was a discussion of reorganizing how the YTEPs are listed. Currently, it looks like this: http://ytep.readthedocs.org/en/latest/ There are essentially two problems with this. First, once a YTEP is accepted, it is difficult to tell the status of the actual enhancement that was proposed. Is it being implemented? Is it done? Second, because we are doing revisions in PRs, there is no listing of unaccepted YTEPs. For comparison, here is the enhancement proposal index for python: http://www.python.org/dev/peps/ They have categories for types (standards, information, and process) and status (accepted, rejected, withdrawn, draft, etc.). This may be slightly overkill for us since we are only on YTEP 14 and they have hundreds. I still think some organization would be helpful. I will have a go at that and issue a PR. The question I have for people is with regard to process. In order to have statuses for the unaccepted proposals, they have to exist in some fashion in the main repo. How do we want to do that? Or do we want to do that? One way would be to issue a PR that would include adding it to the index as Draft status and have it be accepted quickly. People can still leave comments on a merged PR and the author can then issue a new one which moves the listing to the accepted status. I'd really like to hear people's thoughts about this. Even if we don't adopt the above strategy, I'd still like to organize the accepted YTEPs as implemented and not implemented so people can get a better idea of where they might get involved. Britton

3 4

Issue #569: healpix rendering error (yt_analysis/yt)
by Anonymous 17 May '13

17 May '13

New issue 569: healpix rendering error https://bitbucket.org/yt_analysis/yt/issue/569/healpix-rendering-error Anonymous: Running the example script from the documentation for healpix rendering gave me: Traceback (most recent call last): File "healpix.py", line 18, in <module> camera.snapshot() File "/Users/gso/Documents/dev-yt/src/yt-hg/yt/visualization/volume_rendering/camera.py", line 1282, in snapshot tfp = TransferFunctionProxy(self.transfer_function) NameError: global name 'TransferFunctionProxy' is not defined If someone has time please take a look at the cause.

1 0

Consolidating Boxlib frontends
by Matthew Turk 17 May '13

17 May '13

Hi all, I'm spending a bit of time today looking over the Boxlib frontends and identifying commonalities and differences. I wanted to write with some of my initial findings as well as some specific questions. Casey, Andrew, and Jeff I would particularly like your feedback, but I also intend to submit this for detailed review and collaboration. My general plan is to consolidate the data_structures, IO and definitions into a single Boxlib frontend, with subclasses that cover each of the specific differences. The main differences I am seeing: * Castro was originally going to be a frontend, but morphed into the Nyx frontend, and I don't believe anything Castro-specific is left anymore. I am inclined to remove it and in the future add on any subclass-specific items when Castro comes back into the fold. * Nyx and Orion handle particles completely differently. * Nyx has optimized IO, particularly for fluids, which we should use everywhere. * Some weird differences like Level_%i and Level_%02i for level filenames. * Units will need to be set individually. * Parsing the Fortran and non-Fortran parameter files (i.e., Maestro and everyone else) will be tricky. There were a few other things I wanted to get feed back on. * Is it okay to get rid of the old enzo parameter mappings? * Do we need to have all of the paranoid IO still? * Do you mind if I reword some of the names? What do you all think? If anybody wants to help out, I'll be in IRC working on this for a while today, but I'll also try to submit a PR as early as possible to iterate on and get feedback from. -Matt

6 20

Issue #568: Slicing with cylindrical coordinates (yt_analysis/yt)
by rth 17 May '13

17 May '13

New issue 568: Slicing with cylindrical coordinates https://bitbucket.org/yt_analysis/yt/issue/568/slicing-with-cylindrical-coo… rth: # Slicing with cylindrical coordinates # Currenly slicing a 2d cylindrical FLASH simulation along the θ axis with yt-3.0 gives wrong results. ``` #!python from yt.mods import * # file included in the attachement pf = load('./test_hdf5_plt_cnt_0013') fig = SlicePlot(pf, 2, ['r', 'z', 'theta', 'dens'], fontsize=10, origin="domain") fig.save(mpl_kwargs={'bbox_inches':'tight', 'dpi': 500}) ``` the produced figures are attached. 1. Slice_z_theta.png: this projection is supposed to be a constant as there is just one cell in θ direction. On the figure though, there are also some additional cells (ghost cells?) in between blocks with diffferent levels of refinement, that seem to have completely arbitrary values. 2. Slice_z_r.png: same issue as in 1. 3. Slice_z_z.png: the plot should be linearly increasing along the z axis, and it is not the case. 4. Slice_z_dens.png: Density slice. Same issue as 1. the labels are actually misleading: all the plots were done in (r‚ z) plane. Actually, using yt-2.4 and replacing (r, z, θ) -> (x, y, z) still presents the same issue of arbitrary cells between blocks of different levels of refinement in a density slice. Up to now I was using Antony Sopatz's [flash.output.slice](http://flash.uchicago.edu/site/flashcode/user_support/t…, altought based on pf.h.slice, did not show the same behaviour. Unless I seriously misunderstand something, or I messed up my yt installation. Can someone please try to reproduce the attached plots? # Spatial derivatives in cyllindrical # Compuring a spatial derivative of a field fails in yt-3.0. ``` #!python from yt.mods import * # closely based on add_grad and replacing 'x' by 'r' def _gradr(field, data): grad = data['dens'][2:,1:-1,1:-1] - data['dens'][:-2,1:-1,1:-1] grad /= 2.0*data["dr"].flat[0] g = np.zeros(data['dens'].shape, dtype='float64') g[1:-1,1:-1,1:-1] = np.abs(grad) return g add_field("Grad_dens_r", function=_gradr, take_log=False, validators=[ValidateSpatial(1,['dens', 'dr'])], ) pf = load('./test_hdf5_plt_cnt_0013') fig = SlicePlot(pf, 2, 'Grad_dens_r', fontsize=10, origin="domain") #fig.annotate_grids() fig.save(mpl_kwargs={'bbox_inches':'tight', 'dpi': 500}) ``` ``` #!python S1 = 2303214662 ; S2 = 0 ; jname 1 256s = 264 Traceback (most recent call last): File "test_case.py", line 18, in <module> fig = SlicePlot(pf, 2, 'Grad_dens_r', fontsize=10, origin="domain") File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/visualization/plot_window.py", line 1226, in __init__ slc.get_data(fields) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 500, in get_data self._generate_fields(fields_to_generate) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 510, in _generate_fields self.field_data[field] = self._generate_field(field) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 226, in _generate_field return self._generate_fluid_field(field) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 239, in _generate_fluid_field rv = self._generate_spatial_fluid(field, ngt_exception.ghost_zones) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 263, in _generate_spatial_fluid data = gz[field][ngz:-ngz, ngz:-ngz, ngz:-ngz][mask] File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/data_containers.py", line 200, in __getitem__ self.get_data(f) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/construction_data_containers.py", line 437, in get_data if len(fill) > 0: self._fill_fields(fill) File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/construction_data_containers.py", line 555, in _fill_fields chunk.ires) File "misc_utilities.pyx", line 551, in yt.utilities.lib.misc_utilities.fill_region (yt/utilities/lib/misc_utilities.c:10025) ValueError: Buffer dtype mismatch, expected 'float64_t' but got 'float' ``` temporarily fixing the dtype problem in ```data_objects/construction_data_containers.py```, produces a plot that is definitely not d/dr (see Slice_dens_r.png attached). I don't know if the fact that line 510 of ```data_objects/data_containers.py``` there is ``` #!python try: self.field_data[field] = self._generate_field(field) except GenerationInProgress as gip: for f in gip.fields: if f not in fields_to_generate: fields_to_generate.append(f) #else: # raise ``` that is silenly ignoring ```NeedsGridType``` exceptions, for this plot, could have something to do with it. ``` #!python File "/mnt/netapp2/yurchak.r/src/yt-3.0/yt/data_objects/field_info_container.py", line 558, in __call__ raise NeedsGridType(self.ghost_zones,self.fields) yt.data_objects.field_info_container.NeedsGridType: (1, ['dens', 'dr']) ``` Thank you.

1 0

Issue #567: Setup script should test for openmp support (yt_analysis/yt)
by Nathan Goldbaum 14 May '13

14 May '13

New issue 567: Setup script should test for openmp support https://bitbucket.org/yt_analysis/yt/issue/567/setup-script-should-test-for… Nathan Goldbaum: I think this wil just require compiling a small test program and then checking for errors. This should remove the necessity to manually set compilers on OS X and improve the compatibility of the setup script in general. Something like this should work (although we don't care about the version): http://stackoverflow.com/a/13612520 Responsible: ngoldbaum

1 0

Issue #566: Spatial fields double-read data (yt_analysis/yt)
by Matthew Turk 13 May '13

13 May '13

New issue 566: Spatial fields double-read data https://bitbucket.org/yt_analysis/yt/issue/566/spatial-fields-double-read-d… Matthew Turk: Because of where the spatial field validation occurs, it is possible for spatial fields to double-read data with the new 3.0 chunking system. The check for validators occurs after the call to `_read_fluid_fields`. Responsible: MatthewTurk

1 0

Issue #565: Athena Answer Testing (yt_analysis/yt)
by Sam Skillman 11 May '13

11 May '13

New issue 565: Athena Answer Testing https://bitbucket.org/yt_analysis/yt/issue/565/athena-answer-testing Sam Skillman: Add Athena answer testing that covers the various permutations of {unigrid, SMR} and {serial, parallel}. Responsible: samskillman

1 0

Units PR
by Nathan Goldbaum 10 May '13

10 May '13

Hi all, The units refactor is proceeding apace - hopefully we'll ready for more widespread testing sometime this Summer. Over the past week, Casey and I went over the work we did at the yt workshop and tried to condense it into an expanded YTEP. The PR is here: https://bitbucket.org/caseywstark/ytep/src/56395e05b77c/source/YTEPs/YTEP-0… This touches on a lot of user-facing functionality (for the better, I think, but I'm certainly biased ;), so if you have any comments on things we've screwed up or suggestions to improve it, we'd love to hear them. Cheers, Nathan

2 2

Removing the max_level keyword argument from ProjectionPlot
by Nathan Goldbaum 10 May '13

10 May '13

Hi all, As part of the eternal journey that is making yt's plotting code as awesome as possible, we've endeavored to make the plotting code as flexible as it needs to be for quick use but simple enough that a use isn't overloaded by unnecessary or barely-used keyword arguments. Right now there is a pending PR to rework some of the plotting routines, adding a couple of new features, and, per the subject of this e-mail, removing the max_level keyword from ProjectionPlot. I could see how having max_level might be useful if projections are very slow for a user's dataset. However, she should be able to get the exact same result by explicitly constructing a projection data object and then creating a plot for it using projection.to_pw(). I also think in practice max_level isn't used very often since projections are quite fast, even on large datasets. Am I incorrect in that assessment? Please let me know if you'd like to keep the max_level keyword around and I'll happily revert that part of the pull request. Thanks for your help, Nathan

4 6