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

Issue:
repr for particle unions
The `__repr__` for particle unions should include the contents of `sub_types`


Discussion:

Resolving patch:
diff --git a/yt/data_objects/particle_unions.py b/yt/data_objects/particle_unions.py
--- a/yt/data_objects/particle_unions.py
+++ b/yt/data_objects/particle_unions.py
@@ -1,5 +1,6 @@
 from .unions import Union
 
 class ParticleUnion(Union):
+    _union_type = "particle"
     def __init__(self, name, sub_types):
         super(ParticleUnion, self).__init__(name, sub_types)
diff --git a/yt/data_objects/unions.py b/yt/data_objects/unions.py
--- a/yt/data_objects/unions.py
+++ b/yt/data_objects/unions.py
@@ -1,6 +1,7 @@
 from yt.funcs import ensure_list
 
 class Union(object):
+    _union_type = ""
     def __init__(self, name, sub_types):
         self.name = name
         self.sub_types = ensure_list(sub_types)
@@ -9,6 +10,11 @@ def __iter__(self):
         for st in self.sub_types:
             yield st
 
+    def __repr__(self):
+        return "{} Union: '{}' composed of: {}".format(
+            self._union_type.capitalize(), self.name, self.sub_types)
+
 class MeshUnion(Union):
+    _union_type = "mesh"
     def __init__(self, name, sub_types):
         super(MeshUnion, self).__init__(name, sub_types)


Test patch:
Repository: yt-project/yt

Issue:
Bug: colormap turbo_r is not properly registered
### Bug report

**Bug summary**

turbo was recently added to yt, however its reversed version "turbo_r" is currently not available, which breaks the symmetry with core matplotlib and yt's own colormaps api.

**Code for reproduction**

```python
import yt
ds = yt.testing.fake_amr_ds()
p = yt.SlicePlot(ds, "z", "Density")
p.set_cmap('Density', 'turbo_r')
```

**Actual outcome**

```
ValueError: Colormap turbo_r is not recognized. Possible values are: ...
```


Discussion:
relevant PRs:
https://github.com/yt-project/yt/pull/2339
https://github.com/yt-project/yt/pull/2390

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
@@ -305,6 +305,13 @@ def add_colormap(name, cdict):
 
 add_colormap("turbo", _turbo_data)
 
+_turbo_r_colormap_data = np.flip(_turbo_colormap_data, axis=0)
+_turbo_r_data = dict((color, np.transpose([_tvals,
+                             _turbo_r_colormap_data[:, i],
+                             _turbo_r_colormap_data[:, i]]))
+       for i, color in enumerate(['red', 'green', 'blue']))
+add_colormap("turbo_r", _turbo_r_data)
+
 # Add colormaps from cmocean, if it's installed
 if cmocean is not None:
     cmo_cmapnames = cmocean.cm.cmapnames


Test patch:
Repository: yt-project/yt

Issue:
Add tab-completion for fields
Data objects all define a `__getitem__` method, which accepts fields from the dataset `field_list` and `derived_field_list`.  This list can be enormously long, however.  IPython (5.0+) defines a very straightforward way of constructing tab completions which we could utilize:

https://ipython.readthedocs.io/en/stable/config/integrating.html#tab-completion

Defining this on the base object would make it much simpler to navigate large lists of fields.


Discussion:
I can take this one!

Resolving patch:
diff --git a/yt/data_objects/data_containers.py b/yt/data_objects/data_containers.py
--- a/yt/data_objects/data_containers.py
+++ b/yt/data_objects/data_containers.py
@@ -74,6 +74,14 @@ def sanitize_weight_field(ds, field, weight):
         weight_field = weight
     return weight_field
 
+def _get_ipython_key_completion(ds):
+    # tuple-completion (ftype, fname) was added in IPython 8.0.0
+    # with earlier versions, completion works with fname only
+    # this implementation should work transparently with all IPython versions
+    tuple_keys = ds.field_list + ds.derived_field_list
+    fnames = list(set(k[1] for k in tuple_keys))
+    return tuple_keys + fnames
+
 class RegisteredDataContainer(type):
     def __init__(cls, name, b, d):
         type.__init__(cls, name, b, d)
@@ -257,8 +265,9 @@ def __getitem__(self, key):
         # hanging off the dataset to define this unit object.
         # Note that this is less succinct so that we can account for the case
         # when there are, for example, no elements in the object.
-        rv = self.field_data.get(f, None)
-        if rv is None:
+        try:
+            rv = self.field_data[f]
+        except KeyError:
             if isinstance(f, tuple):
                 fi = self.ds._get_field_info(*f)
             elif isinstance(f, bytes):
@@ -266,6 +275,9 @@ def __getitem__(self, key):
             rv = self.ds.arr(self.field_data[key], fi.units)
         return rv
 
+    def _ipython_key_completions_(self):
+        return _get_ipython_key_completion(self.ds)
+
     def __setitem__(self, key, val):
         """
         Sets a field to be some other value.
diff --git a/yt/data_objects/region_expression.py b/yt/data_objects/region_expression.py
--- a/yt/data_objects/region_expression.py
+++ b/yt/data_objects/region_expression.py
@@ -4,6 +4,7 @@
 from yt.units.yt_array import YTQuantity
 from yt.utilities.exceptions import YTDimensionalityError
 from yt.visualization.line_plot import LineBuffer
+from .data_containers import _get_ipython_key_completion
 
 class RegionExpression(object):
     _all_data = None
@@ -63,6 +64,9 @@ def __getitem__(self, item):
                 return self.all_data
             return self._create_region(item)
 
+    def _ipython_key_completions_(self):
+        return _get_ipython_key_completion(self.ds)
+
     def _spec_to_value(self, input):
         if isinstance(input, tuple):
             v = self.ds.quan(input[0], input[1]).to("code_length")


Test patch:
Repository: yt-project/yt

Issue:
Saving multiple YTArrays to a single hdf clobbers the file
Writing more than one YTArray to a single hdf5 file clobbers the file during each write.

**Code for reproduction**
Taken straight from http://yt-project.org/docs/dev/analyzing/units/symbolic_units.html with minor modifications:

```python
import numpy as np
from yt.units.yt_array import YTArray

my_dens = YTArray(np.random.random(10), 'Msun/kpc**3')
my_temp = YTArray(np.random.random(10), 'K')
my_dens.write_hdf5("my_data.h5", dataset_name="density")
my_temp.write_hdf5("my_data.h5", dataset_name="temperature")
read_dens = YTArray.from_hdf5("my_data.h5", dataset_name="density")
print(read_dens)
print(my_dens)
```

**Actual outcome**
```
Traceback (most recent call last):
  File "/tmp/ala.py", line 8, in <module>
    read_dens = YTArray.from_hdf5("my_data.h5", dataset_name="density")
  File "/home/xarth/codes/xarthisius/yt/yt/units/yt_array.py", line 1019, in from_hdf5
    dataset = g[dataset_name]
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "/home/xarth/.local/lib/python3.6/site-packages/h5py/_hl/group.py", line 264, in __getitem__
    oid = h5o.open(self.id, self._e(name), lapl=self._lapl)
  File "h5py/_objects.pyx", line 54, in h5py._objects.with_phil.wrapper
  File "h5py/_objects.pyx", line 55, in h5py._objects.with_phil.wrapper
  File "h5py/h5o.pyx", line 190, in h5py.h5o.open
KeyError: "Unable to open object (object 'density' doesn't exist)"
```

**Expected outcome**

```
[0.15325644 0.06909042 0.13625627 0.79578573 0.97937465 0.53984921
 0.63471635 0.35383393 0.23706361 0.42651924] Msun/kpc**3
[0.15325644 0.06909042 0.13625627 0.79578573 0.97937465 0.53984921
 0.63471635 0.35383393 0.23706361 0.42651924] Msun/kpc**3
```

**Version Information**
  * Operating System: Ubuntu 18.04.4 LTS
  * Python Version: 3.6.9
  * yt version: yt-3.5.1-1372-g1f4051157


Discussion:

Resolving patch:
diff --git a/yt/units/yt_array.py b/yt/units/yt_array.py
--- a/yt/units/yt_array.py
+++ b/yt/units/yt_array.py
@@ -962,7 +962,7 @@ def write_hdf5(self, filename, dataset_name=None, info=None, group_name=None):
         if dataset_name is None:
             dataset_name = 'array_data'
 
-        f = h5py.File(filename, "w")
+        f = h5py.File(filename, mode="a")
         if group_name is not None:
             if group_name in f:
                 g = f[group_name]


Test patch:
Repository: yt-project/yt

Issue:
FutureWarning from numpy
### Bug report

**Bug summary**
This is showing up on Jenkins (`yt_py38_git`), with two occurrences
```
yt.utilities.tests.test_minimal_representation.test_store ... yt : [INFO     ] 2021-02-22 16:45:55,215 Parameters: current_time              = 0.0060000200028298
yt : [INFO     ] 2021-02-22 16:45:55,215 Parameters: domain_dimensions         = [32 32 32]
yt : [INFO     ] 2021-02-22 16:45:55,215 Parameters: domain_left_edge          = [0. 0. 0.]
yt : [INFO     ] 2021-02-22 16:45:55,215 Parameters: domain_right_edge         = [1. 1. 1.]
yt : [INFO     ] 2021-02-22 16:45:55,216 Parameters: cosmological_simulation   = 0.0
yt : [INFO     ] 2021-02-22 16:45:55,318 Gathering a field list (this may take a moment.)
yt : [INFO     ] 2021-02-22 16:45:57,673 Projection completed
FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
```

It's not completely clear what test is hitting this (without further inspection), but it likely lives somewhere in `yt/utilities/tests/`


Discussion:
```
yt/funcs.py:123: FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
  comparison = (dict1[key] == dict2[key]).all()
yt/funcs.py:125: FutureWarning: elementwise comparison failed; returning scalar instead, but in the future will perform elementwise comparison
  comparison = dict1[key] == dict2[key]
```

Resolving patch:
diff --git a/yt/funcs.py b/yt/funcs.py
--- a/yt/funcs.py
+++ b/yt/funcs.py
@@ -120,8 +120,8 @@ def compare_dicts(dict1, dict2):
                 else:
                     return False
             try:
-                comparison = (dict1[key] == dict2[key]).all()
-            except AttributeError:
+                comparison = np.array_equal(dict1[key], dict2[key])
+            except TypeError:
                 comparison = dict1[key] == dict2[key]
             if not comparison:
                 return False


Test patch:
Repository: yt-project/yt

Issue:
Field detection hardcodes vector fields
As discovered by @Xarthisius while working with @jcoughlin11 , the current field detection method hardcodes the names of possible vector fields. This leads to not detecting aliases for common names like `positions`.

It should be possible to check the vector field list, since that ought to be available at runtime through the `io` object.


Discussion:

Resolving patch:
diff --git a/yt/fields/field_detector.py b/yt/fields/field_detector.py
--- a/yt/fields/field_detector.py
+++ b/yt/fields/field_detector.py
@@ -3,6 +3,7 @@
 import numpy as np
 
 from yt.units.yt_array import YTArray
+from yt.utilities.io_handler import io_registry
 
 from .field_exceptions import NeedsGridType
 
@@ -146,24 +147,17 @@ def __missing__(self, item):
                     self[item] = vv.ravel()
                 return self[item]
         elif finfo is not None and finfo.sampling_type == "particle":
-            if (
-                "particle_position" in (item, item[1])
-                or "particle_velocity" in (item, item[1])
-                or "particle_magnetic_field" in (item, item[1])
-                or "Velocity" in (item, item[1])
-                or "Velocities" in (item, item[1])
-                or "Coordinates" in (item, item[1])
-                or "MagneticField" in (item, item[1])
+            io = io_registry[self.ds.dataset_type](self.ds)
+            if hasattr(io, "_vector_fields") and (
+                item in io._vector_fields or item[1] in io._vector_fields
             ):
+                try:
+                    cols = io._vector_fields[item]
+                except KeyError:
+                    cols = io._vector_fields[item[1]]
                 # A vector
                 self[item] = YTArray(
-                    np.ones((self.NumberOfParticles, 3)),
-                    finfo.units,
-                    registry=self.ds.unit_registry,
-                )
-            elif "FourMetalFractions" in (item, item[1]):
-                self[item] = YTArray(
-                    np.ones((self.NumberOfParticles, 4)),
+                    np.ones((self.NumberOfParticles, cols)),
                     finfo.units,
                     registry=self.ds.unit_registry,
                 )
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
@@ -14,7 +14,7 @@
 
 class IOHandlerGadgetHDF5(IOHandlerSPH):
     _dataset_type = "gadget_hdf5"
-    _vector_fields = ("Coordinates", "Velocity", "Velocities")
+    _vector_fields = ("Coordinates", "Velocity", "Velocities", "MagneticField")
     _known_ptypes = gadget_hdf5_ptypes
     _var_mass = None
     _element_names = (
@@ -304,6 +304,7 @@ class IOHandlerGadgetBinary(IOHandlerSPH):
         ("Coordinates", 3),
         ("Velocity", 3),
         ("Velocities", 3),
+        ("MagneticField", 3),
         ("FourMetalFractions", 4),
     )
 


Test patch:
Repository: yt-project/yt

Issue:
set_background_color no longer works for cmocean colormaps
### Bug report

**Bug summary**

Something about the changes in PR #3175 seems to have broken `set_background_color` when using cmocean colormaps.  

**Code for reproduction**

This script used to work:

```
import yt

ds = yt.testing.fake_amr_ds()
p = yt.SlicePlot(ds, "z", 'Density')
p.set_cmap('all', "balance")
p.set_background_color('Density')
```

After applying the changes described in PR #3175 and now documented in PR #3207, this script show now look like this:

```
import yt
import cmocean

ds = yt.testing.fake_amr_ds()
p = yt.SlicePlot(ds, "z", 'Density')
p.set_cmap('all', "cmo.balance")
p.set_background_color('Density')
```

But it fails with this error:

```
Traceback (most recent call last):
  File "/Users/chummels/src/yt/yt/visualization/plot_container.py", line 896, in set_background_color
    cmap = yt_colormaps[cmap]
KeyError: 'cmo.balance'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "cmo_test.py", line 7, in <module>
    p.set_background_color('Density')
  File "/Users/chummels/src/yt/yt/visualization/plot_container.py", line 105, in newfunc
    func(self, f, *args, **kwargs)
  File "/Users/chummels/src/yt/yt/visualization/plot_container.py", line 56, in newfunc
    rv = f(*args, **kwargs)
  File "/Users/chummels/src/yt/yt/visualization/plot_container.py", line 898, in set_background_color
    cmap = getattr(matplotlib.cm, cmap)
AttributeError: module 'matplotlib.cm' has no attribute 'cmo.balance'
```



Discussion:
Weird... the good news is that the traceback correctly points to the exact line that's buggy. I'll try to fix this later today, thank you so much for reporting !

Resolving patch:
diff --git a/yt/visualization/plot_container.py b/yt/visualization/plot_container.py
--- a/yt/visualization/plot_container.py
+++ b/yt/visualization/plot_container.py
@@ -6,6 +6,7 @@
 
 import matplotlib
 import numpy as np
+from matplotlib.cm import get_cmap
 from more_itertools.more import always_iterable
 
 from yt._maintenance.deprecation import issue_deprecation_warning
@@ -16,7 +17,6 @@
 from yt.units.unit_object import Unit
 from yt.utilities.definitions import formatted_length_unit_names
 from yt.utilities.exceptions import YTNotInsideNotebook
-from yt.visualization.color_maps import yt_colormaps
 
 from ._commons import validate_image_name
 
@@ -892,10 +892,7 @@ def set_background_color(self, field, color=None):
         if color is None:
             cmap = self._colormap_config[field]
             if isinstance(cmap, str):
-                try:
-                    cmap = yt_colormaps[cmap]
-                except KeyError:
-                    cmap = getattr(matplotlib.cm, cmap)
+                cmap = get_cmap(cmap)
             color = cmap(0)
         self._background_color[field] = color
         return self


Test patch:
Repository: yt-project/yt

Issue:
A visible deprecation warning in CI
### Bug report

**Bug summary**
We have one test that triggers a VisibleDeprecationWarning from numpy via unyt.
I'm not sure atm where the problem should be addressed:
- in the test itself ?
- in the yt code under test ?
- in unyt ?

**Code for reproduction**

```shell
pytest yt/data_objects/tests/test_derived_quantities.py::test_in_memory_sph_derived_quantities
```

**Actual outcome**

```
.../python3.9/site-packages/unyt/array.py:250: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray.
    return unyt_array(np.array(input_object), ff, registry=registry)
```
This error is visible in our non minimal GH CI workflows.


Discussion:

Resolving patch:
diff --git a/yt/data_objects/derived_quantities.py b/yt/data_objects/derived_quantities.py
--- a/yt/data_objects/derived_quantities.py
+++ b/yt/data_objects/derived_quantities.py
@@ -201,11 +201,11 @@ def __call__(self):
         if ("gas", "mass") in fi:
             gas = super().__call__([("gas", "mass")])
         else:
-            gas = self.data_source.ds.arr([0], "g")
+            gas = self.data_source.ds.quan(0.0, "g")
         if ("nbody", "particle_mass") in fi:
             part = super().__call__([("nbody", "particle_mass")])
         else:
-            part = self.data_source.ds.arr([0], "g")
+            part = self.data_source.ds.quan(0.0, "g")
         return self.data_source.ds.arr([gas, part])
 
 


Test patch:
Repository: yt-project/yt

Issue:
Reminder: remove dead module mods
As discussed in #3083, the `mods.py` module should be removed **after the 4.0 release**.



Discussion:

Resolving patch:
diff --git a/yt/mods.py b/yt/mods.py
--- a/yt/mods.py
+++ b/yt/mods.py
@@ -13,9 +13,14 @@
 # https://mail.python.org/archives/list/yt-dev@python.org/thread/L6AQPJ3OIMJC5SNKVM7CJG32YVQZRJWA/
 import yt.startup_tasks as __startup_tasks
 from yt import *
+from yt._maintenance.deprecation import issue_deprecation_warning
 from yt.config import ytcfg, ytcfg_defaults
 from yt.utilities.logger import _level
 
+issue_deprecation_warning(
+    "The yt.mods module is deprecated.", since="4.1.0", removal="4.2.0"
+)
+
 unparsed_args = __startup_tasks.unparsed_args
 
 


Test patch:
Repository: yt-project/yt

Issue:
load_sample: keyword-only arguments
### Bug report

**Bug summary**

The signature in yt.load_sample should be updated from
```python
def load_sample(
    fn: Optional[str] = None, progressbar: bool = True, timeout=None, **kwargs
):
```
to
```python
def load_sample(
    fn: Optional[str] = None, *, progressbar: bool = True, timeout=None, **kwargs
):
```
Rationale: there are reminiscent calls to load_sample in our cookbooks using the original signature, where the second positional argument was `specific_file`, which is now effectively evaluated as a bool (`progressbar`), so it should be considered a silent bug.
I'm not going to include this change in #3262 for now because CI is currently broken, and I _expect_ this is going to create some failures.
This is mostly a reminder for when CI is op again.


Discussion:

Resolving patch:
diff --git a/yt/loaders.py b/yt/loaders.py
--- a/yt/loaders.py
+++ b/yt/loaders.py
@@ -1304,7 +1304,7 @@ def flatten(l):
 
 # --- Loader for yt sample datasets ---
 def load_sample(
-    fn: Optional[str] = None, progressbar: bool = True, timeout=None, **kwargs
+    fn: Optional[str] = None, *, progressbar: bool = True, timeout=None, **kwargs
 ):
     """
     Load sample data with yt.


