GSoC @ Stingray: Diving into coding period. blog #2
Hey there!
It is time to write a blog about my experience in the coding period so far. So here it goes.
The official coding period for GSoC’22 started on the 13th of June. After discussing with mentors I decided that the first task would be to create a base structure of the code for Bexvar. As the method was already implemented by Dr. Johannes Buchner (who also suggested implementing this method in Stingray)and David Bogensberger, we decided to use this implementation as a reference.
I spent the first 2–3 days planning the structure of the code and planning its implementation in Stingray’s code base. At first, the implementation seemed easy. Although as I explored more and discussed my ideas with my mentors I realized that there are many small but important changes that need to be made.
In addition to these, I realized that I had to set up a proper environment on my computer to write, edit and test the codes that I write. I decided to use Visual Studio Code (VS Code) for it. Before the contribution period, I had only a little familiarity with Github and had never used git in my local system. I somehow made it through the contribution period without installing it. Now since I had an open source project at hand which will require frequent commits, I decided to install git and GitHub desktop on my computer and learn to use git with CLI. I found out that along with many useful tools for professional programming, VS Code also provided support to use git inside from the editor, this seemed quite useful for my purpose. I learned how to install and work with multiple versions of Python. I learned how to set up a Python virtual environment and use it to test codes in a controlled environment. I had to go through multiple iterations of installing, uninstalling, and then reinstalling several packages to set everything perfectly. This made me a bit irritated but later on, I realized that this helped me save a lot of time while coding for the project.
After going through a few iterations the base code was ready and working. It still needed some improvements and structural changes. It had a core function that reads the light curve data from an AstroPy table. After that, it would call internal functions successively to finally obtain the Bayesian Excess Variance of count rate. My mentor Prof. Matteo suggested that I start a PR with this version of the code. As I made this PR, we started discussing how to improve the code.
My mentors pointed out that my core function bexvar() needed further modularization. We decided to separate it into two functions, A core function bexvar() which will accept light curve data as a set of NumPy arrays or lists and calculate bexvar, and a bexvar_from_table() function which can read light curve data from an AstroPy table and call bexvar(). This change made the core bexvar() function more general as now users would not need to have light curve data in form of an AstroPy Table object to obtain bexvar. Also, in the future, we can create a function like bexvar_from_table() which can read data from Stingray’s Lightcurve object and call bexvar().
In the next phase, I updated existing docstrings, added docstrings where it was missing, and worked on code formating. At this stage, the code was still failing in Stingray’s CI tests. The reason behind the failures was that the code uses an integrator ReactiveNestedSampler from UltraNest — a robust, general purpose Bayesian inference engine. UltraNest is not a required dependency for Stingray, hence CI tests were failing with import error. To resolve this, the import statement of UltraNest in bexvar.py needed to be moved inside a try-except statement. This would restrict the user from using bexvar.py if UltraNest is not installed. With this change, the code has passed the majority of CI tests.
The overall experience of the coding period so far has been good. During this period I learned a lot about the essentials of open-source programming. I am learning to think like a programmer. I learned how small improvements in code make it more general and versatile. I learned about the best practices to write code. I must say that all this time my mentors Matteo and Daniela have been quite supportive and helpful. They have patiently listened to my queries and doubts and have always helped me with them.
My code is running perfectly now, from this week onwards I will be focussing on writing tests for the code. Writing tests for a code is a completely new experience for me. I am looking forward to learn a lot about professional code testing in the following weeks. I will soon be back with a blog on my experience with testing. Till then take care! Goodbye!