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.
New issue 1254: Windows test failure: alt_ray_tracers
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)
New issue 1253: offset text not in tex mode
The follow script (on some castro data):
ds = yt.load("smallplt16623")
s = yt.SlicePlot(ds, "z", "density")
produces an image with the axes in 'km' and the offset text rendered as '1e4' instead of as $10^4$.
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.
New issue 1252: Passing clump data source to YTSurface
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.
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.
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
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'
New issue 1251: Cannot construct compound LightRay for gadget frontend
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):
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.
New issue 1250: annotate_cell_edges: Have to increase buff_size for highly refined grids
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.
ds = yt.load("WindTunnel/windtunnel_4lev_hdf5_plt_cnt_0040")
slc = yt.SlicePlot(ds, 'z', 'density', width=(1.0, 1.0))
New issue 1249: annotate_cell_edges: wrong/ugly output for high-resolution data
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:
MWE to generate this image:
ds = yt.load("windtunnel_4lev_hdf5_plt_cnt_0040")
slc = yt.SlicePlot(ds, 'z', 'density')
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:
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,
from 800 to a higher value the result changes, but still it is not satisfactory. For very high resolutions, the results become worse again.
New issue 1247: origin in SlicePlot
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:
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
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.