Test patch:
Repository: yt-project/yt

Issue:
load_sample: some datasets are missing registration
### Bug report

**Bug summary**

The following datasets currently cannot be loaded with `load_sample` for they lack proper registration:
- ParticleCavity
- cm1_tornado_lofs
- acisf05356N003_evt2.fits.gz
- cm1_supercell_native
- grs-50-cube.fits.gz
- m33_hi.fits.gz
- SmartStars
- tiny_fof_halos

Attempting to load any of the above will fail with
```
ValueError: The requested dataset seems to be improperly registered.
```

What's required to fix these is to add entries for each one in `yt/sample_data_registry.json`. The website also probably should be updated (in particular, the file extensions shouldn't be part of the keys as is currently the case for some). I'm hoping that it won't be necessary to repackage the tarballs (load_sample requires that the key matches the output directory name), but I'll look into that.


Discussion:

Resolving patch:
diff --git a/yt/loaders.py b/yt/loaders.py
--- a/yt/loaders.py
+++ b/yt/loaders.py
@@ -1435,7 +1435,7 @@ def load_sample(
             fh.extractall(save_dir)
         os.remove(tmp_file)
     else:
-        os.replace(tmp_file, save_dir)
+        os.replace(tmp_file, os.path.join(save_dir, fn))
 
     loadable_path = Path.joinpath(save_dir, fn)
     if load_name not in str(loadable_path):


Test patch:
Repository: yt-project/yt

Issue:
Weird styling in docs navbar
### Bug report

**Bug summary**

Since 3.6.1, there's a weird offset (or lack of it) for first item in the docs main navbar. See below:

![ytdocs](https://user-images.githubusercontent.com/352673/124974329-4a814e80-dff2-11eb-85a8-a05f524482a4.png)



Discussion:

Resolving patch:
diff --git a/doc/source/conf.py b/doc/source/conf.py
--- a/doc/source/conf.py
+++ b/doc/source/conf.py
@@ -70,7 +70,7 @@
 
 # General information about the project.
 project = "The yt Project"
-copyright = "2013-2020, the yt Project"
+copyright = "2013-2021, the yt Project"
 
 # The version info for the project you're documenting, acts as replacement for
 # |version| and |release|, also used in various other places throughout the
@@ -130,6 +130,7 @@
     bootstrap_version="3",
     bootswatch_theme="readable",
     navbar_links=[
+        ("", ""),  # see https://github.com/yt-project/yt/pull/3423
         ("How to get help", "help/index"),
         ("Quickstart notebooks", "quickstart/index"),
         ("Cookbook", "cookbook/index"),


Test patch: