Astropy: A Community Python Package for Astronomy

The Astropy Collaboration; Thomas P. Robitaille; Erik J. Tollerud; Perry Greenfield; Michael Droettboom; Erik Bray; Tom Aldcroft; Matt Davis; Adam Ginsburg; Adrian M. Price-Whelan; Wolfgang E. Kerzendorf; Alexander Conley; Neil Crighton; Kyle Barbary; Demitri Muna; Henry Ferguson; Frédéric Grollier; Madhura M. Parikh; Prasanth H. Nair; Hans M. Günther; Christoph Deil; Julien Woillez; Simon Conseil; Roban Kramer; James E. H. Turner; Leo Singer; Ryan Fox; Benjamin A. Weaver; Victor Zabalza; Zachary I. Edwards; K. Azalee Bostroem; D. J. Burke; Andrew R. Casey; Steven M. Crawford; Nadia Dencheva; Justin Ely; Tim Jenness; Kathleen Labrie; Pey Lian Lim; Francesco Pierfederici; Andrew Pontzen; Andy Ptak; Brian Refsdal; Mathieu Servillat; Ole Streicher

Source-linked AI summary

Astropy: A Community Python Package for Astronomy

The Astropy Collaboration, Thomas P. Robitaille, Erik J. Tollerud, Perry Greenfield, Michael Droettboom, Erik Bray, Tom Aldcroft, Matt Davis, Adam Ginsburg, Adrian M. Price-Whelan, Wolfgang E. Kerzendorf, Alexander Conley, Neil Crighton, Kyle Barbary, Demitri Muna, Henry Ferguson, Frédéric Grollier, Madhura M. Parikh, Prasanth H. Nair, Hans M. Günther, Christoph Deil, Julien Woillez, Simon Conseil, Roban Kramer, James E. H. Turner, Leo Singer, Ryan Fox, Benjamin A. Weaver, Victor Zabalza, Zachary I. Edwards, K. Azalee Bostroem, D. J. Burke, Andrew R. Casey, Steven M. Crawford, Nadia Dencheva, Justin Ely, Tim Jenness, Kathleen Labrie, Pey Lian Lim, Francesco Pierfederici, Andrew Pontzen, Andy Ptak, Brian Refsdal, Mathieu Servillat, Ole Streicher

arXiv:1307.6212v1Jul 23, 2013astro-ph.IM

TL;DR

Astronomy’s Python tools were fragmented and difficult to maintain or install consistently. This paper presents Astropy v0.2 as a coordinated core package and reports a development workflow that has worked well for contributions by many developers.

Problem
Astronomy’s fragmented Python packages created duplication, inconsistent interfaces, and installation and maintenance difficulties for users.
Method
The paper presents Astropy v0.2, a coordinated core package consolidating astronomy-specific functionality alongside a community development and testing workflow.
Results
The development workflow has worked well, enabling contributions by many developers and blurring the distinction between developers and users.
Takeaways & Limitations
Astropy provides a common coordinate API and shared astronomy tools intended to simplify package use and reduce repeated implementation across the community.
Takeaways & Limitations
Generalized WCS support beyond the FITS representation remained in the early planning stages.

Abstract

from arXiv · show

We present the first public version (v0.2) of the open-source and community-developed Python package, Astropy. This package provides core astronomy-related functionality to the community, including support for domain-specific file formats such as Flexible Image Transport System (FITS) files, Virtual Observatory (VO) tables, and common ASCII table formats, unit and physical quantity conversions, physical constants specific to astronomy, celestial coordinate and time transformations, world coordinate system (WCS) support, generalized containers for representing gridded as well as tabular data, and a framework for cosmological transformations and conversions. Significant functionality is under active development, such as a model fitting framework, VO client and server tools, and aperture and point spread function (PSF) photometry tools. The core development team is actively making additions and enhancements to the current code base, and we encourage anyone interested to participate in the development of future Astropy versions.

1. Introduction

Astropy was created to coordinate fragmented astronomy-specific Python development around a common core package. This paper presents its first public release, v0.2, and outlines its capabilities, workflow, and planned functionality.

