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

Issue:
Document how to do VRs with multiple fields
Originally reported by: **chummels (Bitbucket: [chummels](https://bitbucket.org/chummels), GitHub: [chummels](https://github.com/chummels))**

----------------------------------------

Perhaps adding a script to the cookbook on how to incorporate multiple fields as sources to a single rendering (a la Stella Offner's stuff on the yt gallery page), or a full script using the MultiVariateTransferFunction.

----------------------------------------
- Bitbucket: https://bitbucket.org/yt_analysis/yt/issue/675



Discussion:
*Original comment by* **chummels (Bitbucket: [chummels](https://bitbucket.org/chummels), GitHub: [chummels](https://github.com/chummels))**:

----------------------------------------

Two solutions to this problem:

1) Trying to make MultivariateTransferFunction actually work with the new VR.
2) Making a cookbook recipe demonstrating the kludgy solution of making two VRs each using a different colormap, then stacking the axes on top of each other using MPL or some sort of external program to stack the plots on top of each other.

1 is going to be hard, and should be potentially punted to 3.4, 2 shouldn't be too hard, but maybe not trivial.

*Original comment by* **Nathan Goldbaum (Bitbucket: [ngoldbaum](https://bitbucket.org/ngoldbaum), GitHub: [ngoldbaum](https://github.com/ngoldbaum))**:

----------------------------------------

MultiVariateTransferFunction really needs some love - docstrings, examples, and an improved section in the narrative docs.


Resolving patch:
diff --git a/doc/source/cookbook/render_two_fields.py b/doc/source/cookbook/render_two_fields.py
new file mode 100644
--- /dev/null
+++ b/doc/source/cookbook/render_two_fields.py
@@ -0,0 +1,27 @@
+import yt
+from yt.visualization.volume_rendering.api import Scene, VolumeSource
+
+filePath = "Sedov_3d/sedov_hdf5_chk_0003"
+ds = yt.load(filePath)
+ds.periodicity = (True, True, True)
+
+sc = Scene()
+
+# set up camera
+cam = sc.add_camera(ds, lens_type='perspective')
+cam.resolution = [400, 400]
+
+cam.position = ds.arr([1, 1, 1], 'cm')
+cam.switch_orientation()
+
+# add rendering of density field
+dens = VolumeSource(ds, field='dens')
+dens.use_ghost_zones = True
+sc.add_source(dens)
+sc.save('density.png', sigma_clip=6)
+
+# add rendering of x-velocity field
+vel = VolumeSource(ds, field='velx')
+vel.use_ghost_zones = True
+sc.add_source(vel)
+sc.save('density_any_velocity.png', sigma_clip=6)


Test patch:
Repository: yt-project/yt

Issue:
Windows test failure: alt_ray_tracers
Originally reported by: **Nathan Goldbaum (Bitbucket: [ngoldbaum](https://bitbucket.org/ngoldbaum), GitHub: [ngoldbaum](https://github.com/ngoldbaum))**

----------------------------------------

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/p8fgpx0vhx7q5098

----------------------------------------
- Bitbucket: https://bitbucket.org/yt_analysis/yt/issue/1254



Discussion:

Resolving patch:
diff --git a/yt/geometry/coordinates/cartesian_coordinates.py b/yt/geometry/coordinates/cartesian_coordinates.py
--- a/yt/geometry/coordinates/cartesian_coordinates.py
+++ b/yt/geometry/coordinates/cartesian_coordinates.py
@@ -149,7 +149,7 @@ def _ortho_pixelize(self, data_source, field, bounds, size, antialias,
         return buff
             
     def _oblique_pixelize(self, data_source, field, bounds, size, antialias):
-        indices = np.argsort(data_source['pdx'])[::-1]
+        indices = np.argsort(data_source['pdx'])[::-1].astype(np.int_)
         buff = np.zeros((size[1], size[0]), dtype="f8")
         pixelize_off_axis_cartesian(buff,
                               data_source['x'], data_source['y'],
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
@@ -851,7 +851,7 @@ def __call__(self, plot):
         yy0, yy1 = plot._axes.get_ylim()
         nx = plot.image._A.shape[1] // self.factor
         ny = plot.image._A.shape[0] // self.factor
-        indices = np.argsort(plot.data['dx'])[::-1]
+        indices = np.argsort(plot.data['dx'])[::-1].astype(np.int_)
 
         pixX = np.zeros((ny, nx), dtype="f8")
         pixY = np.zeros((ny, nx), dtype="f8")


Test patch:
Repository: yt-project/yt

Issue:
Make the readme fancier
Now that we're on github we should think about making our readme fancier. Things to include:

* Images (e.g. the yt logo, example outputs)
* Badges (e.g. CI passing badges)
* What is yt?
* Basic installation instructions
* Links to info on documentation, community, testing, contributing


Discussion:

Resolving patch:
diff --git a/setup.py b/setup.py
--- a/setup.py
+++ b/setup.py
@@ -37,6 +37,12 @@
 if os.path.exists('MANIFEST'):
     os.remove('MANIFEST')
 
+try:
+    import pypandoc
+    long_description = pypandoc.convert_file('README.md', 'rst')
+except (ImportError, IOError):
+    with open('README.md') as file:
+        long_description = file.read()
 
 if check_for_openmp() is True:
     omp_args = ['-fopenmp']
@@ -328,7 +334,22 @@ class sdist(_sdist):
     # subclass setuptools source distribution builder to ensure cython
     # generated C files are included in source distribution.
     # See http://stackoverflow.com/a/18418524/1382869
+    # subclass setuptools source distribution builder to ensure cython
+    # generated C files are included in source distribution and readme
+    # is converted from markdown to restructured text.  See
+    # http://stackoverflow.com/a/18418524/1382869
     def run(self):
+        # Make sure the compiled Cython files in the distribution are
+        # up-to-date
+
+        try:
+            import pypandoc
+        except ImportError:
+            raise RuntimeError(
+                'Trying to create a source distribution without pypandoc. '
+                'The readme will not render correctly on pypi without '
+                'pypandoc so we are exiting.'
+            )
         # Make sure the compiled Cython files in the distribution are up-to-date
         from Cython.Build import cythonize
         cythonize(cython_extensions)
@@ -338,6 +359,7 @@ def run(self):
     name="yt",
     version=VERSION,
     description="An analysis and visualization toolkit for volumetric data",
+    long_description = long_description,
     classifiers=["Development Status :: 5 - Production/Stable",
                  "Environment :: Console",
                  "Intended Audience :: Science/Research",


Test patch:
Repository: yt-project/yt

Issue:
help(yt) via `__init__.py` refers to Enzo
The module-level docstring in `yt/__init__.py` says:

```
YT is a package written primarily in Python designed to make the task of
running Enzo easier.  It contains facilities for creating Enzo data (currently
in prototype form) as well as runnning Enzo simulations, simulating the actions
of Enzo on various existing data, and analyzing output from Enzo in a
wide-variety of methods.
```

This should be updated to reflect the fact that the code has grown beyond Enzo


Discussion:

Resolving patch:
diff --git a/yt/__init__.py b/yt/__init__.py
--- a/yt/__init__.py
+++ b/yt/__init__.py
@@ -1,66 +1,10 @@
 """
-YT is a package written primarily in Python designed to make the task of
-running Enzo easier.  It contains facilities for creating Enzo data (currently
-in prototype form) as well as runnning Enzo simulations, simulating the actions
-of Enzo on various existing data, and analyzing output from Enzo in a
-wide-variety of methods.
-
-An ever-growing collection of documentation is also available at
-http://yt-project.org/doc/ . Additionally, there is a
-project site at http://yt-project.org/ with recipes, a wiki, a variety of
-ways of peering into the version control, and a bug-reporting system.
-
-YT is divided into several packages.
-
-frontends
----------
-
-This is where interfaces to codes are created.  Within each subdirectory of
-yt/frontends/ there must exist the following files, even if empty:
-
-* data_structures.py, where subclasses of AMRGridPatch, Dataset and
-  AMRHierarchy are defined.
-* io.py, where a subclass of IOHandler is defined.
-* misc.py, where any miscellaneous functions or classes are defined.
-* definitions.py, where any definitions specific to the frontend are
-  defined.  (i.e., header formats, etc.)
-
-visualization
--------------
-
-This is where all visualization modules are stored.  This includes plot
-collections, the volume rendering interface, and pixelization frontends.
-
-data_objects
-------------
-
-All objects that handle data, processed or unprocessed, not explicitly
-defined as visualization are located in here.  This includes the base
-classes for data regions, covering grids, time series, and so on.  This
-also includes derived fields and derived quantities.
-
-analysis_modules
-----------------
-
-This is where all mechanisms for processing data live.  This includes
-things like clump finding, halo profiling, halo finding, and so on.  This
-is something of a catchall, but it serves as a level of greater
-abstraction that simply data selection and modification.
-
-gui
----
-
-This is where all GUI components go.  Typically this will be some small
-tool used for one or two things, which contains a launching mechanism on
-the command line.
-
-utilities
----------
-
-All broadly useful code that doesn't clearly fit in one of the other
-categories goes here.
-
+yt is a toolkit for analyzing and visualizing volumetric data.
 
+* Website: http://yt-project.org
+* Documentation: http://yt-project.org/doc
+* Data hub: http://hub.yt
+* Contribute: http://github.com/yt-project/yt
 
 """
 


Test patch:
Repository: yt-project/yt

Issue:
Off-axis projection artifacts for SPH data
Off-axis projections for SPH data have artifacts that seem to be due to an F/C ordering issue.

<!--A short 1-2 sentences that succinctly describes the bug-->

**Code for reproduction**

<!--A minimum code snippet required to reproduce the bug, also minimizing the
number of dependencies required.-->

<!-- If you need to use a data file to trigger the issue you're having, consider
using one of the datasets from the yt data hub (http://yt-project.org/data). If
your issue cannot be triggered using a public dataset, you can use the yt
curldrop (https://docs.hub.yt/services.html#curldrop) to share data
files. Please include a link to the dataset in the issue if you use the
curldrop.-->

```python
import yt

# download with $ curl -JO http://use.yt/upload/c7c0d617
fname = "snap_206.hdf5"
unit_base = {'UnitLength_in_cm': 3.08568e+21,
             'UnitMass_in_g':   1.989e+43,
             'UnitVelocity_in_cm_per_s':  100000}
bbox_lim = 1e5   # kpc
bbox = [[-bbox_lim, bbox_lim],
        [-bbox_lim, bbox_lim],
        [-bbox_lim, bbox_lim]]

ds = yt.load(fname, unit_base=unit_base, bounding_box=bbox)

pz = yt.ProjectionPlot(ds, 'z', ('gas', 'density'), width=(1, 'Mpc'))
pz.save()

L = [0, 0, 1]
north_vector = [0, 1, 0]
pz = yt.OffAxisProjectionPlot(ds, L, ('gas', 'density'), width=(1, 'Mpc'))
pz.save()
```

**Actual outcome**

<!--The output produced by the above code, which may be a screenshot, console
output, etc.-->

axis-aligned: http://i.imgur.com/ddKkxaC.png
off-axis:  http://i.imgur.com/mhWR2NL.png

**Expected outcome**

These images should look identical.

**Version Information**
<!--Please specify your platform and versions of the relevant libraries you are
using:-->
  * Operating System: MacOS
  * Python Version: 3.5
  * yt version: latest master
 




Discussion:
As Matt commented in the mailing list thread, making the following modification seems to fix things:

```
diff --git a/yt/data_objects/octree_subset.py b/yt/data_objects/octree_subset.py
index 342737e..030eea0 100644
--- a/yt/data_objects/octree_subset.py
+++ b/yt/data_objects/octree_subset.py
@@ -448,7 +448,7 @@ class OctreeSubsetBlockSlicePosition(object):
         rv = bs.octree_subset[key][:,:,:,self.ind]
         if bs.octree_subset._block_reorder:
             rv = rv.copy(order=bs.octree_subset._block_reorder)
-        return rv
+        return rv.T

     @property
     def id(self):
```
Many thanks, that worked! Now these images looked nearly identical。

Resolving patch:
diff --git a/yt/data_objects/octree_subset.py b/yt/data_objects/octree_subset.py
--- a/yt/data_objects/octree_subset.py
+++ b/yt/data_objects/octree_subset.py
@@ -445,7 +445,7 @@ def __init__(self, ind, block_slice):
 
     def __getitem__(self, key):
         bs = self.block_slice
-        rv = bs.octree_subset[key][:,:,:,self.ind]
+        rv = bs.octree_subset[key][:,:,:,self.ind].T
         if bs.octree_subset._block_reorder:
             rv = rv.copy(order=bs.octree_subset._block_reorder)
         return rv


Test patch:
Repository: yt-project/yt

Issue:
AHF answer tests are flaky
We're seeing random failures from the AHF answer tests on some PRs.

See e.g. https://tests.yt-project.org/job/yt_py3_git/414/.




Discussion:
Ping @qobilidop.
Looks like [the `h=0.7` difference](https://github.com/yt-project/yt/commit/7e7832b45ba9bfc0b1bf9f8d085a1453144003b9). I tried to update the answer tests in this [commit](https://github.com/yt-project/yt/commit/cb18d7aed74838cebe5588e46685d61ad2ca776f). Maybe this is not done correctly?
Hmm, odd, maybe there was a cache issue. Let me see if I can reproduce this on the test box.

Resolving patch:
diff --git a/yt/frontends/ahf/data_structures.py b/yt/frontends/ahf/data_structures.py
--- a/yt/frontends/ahf/data_structures.py
+++ b/yt/frontends/ahf/data_structures.py
@@ -156,3 +156,7 @@ def _read_parameter(self):
                     except:
                         pass
         return param
+
+    @property
+    def _skip_cache(self):
+        return True


Test patch:
diff --git a/tests/tests.yaml b/tests/tests.yaml
--- a/tests/tests.yaml
+++ b/tests/tests.yaml
@@ -35,7 +35,7 @@ answer_tests:
   local_gizmo_002:
     - yt/frontends/gizmo/tests/test_outputs.py
 
-  local_halos_003:
+  local_halos_004:
     - yt/analysis_modules/halo_analysis/tests/test_halo_finders.py  # [py2]
     - yt/analysis_modules/halo_finding/tests/test_rockstar.py  # [py2]
     - yt/frontends/ahf/tests/test_outputs.py
diff --git a/yt/frontends/ahf/tests/test_outputs.py b/yt/frontends/ahf/tests/test_outputs.py
--- a/yt/frontends/ahf/tests/test_outputs.py
+++ b/yt/frontends/ahf/tests/test_outputs.py
@@ -38,7 +38,7 @@ def test_fields_ahf_halos():
     ds = load(ahf_halos)
     assert_equal(str(ds), os.path.basename(ahf_halos))
     for field in _fields:
-        yield FieldValuesTest(ahf_halos, field, particle_type=True)
+        yield FieldValuesTest(ds, field, particle_type=True)
 
 
 @requires_file(ahf_halos)
Repository: yt-project/yt

Issue:
potential problem with zooming in axisymmetric coords
I'm trying to set the center and width for a 2-d slice plot of axisymmetric data, but it does not seem to work correctly. 

**Code for reproduction**
```
import yt
from yt.units import cm

ds = yt.load("plt06677")

print(ds.domain_left_edge)
print(ds.domain_right_edge)

xctr = 0.5*(ds.domain_left_edge[0] + ds.domain_right_edge[0])
yctr = 5000*cm

xwidth = ds.domain_right_edge[0] - ds.domain_left_edge[0]
ywidth = 1.e4*cm

print(yctr - 0.5*ywidth, yctr + 0.5*ywidth)

#slc = yt.SlicePlot(ds, "theta", "temperature", origin="native",
#                   center=(xctr,yctr,0.0), width=(xwidth,ywidth))

slc = yt.plot_2d(ds, "temperature", origin="native",
                   center=(xctr,yctr), width=(xwidth,ywidth))

slc.save("test.png")
```

a datafile can be found here:

http://bender.astro.sunysb.edu/random/plt06677.tgz

(400 MB)

**Actual outcome**

It produced the following plot:
![test](https://user-images.githubusercontent.com/7817509/31736148-f3a43d62-b411-11e7-8fc1-19cd7df3a446.png)


**Expected outcome**

It should have the y (vertical) scale run from 0 to 1.e4 cm.

**Version Information**
<!--Please specify your platform and versions of the relevant libraries you are
using:-->
  * Operating System: Fedora 26
  * Python Version: 3.6.2
  * yt version: 3.5.dev0
  * Other Libraries (if applicable): 

<!--Please tell us how you installed yt and python e.g., from source,
pip, conda. If you installed from conda, please specify which channel you used
if not the default-->

installed from source



Discussion:
Just to clarify, the plot you want has the `r` axis running from 0 to ~8.2*10^4 and the `z` axis running from 0 to 10^4?
yes.

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
@@ -187,15 +187,11 @@ def sanitize_center(self, center, axis):
         theta_ax = self.axis_id['theta']
         z_ax = self.axis_id['z']
         if ax_name == "r":
-            # zeros everywhere
             display_center[theta_ax] = self.ds.domain_center[theta_ax]
             display_center[z_ax] = self.ds.domain_center[z_ax]
         elif ax_name == "theta":
-            # Note we are using domain_right_edge, not domain_width, so that in
-            # cases where DLE is not zero we go to the inner edge.
-            display_center[r_ax] = self.ds.domain_right_edge[r_ax]/2.0
-            display_center[z_ax] = self.ds.domain_center[z_ax]
-            # zeros for the others
+            # use existing center value
+            for idx in (r_ax, z_ax): display_center[idx] = center[idx]
         return center, display_center
 
     def sanitize_width(self, axis, width, depth):


Test patch:
Repository: yt-project/yt

Issue:
Quivers do not appear to respect setting widths manually in SlicePlots
Setting the width of a `SlicePlot` manually, either in the initialization or later using the `set_width` method, results in quiver plots that are not consistent with the spatial locations on which they are overlaid.

Calling `SlicePlot.zoom()` appears to preserve the correct quivers, however. 

Notebook that demonstrates this shown here:
https://gist.github.com/434c7bcdf1cbcf3c92555f031a2551ac


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
@@ -382,8 +382,8 @@ def __init__(self, field_x, field_y, factor=16, scale=None,
         self.normalize = normalize
 
     def __call__(self, plot):
-        x0, x1 = plot.xlim
-        y0, y1 = plot.ylim
+        x0, x1 = [p.to('code_length') for p in plot.xlim]
+        y0, y1 = [p.to('code_length') for p in plot.ylim]
         xx0, xx1 = plot._axes.get_xlim()
         yy0, yy1 = plot._axes.get_ylim()
         # See the note about rows/columns in the pixelizer for more information
@@ -843,8 +843,8 @@ def __init__(self, field_x, field_y, factor=16, scale=None,
         self.normalize = normalize
 
     def __call__(self, plot):
-        x0, x1 = plot.xlim
-        y0, y1 = plot.ylim
+        x0, x1 = [p.to('code_length') for p in plot.xlim]
+        y0, y1 = [p.to('code_length') for p in plot.ylim]
         xx0, xx1 = plot._axes.get_xlim()
         yy0, yy1 = plot._axes.get_ylim()
         nx = plot.image._A.shape[1] // self.factor


Test patch:
Repository: yt-project/yt

Issue:
ParticleIDs loaded from Gadget binary snapshots are wrong
### Bug report

**Bug summary**

ParticlesIDs are expected to be unique. But when loaded from a Gadget binary snapshot, the uniqueness is lost. This is likely to be caused by wrong assumptions of dtype during data loading.

**Code for reproduction**

```python
import yt

ds = yt.load('Gadget3-snap-format2/Gadget3-snap-format2')
ad = ds.all_data()
pid = ad['ParticleIDs']
print(len(pid), len(set(pid.v)))
```

**Actual outcome**

```
1370393 1201707
```

**Expected outcome**

```
1370393 1370393
```

I've done a test to first convert the snapshot to HDF5 and then do the same thing. It does yield the expected outcome.


Discussion:
So this line is causing the trouble:
https://github.com/yt-project/yt/blob/68b0e8f342bfadf188d02f8ae8696d3e81dee6ae/yt/frontends/gadget/io.py#L326

If changed to `return arr`, the expected outcome would be recovered. For `ParticleIDs`, this line converts the `dtype` from `uint32` to `float32`, during which the uniqueness is lost.
Clearly it's not correct to interpret an integer field as float32. We probably need a mapping from field names to field dtypes, e.g. expandings the listings in `yt/frontends/gadget/definitions.py` to be dictionaries mapping field names to field dtypes and then use those dtypes at I/O time.
@ngoldbaum I agree that would be the long-term solution. For a short-term fix, would you be okay with simply changing that one line? I do think the `astype` part is redundant, because in previous lines `dtype` is already set to `dt` which would be `self._float_type` except for `ParticleIDs`.
Fair enough. I didn't notice the existing special-casing for Particle IDs above. +1 to just removing the astype call.

Resolving patch:
diff --git a/yt/frontends/gadget/io.py b/yt/frontends/gadget/io.py
--- a/yt/frontends/gadget/io.py
+++ b/yt/frontends/gadget/io.py
@@ -323,7 +323,7 @@ def _read_field_from_file(self, f, count, name):
         if name in self._vector_fields:
             factor = self._vector_fields[name]
             arr = arr.reshape((count // factor, factor), order="C")
-        return arr.astype(self._float_type)
+        return arr
 
     def _get_morton_from_position(self, data_file, count, offset_count,
                                   regions, DLE, DRE):


Test patch:
diff --git a/yt/frontends/gadget/tests/test_outputs.py b/yt/frontends/gadget/tests/test_outputs.py
--- a/yt/frontends/gadget/tests/test_outputs.py
+++ b/yt/frontends/gadget/tests/test_outputs.py
@@ -76,3 +76,14 @@ def test_iso_collapse():
     for test in sph_answer(ds, 'snap_505', 2**17, iso_fields):
         test_iso_collapse.__name__ = test.description
         yield test
+
+
+@requires_ds(LE_SnapFormat2)
+def test_pid_uniqueness():
+    """
+    ParticleIDs should be unique.
+    """
+    ds = data_dir_load(LE_SnapFormat2)
+    ad = ds.all_data()
+    pid = ad['ParticleIDs']
+    assert len(pid) == len(set(pid.v))