Mailman 3 July 2016 - yt-dev - {{ block.super }

Implementing Backend Independent Plots: Pull Request 2294
by Gilbert, Austin B 01 Aug '16

01 Aug '16

Hello All, I recently submitted a pull request that enables all yt plots to utilize the various interactive backends matplotlib(mpl) has to offer. The primary benefit of this change is that it enables a few more features from mpl in jupyter notebooks, but it also creates the possibility for user created applications using python gui packages (pyqt, tk, cairo, etc.). However, enabling this feature outside of a notebook requires the user to configure matplotlib for the backend they are using, as well as implementing their own event loop for the application. I would like to hear from others if they feel this is to complex a task to put on the user, and also if they would utilize the feature. Austin Gilbert

3 6

Issue #1254: Windows test failure: alt_ray_tracers (yt_analysis/yt)
by Nathan Goldbaum 26 Jul '16

26 Jul '16

New issue 1254: Windows test failure: alt_ray_tracers https://bitbucket.org/yt_analysis/yt/issues/1254/windows-test-failure-alt_r… Nathan Goldbaum: Currently this is causing our python2.7 appveyor builds to fail: ``` Traceback (most recent call last): File "C:\Miniconda-x64\envs\test\lib\site-packages\nose\loader.py", line 251, in generate for test in g(): File "c:\projects\yt\yt\utilities\lib\tests\test_alt_ray_tracers.py", line 65, in test_cylindrical_ray_trace t, s, rztheta, inds = cylindrical_ray_trace(p1, p2, left_grid, right_grid) File "yt\utilities\lib\alt_ray_tracers.pyx", line 203, in yt.utilities.lib.alt_ray_tracers.cylindrical_ray_trace (yt/utilities/lib/alt_ray_tracers.c:6000) tsect, tinds = np.unique(tsect[tmask], return_index=True) ValueError: Item size of buffer (1 byte) does not match size of 'int64_t' (8 bytes) ``` https://ci.appveyor.com/project/Xarthisius/yt/build/1.0.194/job/p8fgpx0vhx7…

1 0

Issue #1253: offset text not in tex mode (yt_analysis/yt)
by Michael Zingale 26 Jul '16

26 Jul '16

New issue 1253: offset text not in tex mode https://bitbucket.org/yt_analysis/yt/issues/1253/offset-text-not-in-tex-mode Michael Zingale: The follow script (on some castro data): ``` import yt ds = yt.load("smallplt16623") s = yt.SlicePlot(ds, "z", "density") s.save() ``` produces an image with the axes in 'km' and the offset text rendered as '1e4' instead of as $10^4$. ![smallplt16623_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/1447452790-smallplt16623_Slice_z_density.png) a related issue is that if you try to use `axes_unit='1e9*cm'`, you get a spurious `(1+z)` factor -- that is meaningless except possibly for cosmology codes, and should probably be suppressed by default. ![smallplt16623_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/697522556-smallplt16623_Slice_z_density.png)

1 0

Issue #1252: Passing clump data source to YTSurface (yt_analysis/yt)
by John Regan 26 Jul '16

26 Jul '16

New issue 1252: Passing clump data source to YTSurface https://bitbucket.org/yt_analysis/yt/issues/1252/passing-clump-data-source-… John Regan: When passing a clump object to the YTSurface operator I get the error: AttributeError: 'Clump' object has no attribute 'get_field_parameter' The script to reproduce this error is here and I was using the IsolatedGalaxy dataset - the one with the potential output included. http://paste.yt-project.org/show/6724/ I can by-pass this error by slightly modifying the YTSurface api to allow a center point to be passed in, this should probably be the point of maximum density within the clump. So surf = clump.data.ds.surface(clump, "density", 1e-24, center=center) but this leads to the next issue Traceback (most recent call last): File "clump_surfing.py", line 33, in <module> triangles = surf.triangles File "/cosma/home/dp004/dc-rega4/YT/yt-x86_64/src/yt-hg/yt/data_objects/construction_data_containers.py", line 1223, in triangles self.get_data() File "/cosma/home/dp004/dc-rega4/YT/yt-x86_64/src/yt-hg/yt/data_objects/construction_data_containers.py", line 1108, in get_data for io_chunk in parallel_objects(self.data_source.chunks([], "io")): AttributeError: 'Clump' object has no attribute 'chunks' Responsible: MatthewTurk

1 0

Issue #1251: Cannot construct compound LightRay for gadget frontend (yt_analysis/yt)
by Cameron Hummels 24 Jul '16

24 Jul '16

New issue 1251: Cannot construct compound LightRay for gadget frontend https://bitbucket.org/yt_analysis/yt/issues/1251/cannot-construct-compound-… Cameron Hummels: Previously, I was somehow able to construct a compound LightRay (one spanning multiple datasets) using the `gizmo_cosmology_plus` dataset, but I can no longer do this. Here is a sample script demonstrating the problem (which effectively just the compound LightRay cookbook recipe with the `gizmo_cosmology_plus` dataset swapped in): http://paste.yt-project.org/show/6712/ It fails if you are not running in the directory with the dataset, but this is a minor problem. The main issue is that `domain_boundaries` are not defined, and then `domain_left_edge` and `domain_right_edge` are not defined. Responsible: chummels

1 0

Issue #1250: annotate_cell_edges: Have to increase buff_size for highly refined grids (yt_analysis/yt)
by Dominik Derigs 24 Jul '16

24 Jul '16

New issue 1250: annotate_cell_edges: Have to increase buff_size for highly refined grids https://bitbucket.org/yt_analysis/yt/issues/1250/annotate_cell_edges-have-t… Dominik Derigs: This issue is related to issue #1249. It addresses a related but different problem that is potentially easier to be solved and should be solved for 3.3. One always has to increase buff_size to get nice annotated cell edges for high resolution data. I think it is necessary to automate the increase of the buffer size when needed. An alternative approach could be to increase it to some high value when the user calls the annotate_cell_edges function explicitly. MWE: ``` #!python import yt ds = yt.load("WindTunnel/windtunnel_4lev_hdf5_plt_cnt_0040") slc = yt.SlicePlot(ds, 'z', 'density', width=(1.0, 1.0)) slc.annotate_cell_edges() slc.annotate_grids() slc.hide_axes() slc.hide_colorbar() slc.save("800x800.png",mpl_kwargs={'dpi': 200}) slc.set_buff_size((3200, 3200)) slc.save("3200x3200.png",mpl_kwargs={'dpi': 200}) ``` 800x800: ![800x800.png](https://bitbucket.org/repo/BXbAb/images/2420740934-800x800.png) 3200x3200: ![3200x3200.png](https://bitbucket.org/repo/BXbAb/images/1803891906-3200x3200.png)

1 0

Issue #1249: annotate_cell_edges: wrong/ugly output for high-resolution data (yt_analysis/yt)
by Dominik Derigs 23 Jul '16

23 Jul '16

New issue 1249: annotate_cell_edges: wrong/ugly output for high-resolution data https://bitbucket.org/yt_analysis/yt/issues/1249/annotate_cell_edges-wrong-… Dominik Derigs: This concerns the functionality added in issue #1198 (annotate_cell_edges). As can be seen in the picture, the routine produces wrong outputs for sufficiently refined data sets: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/2894998979-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density.png) MWE to generate this image: ``` #!python import yt ds = yt.load("windtunnel_4lev_hdf5_plt_cnt_0040") slc = yt.SlicePlot(ds, 'z', 'density') slc.annotate_cell_edges(alpha=0.3,color=(0.0,0.0,0.0)) slc.save() ``` Data taken from: http://yt-project.org/data/WindTunnel.tar.gz If I change the resolution of the generated fixed resolution buffer in yt/visualization/plot_window.py: ``` #!python class PlotWindow(ImagePlotContainer): [...] def __init__(self, data_source, bounds, buff_size=(800,800), antialias=True, periodic=True, origin='center-window', oblique=False, window_size=8.0, fields=None, fontsize=18, aspect=None, setup=False): ``` from 800 to a higher value the result changes, but still it is not satisfactory. For very high resolutions, the results become worse again. 800x800: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density.png](https://bitbucket.org/repo/BXbAb/images/2894998979-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density.png) 1200x1200: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_1200.png](https://bitbucket.org/repo/BXbAb/images/3484107681-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_1200.png) 1600x1600: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_1600.png](https://bitbucket.org/repo/BXbAb/images/1966244505-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_1600.png) 3200x3200: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_3200.png](https://bitbucket.org/repo/BXbAb/images/1115888674-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_3200.png) 6000x6000: ![windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_6000.png](https://bitbucket.org/repo/BXbAb/images/422764143-windtunnel_4lev_hdf5_plt_cnt_0040_Slice_z_density_6000.png)

1 0

Issue #1248: Segmentation fault during profile creation (yt_analysis/yt)
by Kacper Kowalik 21 Jul '16

21 Jul '16

New issue 1248: Segmentation fault during profile creation https://bitbucket.org/yt_analysis/yt/issues/1248/segmentation-fault-during-… Kacper Kowalik: As reported by @MatthewTurk on slack, following code: ``` import yt ds = yt.load("IsolatedGalaxy/galaxy0030/galaxy0030") dd = ds.all_data() yt.create_profile(dd, "x", "ones", n_bins=256, weight_field=None) ``` results in segmentation fault (yt 1f83a250683e) Responsible: xarthisius

1 0

Issue #1247: origin in SlicePlot (yt_analysis/yt)
by Luigi Iapichino 21 Jul '16

21 Jul '16

New issue 1247: origin in SlicePlot https://bitbucket.org/yt_analysis/yt/issues/1247/origin-in-sliceplot Luigi Iapichino: Dear yt community, in the "origin" parameter in SlicePlot is it currently not possible to have the location of the origin of the plot coordinate system in a user-defined point inside the slice. I have sent an email to yt-users about it, and on July 14 Nathan replied that the place that needs to be modified is this function: https://bitbucket.org/yt_analysis/yt/src/1c339ea7619997cba6842e973cf5f0e13b… One would need to add a new if statement to account for the case when origin is a two-element list, tuple or ndarray, and then just use that value. One would also need to update the docstrings for "origin" which are replicated a few places in that file. Unfortunately at the moment I don't have resources to invest in this task, therefore I open this issue for adding a new feature in the origin parameter. Thanks a lot your your efforts, Luigi

1 0

Release incoming
by Nathan Goldbaum 21 Jul '16

21 Jul '16

Hi all, Right now we only have one more significant issue left for 3.3. I've talked with Cameron about it and he'd like to see it fixed so trident works correctly with yt-3.3.0. I'm expecting him to have a patch ready or to let us know that he's punting on it in the next few days. That means that if you have any bugfixes you'd like to see by part of yt 3.3.0, now is a good time to put them together. Please also keep in mind that we will be doing a bugfix release (yt 3.3.1) within a month or so of the initial release, sooner if someone pokes me or if something urgent comes up. I will coordinating with andrew to manage getting the release e-mail out after we have binary wheels and conda packages available via conda-forge, so there might be a day or two between tagging the release and actually publicly announcing it. -Nathan

2 1

yt-dev July 2016