Has it been a month already?
Note — The following post has been spiced up by a sleep-drunk author with a bit of colourful imagery and slight exaggeration for artistic needs, please be advised.
If you compare this post’s GSoC progress footnote (at the bottom) with the one in the previous fortnight’s blog, you will find a marked difference.
On the basis of that (and the Github contribution graph to the left), I’m happy to say that the early stumble I had at the start of the coding period is over and I’m now keeping pace with my GSoC timeline.
The midway point of the project has been reached, with the bulk of the general routines translated. Now I’ll give my attention to the more specialized routines (which have several dependencies, requirement of external packages, unique cases, et cetera)
Since I made use of gaming terminology in my last post (the Steam Summer Sale is happening right now, so why aren’t you there instead of here?) and I’ve drawn a blank on what more to write about, I’ll just give a few examples of what all I’ve encountered till now (and got my coding EXP from).
Quest Title: Sometimes it’s not my fault?
The translated routine co_aberration was giving out the wrong output, no matter what I did. Searching for type instabilities or quadruple checking with the original code in IDL AstroLib lead to nothing. Finally I had to go line by line through the code (each time correlating the output from IDL), until I found that the bug wasn’t there in co_aberration! It was in one its dependencies — sunpos.
Result:
Slightly frustrating. However, the intense scrutiny I gave to co_aberration wasn’t wasted as it lead to AstroLib.jl/issues/24, some nice discussions and a treasure chest of good things.
Quest Title: Sometimes it’s definitely not my fault!
50 years have passed. But I do not age. Time has lost its effect on me. Yet the suffering continues. The code does not give the right output. (Samurai Jack reference)
Until the time came to test the helio routine with an example provide from IDL AstroLib, every little thing about the function was coming along perfectly. It was a slightly more complex function than the norm, as it required modifications to the Planet type provided by AstroLib.jl, among other things. The incorporation of Planet into the code (something not done in the original IDL code) went seamlessly, despite my misgivings.
And then the function was tested with the given IDL example (provided in the IDL AstroLib helio documentation).
The function output was wrong. Debugged and found some actual errors, which I corrected. However, the output was still wrong. Modified the code again. Output still wrong. Imagine what happened next(see image).
After a few hours of this, I just went out of my room and took a walk in the rain (the rain is a daily occurrence at my current place of stay, Goa, which is also a famous tourist spot in India). There was no hope. There was nothing left. I questioned the futility of my life and existence.
And it was at that moment that it struck me -
What if? What if the example itself is wrong?
Well, the answer was yes. The example had one incorrect number and so the 2nd iteration (and not the 102nd) of the code I’d written (where I had found some actual errors) was the code I needed. Nothing else was required, nor asked for.
Result:
I sent a PR to IDL AstroLib repository that fixed that mistake in the example.
And I guess I have now found the kind of bug that I hate the most.
It’s the kind that doesn’t exist.
Quest Title: Where was this supposed to go again?
Unlike in Python, where features like World Coordinate System, FITS File Handling, Astronomical Time have now been merged into the mega-corporation AstroPy Inc. , you’ll find these features are catered to by specialized packages/libraries in Julia (specifically in JuliaAstro organisation).
This creates a few tricky situations where the routines I translate overlap between AstroLib.jl and some other libraries.
One such situation occurred when a feature request for a date of year format was issued in the main JuliaLang repository. Now there’s a routine date_conv (in IDL AstroLib) that does that, which I can translate to AstroLib.jl. However, the routine is mostly covered (except for this specific feature) by the package AstronomicalTime.jl.
I brought the problem a bit tepidly to the concerned parties, fearing that this could turn into a function conquest war (is that even a term?) with cross-package raids (“I will take your docstrings!”) and whatnot. Thankfully Mosè sensed my overflowing imagination and quickly reined it in.
Result:
Now that my second mentor Kyle Barbary gave me a bit of a primer on implementations and dependencies work, I look at my younger (by a week) self and slightly ‘tsk tsk’ my head in disapproval.
Quest Rewards:
For the conclusion, I think it’s pretty safe to say now that Google Summer of Code has been much “more” than what I had expected, in all kinds of sense. Evaluation period starts now, so lets see what happens next.
Footnote : GSoC Progress #2
No of procedures translated — 10.5/21 (#19, #21, #22, #25, #26, #27, #29)
Also, a few issues (the Github kind) related to my project — Uno, Dos, Tres
Project prognosis till now — Going Strong / Halfway Point Reached!
