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 -:
- 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.
- 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.
- 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 -:
- 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.
- 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.
- 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 -:
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!
My GSoC Journey 