The SunPy Project: Open Source Development and Status of the Version 1.0 Core Package

Research astrophysicists rely on software to analyze increasingly large and complex data sets. Scientists that study our nearest star, the Sun, are no different. Solar physicists rely on remote sensing data from both space- and ground-based instruments to measure the properties of our star and deduce the physical mechanisms at work. In the past, most solar data analysis was performed using Fortran, a general purpose, compiled programming language designed for scientific and engineering applications. Several reasons motivated the solar physics community to transition to the Interactive Data Language (IDL), a commercial and closed-source programming language, in the 1980s. For one, IDL is an interpreted programming language that enables faster code development compared to Fortran. Second, IDL includes many libraries that support scientific data visualization and analysis. Finally, the solar community benefitted from functionality developed by the astronomy community (specifically, the IDL Astronomy User's Library). Since then, significant functionality has been developed by the solar community and is freely distributed as the SolarSoftWare library (Freeland & Handy 1998).

Officially founded in 2014 March, the goal of the SunPy project is to provide the core functionality needed for solar data analysis in Python,³⁷ a high-level interpreted programming language, and facilitate a new transition to bring significant and new benefits to the solar community. The SunPy project develops and maintains a community-led, free, and open source³⁸ core Python package (sunpy), supports an ecosystem of affiliated packages (see Section 6) consistent with best practices (Wilson et al. 2014), and engages with the community through mailing lists, chat rooms, tutorials, summer programs, and mentorship. The SunPy project has similar goals to the Astropy project,³⁹ which develops the astropy core package (The Astropy Collaboration et al. 2018) for the astrophysics community.

The choice of Python was motivated by several different factors. The scientific Python ecosystem provides a rich and mature ecosystem of packages for performing scientific analysis and computation. It is supported by foundational packages for manipulating tabular (pandas, McKinney 2010) and multidimensional array (numpy, van der Walt et al. 2011) data, general purpose scientific computing (scipy, Jones et al. 2001), and publication-quality 2D plotting (matplotlib, Hunter 2007).⁴⁰ These core packages form the backbone of hundreds of additional scientific Python packages, such as astropy for functionality and tools specific to astronomy, scikit-learn for machine learning and data mining (Pedregosa et al. 2011), and dask for parallel and distributed computing (Rocklin 2015). Interoperability between all these packages enables interdisciplinary analysis across traditional fields of study including solar physics, space physics, and astrophysics.

The Python programming language is freely available, meaning users are not bound by restrictive and costly proprietary licenses. Python is one of the most widely used programming languages by professional software developers⁴¹ and is also now used by most universities to teach computer science (Guo 2014). Therefore, early career members of the solar physics community will likely already know how to code in Python.

Finally, an important cultural factor motivated the adoption of Python. Python and many Python packages are open source and developed under open source licenses approved by the Open Source Initiative.⁴² The Python developer community has embraced an inclusive and open development culture, which means that anyone is welcome to develop functionality to either enhance existing packages such as sunpy or create new ones (see Section 3). This means one given person or institution does not control the development of scientific Python software. This approach, combined with strict version control, allows scientists to create fully reproducible results.

For all these reasons, the scientific Python ecosystem played a key role in recent major scientific discoveries, such as the first detection of a gravitational wave (LIGO Scientific Collaboration and Virgo Collaboration et al. 2016) and the first image of a black hole (The Event Horizon Telescope Collaboration et al. 2019). The data and code used to generate these results are openly available, allowing anyone to reproduce them. Because the solar community is relatively small⁴³ in relation to other scientific communities, it will benefit immensely by leveraging the growing scientific Python ecosystem to solve increasingly difficult scientific challenges and produce world-class science.

This paper describes the first stable release (version 1.0) of the sunpy core package, which is publicly available in a GitHub repository (Mumford et al. 2020). A previous paper describes version 0.5 (The SunPy Community et al. 2015). This article is not meant to replace the sunpy documentation but provides an overview of the organization and highlights important functionality. The full text of the paper, including all of the code to produce the figures, is available in a GitHub repository.⁴⁴ A list of abbreviations used throughout this paper are provided in Table 1 for convenience.

The organization of the SunPy project is modeled on the structure of a board-only not-for-profit corporate entity. It consists of a self-selected board of up to 10 members. An executive director, elected by the board, leads the core development team and the development of the sunpy package and supports the development of affiliated packages. As such, the executive director is also referred to as the lead developer. A deputy lead developer, a release manager, a group of subpackage maintainers, as well as other volunteers from the developer community, support the lead developer. Board members serve two-year terms while the lead developer serves a one-year term. No positions have term limits.

The SunPy project is formally defined through SunPy Enhancement Proposals (SEPs), which are modeled after the Python Enhancement Proposal (PEP) process.⁴⁵ All SEPs are version-controlled, citable, and publicly available.⁴⁶ The first SEP (SEP-0001, Christe 2014a) defines the scope of an SEP (similar to Greenfield 2013) while the second (SEP-0002, Christe 2018) defines the SunPy project organization.

There are three types of SEPs:

• 1.  
  Standard: introduces and describes a new feature, or changes to an existing feature to sunpy, and is meant to function as a high-level technical design document.
• 2.  
  Process: describes a new process in the organization, or changes to an existing process.
• 3.  
  Informational: provides information but does not introduce any new features, changes, or processes.

As of the time of writing, there are a total of nine SEPs that have been approved by the board. Some notable SEPs have led to the formal adoption of physical units (SEP-0003, Christe 2014b, see Section 4.4) and a specific scientific time class (SEP-0008, Mumford 2018, see Section 4.4) throughout the code base. SEPs have also been used to formally define the affiliated-package program (SEP-0004, Mumford & Christe 2014, see Section 6) as well as the release schedule and versioning system (SEP-0009, Mumford & Hewett 2019, see Section 4.5).

To satisfy the mission of the Project, the SunPy community adopted an open development model, which is widely used within the scientific Python community. The sunpy package is hosted on GitHub and uses git⁴⁷ as its distributed version control software. The entire code base is publicly available and anyone can suggest changes through pull requests. Since the code base is licensed under a permissive two-clause BSD license,⁴⁸ anyone can redistribute, improve, repackage, or use it in a closed environment as long as they credit the SunPy developers and redistribute the license. In order to maintain a high-quality code, every contribution is reviewed and must satisfy the following requirements:

• 1.  
  Code and documentation must follow widely used style guides (e.g., PEP 8⁴⁹ ).
• 2.  
  All new features must be accompanied with documentation, including code comments, formal documentation such as Python docstrings and a guide, if appropriate, as well as gallery examples.
• 3.  
  Contributed code must provide unit tests⁵⁰ that cover the majority of the new functionality.
• 4.  
  All code must be within scope, and must be approved by at least two members of the developer community before it is merged into the code base.⁵¹

These requirements are imposed on every pull request regardless of the contributor.

As of version 1.0, sunpy consists of 48,427 lines of code⁵² contributed by 123 unique contributors with over 11,659 commits.⁵³ The leftmost panel of Figure 1 shows the steady growth of the code base since 2011 with, on average, approximately 16 lines added per day. A large reduction in the code base occurred after the release of version 0.9, primarily due to the deletion of unused code and the removal of Python 2 support.

Zoom In Zoom Out Reset image size

The middle panel of Figure 1 shows the steady rise in the number of unique contributors with, on average, more than one new contributor added each month. The total number of contributors is large for a package of this size in the heliophysics community (Ware et al. 2019).

The rightmost panel of Figure 1 shows the distribution of the total number of commits per contributor as of 2019 June. The distribution is relatively steep with a log–log slope of −0.35, which indicates that relatively few contributors generate the majority of commits. The top 10 contributors are responsible for ∼80% of all commits. This compares poorly to other projects such as Astropy (The Astropy Collaboration et al. 2018). Unlike Astropy, the SunPy project was not formed to bring together and coordinate many existing developers and their Python packages. The development of the sunpy package was begun by a core group of scientists with no prior existing code base. It should be noted that the number of commits is only approximately related to contribution size since a single commit could include a substantial increase in functionality or be a simple typographical fix. Regardless, this distribution suggests that the core developer team has not grown substantially from that original core team. On the other hand, the total number of unique contributors is large, which means that there exists a pool of sunpy developers that are willing and have the knowledge to contribute. Converting these contributors into core developers is crucial to the long-term health of the community.

The aim of the sunpy package, the core package in the SunPy ecosystem, is to provide a set of Python tools for performing common tasks in the analysis of solar data. These tools include querying and downloading data, loading and visualizing time series and images, and performing coordinate transformations. In the following sections, we describe the primary capabilities of sunpy and highlight several improvements to the package that are included in version 1.0.

4.1. Data Search and Retrieval

4.2. Data Types

The sunpy package provides core data types that are designed to provide a general, standard, and consistent interface for loading and representing solar data across different instruments and missions. The two core data types currently supported in sunpy are handled by TimeSeries and Map, objects that support 1D temporal data and 2D image data, respectively. The purpose of these core classes is to standardize data structures regardless of the data source (e.g., observational data from independent instruments). The classes maintain a consistent interface for accessing data attributes such as the data array itself as well as the metadata and relevant units. This arrangement allows for an easier workflow in the analysis of solar data observations. These core classes also include functionality for data manipulation and data visualization. This section provides an overview of the TimeSeries and Map data types.

4.2.1. TimeSeries

Many observations in the field of solar physics consist of spatially integrated measurements as a function of time. For example, the X-Ray Sensor (XRS) instrument on board the Geostationary Operational Environmental Satellite (GOES), which is used as the classification standard for solar flares, continuously measures the disk-integrated X-ray flux as a function of time in two broadband channels. The TimeSeries class aims to accommodate such solar time series data.

Table 1.  Common Abbreviations and Definitions

Abbreviation	Definition
AIA	Atmospheric Imaging Assembly
DRMS	Data Record Management System
GOES	Geostationary Operational Environmental Satellite
HAE	Heliocentric Aries Ecliptic
HCRS	Heliocentric Celestial Reference System
HEEQ	Heliocentric Earth Equatorial
HEK	Heliophysics Event Knowledgebase
HGC	Heliographic Carrington
HGS	Heliographic Stonyhurst
HPC	Helioprojective Cartesian
IDL	Interactive Data Language
IRIS	Interface Region Imaging Spectrograph
JSOC	Joint Science Operations Center
LTS	Long-term Support
MDI	Michelson Doppler Imager
NASEM	National Academies of Sciences, Engineering, and Medicine
NOAA	National Oceanic and Atmospheric Administration
PEP	Python Enhancement Proposal
SDO	Solar Dynamics Observatory
SJI	Slit Jaw Imager
SOHO	Solar and Heliospheric Observatory
SEP	SunPy Enhancement Proposal
UTC	Coordinated universal Time
VSO	Virtual Solar Observatory
WCS	World Coordinate System
XRS	X-Ray Sensor

Download table as:  ASCIITypeset image

TimeSeries allows users to load time series data from a variety of solar instruments with appropriate units and timescales (see Section 4.4). A user can create a TimeSeries object either from data files stored locally (e.g., observational data sets acquired through Fido, see Section 4.1.1), or manually from custom time series data. The data array, metadata, and units data are all stored as attributes in the TimeSeries class.

Functionality is also provided for the manipulation of time series, including: adding, updating, truncating, resampling, and combining data within a TimeSeries or combining multiple TimeSeries together. TimeSeries also has built-in visualization methods to allow for easy inspection. An example of a TimeSeries created from GOES XRS observations of a solar flare is shown in Figure 2.

Zoom In Zoom Out Reset image size

TimeSeries currently supports the data sources listed in Table 2 in addition to indices of solar activity from the National Oceanic and Atmospheric (NOAA) Space Weather Prediction Center that track the solar cycle and its predicted progression. Due to its flexible data structure, it is straightforward to add additional instruments and data sources to the TimeSeries object.

Table 2.  Instruments Supported by the Timeseries and Map Objects as Described in Section 4.2

Supported by Timeseries	Instrument reference
Geostationary Operational Environmental Satellite (GOES) X-Ray Sensor (XRS)	Garcia (1994), Hanser & Sellers (1996)
Fermi Gamma-ray Burst Monitor (GBM)	Meegan et al. (2009)
Nobeyama Radioheliograph (NoRH)	Nakajima et al. (1994)
PRoject for Onboard Autonomy (PROBA2) Large Yield Radiometer (LYRA)	Dominique et al. (2013)
Solar Dynamics Observatory (SDO) EUV Variability Experiment (EVE)	Woods et al. (2010)
Reuven Ramaty High Energy Solar Spectroscopic Imager (RHESSI)	Lin et al. (2002)
Supported by Map	Instrument reference
COronal Solar Magnetism Observatory (COSMO) K-coronagraph (K-Cor)	de Wijn et al. (2012)
Hinode X-Ray Telescope (XRT)	Golub et al. (2008)
Interface Region Imaging Spectrograph (IRIS) Slit Jaw Imager (SJI)	De Pontieu et al. (2014)
PROBA2 Sun Watcher using Active Pixel System detector and Image Processing (SWAP)	Seaton et al. (2013)
RHESSI	Lin et al. (2002)
Solar and Heliospheric Observatory (SOHO) Extreme ultraviolet Imaging Telescope (EIT)	Delaboudiniere et al. (1995)
SOHO Large Angle Spectroscopic COronagraph (LASCO)	Brueckner et al. (1995)
SOHO Michelson Doppler Imager (MDI)	Scherrer et al. (1995)
SDO Atmospheric Imaging Assembly (AIA)	Lemen et al. (2012)
SDO Helioseismic and Magnetic Imager (HMI)	Schou et al. (2012)
Solar TErrestrial RElations Observatory (STEREO) Extreme Ultraviolet Imager (EUVI), COronagraph 1 and 2 (COR1/2) for both STEREO A and B	Howard et al. (2008)
Transition Region and Coronal Explorer (TRACE)	Handy et al. (1999)
Yohkoh Soft X-ray Telescope (SXT)	Tsuneta et al. (1991)

Download table as:  ASCIITypeset image

4.2.2. Map

A majority of solar data is in the form of images of the Sun. Images of the Sun are taken in multiple wavelengths from a wide range of both space- and ground-based instruments. For example, the Helioseismic and Magnetic Imager (HMI) instrument on board the Solar Dynamics Observatory (SDO) maps the magnetic field at the photosphere across the entire solar disk every 45 s. Images also require precise coordinate information in order to compare solar features observed across multiple wavelengths with different instruments.

The Map class in sunpy provides a framework to contain and analyze image data. A Map can be created from local files or using a URL to a remote data file. The Map class will automatically detect supported instruments and parse the metadata to infer the coordinate system from the appropriate Flexible Image Transport System (FITS) keywords (Thompson 2006; Pence et al. 2010). Other source-specific metadata is used to determine the appropriate color table and image normalization for visualization. It is also possible to create a custom Map by providing a 2D data array and metadata.

Similar to TimeSeries, the Map class contains the image data array, coordinate information, and relevant metadata as attributes. Visualization methods are also provided to inspect and plot solar image data. This visualization set includes the ability for Map to plot the image data in a way that represents the coordinates of the image accurately (see Section 4.3 for more on solar coordinates). This routine allows the user to plot coordinates of interest on a Map while correctly accounting for the coordinate frame. Other plotting components in Map include the ability to mask and clip the image data.

An example of a Map using data from the Atmospheric Imaging Assembly (AIA) on board SDO is shown in Figure 3. The left panel shows the full field of view of AIA using the appropriate color table and scaling for the observation, and the right panel shows a cropped view highlighting a solar flare whose GOES XRS light curve is shown in Figure 2.

Zoom In Zoom Out Reset image size

When analyzing the dynamics of features on the solar disk, it is important to account for variations due to the apparent rotation of the Sun, which includes solar differential rotation, a latitudinally varying rotation rate due to the nonrigidity of the solar interior (see Beck 2000). The sunpy.physics.differential_rotation subpackage provides the ability for a Map to be transformed to earlier or future times including the effect of solar differential rotation (see Figure 4).

Zoom In Zoom Out Reset image size

The Map class also provides functionality to analyze multiple images, such as overlaying images from different instruments with overlapping fields of view, or to combine multiple images together in a time-ordered sequence. This class includes the ability to coalign images from different instruments or images taken at different times to facilitate multi-instrument studies.

Map currently supports the data sources listed in Table 2 as well as the Helioviewer JPEG2000 image files of each of these data sources. Similar to TimeSeries, Map is architected to enable new data sources to be added easily.

4.3. Solar Coordinates

The sunpy.coordinates subpackage provides support for representing and transforming coordinates used in solar physics. These coordinates may represent events (e.g., flares), features on or above the Sun (e.g., magnetic loops), or the position of structures traveling throughout the heliosphere (e.g., coronal mass ejections). The package currently implements many of the most widely used Sun-centered coordinate frames including Helioprojective Cartesian (HPC), Heliographic Carrington (HGC), and Heliographic Stonyhurst (HGS), as well as Heliocentric Aries Ecliptic (HAE), Heliocentric Cartesian (HCC), and Heliocentric Earth Equatorial (HEEQ). See Thompson (2006) for more information about each of these coordinate frames. Additional coordinate frames will be available in future releases. The functionality provided in this package is built on top of and integrates with the astropy.coordinates framework (see Section 3.3 of The Astropy Collaboration et al. 2018).

An important feature of some of these solar coordinate frames is that they are observer-dependent, meaning that they are not fully defined without also specifying the location of the observer. The HPC frame, in particular, which is the most widely used coordinate frame for images of the Sun, places the origin of the frame at the observed center of the solar disk. This means that these observer-dependent frames have axes that change orientation depending on the location of the observer. The coordinates of the observer are stored in the same object as the other coordinate information. Since many observations of the Sun take place from or near the Earth, it is frequently an adequate approximation to use the center of the Earth as the observer position.

The observer-independent coordinate frames (HAE, HEEQ, HGC, and HGS) are useful for specifying the locations of features on the Sun or objects (e.g., spacecraft) in interplanetary space. The commonly used HGS frame is of particular note because it transforms in a straightforward manner to and from the Heliocentric Celestial Reference System (HCRS). This reference frame consists of the combination of two rotation angles: the time-independent angle between the Sun's rotation axis and the HCRS celestial pole (see Seidelmann et al. 2007) and the time-dependent angle of the Sun's central meridian (as seen from Earth) relative to the vernal equinox. This transformation provides the link from the frames defined in sunpy.coordinates with those defined in astropy.coordinates, allowing any solar frame to be transformed to and from celestial coordinate frames (see Figure 5). The functionality provided by the sunpy.coordinates subpackage has been extensively tested and agrees with published values in the Astronomical Almanac. For example, the apparent R.A. of the Sun agrees to a precision of 0.01 arcsecond.

Zoom In Zoom Out Reset image size

A few example applications of the sunpy.coordinates subpackage are shown in Figure 6. The leftmost panel shows magnetic-field-line extrapolations projected onto a SDO AIA 171 Å image of an active region. The center and rightmost panels of Figure 6 make use of functions in sunpy.coordinates to obtain the apparent (light-travel time-corrected) locations of solar system bodies and overlay them on images of the Sun in solar coordinate frames.

Zoom In Zoom Out Reset image size

This subpackage also provides the capability to query ephemeris information from a few different sources, including the active ephemeris in astropy.coordinates, JPL ephemerides, or JPL HORIZONS.⁵⁵

4.4. Units and Time Scales

4.5. Release Cycle, Versioning, and Long-term Support

The SunPy project makes use of many tools and web services to develop high-quality code and documentation consistent with best practices. This section provides an overview of these tools which enable the SunPy project to achieve its goals without central institutional oversight.

5.1. Testing

5.2. Documentation and Gallery

In order to foster collaboration, coordination, and code re-use, the SunPy project supports affiliated packages. These are Python packages that build upon the functionality of sunpy and/or provide general functionality useful to solar physics. Affiliated packages can also be used to develop and mature subpackage functionality outside of the sunpy core package for eventual inclusion. The following requirements must be met by affiliated packages:

• 1.  
  The package must make use of all appropriate features in sunpy.
• 2.  
  Documentation must be provided that explains the function and use of the package, and should be of comparable quality to sunpy documentation.
• 3.  
  A test suite must be provided to verify the correct operation of the package.

For a package to become affiliated, developers can apply to the lead developer, and the SunPy board provides the final approval. Packages are re-reviewed on a yearly basis to ensure that they continue to meet the standards. To aid discoverability, all affiliated packages are listed on the SunPy website,⁶⁶ and they are advertised at national and international conferences and workshops. Finally, the development of these packages is provided informal support by the SunPy developer community, and a package template⁶⁷ has been developed that simplifies and standardizes packaging, testing, and documentation.

The following sections provide short descriptions of the existing affiliated packages.

6.1. drms

6.2. Ndcube

6.3. Radiospectra

6.4. IRISPy

To date, the SunPy project relies largely on unpaid, volunteer efforts from early career scientists. The project has not received any significant direct financial support for its work facilitating and promoting open source and open development, including developing the sunpy package itself. This lack of financial support presents a number of challenges that the Astropy community also faces and have been described in Price-Whelan et al. (2018) and Muna et al. (2016).

The National Academies of Sciences, Engineering, and Medicine (NASEM) report on Open Source Software Policy Options for NASA Earth and Space Sciences (National Academies of Sciences, Engineering, and Medicine 2018) outlines several solutions to alleviate these problems—namely that the NASA Science Mission Directorate provide funding for new and existing open source software projects, promote scientists who spend time developing and improving open source software, and offer prizes for exemplary contributions to the open source software community. The NASEM report on Reproducibility and Replicability in Science (National Academies of Sciences, Engineering, and Medicine 2019) recommends that funding agencies invest in the research and development of open source software that support reproducibility. The SunPy project supports solutions like these for all relevant funding agencies (Christe et al. 2019) and furthermore has the ability to accept financial contributions from institutions or individuals through the NumFOCUS⁷⁰ organization. NumFOCUS is a 501(c)(3) public charity that collects and manages tax-deductible contributions for many open source scientific software projects such as NumPy and Astropy.

The SunPy project participates in two summer-of-code programs, as part of OpenAstronomy⁷¹ , which offer stipends for students to contribute to open source projects. OpenAstronomy is a collaboration between open source astronomy, astrophysics, and heliophysics projects to share resources, ideas, and to improve code and support open development. Since 2013, 16 students have contributed to sunpy and affiliated packages through the Google Summer of Code⁷² program. Through a similar program called the European Space Agency Summer of Code in Space⁷³ program, an additional 7 students have contributed since 2011. Many SunPy community members volunteered to serve as mentors.⁷⁴

As discussed in Bangerth & Heister (2013), a vital component to the long-term success of a project is building a healthy community of users, developers, and maintainers. The SunPy project has taken a number of steps to nurture and grow the SunPy community. We have adopted and enforce a formal code of conduct⁷⁵ that strives to foster an open, considerate, and respectful environment for all. Additionally, we maintain a number of active communication channels including mailing lists, real-time chats based on the open source Matrix protocol,⁷⁶ and weekly teleconferences. SunPy community members have also lead tutorials at national and international conferences, participated in summer programs, and provided mentorship to new members of the community. Developers and contributors are currently provided credit for their work by authorship on papers, posters, and release notes, as well as awards. For example, in 2018, Vishnunarayan K. I. was presented an award by NumFOCUS for exceptional contributions to the open source scientific software ecosystem by updating sunpy to use astropy.time.

Development of the sunpy core package has been ongoing for 8 yr, with the adoption of a formal project structure 5 yr ago. The core package has grown to provide significant and now mature functionality for a growing number of users. The release of version 1.0 is a significant milestone, and comes with a commitment to stability in future releases. Significant additional features are either being actively developed or are planned for future development. These planned udpates include support for generic spectra (one-dimensional or multidimensional), multidimensional data sets (e.g., slit spectrographs), and a standardized approach to metadata. The roadmap is maintained in a repository⁷⁷ to enable community discussion and suggestions.

The project formalization process, which defined a board structure, has succeeded in providing project stability as well as better recognition in the community. Through the board, significant decisions were able to be made such as joining NumFOCUS and adopting an official code of conduct,⁷⁸ the purpose of which is to ensure that the SunPy community is positive, inclusive, successful, and growing.

There are a number of obstacles to the continued growth and success of the project. The project does not yet have a significant and long-term funding stream. In addition to that challenge, the current core team is relatively small, which translates to an unhealthy dependence on key developers. A significant obstacle to the growth of the core developer team is the low familiarity of modern software engineering best practices in the solar community. Core developers of sunpy or affiliated packages must be knowledgeable of version control, code refactoring for public use, good user documentation, and unit testing. It takes considerable effort to provide new contributors with the appropriate guidance and training. The SunPy project is considering a number of ways to address this issue, including providing webinars, internship opportunities, and improving online documentation.

The SunPy project is now a member of the Python in Heliophysics Community,⁷⁹ whose members contribute to a collection of over 50 Python packages that span every subdiscipline within heliophysics. Burrell et al. (2018) provides an overview of the current state of Python packages in heliophysics and calls for a common framework to be developed. The development of sunpy is consistent with the standards established by the community (Annex et al. 2018) and many members of the SunPy project are signatories to these standards. The goal of this group is to coordinate Python development for heliophysics in order to improve interoperability and efficiency. In addition, some of the functionality provided by sunpy subpackages may be broadened to be generally useful for all of the heliophysics subdisciplines.

We thank the members of the community that have contributed to the SunPy project, that have opened issues and provided feedback, and that have supported the project in a number of other ways. We would like to acknowledge two new members of the SunPy board who joined while this paper was being prepared: Bin Chen and Tiago Pereira. Additionally, we thank Brian Dennis, Richard Schwartz, and William Thompson whose comments and discussion greatly improved this manuscript.

The following individuals recognize support for their personal contributions. B.M.S. is supported by the NSF grant AST-1715122 and acknowledges support from the DIRAC Institute in the Department of Astronomy at the University of Washington. The DIRAC Institute is supported through generous gifts from the Charles and Lisa Simonyi Fund for Arts and Sciences, and the Washington Research Foundation. D.S. was supported by STFC studentship ST/N504336/1 and STFC grant ST/N000692/1.

We acknowledge financial contributions from Google as part of the Google Summer of Code program and from the European Space Agency as part of the Summer of Code in Space program. We acknowledge financial contributions from NumFocus for improving the usability of SunPy's Data Downloader. Additionally, we acknowledge current and future funding from the Solar Physics Division of the American Astronomical Society for SunPy workshops and tutorials at annual meetings.

This work has made use of data from the European Space Agency (ESA) mission Gaia,⁸⁰ processed by the Gaia Data Processing and Analysis Consortium (DPAC).⁸¹ Funding for the DPAC has been provided by national institutions, in particular, the institutions participating in the Gaia Multilateral Agreement.

This research made use of astropy,⁸² a community-developed core Python package for Astronomy (Astropy Collaboration et al. 2013; The Astropy Collaboration et al.2018).

Software: astropy (Collaboration 2018), astroquery (Ginsburg et al. 2019), drms (Glogowski et al. 2019), GWCS (Dencheva et al. 2018), matplotlib (Caswell et al. 2019), ndcube, numpy (v1.14.5 van der Walt et al. 2011), pandas (McKinney 2010), pfsspy (Stansby 2019), scipy (Jones et al. 2001), sunpy (Mumford et al. 2019).