Motivation: Fragmented development produced dozens of astronomy Python packages with duplication and little coordination.The fragmentation also led to a lack of homogeneity across packages.
Motivation: Started in 2011, Astropy aimed to coordinate developers and simplify the landscape of astronomy Python tools.The project’s development mailing list had over 200 individuals signed up at the time described.
Project scope: The project’s primary aim was a core astropy package covering astronomy-specific functionality while complementing NumPy and SciPy.The broader project also included work beyond the core package.
Design philosophy: Astropy’s interface philosophy emphasizes concise, readable code that resembles spoken or written language and helps reduce errors.The design is intended to let astronomers focus more on science objectives rather than interpreting obscure code.
Paper scope: The paper presents the first public astropy release, v0.2, reviewing current capabilities, development workflow, and planned functionality.It provides an overview rather than detailed package documentation, which is available online.

2. Capabilities · 2.1. Units, Quantities, and Physical Constants

Astropy’s capabilities include units, quantities, and physical constants, with support for unit manipulation, conversions, equivalencies, standards, array-based quantities, and astronomy-specific calculations. The package also covers broader sub-packages for dates and times, coordinates, data, file formats, WCS transformations, and cosmological utilities.

2. Capabilities: Astropy’s capabilities overview spans units and conversions, dates and times, celestial coordinates, tabular and gridded data, file formats, WCS transformations, and cosmological utilities.The paper illustrates these areas with concise code examples and refers readers elsewhere for additional details.
2.1. Units, Quantities, and Physical Constants: The astropy.units sub-package attaches units to scalars and arrays, converts between unit systems, defines custom units, and supports non-strict equivalencies.It originated in pynbody and was significantly enhanced in behavior and implementation.
2.1.1. Units: The Unit class represents manipulable base units that can be composed, decomposed, converted, or matched to identical higher-level units.Users can define standalone base units or construct units by composing existing ones.
2.1.1. Units: Unit equivalencies represent equations linking different physical quantities, including photon frequency, wavelength, and energy.Users supply an equivalency list to perform conversions between such quantities.
2.1.1. Units: Astropy supports multiple astronomy-community unit-string standards and lets users select the appropriate standard for external file input and output.Supported standards include FITS, CDS, and VO-related formats, while OGIP support was planned for the next major release.
2.1.2. Quantities and Physical Constants: Attaching units to Python scalars or NumPy arrays produces Quantity objects that preserve units during arithmetic with numbers and other quantities.Multiplication and division retain unit information in the resulting objects.
2.1.2. Quantities and Physical Constants: Quantity objects convert efficiently across large NumPy datasets through .to(), using dimensional equivalence or supplied equivalencies.The conversion requires dimensionally equivalent units unless an equivalency is provided.
2.1.2. Quantities and Physical Constants: Astropy.constants provides astronomical constants with associated units, provenance metadata, and uncertainties for calculations using Quantity objects.The paper illustrates calculating the gravitational force between two bodies in Newtons.

2.2. Time

The astropy.time package supports astronomical time manipulation across specialized time scales and representations, with high-precision computations enabled by its SOFA-based implementation.

Time scales and representations: astropy.time supports astronomical time scales including UTC, TAI, and UT1, alongside formats such as JD, MJD, and ISO 8601.These scales and representations are commonly used in astronomy.
Time scales and representations: Users create Time objects by providing values together with their time format and time scale.Inputs may be scalar values or sequences, with formats including ISO, JD, and Unix time.
Implementation and precision: The package uses a derived version of the Standards of Fundamental Astronomy time and calendar library.The implementation leverages SOFA routines for time and calendar calculations.
Implementation and precision: Two 64-bit floating-point values represent each time, enabling a dynamic range of 30 orders of magnitude for high-precision computations.This representation supports accurate fundamental time-scale conversions.

2.3. Celestial Coordinates

Astropy’s astropy.coordinates sub-package provides a common Python API for representing, parsing, formatting, and transforming astronomical coordinates. It supports multiple coordinate systems, line-of-sight distances, and extensibility through custom systems and a transformation graph.

Celestial Coordinates: astropy.coordinates provides a common Python API for manipulating, parsing, converting, and formatting astronomical coordinates.It is intended to relieve astronomy packages from reimplementing common coordinate utilities.
Celestial Coordinates: Coordinate objects offer natural Python representations, flexible string, numeric, and tuple inputs, and straightforward transformations between coordinate systems.The package also aims to support custom coordinate systems consistently with built-in systems.
Celestial Coordinates: Implemented coordinate classes include equatorial systems such as ICRS, FK4, and FK5, along with Galactic coordinates.Classes provide customized initializers, formatting defaults, and system-specific functionality such as precession to a new equinox.
Celestial Coordinates: Coordinate objects can represent three-dimensional positions by optionally including a line-of-sight distance from the coordinate-system origin.Distances may be specified in physical units.
Celestial Coordinates: New coordinate systems can be added through a transformation graph that selects the shortest path between connected systems and applies the required transformations.Adding a system requires implementing one pair of transformations to and from an already connected system.

