internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: yt-project/yt

Issue:
SlicePlot artifacts on corners/edges
### Bug report

A SlicePlot of a 2D cylindrical dataset has artifacts on the edges and corners that do not represent the underlying data.

**Code for reproduction**

This can be reproduced using the same dataset and plot as #1663. Download the WDMerger_hdf5_chk_1000 sample dataset, and then do a sliceplot:

```python
# import yt
# ds = yt.load('WDMerger_hdf5_chk_1000/WDMerger_hdf5_chk_1000.hdf5')
# yt.SlicePlot(ds, 'theta', 'density', width=1.e9).set_center([2.e9, 0.0]).save()
```

**Actual outcome**

![wdmerger_hdf5_chk_1000 hdf5_slice_theta_density](https://user-images.githubusercontent.com/8052594/34921634-319783a0-f93a-11e7-9708-87240f332695.png)

Note the spurious "hotspots" in the corners, and the solid lines along the edges.

**Version Information**
  * Operating System: SLES 11
  * Python Version: 3.5.1
  * yt version: Development (eb3358c622bc047200b9bc6a954ddee8f59a0e07)
  * Other Libraries (if applicable): 


Discussion:
May it be related to #1573 ?
I can reproduce this.
I was able to demonstrate that this is a problem with the width setting by comparing the results of these two:

```
yt.SlicePlot(ds, 'theta', 'ones', width=1.e9)
yt.SlicePlot(ds, 'theta', 'ones')
```

Resolving patch:
diff --git a/yt/geometry/coordinates/cylindrical_coordinates.py b/yt/geometry/coordinates/cylindrical_coordinates.py
--- a/yt/geometry/coordinates/cylindrical_coordinates.py
+++ b/yt/geometry/coordinates/cylindrical_coordinates.py
@@ -96,7 +96,11 @@ def _path_z(field, data):
                  units = "code_length")
 
     def pixelize(self, dimension, data_source, field, bounds, size,
-                 antialias = True, periodic = True):
+                 antialias = True, periodic = False):
+        # Note that above, we set periodic by default to be *false*.  This is
+        # because our pixelizers, at present, do not handle periodicity
+        # correctly, and if you change the "width" of a cylindrical plot, it
+        # double-counts in the edge buffers.  See, for instance, issue 1669.
         ax_name = self.axis_name[dimension]
         if ax_name in ('r', 'theta'):
             return self._ortho_pixelize(data_source, field, bounds, size,


Test patch:
Repository: yt-project/yt

Issue:
OffAxisProjection only projects in code units
### Bug report

**Bug summary**

The addition of the `OffAxisProjectionPlot` for use with particle-based datasets is great and a wonderful contribution to the code, but I've discovered a few small issues.  One of which is while `ProjectionPlot` gives results in CGS, `OffAxisProjectionPlot` seems to only give results in code units for particle-based datasets.  

**Code for reproduction**

```python
import yt
ds = yt.load('FIRE/FIRE_M12i_ref12/snapshot_600.hdf5')
yt.OffAxisProjectionPlot(ds, [1,0,0], ('gas', 'density')).save()
```

**Actual outcome**
![snapshot_600_offaxisprojection_density](https://user-images.githubusercontent.com/8250999/42977375-a5bb01ca-8b7b-11e8-974e-4bb2e5675589.png)



**Expected outcome**

Something like a `ProjectionPlot` like this one where the z field is in CGS:

![snapshot_600_projection_x_density](https://user-images.githubusercontent.com/8250999/42977409-e1ad609c-8b7b-11e8-83d3-d1dba1b90d4e.png)



Discussion:

Resolving patch:
diff --git a/yt/visualization/volume_rendering/off_axis_projection.py b/yt/visualization/volume_rendering/off_axis_projection.py
--- a/yt/visualization/volume_rendering/off_axis_projection.py
+++ b/yt/visualization/volume_rendering/off_axis_projection.py
@@ -202,11 +202,15 @@ def off_axis_projection(data_source, center, normal_vector,
                     normal_vector,
                     north)
 
+            # Assure that the path length unit is in the default length units
+            # for the dataset by scaling the units of the smoothing length
             path_length_unit = data_source.ds._get_field_info('smoothing_length').units
             path_length_unit = Unit(path_length_unit, registry=data_source.ds.unit_registry)
+            default_path_length_unit = data_source.ds.unit_system['length']
+            buf *= data_source.ds.quan(1, path_length_unit).in_units(default_path_length_unit)
             item_unit = data_source.ds._get_field_info(item).units
             item_unit = Unit(item_unit, registry=data_source.ds.unit_registry)
-            funits = item_unit * path_length_unit
+            funits = item_unit * default_path_length_unit
 
         else:
             # if there is a weight field, take two projections:


Test patch:
Repository: yt-project/yt

Issue:
Support periodic BC in ParticleProjectionPlot
Currently, periodic boundary condition is not considered in ParticleProjectionPlot. For example:
```python
import yt

ds = yt.load('gizmo_64/output/snap_N64L16_093.hdf5')
center = ds.domain_width * 0.618
yt.ParticleProjectionPlot(ds, 'z', 'particle_mass', center=center).save()
```
would give:
![snap_n64l16_093_particle_z_particle_mass](https://user-images.githubusercontent.com/5176695/44060243-e6b093e8-9f08-11e8-8a47-58d56b55b221.png)

It would be nice to have this feature.



Discussion:

Resolving patch:
diff --git a/yt/visualization/fixed_resolution.py b/yt/visualization/fixed_resolution.py
--- a/yt/visualization/fixed_resolution.py
+++ b/yt/visualization/fixed_resolution.py
@@ -587,9 +587,16 @@ def __getitem__(self, item):
         y_data = self.data_source.dd[ftype, self.y_field]
         data = self.data_source.dd[item]
 
+        # handle periodicity
+        dx = x_data.in_units("code_length").d - bounds[0]
+        dy = y_data.in_units("code_length").d - bounds[2]
+        if self.periodic:
+            dx %= float(self._period[0].in_units("code_length"))
+            dy %= float(self._period[1].in_units("code_length"))
+
         # convert to pixels
-        px = (x_data - self.bounds[0]) / (self.bounds[1] - self.bounds[0])
-        py = (y_data - self.bounds[2]) / (self.bounds[3] - self.bounds[2])
+        px = dx / (bounds[1] - bounds[0])
+        py = dy / (bounds[3] - bounds[2])
 
         # select only the particles that will actually show up in the image
         mask = np.logical_and(np.logical_and(px >= 0.0, px <= 1.0),


Test patch:
Repository: yt-project/yt

Issue:
annotate_domain in disagreement with rendered image.
### Bug report

I want to volume-render a non-cubic simulation from FLASH. So far, I tried to follow the official [volume rendering tutorial](http://yt-project.org/doc/visualizing/volume_rendering_tutorial.html#volume-rendering-tutorial) but I'm struggling with orienting myself in the generated graphs.
I think this is mainly due to the fact that the result of `annotate_domain` does not seem to correspond to anything in the generated image:
![render6_1](https://user-images.githubusercontent.com/16748619/38739737-0c47a4d0-3f36-11e8-815c-0460e48c598d.png)


**Code for reproduction**
curldrop: http://use.yt/upload/df1b59f5

```python
import yt

ds = yt.load("CF97W4_N1B025_hdf5_plt_cnt_0055")
sc = yt.create_scene(ds)#, lens_type='perspective')

# Set up the camera parameters: focus, width, resolution
sc.camera.focus = ds.domain_center
sc.camera.resolution = (1000,500)
sc.camera.width = (100, 'pc')
sc.camera.switch_orientation()

sc.annotate_axes(alpha=0.02)
sc.annotate_domain(ds, color=[1, 1, 1, .3])
sc.save("render6_1.png", sigma_clip=3.0)
```

With `lens_type='perspective'` and otherwise unchanged code from above, things seem to be even worse:
![render6_1](https://user-images.githubusercontent.com/16748619/38739953-a057d8ac-3f36-11e8-8362-23bed86e1e43.png)

**(Roughly) expected output**
(generated using VisIt 2.13.1`)
![screenshot at 2018-04-13 16-29-51](https://user-images.githubusercontent.com/16748619/38740483-ffa07d04-3f37-11e8-8ce8-26339be32715.png)

**Version Information**
<!--Please specify your platform and versions of the relevant libraries you are
using:-->
  * Operating System: Linux Mint 18
  * Python Version: Python 2.7.12 (default, Dec  4 2017, 14:50:18)
  * yt version: yt-3.4.0-595-gb30e5cb (compiled from source after cloning repository from github)
  * Other Libraries (if applicable): ---


Discussion:
Thanks for the detailed report!

Resolving patch:
diff --git a/yt/visualization/volume_rendering/lens.py b/yt/visualization/volume_rendering/lens.py
--- a/yt/visualization/volume_rendering/lens.py
+++ b/yt/visualization/volume_rendering/lens.py
@@ -131,9 +131,8 @@ def project_to_plane(self, camera, pos, res=None):
         dy = np.array(np.dot(pos - origin, camera.unit_vectors[0]))
         dz = np.array(np.dot(pos - front_center, -camera.unit_vectors[2]))
         # Transpose into image coords.
-
-        py = (res[0]*(dx/width[0])).astype('int64')
-        px = (res[1]*(dy/width[1])).astype('int64')
+        px = (res[0]*(dy/width[0])).astype('int64')
+        py = (res[1]*(dx/width[1])).astype('int64')
         return px, py, dz
 
     def __repr__(self):


Test patch:
Repository: yt-project/yt

Issue:
Density projections use the wrong smoothing lengths with particle filters
### Bug report

**Bug summary**

Off-axis density projections use the wrong smoothing lengths when a particle filter is applied.

**Code for reproduction**

```python
import yt
import numpy as np
import matplotlib
matplotlib.use("Agg")
from matplotlib import pyplot as plt

ds = yt.load(
    "gizmo_64/output/snap_N64L16_135.hdf5"
)
galaxy_pos = ds.arr([14874.90526271, 2789.92175182, 6898.11417307], 'kpccm')

@yt.particle_filter("central_gas", requires=["ParticleIDs"], filtered_type="PartType0")
def _filter(pfilter, data):
    mask = np.ones(data[(pfilter.filtered_type, 'ParticleIDs')].shape, dtype=bool)
    mask[0] = False # Comment this out and the projection is correct
    return mask

ds.add_particle_filter("central_gas")

image = yt.off_axis_projection(
    ds,
    center=galaxy_pos,
    normal_vector=[1.0, 0, 0.0],
    width=[250., 250., 250.],
    resolution=[512, 512],
    item=("central_gas", "density"),
)
plt.imshow(np.log10(image), cmap="magma").write_png("output.png")
```
Uses http://yt-project.org/data/ahf_halos.tar.gz

**Actual outcome**
![bad_output](https://user-images.githubusercontent.com/12105168/46979908-ef200d00-d0a0-11e8-8f50-a736df1e8ed3.png)

**Expected outcome**
![good_output](https://user-images.githubusercontent.com/12105168/46979925-ff37ec80-d0a0-11e8-989b-63aaa32809a0.png)

**Version Information**
  * Operating System: linux
  * Python Version: 3.7
  * yt version: 4.0-dev0


Discussion:

Resolving patch:
diff --git a/yt/visualization/volume_rendering/off_axis_projection.py b/yt/visualization/volume_rendering/off_axis_projection.py
--- a/yt/visualization/volume_rendering/off_axis_projection.py
+++ b/yt/visualization/volume_rendering/off_axis_projection.py
@@ -144,6 +144,8 @@ def off_axis_projection(data_source, center, normal_vector,
         if fi.alias_field:
             if fi.alias_name[0] != ptype:
                 raise_error = True
+            elif item[0] != 'gas':
+                ptype = item[0]
         else:
             if fi.name[0] != ptype and fi.name[0] != 'gas':
                 raise_error = True


Test patch:
Repository: yt-project/yt

Issue:
Wrong units for sphere radius
### Bug report

**Bug summary**

When annotating a sphere, the `radius` argument is expected to be given in the same units as the `center` argument.

**Code for reproduction**

```python
import yt

ds = yt.load('output_00080/info_00080.txt')

pos = ds.arr([.5, .5, .5], 'code_length')
r = ds.quan(20, 'Mpc')

sp = ds.sphere(pos, 2*r)

p = yt.ProjectionPlot(ds, 'x', 'density', data_source=sp, center=pos, width=2*r)

# This doesn't work
p.annotate_sphere(pos, r)
p.save(suffix='base.png')

# This works
p.annotate_clear()
p.annotate_sphere(pos, r.to(pos.units))
p.save(suffix='expected.png')

```

**Actual outcome**

![info_00080_projection_x_density base](https://user-images.githubusercontent.com/5411875/50823314-f9664600-1333-11e9-9a99-8745902fa8b7.png)
![info_00080_projection_x_density expected](https://user-images.githubusercontent.com/5411875/50823316-f9664600-1333-11e9-81ee-95eeeb1d98ef.png)

**Expected outcome**

I expect both images to be the same.

**Version Information**
  * yt version: 3.5dev0, installed from git



Discussion:

Resolving patch:
diff --git a/yt/visualization/plot_modifications.py b/yt/visualization/plot_modifications.py
--- a/yt/visualization/plot_modifications.py
+++ b/yt/visualization/plot_modifications.py
@@ -1328,6 +1328,12 @@ def __call__(self, plot):
         if iterable(self.radius):
             self.radius = plot.data.ds.quan(self.radius[0], self.radius[1])
             self.radius = np.float64(self.radius.in_units(plot.xlim[0].units))
+        if isinstance(self.radius, YTQuantity):
+            if isinstance(self.center, YTArray):
+                units = self.center.units
+            else:
+                units = 'code_length'
+            self.radius = self.radius.to(units)
 
         # This assures the radius has the appropriate size in
         # the different coordinate systems, since one cannot simply


Test patch:
Repository: yt-project/yt

Issue:
Default PhasePlot Behavior Different for Particle and Grid Datasets
### Bug report

**Bug summary**

When one creates a PhasePlot with a grid-based dataset, it defaults to using log-based axis ranges.  When one does the same script with a particle-based dataset, it uses linear axis ranges, which is usually not desired.

**Code for reproduction**

```python
import yt
ds = yt.load('FIRE_M12i_ref11/snapshot_600.hdf5')
yt.PhasePlot(ds, ('gas', 'density'), ('gas', 'temperature'), ('gas', 'mass'), weight_field=('gas', 'mass')).save()
ds = yt.load('IsolatedGalaxy/galaxy0030/galaxy0030')
yt.PhasePlot(ds, ('gas', 'density'), ('gas', 'temperature'), ('gas', 'mass'), weight_field=('gas', 'mass')).save()
```

**Actual outcome**

![galaxy0030_2d-Profile_density_temperature_mass](https://user-images.githubusercontent.com/8250999/54630703-ab5a7680-4a37-11e9-8a6d-b298b0cdf4a1.png)

![snapshot_600_2d-Profile_density_temperature_mass](https://user-images.githubusercontent.com/8250999/54630713-b0b7c100-4a37-11e9-9215-8d59cd930cd0.png)

**Expected outcome**

For both PhasePlots to be in log-space.

**Version Information**
Tip of yt-4.0: f5975b0248c9c1410992e944d97b869d90ea37c9


Discussion:

Resolving patch:
diff --git a/yt/data_objects/profiles.py b/yt/data_objects/profiles.py
--- a/yt/data_objects/profiles.py
+++ b/yt/data_objects/profiles.py
@@ -1305,8 +1305,6 @@ def create_profile(
                     "The accumulation and fractional keyword arguments must be "
                     "False for CIC deposition"
                 )
-        elif logs is None:
-            logs = {bin_fields[0]: False, bin_fields[1]: False}
         cls = ParticleProfile
     elif len(bin_fields) == 2:
         cls = Profile2D
diff --git a/yt/fields/field_info_container.py b/yt/fields/field_info_container.py
--- a/yt/fields/field_info_container.py
+++ b/yt/fields/field_info_container.py
@@ -667,4 +667,21 @@ def check_derived_fields(self, fields_to_check=None):
             dfl = filtered_dfl
 
         self.ds.derived_field_list = dfl
+        self._set_linear_fields()
         return deps, unavailable
+
+    def _set_linear_fields(self):
+        """
+        Sets which fields use linear as their default scaling in Profiles and
+        PhasePlots. Default for all fields is set to log, so this sets which
+        are linear.  For now, set linear to geometric fields: position and
+        velocity coordinates.
+        """
+        non_log_prefixes = ("", "velocity_", "particle_position_", "particle_velocity_")
+        coords = ("x", "y", "z")
+        non_log_fields = [
+            prefix + coord for prefix in non_log_prefixes for coord in coords
+        ]
+        for field in self.ds.derived_field_list:
+            if field[1] in non_log_fields:
+                self[field].take_log = False


Test patch:
Repository: yt-project/yt

Issue:
get_yt_version not working in Python 3
### Bug report

Running `yt.get_yt_version` shows the following behavior.

```
>>> import yt
>>> yt.get_yt_version()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/britton/Documents/work/yt/yt/yt/funcs.py", line 652, in get_yt_version
    return version[:12].strip().decode('utf-8')
AttributeError: 'str' object has no attribute 'decode'
```

This is on the yt dev tip with Python 3.7.1. I can take care of this, but not at the moment. I'm making this issue so I don't forget.



Discussion:

Resolving patch:
diff --git a/yt/funcs.py b/yt/funcs.py
--- a/yt/funcs.py
+++ b/yt/funcs.py
@@ -649,7 +649,10 @@ def get_yt_version():
     if version is None:
         return version
     else:
-        return version[:12].strip().decode('utf-8')
+        v_str = version[:12].strip()
+        if hasattr(v_str, 'decode'):
+            v_str = v_str.decode('utf-8')
+        return v_str
 
 def get_version_stack():
     version_info = {}


Test patch:
Repository: yt-project/yt

Issue:
Dynamic parallel objects StopIteration error in Python 3.7
### Bug report

**Bug summary**

Dynamic parallel objects would result in [`StopIteration` error stemming from a Python 3.7 new behavior](https://stackoverflow.com/a/51701040/10892982).

**Code for reproduction**

Given `test.py`:
```python
import yt
yt.enable_parallelism()

for x in yt.parallel_objects(range(10), dynamic=True):
    print(x)
```

Run:
```console
$ mpirun python test.py
```

**Actual outcome**

```console
...
  File "test.py", line 4, in <module>
    for x in yt.parallel_objects(range(10), dynamic=True):
  File "/Users/qobilidop/work/rse/yt-project/yt-dev/yt/utilities/parallel_tools/parallel_analysis_interface.py", line 481, in parallel_objects
    storage=storage):
  File "/Users/qobilidop/work/rse/yt-project/yt-dev/yt/utilities/parallel_tools/task_queue.py", line 174, in dynamic_parallel_objects
    for task in my_q:
P001 yt : [ERROR    ] 2019-05-27 12:40:34,817 RuntimeError: generator raised StopIteration
...
```

**Expected outcome**

No error.

**Version Information**

  * Python Version: 3.7
  * yt version: master branch (3.6.dev0)



Discussion:

Resolving patch:
diff --git a/yt/utilities/parallel_tools/task_queue.py b/yt/utilities/parallel_tools/task_queue.py
--- a/yt/utilities/parallel_tools/task_queue.py
+++ b/yt/utilities/parallel_tools/task_queue.py
@@ -43,7 +43,7 @@ def send_result(self, result):
             self.comm.comm.send(new_msg, dest = 0, tag=1)
         self.subcomm.barrier()
 
-    def get_next(self):
+    def __next__(self):
         msg = messages['task_req'].copy()
         if self.subcomm.rank == 0:
             self.comm.comm.send(msg, dest = 0, tag=1)
@@ -54,9 +54,11 @@ def get_next(self):
             raise StopIteration
         return msg['value']
 
+    # For Python 2 compatibility
+    next = __next__
+
     def __iter__(self):
-        while 1:
-            yield self.get_next()
+        return self
 
     def run(self, callable):
         for task in self:


Test patch:
Repository: yt-project/yt

Issue:
Quiver callback doesn't work for OffAxisProjection
Following code:

```
import yt
ds = yt.load("Enzo_64/DD0043/data0043")
s = yt.OffAxisSlicePlot(ds, [1,1,0], ["density"], center="c")
s.annotate_cquiver('cutting_plane_velocity_x', 'cutting_plane_velocity_y',
                   factor=10, plot_args={'color':'orange'})
s.zoom(1.5)
s.save()
```

yields:

![bad](https://user-images.githubusercontent.com/352673/61084189-0eab5280-a3f3-11e9-8506-09cdf3062884.png)

but it should produce:

![good](https://user-images.githubusercontent.com/352673/61084219-1a971480-a3f3-11e9-8ff3-37314c686f85.png)


Discussion:

Resolving patch:
diff --git a/yt/visualization/plot_modifications.py b/yt/visualization/plot_modifications.py
--- a/yt/visualization/plot_modifications.py
+++ b/yt/visualization/plot_modifications.py
@@ -1011,14 +1011,18 @@ def __call__(self, plot):
         pixX = np.zeros((ny, nx), dtype="f8")
         pixY = np.zeros((ny, nx), dtype="f8")
         pixelize_off_axis_cartesian(pixX,
-                               plot.data['x'], plot.data['y'], plot.data['z'],
+                               plot.data['x'].to('code_length'),
+                               plot.data['y'].to('code_length'),
+                               plot.data['z'].to('code_length'),
                                plot.data['px'], plot.data['py'],
                                plot.data['pdx'], plot.data['pdy'], plot.data['pdz'],
                                plot.data.center, plot.data._inv_mat, indices,
                                plot.data[self.field_x],
                                (x0, x1, y0, y1))
         pixelize_off_axis_cartesian(pixY,
-                               plot.data['x'], plot.data['y'], plot.data['z'],
+                               plot.data['x'].to('code_length'),
+                               plot.data['y'].to('code_length'),
+                               plot.data['z'].to('code_length'),
                                plot.data['px'], plot.data['py'],
                                plot.data['pdx'], plot.data['pdy'], plot.data['pdz'],
                                plot.data.center, plot.data._inv_mat, indices,


Test patch:
Repository: yt-project/yt

Issue:
Cmocean reversed map names are not recognised
### Bug report

**Bug summary**
Setting a cmap using a cmocean cmap name doesn't work when suffix `"_r"` is appended.


**Code for reproduction**
**note:** cmocean must be installed to reproduce.

```python
import yt
from yt.testing import fake_amr_ds

ds = fake_amr_ds()
p = yt.SlicePlot(ds, "z", "Density")
p.set_cmap("Density", "thermal")
```
works

![fake_ds_thermal_Slice_z_Density](https://user-images.githubusercontent.com/14075922/70799806-f036f200-1daa-11ea-89ce-2444f11d6880.png)

as does
```python
from cmocean.cm import thermal_r 
p.set_cmap("Density", thermal_r)
```
or equivalently
```python
p.set_cmap("Density", "cmo.thermal_r")
```
![fake_ds_thermal_r_Slice_z_Density](https://user-images.githubusercontent.com/14075922/70800103-ad294e80-1dab-11ea-8d63-9c72e3ebfa3e.png)


but
```python
p.set_cmap("Density", "thermal_r")
```
breaks. Matplotlib raises `ValueError`, but I think it's taking a wrong turn at some point because this cmap should not be looked for in Matplotlib itself.


Discussion:

Resolving patch:
diff --git a/yt/visualization/color_maps.py b/yt/visualization/color_maps.py
--- a/yt/visualization/color_maps.py
+++ b/yt/visualization/color_maps.py
@@ -301,7 +301,9 @@ def add_cmap(name, cdict):
 
 # Add colormaps from cmocean, if it's installed
 if cmocean is not None:
-    for cmname in cmocean.cm.cmapnames:
+    cmo_cmapnames = cmocean.cm.cmapnames
+    cmo_cmapnames += ["%s_r" % name for name in cmo_cmapnames]
+    for cmname in cmo_cmapnames:
         cm = getattr(cmocean.cm, cmname)
         # cmocean has a colormap named 'algae', so let's avoid overwriting
         # yt's algae or any other colormap we've already added


Test patch: