Ahmed Hossam
✅✅❌✅❌❌
code29563
✅✅✅✅✅✅
DeadSpheroid
✅✅❌✅✅❌
Deus1704
❌✅❌✅✅❌
Kartik Mandar
✅✅✅✅✅✅
Lucas Martin Garcia
✅✅✅❌✅✅
Manit Singh
✅✅❌✅✅❌
ViciousEagle03
✅✅❌❌✅❌
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 solution to switch the base URL of the python API wrapper got merged with PR #41 and follow-up with PR #44 by Nabil, now the next endpoint group was the movies.
I rebased my old PR #38 with the main branch, which brings the QueueMovie endpoint, and opened #51 which brings reQueueMovie and getMovieStatus endpoint to facade and backend.
By the end of the week, both the PR is merged and we now focus on the documentation before the first release.
For now, my priority is to focus on extensive user-testing cases from real-life experimental spectra, instead of the synthetic ones in first phase of the project. One of the very first experimental spectra I get, is from Mr. Nicolas MinesiMinesi, or Mr. Minou, a Post-doctoral Researcher at Universify of California, L.A. He specializes in laser spectroscopy and also one of my mentors in RADIS.
Mr. Minou introduced an absorbance CO spectrum near 2011 cm-1. He stored the data in a MAT (Matlab) file, which is extracted by this script:
Impove default resolution of ploted spectrum In wstep = “auto” radis app gives slitly low res. for that reasons plotted spectrum is…
Now, this week was the Mid-Term Evaluation week and I was totally nervous about it. I knew that I had put alot of efforts and time into the…
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.
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.
In this final week, I fully dedicate myself into user-testing cases. As pointed out by Mr. Erwan Pannier, “Things will definitely change after user feedback so don’t waste too much time before that”. Thus, I must quickly bring up several notebooks for the users - our spectroscopic scientists - to test and provide feedbacks, and from then I can shape my fitting modules closer to the real usages and needs. Firstly, I will talk about several additional updates in this final week of phase 1:
Now the fitting module supports non-LTE input. The module will automatically switch to non-LTE mode when Tvib is detected inside the input meterials.
After analyzing the the benchmarks and taking with my mentors , we are decided to go with React Hook Form for it’s performace , low…
Entering into the 5th week I created a PR https://github.com/radis/radis/pull/492 to address the task to add, retrieve and store the…