GSoC Post 2
Hi! In the previous post I mentioned that the matching part between the quads was done. Following that, the past 2 weeks were devoted to:
-
Adwait Bhope
❌✅❌✅🔲🔲
-
anandxkumar
✅✅✅✅🔲🔲
-
Dhruv Vats
✅✅✅✅🔲🔲
-
Gagan Aryan
✅✅❌✅🔲🔲
-
Jeffrey Paul
✅✅❌✅🔲🔲
-
ndanzanello
❌✅✅❌🔲🔲
-
Rachitt Shah
✅✅❌❌🔲🔲
-
Raj Rashmi
❌✅✅❌🔲🔲
-
Suyog Garg
✅✅✅✅✅🔲
astropy@GSoC Blog Post #3, Week 3
So, it's the start of the 3rd week now. I will be virtually meeting Aarya and Moritz again Tom.
For the past few weeks now, I have been pushing commits to a Draft PR https://github.com/astropy/astropy/pull/11835 on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the cdspyreadme code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from cdspyreadme get integrated into cds.py, those files and codes added earlier will be removed.
About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to Add a CDS format writer to Astropy, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.
So, in a nutshell, this is my workflow:
I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate CDSColumn.py won't be required. I can open another PR which adds the Data writer, in the meantime.
For the past few weeks now, I have been pushing commits to a Draft PR https://github.com/astropy/astropy/pull/11835 on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the cdspyreadme code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from cdspyreadme get integrated into cds.py, those files and codes added earlier will be removed.
About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to Add a CDS format writer to Astropy, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.
So, in a nutshell, this is my workflow:
- Try out directly using cdspyreadme from within Astropy.
- Add CdsData.write method.
- Add a ByteByByte writer.
- Write features to add complete ReadMe to the Header, starting off with having both ReadMe and Data in a single file.
- Have features for writing separate CDS ReadMe and Data file.
- Further work on some specific table columns, for instance, those containing Units and Coordinates.
- Add appropriate tests along the way.
- Resolve other issues that come up.
- MRT format reader/writer.
I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate CDSColumn.py won't be required. I can open another PR which adds the Data writer, in the meantime.
Let's see how it goes!
astropy@GSoC Blog Post #3, Week 3
So, it's the start of the 3rd week now. I will be virtually meeting Aarya and Moritz again Tom.
For the past few weeks now, I have been pushing commits to a Draft PR https://github.com/astropy/astropy/pull/11835 on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the cdspyreadme code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from cdspyreadme get integrated into cds.py, those files and codes added earlier will be removed.
About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to Add a CDS format writer to Astropy, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.
So, in a nutshell, this is my workflow:
I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate CDSColumn.py won't be required. I can open another PR which adds the Data writer, in the meantime.
For the past few weeks now, I have been pushing commits to a Draft PR https://github.com/astropy/astropy/pull/11835 on GitHub. I wanted to have something working quite early in the project, in order to be able to pinpoint accurately when something doesn't work. This is why I started with directly adding the cdspyreadme code within Astropy. Afterwards, I am also writing the code from scratch. As more of the required features from cdspyreadme get integrated into cds.py, those files and codes added earlier will be removed.
About the reading/writing to Machine Readable Table format, in fact I wrote about it briefly in my GSoC Proposal that I could attempt it as an extension. I don't have an opinion on whether or not it should have it's own format classes etc. However, since the title of my GSoC project is to Add a CDS format writer to Astropy, I would prefer to work on the CDS format writer first and then on the MRT format. The MRT header anyway appears to be a bit simpler than the CDS header, so there shouldn't be much difficulty in the extension.
So, in a nutshell, this is my workflow:
- Try out directly using cdspyreadme from within Astropy.
- Add CdsData.write method.
- Add a ByteByByte writer.
- Write features to add complete ReadMe to the Header, starting off with having both ReadMe and Data in a single file.
- Have features for writing separate CDS ReadMe and Data file.
- Further work on some specific table columns, for instance, those containing Units and Coordinates.
- Add appropriate tests along the way.
- Resolve other issues that come up.
- MRT format reader/writer.
I have completed the first three tasks and will now work on the fourth. I think by the time this finishes, a separate CDSColumn.py won't be required. I can open another PR which adds the Data writer, in the meantime.
Let's see how it goes!
Rotation and Coordinates
Finally, the official “coding period” of GSoC finally began a couple of days ago. From where we started of with Sunkit-Pyvista, to where we are today makes me feel a tad bit happy! 😄
Weeks 1 and 2 were initially set out for me to complete adding rotation functionality to the library, which started off great, but ended up causing some confusion 😅.
This was quickly sorted out and we went with not having to implement rotation functionality and moved on, learning that not everything will go according to plan and it’s okay for stuff to not work out at times.
Chapter 1: First Flight
Hey! Missed me? I’m back with another blog, the first related to the Coding Period. Got some progress and interesting observation to share!
Ready -> Set -> Code -> Analyze
The first thing I did in the coding period, was analyse the problem and get a feasible approach to resolve it.
About my Google Summer of Code Project: Part 1
I had been eyeing Google Summer of Code last year (and the year before that), but never really got around to doing anything about it. It’s a wonderful learning experience and being in my final year of college this was the last opportunity I was going to get. So I decided to give it a shot.
I started late, sometime during late February. I picked out a few organizations that looked interesting to me. openastronomy particularly caught my eye because I was working on another project of mine related to Astronomy. In fact we were using one of the Python libraries under openastronomy. Now this is an umbrella organization, which means that there are multiple sub-organizations — sunpy, astropy, radis, poliastro, and a few more. They’re used extensively by the scientific community in their research. The project I selected was under sunpy, which is a Python library for solar data analysis. The project is about resampling data to increase or decrease its resolution — more on that later. Again, I had recently performed this operation in one of my projects, so it seemed only natural for me to go with this one. I worked on some issues on GitHub and submitted PRs, tried to get a hold of the codebase, put together a proposal, got feedback from the project mentors and friends, and submitted it. After about a month of impatient waiting, I received an email saying that my proposal was accepted! Awesome!
Now, I plan to continue writing these blogs throughout the project and since this is the first one, let me take a moment to talk about the project. So, there’s a sunpy-affiliated package called ndcube, which exists to provide users an easier way of handling coordinates. Astronomical data like images taken from cameras are usually stored as n-dimensional arrays. A dimension could represent spatial or temporal axes. In such an array, the pixel coordinates map to some coordinates in the real world. These could be RA and Dec, or in the case of solar data, Helioprojective Latitude and Longitude. Nevertheless, there needs to be a mapping from the pixels to the real world. This is given by the World Coordinate System, which is just a set of (complicated) mathematical transformations. ndcube is a package that correlates the actual data with its transformations in such a way that you can manipulate the data, and the transformations will continue to remain consistent. It can be used with any type of data like images, spectra, timeseries data, and so on.
GSoC Progress Report? Almost Done!
With only 2 weeks into the coding period, it feels good to say that the bulk of the work associated with the 2 milestones is almost done. Almost because the newly added functionality is yet to be battle-tested and while there is always room for change and improvements, my focus will be shifting from the main objective to the optional objectives.
The Project
Scientific jargon ahead!
The study and interpretation of time-series data have become an integral part of modern-day astronomical studies and a common approach for characterizing the properties of time-series data is to estimate the power spectrum of the data using the periodogram. But the periodogram as an estimate suffers from being:
JAX-based automatic differentiation: Introduction of modern statistical modeling to Stingray
I assume everyone reading this is already aware of two classical forms of differentiation, namely symbolic and finite differentiation. Symbolic differentiation operates on expanded mathematical expressions which lead to inefficient code and introduction of truncation error while finite differentiation deals with round-off errors. Optimized calculation of derivatives is crucial when it comes to training neural networks or mathematical modeling using bayesian inference. Both classical methods are slow at computing partial derivatives of a function with respect to many inputs, as is needed for gradient-based optimization algorithms. Here, automatic differentiation comes to the rescue. Automatic differentiation is a powerful tool to automate the calculation of derivatives and is preferable to more traditional methods, especially when differentiating complex algorithms and mathematical functions.
Stingray is astrophysical spectral timing software, a library in python built to perform time series analysis and related tasks on astronomical light curves. JAX is a python library designed for high-performance numerical computing. Its API for numerical functions is based on NumPy, a collection of functions used in scientific computing. Both Python and NumPy are widely used and familiar, making JAX simple, flexible, and easy to adopt. It can differentiate through a large subset of python’s features, including loops, ifs, recursion, and closures, and it can even take derivatives of derivatives. Such modern differentiation packages deploy a broad range of computational techniques to improve the applicability, run time, and memory management.
JAX utilizes the grad function transformation to convert a function into a function that returns the original function’s gradient, just like Autograd. Beyond that, JAX offers a function transformation jit for just-in-time compilation of existing functions and vmap and pmap for vectorization and parallelization, respectively.