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!

GitHub Wiki RST Solution

After some deliberation with Cadair and DavidPS, we finally found out what was going wrong on the SunPy Wiki page for my GSoC application.

<Cadair> It seems that it throws it’s toys out of the pram if the title gets too long
<Cadair> and then wont come back
<Cadair> though changing the underline from = to # seems to have worked

The application page, stored in RST(restructuredText) format, would sometimes not render properly. Garbled text would be the outcome of saving the page, and yet, the preview worked perfectly fine. The solution to this is to not use “=” as a header/H1 marker, and to use “#” instead.