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

Issue:
PhasePlots don't correctly render ion fields for z_axis label
### Bug report

**Bug summary**

Usage of ion fields such as `H_p0_mass` (for H I mass) are not rendered properly for `PhasePlot` z-axis labels, but they work correctly for `ProjectionPlot`s z-axis labels.  I'm happy to fix this, but I cannot find where in the code `ProjectionPlot` is doing this step.  Suggestions are welcome.

**Code for reproduction**

```python
import yt
ds = yt.load_sample('IsolatedGalaxy')
yt.PhasePlot(ds, ('gas', 'density'), ('gas', 'temperature'), ('gas', 'H_p0_mass')).save()
yt.ProjectionPlot(ds, 'x', ('gas', 'H_p0_number_density')).save()
```

**Actual outcome**

![galaxy0030_2d-Profile_density_temperature_H_p0_mass](https://user-images.githubusercontent.com/8250999/118381594-321c2700-b5a1-11eb-9e5b-c3efe59b8dee.png)

![galaxy0030_Projection_x_H_p0_number_density](https://user-images.githubusercontent.com/8250999/118381589-27fa2880-b5a1-11eb-9f58-839c5940df84.png)




Discussion:

Resolving patch:
diff --git a/yt/visualization/profile_plotter.py b/yt/visualization/profile_plotter.py
--- a/yt/visualization/profile_plotter.py
+++ b/yt/visualization/profile_plotter.py
@@ -725,7 +725,7 @@ def _get_field_log(self, field_y, profile):
 
     def _get_field_label(self, field, field_info, field_unit, fractional=False):
         field_unit = field_unit.latex_representation()
-        field_name = field_info.display_name
+        field_name = field_info.get_latex_display_name()
         if isinstance(field, tuple):
             field = field[1]
         if field_name is None:
@@ -1013,7 +1013,7 @@ def _get_field_title(self, field_z, profile):
 
     def _get_field_label(self, field, field_info, field_unit, fractional=False):
         field_unit = field_unit.latex_representation()
-        field_name = field_info.display_name
+        field_name = field_info.get_latex_display_name()
         if isinstance(field, tuple):
             field = field[1]
         if field_name is None:


Test patch:
Repository: yt-project/yt

Issue:
PhasePlots don't correctly render ion fields for z_axis label
### Bug report

**Bug summary**

Usage of ion fields such as `H_p0_mass` (for H I mass) are not rendered properly for `PhasePlot` z-axis labels, but they work correctly for `ProjectionPlot`s z-axis labels.  I'm happy to fix this, but I cannot find where in the code `ProjectionPlot` is doing this step.  Suggestions are welcome.

**Code for reproduction**

```python
import yt
ds = yt.load_sample('IsolatedGalaxy')
yt.PhasePlot(ds, ('gas', 'density'), ('gas', 'temperature'), ('gas', 'H_p0_mass')).save()
yt.ProjectionPlot(ds, 'x', ('gas', 'H_p0_number_density')).save()
```

**Actual outcome**

![galaxy0030_2d-Profile_density_temperature_H_p0_mass](https://user-images.githubusercontent.com/8250999/118381594-321c2700-b5a1-11eb-9e5b-c3efe59b8dee.png)

![galaxy0030_Projection_x_H_p0_number_density](https://user-images.githubusercontent.com/8250999/118381589-27fa2880-b5a1-11eb-9f58-839c5940df84.png)




Discussion:

Resolving patch:
diff --git a/yt/visualization/profile_plotter.py b/yt/visualization/profile_plotter.py
--- a/yt/visualization/profile_plotter.py
+++ b/yt/visualization/profile_plotter.py
@@ -725,7 +725,7 @@ def _get_field_log(self, field_y, profile):
 
     def _get_field_label(self, field, field_info, field_unit, fractional=False):
         field_unit = field_unit.latex_representation()
-        field_name = field_info.get_latex_display_name()
+        field_name = field_info.display_name
         if isinstance(field, tuple):
             field = field[1]
         if field_name is None:
@@ -1013,7 +1013,7 @@ def _get_field_title(self, field_z, profile):
 
     def _get_field_label(self, field, field_info, field_unit, fractional=False):
         field_unit = field_unit.latex_representation()
-        field_name = field_info.get_latex_display_name()
+        field_name = field_info.display_name
         if isinstance(field, tuple):
             field = field[1]
         if field_name is None:


Test patch:
Repository: yt-project/yt

Issue:
BUG: wrong axis labels representation in SlicePlot for spherical data
### Bug report

**Bug summary**

There's an inconsistency in math representation (or lack thereof) of axis labels when performing SlicePlot along the "r" direction for spherical data.

**Code for reproduction**


```python
import yt
ds = yt.load_sample("bw_spherical_2d")
p = yt.SlicePlot(ds, "r", "density")
p.save("/tmp/bug.png")
```

**Actual outcome**

![bug](https://user-images.githubusercontent.com/14075922/134900776-771c7787-44cb-4751-9a16-b06432be46f3.png)

**Expected outcome**

I expect axis labels to use `\theta` and `\phi` latex glyphs instead of "theta" and "phi" strings, consistently with what happens when slicing along the "theta" direction, for instance
![bug_theta](https://user-images.githubusercontent.com/14075922/134901098-a37df2fa-3b1e-4d8f-aebb-a9c3c5197864.png)

(here the frame is wrong, this was already reported as #3529)



Discussion:
Note that Slicing along the "theta" or "phi" directions also shows a bug where density is shown in physical units but distances are shown in "code_length". This is an amrvac dataset and it uses the "cgs" unit system by default, so this is another way the axis labels are wrong. I'll open a separate issue if it turns out I can't solve both in one go.

Resolving patch:
diff --git a/yt/geometry/coordinates/spherical_coordinates.py b/yt/geometry/coordinates/spherical_coordinates.py
--- a/yt/geometry/coordinates/spherical_coordinates.py
+++ b/yt/geometry/coordinates/spherical_coordinates.py
@@ -260,7 +260,7 @@ def image_axis_name(self):
         # non-Cartesian coordinates, we usually want to override these for
         # Cartesian coordinates, since we transform them.
         rv = {
-            self.axis_id["r"]: ("theta", "phi"),
+            self.axis_id["r"]: ("\\theta", "\\phi"),
             self.axis_id["theta"]: ("x / \\sin(\\theta)", "y / \\sin(\\theta)"),
             self.axis_id["phi"]: ("R", "z"),
         }


Test patch:
Repository: yt-project/yt

Issue:
DEPR: deprecate annotate_halos (HaloCatalogCallback)
As soon as [PR #98](https://github.com/yt-project/yt_astro_analysis/pull/98) in yt_astro_analysis is accepted, the HaloCatalogCallback should be deprecated or removed. This will get rid of the need to import yt_astro_analysis inside yt itself.


Discussion:
as we discussed yesterday, it probably doesn't need to be formally deprecated because (I think ?) nobody is going to miss it: it will stay available for yt_astro_analysis users, and I expect it that the migration is going to be 100% transparent to them ?
We can add an item to yt 4.1 release notes specifically for yt_astro users, saying that they should upgrade it too, but other than that I think we should be good.

Resolving patch:
diff --git a/doc/source/cookbook/halo_plotting.py b/doc/source/cookbook/halo_plotting.py
deleted file mode 100644
--- a/doc/source/cookbook/halo_plotting.py
+++ /dev/null
@@ -1,12 +0,0 @@
-import yt
-
-# Load the dataset
-ds = yt.load("Enzo_64/RD0006/RedshiftOutput0006")
-
-# Load the halo list from a rockstar output for this dataset
-halos = yt.load("rockstar_halos/halos_0.0.bin")
-
-# Create a projection with the halos overplot on top
-p = yt.ProjectionPlot(ds, "x", "density")
-p.annotate_halos(halos)
-p.save()
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
@@ -7,6 +7,7 @@
 import matplotlib
 import numpy as np
 
+from yt._maintenance.deprecation import issue_deprecation_warning
 from yt.data_objects.data_containers import YTDataContainer
 from yt.data_objects.level_sets.clump_handling import Clump
 from yt.data_objects.selection_objects.cut_region import YTCutRegion
@@ -1940,6 +1941,14 @@ def __init__(
         font_kwargs=None,
         factor=1.0,
     ):
+        issue_deprecation_warning(
+            "The annotate_halos method has been fully migrated to the "
+            "yt_astro_analysis extension. "
+            "Please update the extension to version 1.1 or newer. "
+            "This duplicated functionality will be removed from the main yt package.",
+            since="4.1",
+            removal="4.2",
+        )
 
         try:
             from yt_astro_analysis.halo_analysis.api import HaloCatalog


Test patch:
Repository: yt-project/yt

Issue:
BUG: spurious log warning when saving a plot to png format
### Bug report

**Bug summary**

**Code for reproduction**

```python
import yt

yt.funcs.mylog.setLevel("warning")

ds = yt.load_sample("IsolatedGalaxy")
p = yt.SlicePlot(ds, "z", "density")
p.save("/tmp/test.png")
```


**Actual outcome**

```
yt : [WARNING  ] 2021-10-20 11:50:44,393 Received two valid image formats '.png' (from `filename`) and 'png' (from `suffix`). The former is ignored.
```

**Expected outcome**

No log warning


Discussion:

Resolving patch:
diff --git a/yt/visualization/_commons.py b/yt/visualization/_commons.py
--- a/yt/visualization/_commons.py
+++ b/yt/visualization/_commons.py
@@ -61,9 +61,12 @@ def validate_image_name(filename, suffix: Optional[str] = None) -> str:
     Otherwise, suffix is appended to the filename, replacing any existing extension.
     """
     name, psuffix = os.path.splitext(filename)
-    if normalize_extension_string(psuffix) in SUPPORTED_FORMATS:
-        if suffix is not None:
-            suffix = normalize_extension_string(suffix)
+    psuffix = normalize_extension_string(psuffix)
+
+    if suffix is not None:
+        suffix = normalize_extension_string(suffix)
+
+    if psuffix in SUPPORTED_FORMATS:
         if suffix in SUPPORTED_FORMATS and suffix != psuffix:
             mylog.warning(
                 "Received two valid image formats '%s' (from `filename`) "
@@ -75,9 +78,7 @@ def validate_image_name(filename, suffix: Optional[str] = None) -> str:
         return str(filename)
 
     if suffix is None:
-        suffix = ".png"
-
-    suffix = normalize_extension_string(suffix)
+        suffix = "png"
 
     if suffix not in SUPPORTED_FORMATS:
         raise ValueError(f"Unsupported file format '{suffix}'.")


Test patch:
Repository: yt-project/yt

Issue:
rootonly does not broadcast the function result
### Bug report

**Bug summary**

The description for `yt.funcs.rootonly` states 

>     This is a decorator that, when used, will only call the function on the
>     root processor and then broadcast the results of the function to all other
>     processors.

However, looking at [L230](https://github.com/yt-project/yt/blob/master/yt/funcs.py#L230) in the source code the return value for all processors with rank > 0 is `None`: the broadcast never happens.

**Code for reproduction**

```
import yt

yt.enable_parallelism()

@yt.rootonly
def test(value):
    return value

print(test("Input value"))
```

**Actual outcome**

```
None
Input value
```

**Expected outcome**

```
Input value
Input value
```

**Version Information**
<!--Please specify your platform and versions of the relevant libraries you are
using:-->
  * Operating System: OSX 10.13.6
  * Python Version: 3.6
  * yt version: 3.4.1
(conda install -c conda-forge yt)




Discussion:
It looks like we don't actually use `rootonly` internally and it hasn't been updated since 2012. It's possible people are using this and depending on the behavior that contradicts the docstring. It's also possible no one is using it.

@MatthewTurk it looks like you wrote `rootonly` originally way back in 2009, any chance you have some context?
The `rootonly` docstring should at least be changed to reflect what the function actually does.

The only way to be sure that existing code isn't broken would be to introduce a new function.
I'd happily merge a PR that corrects the docstring.
So it looks like the docstring was added here: https://github.com/yt-project/yt/commit/38e81b2058da1cfe4404ad140b309fbb5b86c8e9

And the implementation below that docstring doesn't do a broadcast, so I think it's just that the docstring has always been wrong. We should just correct the docstring.

I'm happy to put in that PR but if you would like to make your first yt pull request I'd happily review that :)

Resolving patch:
diff --git a/yt/funcs.py b/yt/funcs.py
--- a/yt/funcs.py
+++ b/yt/funcs.py
@@ -220,8 +220,7 @@ def run_func(*args, **kwargs):
 def rootonly(func):
     """
     This is a decorator that, when used, will only call the function on the
-    root processor and then broadcast the results of the function to all other
-    processors.
+    root processor.
 
     This can be used like so:
 


Test patch:
Repository: yt-project/yt

Issue:
BUG: incorrect LaTeX typesetting in ylabel for fractions
### Bug report

**Bug summary**

Just noticed this in some image reference used for testing:
<img width="117" alt="Screenshot 2021-11-01 at 09 29 15" src="https://user-images.githubusercontent.com/14075922/139643882-f6d9b966-7b86-4fe9-bc6c-34f2a18d155c.png">

The bug is that parenthesis should be bigger around a fraction. This is very similar to a bug that was fixed in #3282, but apparently we missed some cases.


Discussion:
So I thought the issue was in `ProfilePlot` but I can't reproduce the bug with the following script
```python
import yt

ds = yt.load_sample("IsolatedGalaxy/galaxy0030/galaxy0030")
sphere = ds.sphere("c", (100.0, "kpc"))
plot = yt.ProfilePlot(
    sphere,
    ("gas", "temperature"),
    ("gas", "density"),
    weight_field=("gas", "mass"),
)
plot.save("/tmp/profile_test.png")
```

![profile_test_1d-Profile_temperature_density](https://user-images.githubusercontent.com/14075922/139649071-8f2f2f82-a197-4b04-8eb1-2bc29ce12bd9.png)

indeed the failing plot is of class `LinePlot`, not `ProfilePlot`.
Here's a reproducer:
```python
import yt
ds = yt.load_sample("IsolatedGalaxy")
plot = yt.LinePlot(
    ds,
    [("gas", "density")],
    (0.0, 0.0, 0.0), (0.0, 1.0, 0.0), 1000
)

plot.save("/tmp/lineplot_test.png", mpl_kwargs=dict(bbox_inches="tight"))
```
![lineplot_test](https://user-images.githubusercontent.com/14075922/139649989-427914b1-996f-41bd-94e0-e15d2fe83bca.png)


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
@@ -781,7 +781,10 @@ def _get_axes_unit_labels(self, unit_x, unit_y):
                         symbol_wo_prefix = un[1:]
                         if symbol_wo_prefix in self.ds.unit_registry.prefixable_units:
                             un = un.replace(pp, "{" + latex_prefixes[pp] + "}", 1)
-                axes_unit_labels[i] = r"\ \ (" + un + ")"
+                if r"\frac" in un:
+                    axes_unit_labels[i] = r"\ \ \left(" + un + r"\right)"
+                else:
+                    axes_unit_labels[i] = r"\ \ (" + un + r")"
         return axes_unit_labels
 
     def hide_colorbar(self, field=None):


Test patch:
Repository: yt-project/yt

Issue:
Colortransferfunction map_to_colormap makes last values for all channels zero
### Bug report

**Bug summary**

When using the `map_to_colormap` of a `yt.visualization.volume_rendering.transfer_functions.ColorTransferFunction` object, the last value of the `red`, `green`, `blue`, `alpha` channels are always zero.

**Code for reproduction**

```python
import yt
tf = yt.visualization.volume_rendering.transfer_functions.ColorTransferFunction(
    x_bounds=(0.0, 1.0),
    nbins=8
)
tf.map_to_colormap(
    tf.x_bounds[0],
    tf.x_bounds[1],
    colormap='Blues',
)
print(tf.alpha.y)
print(tf.red.y)
print(tf.green.y)
print(tf.blue.y)
tf.show()
```

**Actual outcome**
I have not been able to see if this actually influences rendering, but the transfer function looks off
![image](https://user-images.githubusercontent.com/89517300/141096293-f548f171-83b4-4645-a020-d9a71e60f649.png)

```
[1., 1., 1., 1., 1., 1., 1., 0.]
[0.96862745, 0.84069204, 0.67189542, 0.41708574, 0.21568627, 0.06251442, 0.03137255, 0.]
[0.98431373, 0.90163783, 0.81437908, 0.68063053, 0.52941176, 0.35750865, 0.18823529, 0]
[1., 0.95866205, 0.90065359, 0.83823145, 0.75424837, 0.64290657, 0.41960784, 0]
```

**Expected outcome**

I would expect for a flat transfer function that all alpha values are the same value and all the color channels last value represent the max blue in the 'Blues' colormap (something like (0, 0.1, 0.3)?)

**Version Information**
  * Operating System: Ubuntu 20.04.3 LTS
  * Python Version: 3.8.7
  * yt version: 4.0.1

I installed yt with just `pip install yt`. Same issue also occurs in 3.6.1



Discussion:
Hi, and welcome to yt!  Thanks for opening your first issue.  We have an issue template that helps us to gather relevant information to help diagnosing and fixing the issue.

Thanks for reporting this ! This looks like an off-by-one error and I believe the patch is trivial.

Resolving patch:
diff --git a/yt/visualization/volume_rendering/transfer_functions.py b/yt/visualization/volume_rendering/transfer_functions.py
--- a/yt/visualization/volume_rendering/transfer_functions.py
+++ b/yt/visualization/volume_rendering/transfer_functions.py
@@ -787,7 +787,7 @@ def map_to_colormap(
             self.nbins * (ma - self.x_bounds[0]) / (self.x_bounds[1] - self.x_bounds[0])
         )
         rel0 = max(rel0, 0)
-        rel1 = min(rel1, self.nbins - 1)
+        rel1 = min(rel1, self.nbins - 1) + 1
         tomap = np.linspace(0.0, 1.0, num=rel1 - rel0)
         cmap = get_cmap(colormap)
         cc = cmap(tomap)


Test patch:
Repository: yt-project/yt

Issue:
BUG: improper masking in line integral convolution callback
### Bug report

**Bug summary**

LIC callback doesn't currently apply any masking, which creates very visible artefacts when plotting non cartesian data, where typically some regions of the plot window are outside the actual simulation box

**Code for reproduction**

For instance
```python
import yt

ds = yt.testing.fake_amr_ds(
    fields=[("gas", "density"), ("gas", "velocity_x"), ("gas", "velocity_y")],
    units=["g/cm**3", "cm/s", "cm/s"],
    geometry="polar",
)
p = yt.SlicePlot(ds, "z", "density")
p.annotate_line_integral_convolution("velocity_x", "velocity_y", lim=(0.5, 0.65))
```

**Actual outcome**

![before](https://user-images.githubusercontent.com/14075922/147707729-7359ef0d-4b92-4b8c-8fa7-5f55c32cb863.png)


**Expected outcome**

Regions where there is no data should be masked (as is the background)


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
@@ -3090,7 +3090,8 @@ def __call__(self, plot):
         vectors = np.concatenate((pixX[..., np.newaxis], pixY[..., np.newaxis]), axis=2)
 
         if self.texture is None:
-            self.texture = np.random.rand(nx, ny).astype(np.double)
+            prng = np.random.RandomState(0x4D3D3D3)
+            self.texture = prng.random_sample((nx, ny))
         elif self.texture.shape != (nx, ny):
             raise ValueError(
                 "'texture' must have the same shape "
@@ -3104,6 +3105,10 @@ def __call__(self, plot):
         lic_data = lic_data / lic_data.max()
         lic_data_clip = np.clip(lic_data, self.lim[0], self.lim[1])
 
+        mask = ~(np.isfinite(pixX) & np.isfinite(pixY))
+        lic_data[mask] = np.nan
+        lic_data_clip[mask] = np.nan
+
         if self.const_alpha:
             plot._axes.imshow(
                 lic_data_clip,


Test patch:
Repository: yt-project/yt

Issue:
DOC: private methods used in cookbook recipe
### Bug report

**Bug summary**

in #2567, `doc/source/cookbook/render_two_fields_tf.py` was added to the cookbook
On the two following lines, the private method `_get_field_info` is used
https://github.com/yt-project/yt/blob/ef08989d8222e7172751d17009959102db05dd20/doc/source/cookbook/render_two_fields_tf.py#L15
https://github.com/yt-project/yt/blob/ef08989d8222e7172751d17009959102db05dd20/doc/source/cookbook/render_two_fields_tf.py#L30

This should be refactored to avoid showing private elements
@zingale, do you know how we could do this ?


Discussion:
they might not actually be needed, since log might be the default.  But it is common to want to change the log-ness for volume renders, so if there isn't a public-API, we definitely will want to show how a user can do it in any case.

Resolving patch:
diff --git a/doc/source/cookbook/render_two_fields_tf.py b/doc/source/cookbook/render_two_fields_tf.py
--- a/doc/source/cookbook/render_two_fields_tf.py
+++ b/doc/source/cookbook/render_two_fields_tf.py
@@ -12,7 +12,6 @@
 # Add density
 
 field = "density"
-ds._get_field_info(field).take_log = True
 
 vol = create_volume_source(ds, field=field)
 vol.use_ghost_zones = True
@@ -27,7 +26,6 @@
 # Add temperature
 
 field = "temperature"
-ds._get_field_info(field).take_log = True
 
 vol2 = create_volume_source(ds, field=field)
 vol2.use_ghost_zones = True


Test patch: