NOTE: the project ideas as of Feb 9, 17:00 UTC have been moved to the OpenAstronomy page at http://openastronomy.org/gsoc/gsoc2017/ (search for "astropy") - if you want to modify the ideas, please go to that page's github repo at https://github.com/OpenAstronomy/openastronomy.github.io.

Welcome to the project ideas page for the Astropy project! This page is a repository to collect ideas related to be both the core Astropy package along with affiliated packages.

Astropy will be participating in the Google Summer of Code 2017 under the OpenAstronomy organization. Strong project ideas and good mentor support are needed to make a strong org application to GSoC for OpenAstronomy.

In order to enter an idea please follow the template example idea below and append to the bottom of the document.

Package: Astropy core (or package name)

Suggested Mentor(s): Erik Tollerud

Difficulty: Beginner to Intermediate

Astronomy knowledge needed: none, but statistics knowledge/background useful

Programming skills: Python

The Quantity class is powerful but doesn’t have particularly useful support for uncertainties on quantities or other statistical approaches to thinking about numbers. A very straightforward way to make progress on this would be to create a subclass of Quantity called “Distribution” (or similar) that represents a probability density function of a quantity as Monte-Carlo-sampled arrays. This project would involve implementing this subclass, propagating operations while combining distributions, as well as tools for extracting useful information from such distributions. If there is time, this could also involve expanding this system to support common analytically-representable distributions such as Gaussian and Poisson distributions.

---

Package: regions

Suggested Mentor(s): Adam Ginsburg, Christoph Deil

Difficulty: Beginner to Intermediate

Astronomy knowledge needed: none

Programming skills: Python

ds9 region files are the de facto standard way to specify regions on the sky for many astronomers. The regions package has been developed to replace the dated pyregion module. To complete the transition, we need a fully operational ds9 reader/writer system, including appropriate metadata. This project will largely entail writing and modifying a parser and producing the appropriate associated tests. If there is time, a CASA regions reader/writer will also be developed.

Package: Astropy core

Suggested Mentor(s): Tom Aldcroft

Difficulty: Intermediate

Astronomy knowledge needed: None

Programming skills: Python, Cython, C, web

The Astropy core package was designed and implemented with priority placed on good code structure, long-term maintainability, and code correctness. Currently the package is nearly six years old and this strategy has proved its merit. Nevertheless, development decisions along the way often sacrificed performance in favor of clean or simple implementation. At this point as a relatively mature project with wide community adoption it makes sense to profile both the astronomical user community and the code to find areas where performance issues need to be addressed. In many cases there is "low-hanging fruit" where simple solutions like caching or initialization fixes can yield factors-of-many improvement. In other areas there may be need for more substantial changes and even reimplementation using Cython or C.

One of the key available technologies for performance evaluation is the asv (Air Speed Velocity) package which provides the infrastructure to do performance regression testing across a wide swath of a large project like astropy. Unfortunately its use in the normal development workflow is rather cumbersome. Improving this interface would make it much easier to both improve speed and to prevent performance regressions from getting into the code base.

This GSoC project thus has the following high-level steps:

• Poll the astropy user community for their perspectives on performance bottlenecks in astropy. Engage in discussion and develop a prioritized list of areas to improve. A minimal list of known issues right now includes coordinate initialization, iteration, and table / column creation.
• Work on asv (performance testing suite) to make it easy to run relevant tests for a development branch and compare to master.
• Get asv up and running regularly in a sustainable way with a maintenance model that allows for shared responsibility.
• Address astropy performance issues based on the prioritized list and asv results.

Package: Astropy core

Suggested Mentor(s): No commitments yet

Difficulty: Intermediate

Astronomy knowledge needed: any area of astronomy where you've seen FITS files and coordinate systems

Programming skills: Python

Here is a common astronomical problem: I have a table with objects on the sky, each of which has a flux and an observation time. I match them with some other photometric catalog and them compute certain values (e.g. the mass, the age and the accretion rate). I store all that in the table. Astropy offers a lot of classes to make this easier, for example coordinates that know how to transform between different coordinate systems. Once I write my publication, I need to store that table as a fits file and print it out to LaTeX. This is where the problem comes: Each of the special objects (coordinates, times, units) has metadata that does not easily fit into the data column.

Astropy grew out of several independent pacakges (pyfits, asciitable) that each did one thing well, but were not very easy to interoperate. Astropy has (mostly) unified the interface, but functionally components still work separately. In this project, you will makes things interoperable. For the example above, you need to develop a protocol that allows storage of coordinates and times in fits and ascii tables. There is some discussion about this in issue 5625.

This project includes:

• Find breaks in the workflow as described in the example above.
• Define protocols for meta data that make it work between different packages.
• Solicit feedback from the community on those protocols.
• Implement code and test cases.
• Test and document the steps above.
• Update documentation and examples to show the new capabilities.

Package: Astropy core

Suggested Mentor(s): Adrian Price-Whelan, Erik Tollerud, YOUR NAME HERE

Difficulty: Intermediate to expert

Astronomy knowledge needed: Understanding of coordinate transformations, some knowledge of astronomical coordinate systems would be useful

Programming skills: Python