2.4. Tables and Gridded data

Astropy’s Table and NDData classes address astronomy-specific shortcomings in conventional tables and arrays by representing tabular and gridded data together with their associated metadata. Table supports flexible table construction and I/O, while NDData extends NumPy arrays with masks, flags, uncertainties, units, and transformations.

Metadata-aware data structures: Astropy’s Table and NDData classes represent astronomical tables and n-dimensional gridded datasets while retaining associated metadata.They address metadata needs including units, masks, per-cell attributes, keyword-value pairs, comments, and astronomy-specific formats.
Table: The Table class wraps NumPy structured arrays and simplifies creating tables, modifying rows and columns, masking values, and reading or writing common file formats.It provides a higher-level interface for heterogeneous columns and variable row counts.
Table: Table supports units for individual columns and arbitrary metadata stored in Table.meta.Column units use the astropy.units framework.
NDData: The NDData class stores n-dimensional data in a NumPy ndarray while supporting keyword-value metadata, boolean masks, flags, uncertainties, units, and transformations.Its ndarray storage preserves compatibility with other scientific packages.

2.5. File Formats

Astropy provides broad file-format support through FITS, ASCII-table, and VOTable sub-packages. These tools support standard and specialized formats, compression, in-memory editing, interoperability, and handling of nonstandard or imperfect files.

2.5.1. FITS: astropy.io.fits implements all FITS-standard features, including images, binary tables, ASCII tables, and common compression algorithms.FITS header-data units use Python classes, NumPy arrays for data, and a Header class for metadata.
2.5.1. FITS: FITS files can be read, modified in memory, and written back, including transparently when gzip-compressed.The workflow includes opening files, accessing and modifying headers and data, and writing new files to disk.
2.5.1. FITS: The FITS implementation supports an extensive variety of files, including deprecated GROUPS HDUs and non-standard HDUs encapsulating multiple FITS files.Its long development history supports files that deviate from the FITS standard.
2.5.1. FITS: Astropy’s FITS interface matches PyFITS, allowing existing code to migrate by changing import statements without other code changes.The integration also enables future links with Astropy’s Table, unit, and WCS support.
2.5.2. ASCII table formats: astropy.io.ascii reads and writes tabular data across generic, specialized, and fixed-width ASCII-based formats.Supported formats include space-delimited, tab-delimited, comma-separated, CDS, IPAC, IRAF DAOphot, and LaTeX tables.
2.5.3. Virtual Observatory tables: astropy.io.votable supports reading and writing VOTable versions 1.1, 1.2, and proposed 1.3 using NumPy structured arrays.Streaming input reduces memory use, and gzip- and bzip2-compressed files are supported transparently.
2.5.3. Virtual Observatory tables: VOTable data can be converted to editable Table objects and returned without data loss, while workarounds and validation support imperfect standard compliance.The volint tool provides compliance recommendations and validates files against the official VOTable schema.

2.6. World Coordinate Systems

The astropy.wcs sub-package provides FITS-specific World Coordinate System transformations, mapping image pixels to real-world coordinates. It wraps wcslib and supports additional distortion conventions, while a generalized representation-independent WCS remains planned.

Current FITS WCS support: astropy.wcs provides FITS-specific World Coordinate System transformations that map image pixel locations to real-world units such as celestial-sphere positions.Its scope follows the FITS WCS papers and is distinct from a planned general WCS package.
Current FITS WCS support: The sub-package wraps wcslib for FITS header parsing, matching the behavior of other tools that use wcslib.This provides consistent parsing behavior across the tool ecosystem.
Current FITS WCS support: SIP and table lookup distortions extend the basic FITS WCS support, and each transformation can be used independently or together in a fixed pipeline.These additions follow the basic FITS WCS functionality provided by the wrapper.
Future generalized WCS: A generalized WCS is planned to map world coordinates and image coordinates in either direction without being tied to FITS representation.The planned package would also connect more closely with other Astropy components, including astropy.coordinates.

2.7. Cosmology

Astropy’s cosmology sub-package represents cosmological models as parameterized classes and provides calculations based on those models. It supports widely used, non-flat, and time-varying dark-energy cosmologies, with implementations tested against established calculators and Mathematica when needed.

Cosmology model representation: It provides classes for widely used cosmologies and functions for calculating quantities that depend on a cosmological model.The framework also accommodates cosmologies that are non-flat or have a time-varying dark-energy pressure-to-density ratio, w.
Cosmology model representation: The sub-package represents each cosmology as a class whose attributes specify parameters such as the Hubble parameter, CMB temperature, and matter and dark-energy densities at z = 0.Methods on each cosmology object perform calculations using these parameters.
Cosmology utilities: FlatLambdaCDM objects can calculate comoving volume, age, and transverse separation at a given redshift, with equivalent procedural functions also available.The procedural functions take cosmological parameters directly.
Supported cosmologies: Pre-defined instances include WMAP5, WMAP7, and WMAP9 parameter sets, while supported dark-energy models include a cosmological constant, constant w, and w(a) = w0 + wa(1 −a).Arbitrary cosmologies can be represented by subclassing a basic cosmology class.
Validation: The code is tested against Wright’s web-based cosmology calculator and two other widely used calculators, with Mathematica used when those calculators lack sufficient precision.This testing strategy supports meaningful comparisons when calculator precision is adequate.

3. Development Approach

Astropy is developed for and partly by the astronomy user community through permissive, collaborative open-source practices. Its workflow combines GitHub-based review, extensive testing, continuous integration, and accessible contributions from users.

Community philosophy: Astropy is developed for and at least partly by the astronomy user community, with an interface designed around working astronomers’ workflows.The package also uses software expertise to support broad adoption and welcomes input from all users.
Collaborative workflow: GitHub hosts Astropy’s main git repository, and non-trivial changes enter through pull requests for review before merging.This process improves the quality, documentation, and testing of included code.
Testing and integration: Several thousand tests check scientific correctness and programming-interface behavior, with continuous integration running them across configurations and platforms.Configurations include different Python and NumPy versions and operating systems.
User participation: The workflow enables contributions from many developers and users, including bug fixes and documentation suggestions submitted directly through the web browser.Documentation readers can suggest improvements without prior knowledge of git version control.

4. Planned functionality

Astropy’s active development targets major new functionality for the next v0.3 release and longer-term expansion. Planned work spans interoperability, data handling, analysis tools, coordinate transformations, and Virtual Observatory services.

Next release: For v0.3, Astropy plans improved interoperability, including seamless integration of astropy.units across all sub-packages.The development effort also targets additional package-level enhancements.
Next release: For v0.3, coordinates will support NumPy arrays for efficient representation and conversion in large datasets.The planned release also includes support for more file formats in Table and NDData objects.
Next release: For v0.3, planned additions include a Virtual Observatory cone search tool and a generalized model-fitting framework.Statistical functions commonly used in astronomy are also listed among the planned functionality.
Longer term: Longer-term plans include image analysis with aperture and PSF photometry, spectroscopic analysis, and generalized WCS transformations beyond the FITS WCS standard.These plans extend Astropy’s analysis and coordinate-transformation capabilities.
Longer term: Longer-term functionality includes a SAMP server/client, SIAP support, and possible TAP support, while the package will remain continuously evolving.TAP support is under consideration, and the core functionality is expected to grow beyond the listed plans.

5. Summary

Astropy’s first public release, v0.2, provides core astronomy functionality across units, time, coordinates, data, file formats, WCS, and cosmology. The project was developed through international collaboration, with plans for greater interoperability and new functionality.

Release: Astropy v0.2 is presented as the package’s first public release and a core Python package for astronomers.The paper describes the main functionality included in this release.
Functionality: The release includes units and conversions, dates and times, celestial coordinates, tabular and gridded data, astronomical file formats, WCS transformations, and cosmological calculations.These capabilities are listed as the main functionality described in the paper.
Development: Astropy’s development approach enabled an international collaboration of scientists and software developers to create and contribute to the package.The paper briefly describes this collaborative development approach.
Future plans: Future plans include greater interoperability among sub-packages and new functionality.The authors also invite community members to adopt Astropy, report issues, and develop new functionality.