The Final Push

All good things must come to an end.

~ Some Dude on the Internet

And so, we have reached the close of the code-fest that is Google Summer of Code. It has been an enlightening, thoroughly enjoyable and skill-building journey. One that has laid the foundation of my future career and one that I will never forget.

In any program like GSoC, the mentors matter the most – they are the ones who enable a student to reach their potential and deliver something of note. I would like to thank all my SunPy mentors – Stuart, David, Steven, Nabil – for ensuring that I never had any uncleared doubts. Stuart, especially, has been available throughout the duration of the program, and was always around for a screenshare session, or to explain something that I didn’t understand. He was open to conversation even when he was out of town. I am very thankful for their active support! I would also like to thank Google and Melange for ensuring a smooth and wonderful experience. 

The last few weeks have gone mostly in testing and documentation. Stuart and I introduced some analytical tests to check on the accuracy of the coordinate transforms. The tests were mostly passing, except for one parameter which seems to be giving us the wrong values, i.e., expected values don’t match the output. Those interested in the mathematics behind this kind of testing may access the relevant document here, and those who wish to see the test code in action may check it out here

The final (in GSoC terms) code can be accessed here and the PR is on GitHub, of course! Over the next few days, I will be completing the SunPy Enhancement Proposal to get this pull request fully accepted. I also gave a presentation on Hangouts to explain the purpose of my module, whose IPython notebook can be accessed here.

Besides all this, I have been learning a bunch of web frameworks to aid in my quest for a job. It was Stuart’s suggestion to start learning Flask, and now that I am learning Django as well, I can see why he suggested it. Everything is so…simple in Flask. But then, it would be to my benefit to learn both to some extent. Miguel Grinberg’s Mega Tutorial on Flask has been extremely helpful, and I would recommend it to those who wish to learn web development in Python. Hopefully, with my Flask knowledge, and a bit of Bootstrap, I will be able to make a nice web framework for SunPy in the near future, or atleast I plan to!

I am signing off for now, but I may post some more stuff in the future. Stay tuned!

Break – Fix – Repeat!

Cadair commented 9 hours ago

@VaticanCameos I broke it

This quote seems to sum up all that we’ve done in the past few weeks. So far, the Coordinates Framework PR has 80 commits. We are to have a meeting on Tuesday to gauge progress and set the path for the rest of the month.

It has been quite an experience. Having complete ownership of a module isn’t easy. One has to think of design and implementation, testing and experimentation, etc. all in quick succession.  On top of that, the repository does not stay the same all the time – one is always on the bleeding-edge of things. Having said that, my mentor has been really supportive. I have migrated to a new laptop, and on his insistence, tried to install ArchLinux but failed due to some problems with the Radeon graphics card. Nevertheless, I am on Linux Mint for the time being!

A summary of things -:

  1. Some coordinate frames have undergone several changes – Heliographic and Helioprojective, more precisely. Helioprojective ‘Cartesian’ is in fact a spherical representation masquerading as Cartesian, so it was decided that it would be better to change the representation to spherical, but keep the attribute names as Tx and Ty.
  2. Astropy have introduced the RepresentationMapping class, which is a useful encapsulation of the mapping of frame representation attributes to the names that the designer wishes to specify, as well as their units. RM objects take a 3-tuple, thus.
  3. Helioprojective frames now have a new property – ‘zeta’ – which was earlier being mapped to the distance attribute. On reviewing the code, we found that distance should actually be ‘d’ (which was a FrameAttribute then) and it is better to have zeta as a property which returns the value of ‘D0 – d’. ‘zeta’ can be used in the constructor to generate a value for ‘d’. This ultimately fixed most of the transformation issues we had from Helioprojective to other class, except for a few corner cases which we are now working on.
  4. A lot has been learned about how to default attributes in the frame constructor. Careful consideration of the various input cases was necessary. Heliographic frames now default ‘rad’ and a FrameAttribute called ‘dateobs’. The empty frame case was the biggest thorn – breaking a lot of things. Since Astropy’s code purposefully generates an empty frame of the same class to check certain things, it was necessary to keep empty frame design clear in mind. Helioprojective frames can default ‘D0’ and ‘d’.
  5. SphericalRepresentation was subclassed to create Spherical180WrapRepresentation. This was done after Stuart noticed that the ‘hlon’ attribute actually spans a range of -180 to +180 degrees. Creating a negative valued longitude was not possible with ordinary Longitude objects. Thus, a new representation had to be created. All frames which were earlier on spherical representations have been shifted to this new frame.
  6. Currently, there are a few corner cases that have to be fixed. These include transformations from Helioprojective to Heliographic when all three attributes are specified as zero and transformation from Heliographic Stonyhurst to Heliographic Carrington which is breaking, presumably because of the dateobs parameter. The dateobs parameter will also be used to generate the Carrington offset for transformation.
  7. Lastly, the coordinates framework has, for the most part, successfully been integrated into the Ginga project! It is now used to model solar coordinates and visualize SunPy maps. This is great news, and it will also push us to work harder on keeping the framework bug free.

In other news, I have started delving into other projects, such as working on an IRC bot, some competitive programming (really lagging on this) and – of course – looking for jobs! The main thing though, is the side project that I have acquired from my mentor to build #sunpy’s irc logs website in Flask. It’s going to take a while as I am completely nil in web dev, but it will be quite worth it!

Oh, and here, have a gif which signifies what Germany have been like this World Cup . Over and out!

Germanic Slaughter

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 -:

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!

Welcome to GSoC!

Ladies and Gentlemen,

Presenting, Google’s welcome package!

 

Look at these beauties.

Look at these beauties.

Sexiest pen ever!

Sexiest pen ever!

Not pictured here are the wonderful GSoC stickers. I’ve already popped one out of the notebook and stuck it on the fridge. 😀

Thanks for the goodies, Google!