The Midterms Approach

It has been a long, long two months for me, folks. I have finally completed my last set of semester exams, and graduated from college. Celebratory dances and jigs apart, this also meant that I could devote full time to the work, and that is all that matters!

I had not been sitting idle for that matter during my exams, either. Following on from the issue that Stuart and I posted on Astropy, regarding SkyCoord not recognizing frames in Cartesian representation, a lot has changed since then. Tom Aldcroft, a collaborator with Astropy, began working on adding the requisite changes to the SkyCoord class, with guidance from other Astropy members such as Erik Tollerud (one of the main collaborators who worked on APE5). I summarize some of the changes here as follows -:

1. The concept of frame_attr_names was removed in favour of FrameAttribute and TimeFrameAttribute objects. For example, if I am to specify an attribute ‘d’ which defaults to 1AU (Astronomical Unit, for the uninitiated), I would write -:

   d = FrameAttribute(default=(1*u.au).to(u.km))

   Not only does this make the code easier to read, it is an example of good design principles in object-oriented programming. Additionally, such attributes are specifiable in the constructor during frame initialization.

2. Getters and setters were added for the representation property of a frame class. One may now change the representation of a frame coordinate simply by setting the representation property.
3. _frame_specific_representation_info was added as a nested dict which stores ‘overrides’ of representation information. For example, if I want a frame’s Cartesian representation units to be in degrees, I would specify it in this dict. I could then access the overriden representation by writing frame_coord.cartesian, for example.

I contributed to this pull request by adding tests for the builtin_frames.py and sky_coordinate.py files. It was an exercise in git rebasing, and I learned that the git push that follows a rebase must be done with the -f (forced) parameter. Once the SkyCoord PR was merged to Astropy-master, SkyCoord was SunPy ready. It was rather unfortunate that I fell sick in between, and I could not contribute as many tests as I would’ve liked.

The following week, my Map Tests PR was finally merged into SunPy-master. It underwent a lot of scrutiny before Stuart finally decided to merge it because it was out unmerged too long! It feels nice to have contributed something substantial, but I knew that the real work still remained: the coordinate frames!

We began by specifying some Coordinates API tests for SunPy, as a roadmap to the features we wanted to achieve. They can be found here. Initially, of course, these tests will fail, but as features are added to the codebase, each one of those tests is supposed to pass. They were modelled after the API tests in the Astropy codebase. These will also help in completing the SunPy Enhancement Proposal which I’d filed as a PR earlier, to the sunpy-SEP repository.

Then, we began work on the coordinate frames. The PR here captures the work done so far on the coordinates API. Four frames have been defined for use with SunPy – Heliographic (Stonyhurst and Carrington realizations), Heliocentric and Helioprojective. Each of their representations and frame attributes have been defined as given in Thompson. Additionally, a transformation framework based on Astropy’s frame_transform_graph has also been created. Since each frame subclasses astropy.coordinates.baseframe.BaseCoordinateFrame, each of them gets registered into Astropy’s frame registry. The transformation framework makes use of the mathemagic given in sunpy.wcs. This was a re-implementation project after all, and this is how we plan to phase out sunpy.wcs in favour of sunpy.coordinates! I feel like a lot of things are finally coming into place.

Once I’m done with the low-level frame classes, I will look to possibly patching the high-level SkyCoord object to work properly with SunPy frames.

I’d like to add a closing thanks to my mentors – Stuart, David, Steven, Nabil and the SunPy-Astropy combine for helping me come this far. It’s been fun so far, I’m looking forward to more!

Two Weeks In

A lot has transpired, two weeks into the coding period. I have been rather handicapped by the inappropriate timing of my semester exams, and yet, I have gained a few insights into work ahead.

To begin with, my map tests branch is finally passing on Travis CI. With a few cosmetic changes, I assume it will be merged on Monday during the developer meeting. Next, the Astropy community have merged their APE5 PR and are in the final stages of setting it up for the 0.4 release, which is slated for 3rd June. The APE5 is an important design document for the coordinates subpackage and introduces a clear separation of concerns – which class does what, and how to use them.

Astropy has subdivided the notion of a coordinate object into the following components -:

1. Coordinate Representation: It is a particular way of describing a unique point in a vector space (usually 3D space). Some examples of significance to SunPy are the Cartesian and Cylindrical representations.
2. Reference System: It is a scheme used to orient points in a space. It is used to describe how a point is transformed from system to system. Examples from the Astropy codebase are the ICRS and equitorial coordinates (mean equinox) systems.
3. Coordinate Frame: This is a specific realization of a reference system. Some systems may have only one meaningful frame while yet others may have several different frames. A tentative example in the proposed SunPy subpackage would be that of the helioprojective coordinates, with Stonyhurst and Carrington realizations.

For separation of concerns, there are three types of classes involved -:

1. Data Representation: These classes are to be used to represent the data in a form meaningful to the Astropy/SunPy user. They are subclassed from the `CoordinateRepresentation` abstract class. They are made to store the actual spatial information of a coordinate as a set of `Quantity` subclasses. They also provide methods to invoke transformations between systems.
2. Low-Level: These classes are to serve as descriptions of both coordinate frames and act as containers around the data. They subclass from `CoordinateFrame`. Note that a pure frame is one that does not have any coordinate data, while a frame that does have such data becomes a coordinate.
3. High-Level: These classes wrap around the low-level classes and use their functionality. They provide additional functionality to make the low-level classes easier to use. Astropy uses the `SkyCoord` class to this end.

These descriptions have been copied verbatim from my SunPy Enhancement Proposal., which is still a work in progress (here). Such proposals are put forward whenever SunPy undergoes a major feature change, or some major modifications. 

There has been some debate on whether Astropy’s SkyCoord class should be able to support representations such as the Cartesian and Cylindrical, out of the box. Such functionality is important to SunPy. This issue thread and consequent PoC seeks to address that concern. I will be adding tests and documentation so that the PR is complete and it is merged into the Astropy codebase.

I created a bunch of Interactive Python notebooks for the purpose of getting everyone up to speed on how Astropy’s coordinate subpackage works and how we will be using it. They can be found at -:

• The astropy.coordinates Subpackage
• Playing With Frames

For the duration of my exams, I’ll try my best to add new stuff to SunPy, after Astropy v0.4 is put out of development stage.

More later!