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

Issue:
Add documentation explaining why/how to switch the Astropy ephemeris
Astropy's built-in ephemeris is not as accurate as a JPL ephemeris (e.g., DE430), although the discrepancies are appreciable only when querying non-Earth planets.  Our documentation should explain how to switch the Astropy ephemeris (via `astropy.coordinates.solar_system_ephemeris`).


Discussion:
Keep an eye on astropy/astropy#8751
Is this explained anywhere in the astropy docs, that we could easily link to?
The appropriate Astropy page is https://docs.astropy.org/en/v3.2.x/coordinates/solarsystem.html, but of course our docs need to provide the context.

> Our documentation should explain how to switch the Astropy ephemeris (via `astropy.coordinates.solar_system_ephemeris`).

I'm not able to understand what this means?


Please take a look at https://docs.astropy.org/en/stable/coordinates/solarsystem.html.  At the bare minimum, we would add a line to the docstring for `get_body_heliographic_stonyhurst()` that links to the Astropy page.
So the end goal is to add a line in docs that links to https://docs.astropy.org/en/stable/coordinates/solarsystem.html ?

Resolving patch:
diff --git a/sunpy/coordinates/ephemeris.py b/sunpy/coordinates/ephemeris.py
--- a/sunpy/coordinates/ephemeris.py
+++ b/sunpy/coordinates/ephemeris.py
@@ -63,6 +63,11 @@ def get_body_heliographic_stonyhurst(body, time='now', observer=None, *, include
     angular direction relative to the observer, the correction can be negligible because the
     apparent location of the body will shift in tandem with the Sun.
 
+    For planets other than Earth, Astropy's built-in ephemeris is not as accurate as JPL
+    ephemerides, so one can use :func:`astropy.coordinates.solar_system_ephemeris` to switch
+    to a JPL ephemeris. See :ref:`astropy-coordinates-solarsystem` for more information, and see
+    :ref:`sphx_glr_generated_gallery_units_and_coordinates_venus_transit.py` for an example.
+
     Examples
     --------
     >>> from sunpy.coordinates.ephemeris import get_body_heliographic_stonyhurst


Test patch:
Repository: sunpy/sunpy

Issue:
Suggest the use of `assume_spherical_screen()` in the autoalign/reproject examples
These two examples:
* Autoaligning: https://docs.sunpy.org/en/v3.1.5/generated/gallery/map_transformations/autoalign_aia_hmi.html
* Reprojecting: https://docs.sunpy.org/en/v3.1.5/generated/gallery/map_transformations/reprojection_align_aia_hmi.html

are silent about the fact that off-disk HMI data is being discarded.  The examples should note that, and additionally suggest that the user can use `Helioprojective.assume_spherical_screen()` to retain the off-disk HMI data.


Discussion:

Resolving patch:
diff --git a/examples/map_transformations/autoalign_aia_hmi.py b/examples/map_transformations/autoalign_aia_hmi.py
--- a/examples/map_transformations/autoalign_aia_hmi.py
+++ b/examples/map_transformations/autoalign_aia_hmi.py
@@ -45,10 +45,18 @@
 # Setting ``autoalign=True`` allows plotting the HMI image onto axes
 # defined by the AIA reference frame.  In contrast to the above code
 # block, we intentionally set the ``projection`` for the axes to be
-# the AIA map # instead of the HMI map.  We also need to manually set
+# the AIA map instead of the HMI map. We also need to manually set
 # the plot limits because Matplotlib gets confused by the off-disk
-# parts of the image.  Note that the HMI image now has the same
+# parts of the image. The HMI image now has the same
 # orientation as the AIA image.
+#
+# Note that off-disk HMI data are not retained by default because an
+# additional assumption is required to define the location of the HMI
+# emission in 3D space. We can use
+# :meth:`~sunpy.coordinates.Helioprojective.assume_spherical_screen` to
+# retain the off-disk HMI data. See
+# :ref:`sphx_glr_generated_gallery_map_transformations_reprojection_spherical_screen.py`
+# for more reference.
 
 fig = plt.figure(figsize=(12, 5))
 ax1 = fig.add_subplot(121, projection=map_aia)
diff --git a/examples/map_transformations/reprojection_align_aia_hmi.py b/examples/map_transformations/reprojection_align_aia_hmi.py
--- a/examples/map_transformations/reprojection_align_aia_hmi.py
+++ b/examples/map_transformations/reprojection_align_aia_hmi.py
@@ -55,6 +55,14 @@
 
 ######################################################################
 # Plot the images side by side.
+#
+# Note that off-disk HMI data are not retained by default because an
+# additional assumption is required to define the location of the HMI
+# emission in 3D space. We can use
+# :meth:`~sunpy.coordinates.Helioprojective.assume_spherical_screen` to
+# retain the off-disk HMI data. See
+# :ref:`sphx_glr_generated_gallery_map_transformations_reprojection_spherical_screen.py`
+# for more reference.
 
 fig = plt.figure(figsize=(12, 5))
 ax1 = fig.add_subplot(121, projection=map_aia)


Test patch:
Repository: sunpy/sunpy

Issue:
Add a "How do I..." page to our documentation
<!--
We know asking good questions takes effort, and we appreciate your time.
Thank you.

Please be aware that everyone has to follow our code of conduct:
https://sunpy.org/coc

These comments are hidden when you submit this github issue.

Please have a search on our GitHub repository to see if a similar issue has already been posted.
If a similar issue is closed, have a quick look to see if you are satisfied by the resolution.
If not please go ahead and open an issue!
-->


<!--
Provide a general description of the feature you would like.
If you prefer, you can also suggest a draft design or API.
-->

e.g. this page from the xarray docs: http://xarray.pydata.org/en/stable/howdoi.html



Discussion:

Resolving patch:
diff --git a/examples/acquiring_data/searching_multiple_wavelengths.py b/examples/acquiring_data/searching_multiple_wavelengths.py
deleted file mode 100644
--- a/examples/acquiring_data/searching_multiple_wavelengths.py
+++ /dev/null
@@ -1,44 +0,0 @@
-"""
-==============================================
-Searching for multiple wavelengths with Fido
-==============================================
-
-This example shows how you can search for several wavelengths of AIA data with Fido.
-"""
-from astropy import units as u
-
-from sunpy.net import Fido
-from sunpy.net import attrs as a
-
-###############################################################################
-# Here we are demonstrating how you can search for specific wavelengths of
-# AIA data using `Fido <sunpy.net.fido_factory.UnifiedDownloaderFactory>`
-# and the `sunpy.net.attrs.AttrOr` function.
-# For example, you may only want a single wavelength, say 171 Angstrom:
-
-aia_search = Fido.search(a.Time("2022-02-20 00:00", "2022-02-20 00:01"),
-                         a.Instrument("AIA"),
-                         a.Wavelength(171*u.angstrom))
-
-print(aia_search)
-
-###############################################################################
-# But say you actually want to search for several wavelengths, rather than just one.
-# You could use the "|" operator, or instead you can use the `sunpy.net.attrs.AttrOr`
-# function.
-
-wavelengths = [94, 131, 171, 193, 211]*u.angstrom
-aia_search = Fido.search(a.Time("2022-02-20 00:00", "2022-02-20 00:01"),
-                         a.Instrument("AIA"),
-                         a.AttrOr([a.Wavelength(wav) for wav in wavelengths]))
-
-print(aia_search)
-
-# This returns several searches for each of the wavelengths, which can be indexed.
-# Here the first index is that of 94 angstrom.
-print(aia_search[0])
-
-###############################################################################
-# You can then pass the `Fido <sunpy.net.fido_factory.UnifiedDownloaderFactory>`
-# result to :meth:`Fido.fetch <sunpy.net.fido_factory.UnifiedDownloaderFactory.fetch>`
-# to download the data, i.e., ``Fido.fetch(aia_search)``.


Test patch:
Repository: sunpy/sunpy

Issue:
Move Map factory examples from API docs to a how-to guide
Currently, on the [`Map` factory API page](https://docs.sunpy.org/en/latest/generated/api/sunpy.map.Map.html), there is an extensive list of the various inputs that the Map 
factor accepts. This is essentially a how-to guide for the various ways for creating a `Map`. We should move 
this out of the reference docs and into a proper how-to guide.



Discussion:

Resolving patch:
diff --git a/sunpy/map/map_factory.py b/sunpy/map/map_factory.py
--- a/sunpy/map/map_factory.py
+++ b/sunpy/map/map_factory.py
@@ -83,69 +83,6 @@ class MapFactory(BasicRegistrationFactory):
     >>> from astropy.io import fits
     >>> import sunpy.data.sample  # doctest: +REMOTE_DATA
     >>> mymap = sunpy.map.Map(sunpy.data.sample.AIA_171_IMAGE)  # doctest: +REMOTE_DATA
-
-    The SunPy Map factory accepts a wide variety of inputs for creating maps
-
-    * Preloaded tuples of (data, header) pairs
-
-    >>> mymap = sunpy.map.Map((data, header))   # doctest: +SKIP
-
-    headers are some base of `dict` or `collections.OrderedDict`, including
-    `sunpy.io.header.FileHeader` or `sunpy.util.metadata.MetaDict` classes.
-
-    * data, header pairs, not in tuples
-
-    >>> mymap = sunpy.map.Map(data, header)   # doctest: +SKIP
-
-    * data, wcs object, in tuple
-
-    >>> from astropy.wcs import WCS
-    >>> wcs = WCS(sunpy.data.sample.AIA_171_ROLL_IMAGE)  # doctest: +SKIP
-    >>> data = fits.getdata(sunpy.data.sample.AIA_171_ROLL_IMAGE)  # doctest: +SKIP
-    >>> mymap = sunpy.map.Map((data, wcs))  # doctest: +SKIP
-
-    * data, wcs object, not in tuple
-
-    >>> from astropy.wcs import WCS
-    >>> wcs = WCS(sunpy.data.sample.AIA_171_ROLL_IMAGE)  # doctest: +SKIP
-    >>> data = fits.getdata(sunpy.data.sample.AIA_171_ROLL_IMAGE)  # doctest: +SKIP
-    >>> mymap = sunpy.map.Map(data, wcs)  # doctest: +SKIP
-
-    * File names
-
-    >>> mymap = sunpy.map.Map('file1.fits')   # doctest: +SKIP
-
-    * All fits files in a directory by giving a directory
-
-    >>> mymap = sunpy.map.Map('local_dir/sub_dir')   # doctest: +SKIP
-
-    * A filesystem path expressed as a `pathlib.Path`
-
-    >>> import pathlib
-    >>> mymap = sunpy.map.Map(pathlib.Path('file1.fits'))   # doctest: +SKIP
-    >>> sub_dir = pathlib.Path('local_dir/sub_dir')
-    >>> mymap = sunpy.map.Map(sub_dir)   # doctest: +SKIP
-    >>> mymap = sunpy.map.Map(sub_dir / 'file3.fits')   # doctest: +SKIP
-
-    * Some regex globs
-
-    >>> mymap = sunpy.map.Map('eit_*.fits')   # doctest: +SKIP
-
-    * URLs
-
-    >>> mymap = sunpy.map.Map(url_str)   # doctest: +SKIP
-
-    * DatabaseEntry
-
-    >>> mymap = sunpy.map.Map(db_result)   # doctest: +SKIP
-
-    * Lists of any of the above
-
-    >>> mymap = sunpy.map.Map(['file1.fits', 'file2.fits', 'file3.fits', 'directory1/'])  # doctest: +SKIP
-
-    * Any mixture of the above not in a list
-
-    >>> mymap = sunpy.map.Map(((data, header), data2, header2, 'file1.fits', url_str, 'eit_*.fits'))  # doctest: +SKIP
     """
 
     def _read_file(self, fname, **kwargs):


Test patch:
Repository: sunpy/sunpy

Issue:
`sunpy.coordinates.wcs_utils.solar_wcs_frame_mapping` only checks `dateobs` not `dateavg` 
### Describe the bug

When looks for the obstime of a WCS the `solar_wcs_frame_mapping` function should prioritise `dateavg` as it's the more modern reference time for the WCS.

Note that the DKIST data doesn't have `DATE-OBS` so this just fails to extract a obstime at all for DKIST data.

### To Reproduce

_No response_

### Screenshots

_No response_

### System Details

_No response_

### Installation method

_No response_


Discussion:
See https://github.com/sunpy/sunpy/blob/feccb44ffd5e40fa75d6d1a1261d3fe10f64a3e9/sunpy/coordinates/wcs_utils.py#L100

Resolving patch:
diff --git a/sunpy/coordinates/wcs_utils.py b/sunpy/coordinates/wcs_utils.py
--- a/sunpy/coordinates/wcs_utils.py
+++ b/sunpy/coordinates/wcs_utils.py
@@ -13,7 +13,6 @@
 
 from sunpy import log
 from .frames import (
-    BaseCoordinateFrame,
     Heliocentric,
     HeliographicCarrington,
     HeliographicStonyhurst,
@@ -98,7 +97,7 @@ def solar_wcs_frame_mapping(wcs):
     if hasattr(wcs, "coordinate_frame"):
         return wcs.coordinate_frame
 
-    dateobs = wcs.wcs.dateobs or None
+    dateobs = wcs.wcs.dateavg or wcs.wcs.dateobs or None
 
     # Get observer coordinate from the WCS auxiliary information
     required_attrs = {HeliographicStonyhurst: ['hgln_obs', 'hglt_obs', 'dsun_obs'],


Test patch:
diff --git a/sunpy/coordinates/tests/test_wcs_utils.py b/sunpy/coordinates/tests/test_wcs_utils.py
--- a/sunpy/coordinates/tests/test_wcs_utils.py
+++ b/sunpy/coordinates/tests/test_wcs_utils.py
@@ -46,6 +46,25 @@ def test_wcs_frame_mapping_none():
     assert result is None
 
 
+def test_wcs_frame_mapping_dateavg():
+    wcs = WCS(naxis=2)
+    wcs.wcs.dateavg = "2020-01-01T00:00:00"
+    wcs.wcs.ctype = ["HPLN", "HPLT"]
+
+    result = solar_wcs_frame_mapping(wcs)
+
+    assert result.obstime == Time("2020-01-01T00:00:00")
+
+    wcs = WCS(naxis=2)
+    wcs.wcs.dateavg = "2020-01-01T00:00:00"
+    wcs.wcs.dateobs = "2020-01-01T01:00:00"
+    wcs.wcs.ctype = ["HPLN", "HPLT"]
+
+    result = solar_wcs_frame_mapping(wcs)
+
+    assert result.obstime == Time("2020-01-01T00:00:00")
+
+
 def test_wcs_frame_mapping_observer_hgc_self():
     # Test whether a WCS with HGC coordinates for the observer location uses observer="self"
     wcs = WCS(naxis=2)
Repository: sunpy/sunpy

Issue:
Fido query for GBM data only matches files with v00.pha and misses those that have been version updated (e.g. v01.pha)
### Describe the bug

The way the source client for GBM is currently implemented, scraper only looks for files ending with `v00.pha`, and hence wont return data if its instead `v01.pha`

I'll make a PR now



### To Reproduce

```python
>>> from sunpy.net import Fido, attrs as a
>>> res_gbm = Fido.search(a.Time("2014-10-14 00:00", "2014-10-15"), a.Instrument.gbm, a.Resolution.cspec, a.Detector("n5"))
Results from 1 Provider:

1 Results from the GBMClient:
Source: https://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/daily

       Start Time               End Time        Instrument Physobs Source Provider Resolution Detector
----------------------- ----------------------- ---------- ------- ------ -------- ---------- --------
2014-10-15 00:00:00.000 2014-10-15 23:59:59.999        GBM    flux  FERMI     NASA      cspec       n5
```
however data exists for the 14th but not returned here.




Discussion:

Resolving patch:
diff --git a/sunpy/net/dataretriever/sources/fermi_gbm.py b/sunpy/net/dataretriever/sources/fermi_gbm.py
--- a/sunpy/net/dataretriever/sources/fermi_gbm.py
+++ b/sunpy/net/dataretriever/sources/fermi_gbm.py
@@ -48,7 +48,8 @@ class GBMClient(GenericClient):
     <BLANKLINE>
 
     """
-    baseurl = r'https://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/daily/%Y/%m/%d/current/glg_(\w){5}_(\w){2}_%y%m%d_v00.pha'
+
+    baseurl = r'https://heasarc.gsfc.nasa.gov/FTP/fermi/data/gbm/daily/%Y/%m/%d/current/glg_(\w){5}_(\w){2}_%y%m%d_.*\.pha'
     pattern = '{}/daily/{year:4d}/{month:2d}/{day:2d}/current/glg_{Resolution:5}_{Detector:2}_{:6d}{}'
 
     @property


Test patch:
Repository: sunpy/sunpy

Issue:
Show a warning when calling `reproject_to()` and there is a (minor) mismatch in `rsun`
People continue to get tripped up on a mismatch in `rsun` causing data to be lost in a reprojection (e.g., #7323 or https://community.openastronomy.org/t/derotate-hmi-map-at-carrington-rate-with-postel-projection/840/5).  Something like #7328 can help a user deal with an `rsun` mismatch, but only if they're aware that that's the problem.

We could emit a warning specific to `reproject_to()` such that it alerts a user if the `rsun` values of the map and the output header are not the same, since it might lead to unexpected results.  It should probably come with a tolerance parameter to control what level of `rsun` mismatch is considered a potential mistake.


Discussion:
The most frequent problem is the consequence of SDO (AIA and HMI) headers having the solar radius as 696 Mm, versus our default value being the IAU definition of 695.7 Mm.
What about also throwing a warning if the only reason HPC-HPC isn't loopback is a small rsun mismatch?

Resolving patch:
diff --git a/sunpy/map/mapbase.py b/sunpy/map/mapbase.py
--- a/sunpy/map/mapbase.py
+++ b/sunpy/map/mapbase.py
@@ -2739,6 +2739,12 @@ def reproject_to(self, target_wcs, *, algorithm='interpolation', return_footprin
         outmap = GenericMap(output_array, target_wcs.to_header(),
                             plot_settings=self.plot_settings)
 
+        # Check rsun mismatch
+        if self.rsun_meters != outmap.rsun_meters:
+            warn_user("rsun mismatch detected: "
+                      f"{self.name}.rsun_meters={self.rsun_meters}; {outmap.name}.rsun_meters={outmap.rsun_meters}. "
+                      "This might cause unexpected results during reprojection.")
+
         if return_footprint:
             return outmap, footprint
         return outmap


Test patch:
diff --git a/sunpy/map/tests/test_reproject_to.py b/sunpy/map/tests/test_reproject_to.py
--- a/sunpy/map/tests/test_reproject_to.py
+++ b/sunpy/map/tests/test_reproject_to.py
@@ -13,6 +13,7 @@
 
 import sunpy.map
 from sunpy.tests.helpers import figure_test
+from sunpy.util.exceptions import SunpyUserWarning
 
 
 @pytest.fixture
@@ -119,3 +120,11 @@ def test_return_footprint(aia171_test_map, hpc_header):
 def test_invalid_inputs(aia171_test_map, hpc_header):
     with pytest.raises(ValueError, match="The specified algorithm must be one of"):
         aia171_test_map.reproject_to(hpc_header, algorithm='something')
+
+def test_rsun_mismatch_warning(aia171_test_map, hpc_header):
+    with pytest.warns(SunpyUserWarning, match="rsun mismatch detected: "):
+        # Modifying the `hpc_header` rsun value to create a mismatch
+        hpc_header["rsun_ref"] += 1
+
+        # Reproject with the mismatched rsun
+        aia171_test_map.reproject_to(hpc_header)
Repository: sunpy/sunpy

Issue:
User confusion because warnings are hidden in gallery examples for stable docs
No doubt there was a good reason to do this, but it can be confusing to users that warnings are hidden in the gallery examples for stable docs (was done in #5279):
https://github.com/sunpy/sunpy/blob/bc8f08fe912adb1396e1a0b976ae98bdc32170a8/docs/conf.py#L59-L61

That means when a user runs the example on their own machine, and they see warning messages that do not appear on the rendered example, the natural reaction is that the user thinks something is not set up properly on their end.

Can we stop hiding the warnings?


Discussion:
Do we need explanations in examples with expected warnings? callout boxes?

Resolving patch:
diff --git a/docs/conf.py b/docs/conf.py
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -56,14 +56,11 @@
 sunpy_version = Version(__version__)
 is_release = not(sunpy_version.is_prerelease or sunpy_version.is_devrelease)
 
-# We want to ignore all warnings in a release version.
-if is_release:
-    warnings.simplefilter("ignore")
+# We want to make sure all the following warnings fail the build
 warnings.filterwarnings("error", category=SunpyDeprecationWarning)
 warnings.filterwarnings("error", category=SunpyPendingDeprecationWarning)
 warnings.filterwarnings("error", category=MatplotlibDeprecationWarning)
 warnings.filterwarnings("error", category=AstropyDeprecationWarning)
-warnings.filterwarnings("ignore", message="The `sunpy.io.file_tools` module is deprecated",category=SunpyDeprecationWarning)
 
 # -- SunPy Sample Data and Config ----------------------------------------------
 # We set the logger to debug so that we can see any sample data download errors


Test patch:
Repository: sunpy/sunpy

Issue:
Saving with the ".jp2" extension results in a vertically flipped image
### Describe the bug

Images get flipped when saving as jp2 files.
This was my fault when I added this feature 🎉

### To Reproduce

```
from sunpy.map import Map
m = Map("https://helioviewer.org/jp2/AIA/2024/03/08/304/2024_03_08__00_00_05_123__SDO_AIA_AIA_304.jp2")
m.peek()
m.save("test.jp2")
flipped = Map("test.jp2")
flipped.peek()
```

See screenshots below


### Screenshots

`m.peek()`
<img width="634" alt="image" src="https://github.com/sunpy/sunpy/assets/94071409/fc6f1648-9bd3-4e11-a726-9b2d4810e42e">

`flipped.peek()`
<img width="634" alt="image" src="https://github.com/sunpy/sunpy/assets/94071409/04c66615-05b3-4776-81c6-7aefa3c9ca5f">


### System Details


>>> import sunpy
>>> sunpy.util.system_info()
==============================
sunpy Installation Information
==============================

General
#######
OS: Mac OS 14.3.1
Arch: 64bit, (arm)
sunpy: 4.0.dev2573+gf79e5d92d
Installation path: sunpy.egg-info

Required Dependencies
#####################
astropy: 6.0.0
numpy: 1.26.4
packaging: 23.2
parfive: 2.0.2
pyerfa: 2.0.1.1
requests: 2.31.0

Optional Dependencies
#####################
sunpy: 4.0.dev2573+gf79e5d92d

### Installation method

git checkout


Discussion:

Resolving patch:
diff --git a/sunpy/io/_jp2.py b/sunpy/io/_jp2.py
--- a/sunpy/io/_jp2.py
+++ b/sunpy/io/_jp2.py
@@ -176,7 +176,11 @@ def write(fname, data, header, **kwargs):
 
     tmpname = fname + "tmp.jp2"
     jp2_data = np.uint8(data)
-    jp2 = Jp2k(tmpname, jp2_data, **kwargs)
+
+    # The jp2 data is flipped when read in, so we have to flip it back before
+    # saving. See https://github.com/sunpy/sunpy/pull/768 for context.
+    flipped = np.flip(jp2_data, 0)
+    jp2 = Jp2k(tmpname, flipped, **kwargs)
 
     # Append the XML data to the header information stored in jp2.box
     meta_boxes = jp2.box


Test patch:
diff --git a/sunpy/io/tests/test_jp2.py b/sunpy/io/tests/test_jp2.py
--- a/sunpy/io/tests/test_jp2.py
+++ b/sunpy/io/tests/test_jp2.py
@@ -44,3 +44,8 @@ def test_simple_write(tmpdir):
     # Sanity check that reading back the jp2 returns coherent data
     jp2_readback = _jp2.read(outfile)
     assert header['DATE'] == jp2_readback[0].header['DATE']
+
+    # jp2 requires the data array to have type uint8, so cast the original
+    # data array to uint8 to compare it with the generated jp2 file.
+    original_data = np.uint8(data)
+    assert np.array_equal(original_data, jp2_readback[0].data)