The coordinates subpackage currently only supports transforming positional coordinates, but it would be useful to develop a consistent framework for also transforming velocities (e.g., proper motion to proper motion, or proper motion to cartesian) with full support for barycentric, galactocentric, and LSR motion. This project could be:

1. working with us to develop a consistent API for handling velocities within coordinates,
2. developing a trial implementation of an API,
3. actually doing core development to implement the new features, or
4. some combination of all of the above.

Package: Astropy core

Suggested Mentor(s): Pey Lian Lim, Brigitta Sipocz, YOUR NAME HERE

Difficulty: Advanced

Astronomy knowledge needed: none

Programming skills: Python, packaging, pytest

Astropy's test helper (inside astropy.tests) is very useful. I have some packages that do not want to use astropy-helpers submodule nor Astropy's package template, but could use its test helper very much. It seems natural to extract the test helper into a new package on its own, so any developer can take advantage of its extra pytest features (e.g., remote data, doctest, etc). Currently, the test helper uses other utility functions from astropy.utils and Astropy logging. Ideally, this new package would be a complete standalone. This project would be to explore ways to re-package Astropy test helper as a standalone package that is not dependent on Astropy, and make it happen.

Note: An attempt to make it more modular, but not taking it out of core, is available at https://github.com/astropy/astropy/pull/5770

Package: Astroquery

Suggested Mentor(s): Adam Ginsburg, Erik Tollerud, Brigitta Sipocz, Pey Lian Lim

Difficulty: Beginner to Intermediate

Astronomy knowledge needed: none, although it might be helpful for understanding some of the datasets

Programming skills: Python and basic concept about web queries and APIs

The Space Telescope Science Institute maintains a data archive called the Mikulski Archive for Space Telescopes (MAST). This archive holds data from many NASA astronomy missions, most notably images from the Hubble Space Telescope. Currently the only way to access this archive is through the MAST web site. In the coming months, however, the MAST group intends to document the web APIs the MAST web site uses. With those APIs in place, it will be possible to implement a Python module to access MAST datasets. astroquery, an astropy affiliated package, is the ideal place to put such a module, as it already has a lot of the frameworks and tools to make this sort of module possible and easy to use. So the aim of this project will be to implement just such a module. A possible set of milestones in this project might be:

1. Research/understand the MAST API sufficiently to determine who the following goal can be achieved.
2. Determine the best interface to download Hubble Space Telescope ACS imaging
3. Create an astroquery module to actually implement that interface
4. Add tests to ensure the module works correctly
5. Generalize that architecture to extend to other imaging data products
6. (Stretch goal) Add a module to do all the same as the above, but with spectroscopic data sets

Since this project relies on upstream API development for MAST, the alternative project would be to create astroquery modules of other yet missing Archives. A list of new services that have been suggested by our users can be found here and in this summary issue.

Package: working name: astrowidgets

Suggested Mentor(s): Matt Craig

Difficulty: Beginner to Intermediate

Astronomy knowledge needed: Basic understanding optical image reduction and photometry

Programming skills: Python, very basic knowledge of CSS layout, basic knowledge of javascript

The goal of this project is to develop a set of widgets allowing easy use of functionality from astropy and its affiliated packages in Jupyter notebooks. While some work in this direction has been done in reducer, a package that provides a widget-based interface to ccdproc, the widgets in reducer are too tightly bound to the task of image reduction to be useful outside reducer.

The final deliverable for the project will be a new package ready for application to be an astropy affiliated package.

Some of the deliverables for this project would be widget interfaces for:

• A FITS image viewer utilizing the affiliated package ginga to handle the image display. This widget should allow for overlays of sources from catalogs (using astroquery), selection of sources in the image using a mouse, and user-configurable key bindings.
• Point source detection and photometry using either photutils or sep.
• Observation planning using astroplan.

In addition, these Jupyter notebooks will be developed:

• Sample notebooks demonstrating how to compose the widgets into applications.
• An image reduction notebook, similar to reducer.
• A photometry notebook for source detection and photometry.
• A notebook for performing differential photometry on a time series of measurements.

Preliminary development of this project is already underway, so some of the specific deliverables might have changed by the beginning of the summer of code.

Package: Astropy core and astroplan

Suggested Mentor(s): Brett Morris, Stuart Littlefair, Erik Tollerud

Difficulty: Intermediate

Astronomy knowledge needed: none, although might be helpful if optimization API changes are needed

Programming skills: Python

You want to schedule observations of one thousand targets over the next month. You are given one hour. Can you help us make astroplan the tool that's up to the task?

Last summer's astroplan GSoC student began implementing a module for scheduling astronomical observations. These scheduling operations require many calls to basic coordinate calculations – e.g. when does this target rise/set? – which can be optimized at several places within astropy core in the SkyCoord object and within the astroplan package to speed up astroplan's schedulers. Some goals of this project are to:

1. Profile astroplan's rise/set functions and identify inefficiencies in the SkyCoord object
2. Make efficiency improvements wherever possible with the findings of Step 1
3. Design/implement an API for accessing simple trigonometric rise/set calculations within astroplan's schedulers (this is where some observational astronomy experience would be handy)
4. Test improved astroplan against some target use cases. We'd like to generate schedules for thousands of targets in a reasonable amounts of time, like those required by the LCOGT operators.