You’ll find this post in your _posts directory. Go ahead and edit it and re-build the site to see your changes. You can rebuild the site in many different ways, but the most common way is to run jekyll serve, which launches a web server and auto-regenerates your site when a file is updated.
Jekyll requires blog post files to be named according to the following format:
The first half of the coding period is almost done, and here I am with the updates! As stated at the end of the last blog, I started the 3rd week by improving the second PR. I performed pretty intensive memory and performance analysis on the functions in fourier.jl, using BenchmarkTools and .mem files to analyze bottlenecks in the program. With my mentors’ help, I removed many allocation and type-stability related issues during that time. I also had some problems with non-idiomatic code, like I could use multiple-dispatch or dot broadcast in functions, some of which I solved, and some are due for refactoring after the mid-evaluation. After finishing the improvements and getting my second PR merged, I planned to work on LightCurves and implement periodograms and other APIs so that users can easily manipulate photon count data. But my mentor suggested I implement file reading and mechanisms to manage the GTIs (Good Time Intervals) obtained from these files.
Working out the GTI mechanisms
I had learned a lot from the previous PR, and one of the things was I should try to implement some of the methods in my way rather than using the python algorithms with an idiomatic Julian code in mind. I started the 4th week with methods for reading GTIs from a FITS file (For those unfamiliar, it is a file format for storing, processing, and transmitting scientific data, especially images). I used the FITSIO.jl package, and experimenting on the terminal led me to manipulate HDUs and their data. One thing I thoroughly thought of was the appropriate data structure of the GTIs. Should I use Intervals from the Intervals.jl package? Or a vector of vector like the python library does? I finally decided to use what I was using in the fourier.jl, an AbstractMatrix of Reals. It was easy to access data from them, and you could use slices to get a list of start and end times. For the operations, I had to convert among matrix, intervals frequently, and vectors as the Intervals.jl provided many ways to manipulate GTIs like union or intersection or getting its complement, i.e., Bad Time Intervals. With some more methods like creating masks and GTIs from conditions and implementing Tests for all of these functions, I was finished with the gti.jl file. A little performance analysis told me that the code was efficient. After some refactoring, like removing code duplication by merging union and intersection in the same function, I was done with the PR. It has some minor changes currently to be made before it gets merged.
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.
Writing the extension modules and Python wrappers for a package is one thing, but a step that is often overlooked is making a build system that complies with the rest of your program, ensures the correct installation based on your dependencies and also is portable enough to be distributable.
I learned these things the hard way in Week 3 and 4, where I went as low level as I could to try to solve all the weird build errors and glitches I had while trying to build a Python Package using GNU Autotools.
GSoC 2022: Project Helioviewer — Facade for the API wrapper
The Generic Function got merged with PR #21. This PR adds a function that accepts a URL Endpoint, Input Parameters (dictionary), and a descriptor of Output Parameters (what the endpoint is expected to return), which all the endpoint classes will inherit.
This PR also includes the unittest for the Generic function and brings the first endpoint to the API wrapper, which is getJP2Image. This endpoint retrieves a JP2000 image from the helioviewer.org API.
The next task was to create a frontend for the getJP2Image endpoint. The actual front end that users will interface with lives in a file called facade which will hide this internal design. This module contains the API interface in its simplest form. It is responsible for taking user input, constructing the HvpyParameters instance (the base class) and passing it to the core to perform the request.
The ideal of benchmarking result is to test and assess under what conditions, such as fitting method, pipeline, refinement, etc., the fitting process can achieve a stable and robust result. Firstly, I want to test the fitting method and see which ones are the best to put into the module as the default method. As we use LMFIT.Minimizer, we have 23 fitting methods in total: