GSOC 2022 Application RADIS Tran Huu Nhat Huy: Spectrum Fitting Improvement
- Name: Tran Huu Nhat Huy (Trần Hữu Nhật Huy)
- Age: 22
- Time-zone: UTC + 09:00
- GitHub ID: TranHuuNhatHuy
- LinkedIn ID: tranhuunhathuy
- Email: [private info, redacted]
- Phone number: [private info, redacted]
Spectroscopy is the field of study that measures and analyzes electromagnetic spectrum absorbed or emitted by matters [1]. For this, RADIS is a fast line-by-line code featuring synthesis, processing and analysis of high-resolution infrared absorption and emission molecular spectra, under both equilibrium and nonequilibrium conditions [2]. Developed to characterize the radiation of plasmas, planetary atmospheres and other distant heat sources, RADIS uses molecular databases comprising of millions of records from HITRAN, HITEMP, ExoMol and other sources to calculate high-temperature infrared spectra with a speed making it one of the fastest line-by-line spectral calculation modules at the moment. Besides, RADIS also features post-processing tools to analyze the calculated spectra and compare them with corresponding experimental results [3]. RADIS also features spectrum fitting tools for several experimental cases, and the efficiency of these fitting processes depends on the RADIS calculation times as well as the fitting algorithm used. The goal of this project is to improve the RADIS fitting process to reduce the fitting time, by optimizing its models, fitting methods and other features under different reference cases.
One of the primary tasks in spectroscopic analysis is fitting models of spectra. As we observe and record a spectrum, we will get an analog visualization of energy intensity emitted from the spectrum’s source, which we can estimate the source’s characteristics based on intensity and arrangement of bands. However, there are other quantitative and qualitative parameters such as temperature, constituted species and their corresponding concentrations, etc. which are challenging to be determined by conventional statistical analysis. To solve this issue, the measured spectrum is compared to several calculated spectra until a good match is obtained. This process of spectrum fitting can be described in the diagram below:
Fig. 1 – The general structure of a spectrum fitting workflow
As described above, a standard spectrum fitting procedure involves:
- Step 1: a set of arbitrary parameters representing unknown characteristics of the measured spectrum (such as temperature, species, concentrations, etc.) is initialized, along with a mathematical/physical model that can calculate a theoretical spectrum with those fit parameters as input.
- Step 2: from the fit model and parameters, derive a calculated spectrum.
- Step 3: compare calculated and measured spectra to obtain deviations. If the deviations are acceptable or negligible, go to step 5, else go to step 4.
- Step 4: adjust fit parameters so that the deviations between measured and calculated spectra can be minimized, then go back to step 2.
- Step 5: as the calculated spectrum can represent its measured counterpart to an acceptable degree, the fit parameters can now be considered as measured spectrum’s corresponding properties.
The efficiency of a fitting workflow is usually measured by the calculation time required and how close the calculated spectrum is compared to its measured counterpart. For this, there are two main features contributing to a workflow’s efficiency:
- Model: A model in general terms can describe the input data as mathematical results. Similarly, a model in spectrum fitting visualizes fit parameters as spectra containing quantitative and qualitative characteristics of its input. There are several tasks a model can do to enhance fitting performance, such as data reduction - reducing the computational load of raw data without significantly affecting overall performance of the process. In practice, spectra with high wavenumbers have millions of data points, which consume large memory usage and lead to inflated computational time when running convolutions. Another approach is data filter - mitigating experimental factors unaccounted for the fitting process, which can later be easier to calculate the spectrum. Examples include noise reduction and filtering algorithms – Kalman filter, Savitsky-Golay filter, etc.
- Cost function: as we fit the calculated spectrum to the measured one, we vary the fit parameters until the calculated result shows the best agreement with the measured spectrum. To define a good agreement, cost function (or loss function) – a function of the deviation between measured and calculated values – is needed. Least-squares method is one of the most prominent choices in spectrum fitting, and defining this function under different reference cases will be the main task for our spectrum fitting optimization.
Currently RADIS provides a fitting method capable of fitting an experimental spectrum by arbitrary models and fit parameters, called fit_spectrum(). The structure of fit_spectrum() can be described as below:
Fig. 2 – Structure of radis.tools.fitting.fit_spectrum()
As illustrated in the diagram above, the workflow of fit_spectrum() first starts with the set of input parameters including:
- fixed_parameters: parameters that will remain unchanged throughout the process.
- fit_parameters: parameters that will join the fitting process and are subject to change.
- factory: an object of class SpectrumFactory which provides line-by-line modules for calculation of spectra based on input parameters.
- s_exp: measured spectrum.
- model: a line-of-sight model which takes fixed_parameters and fit_parameters to compute and return a spectrum. Currently RADIS features two basic models: LTEModel for computing long-term evolution (LTE) spectra based on one temperature and Tvib12Tvib3Trot_NonLTEModel for computing non-LTE spectra from a given set of vibrational and rotational temperatures.
- Other auxiliary parameters for temperature bounding, fit options, plotting, etc.
A spectrum s is generated as model uses radis.lbl.factory.eq_spectrum() or radis.lbl.factory.non_eq_spectrum() to calculate from fit temperatures. Then, the two spectra are acquired to get their least-squares error by cost_and_plot_function(). Later on, this cost function is called by minimize(), a fitting optimization module from SciPy, to start the fitting loop. As the fitting progresses, residuals and fitting curves are generated by fit_spectrum()’s built-in methods, until the current fitting result satisfies solver_options. Finally, best fit temperatures and corresponding spectrum is returned. For current implementation of spectrum fitting, there are several limitations, such as slow processing speed and not necessarily very robust. For instance, the RADIS’s Multi-temperature fit gallery example [4] which attempts to fit multi-dimensional, multi-slab spectra, runs in over 1 minute. Also, since the current fitting structure is fixed with default scipy.optimize() settings, it does not cover various different input cases a spectrum analyst can bring forth. Finally, it is better to have more reference cases as gallery examples, as well as additional documentations, so that both spectroscopy beginners and researchers can refer to, which will help them a lot during their work on spectrum fitting process, and RADIS experience in overall. This project aims to express those limitations, investigate their nature scientifically, and find a way to improve them, along with RADIS’s spectrum fitting process.
For now, as RADIS’s spectrum fitting feature is still under development, there are several strategies that can be improved to enhance its fitting efficiency. Apparently, we can straightforwardly enhance the spectrum calculation process, which has been done and effectively optimized within previous years, such as Anand Kumar’s GSoC 2021 project of Automatic Lineshape Engine [5]. Thus, there is no much room for improvement in terms of spectrum calculation now. Hence, during this GSoC program I would like to work on the limitations proposed in the RADIS Spectrum Fitting section. Here I divide the implementation ideas into 2 groups: core works which are important implementations that must be included during the program, and extra works which are less prioritized and will be developed depending on time availability.
As spectrum fitting is the process of optimization in which we will deal with different cases of input, each returns a different type of spectrum, we would like to adjust the fitting process according to each case’s complexion.
For example, some large spectra cover a large range of wavelength/wavenumber and thus contain a significant number of data points, which require a huge load of computer memory and time for calculation as part of the fitting process. However, thanks to Gagan Aryan’s work at GSoC 2021 [6] we can reduce memory load while computing spectral data consisting of up to billions of lines, such as a full-range spectrum ranging from 500 to 20000 cm-1. As for these large spectra, we can utilize several preprocessing strategies such as halving the number of data points - for each two adjacent data points, only pick one and discard the other. I expect this will reduce the computation time for the fitting process at an insignificant cost of fitting accuracy.
On the other hand, sometimes scientists compute extremely narrow spectra, for only several cm-1s, in which the number of data points is just low enough that the computation time is very small. Thus, in this case the bottleneck is not computation time of absorbance/emission, but the allocation of quantitative information, which makes this process the longest part during the generation of Spectrum object. An idea suggested by Nicolas Minesi is to bypass the spectrum making in the fitting loop, and only use it in the end to visualize the best fit. I believe this approach will significantly improve our current fitting process for this particular input case. Above are some ideas about how we can tackle different input cases to achieve a better overall fitting efficiency. To properly decide which strategy is suitable for which input type, we will need to build benchmarks and conduct various tests, which will require an extensive amount of reference examples. I am determined to set up a massive database comprising of no less than 100 experimental spectra and their corresponding labelled ground truths. The data can be harvested from:
- Published research, literatures, experiments (preferred)
- Current RADIS users working in spectroscopy (preferred).
- Synthetic spectra with noise (in case additional data is needed).
In this GSoC project, I will build a database containing various of these reference cases and find the appropriate fitting strategies for:
- Large spectra (500 - 20000 cm-1)
- Narrow spectra (length of several cm-1s)
- Spectra involving one temperature
- Spectra involving multiple temperatures
- Others
The entire database will be built outside of RADIS repositories, for the benchmarking process.
After building a massive database for benchmarks and tests, the work continues with setting up a test suite which allows us to adapt to different input cases. For this, LMFIT – Nonlinear Least-Squares Minimization and Curve-fitting – is a Python package which provides a high-level interface to non-linear optimization and curve fitting problems. I will replace scipy.optimize() along with the rest of current fitting loop by LMFIT’s modules to support the benchmarking process mentioned in previous core work, and there are several reasons for me to choose LMFIT:
- LMFIT provides useful enhancements to optimization and data fitting problems. Most notably, it features Parameter object type, which has extensive flexibility in managing attributes such as standard error, constraints, and so on.
- LMFIT allows change of fitting algorithm freely, which means greater freedom to adjust fitting algorithms and routines compared to current SciPy modules.
- LMFIT also provides various functions and methods which extend the capabilities of their scipy.optimize counterparts, such as functions to evaluate parameter correlations and uncertainties, or Model class with improved curve-fitting efficiency.
- LMFIT supports extensive amount of built-in models for common lineshapes, which we can use and modify to suit our RADIS spectra lineshapes.
- LMFIT is currently used by MassiveOES - another line-by-line code featuring very robust fitting works. This is another convincing idea that I entrust LMFIT for this project. In addition, looking at MassiveOES codebase might provide me additional ideas on their robust fitting mechanisms.
The main objective for this work, is to design multiple optimization routines and test them with our database of reference cases. To do this, firstly a Minimizer object is created. It takes a fitting function, a _Parameter _object, and some fitting options such as fitting method or maximum iterations. After setting up the minimizer, various combinations of fitting method, parameter bounds and constraints will be applied for the benchmarking process. Generally speaking, the Levenberg-Marquardt least-squares minimization is usually preferred due to being fast, and usually returning acceptable fits for most cases. However, there are other fitting methods such as trust-region-reflective-adapted least-squares, Nelder-Mead, trust-region for constrained optimization, maximum likelihood via Monte-Carlo Markov Chain, differential evolution, etc. that can be included in our benchmarking process. In some cases, the module can be restructured if deemed necessary (for example, when dealing with narrow spectra).
After conducting the optimization with a particular setting, a _MinimizerResult _object is returned. Information such as fit statistics, residual log, fitted parameters can be extracted and we can evaluate the performance of this optimization routine. Then, we conclude the evaluation and log its result into database, before moving to next tests. The entire benchmarking process will be conducted outside of RADIS repositories. Finally, after we have determined optimal optimization routines for corresponding input cases, the experimental LMFIT modules along with optimal fit settings will be integrated into RADIS codebase and serve as new fitting modules. Documentations and examples will also be created later in Phase 2 for future RADIS users.
We also can enhance the fitting process of RADIS with various native features such as caching spectra or utilizing existing databases, in order to reduce complexity of computing fit spectra or have better estimation of initial temperatures and bounds.
Another idea is to utilize RADIS-GPU spectrum calculation. As RADIS provides GPU augmentation to significantly accelerate spectral computations, I intend to make the GPU execution possible by allowing selection of eq_spectrum_gpu() and eq_spectrum_gpu_interactive() instead of conventional eq_spectrum().
As my knowledge in these native features are still limited, I would like to invest the whole second phase of the GSoC program to crack it.
Spectroscopy has a particular fitting technique called Boltzmann Plot method, which fits each line of the spectrum independently and gets the populations of each level. The temperature is eventually determined from the fitted distribution. This method can be ideally used for spectra whose lines have relatively large intensity difference, or spectra where lines can be clearly isolated from one to another (such as CO). In a molecular spectrum with large number of lines (such as CO2), a similar approach can be used by grouping lines in vibrational bands and fitting vibrational bands independently. Eventually, the vibrational temperature is determined from the fitted distribution. This idea is brought upon by Erwan Pannier’s suggestion, and I would like to implement this as an extra feature after all the core works have been done.
First half of the program will focus on delivering improvements on the fitting process in areas where we already have several progressions, by generalizing and specializing fitting strategies for various input cases in the reference database with a lot of benchmark runs:
- Build a massive reference database comprising of multiple experimental spectra and their fitting ground-truths under different conditions from various sources, then classify and restructure them.
- Determine best fitting strategies for those reference cases through benchmarking process, then implement said strategies into RADIS codebase.
Second half of the program will extend further the results of first half, by trying new approaches involving RADIS native features and other novel implementations:
- Further enhance the fitting process through RADIS’s local databases, GPU, etc. If there is still time, the Boltzmann Plot feature can be implemented.
- Add documentations about spectrum fitting, update and renovate RADIS documentation if deemed necessary.
- Finish what I started - adding parsers to HITRAN database at #441, then work on other issues currently available. This is to further familiarize myself with the RADIS codebase and its workflows.
- Learn more about spectroscopy and its nature in a laboratory environment, in order to understand the process of conducting spectroscopy and its purposes.
- Get to know all of RADIS developers and mentors. Discuss with them about current fitting performance of RADIS, and what can be improved.
- Meet as many RADIS users on the Slack community as possible, to gather their experimental spectra and corresponding ground truths they achieved from manual fitting. This is to prepare for the reference database.
- Prepare a blog.
- Setup a dedicated repository for reference database. Upload gathered spectra labelled with ground truths onto the database.
- Investigate and understand each spectra type’s nature, identification and complexity, under instructions of mentors.
- Prepare LMFIT modules for benchmarking process.
- Conduct benchmark tests for large spectra and narrow spectra. Determine the best strategies for each type.
- Implement those strategies into RADIS codebase.
- Conduct benchmark tests for spectra involving one temperature, and spectra involving multiple temperatures. Determine the best strategies for each type.
- Implement those strategies into RADIS codebase.
- Prepare for Phase 1 evaluation. This evaluation is all about the selection of fitting strategies for different reference cases and spectral types, which has achieved agreement with mentors beforehand.
- Investigate RADIS native features such as caching spectra or utilizing existing databases, see in which way they can be used to reduce complexity of computing fit spectra or have better estimation of initial temperatures and bounds.
- Learn how the GPU works in RADIS, how we can implement it into fitting.
- Implement what obtained at week 7 into the code. As this task is new and novel for me, I dedicate 2 weeks to implement, integrate and debug.
- Create a detailed documentation of architecture and workflow of the fitting process, and integrate it to RADIS official documentation.
- Develop a rudimentary Boltzmann Plot feature in RADIS codebase.
- Prepare for the final evaluation. Clean up the code, check out the blogs, see if any features have not yet been documented, upload them all to GitHub.
- Submit final work product onto GSoC.
Ideally, each type of spectra is expected to cost 1 week to design the process, integrate to RADIS and debug. However, the work can be accelerated if several spectral types benefit from the same fitting strategy. In this case, the time left is for additional features that can benefit the fitting process, such as Boltzmann Plot technique.
I have finished the spectroscopy tutorial to train and gain better knowledge in the field, as well as reading several related papers [1][2][9]. In addition, to further acquaint myself with RADIS’s structure and mechanisms, I have dedicated my time to look around the RADIS’s main repository, report some new issues and try to solve old ones with pull requests.
- #440 apply_slit() returns error in co2-4080-4500 example. When I was training myself with spectroscopy, I took some example cases and ran them with Binder. That was the moment this error occurred.
- #537 Strange dialog messages in several specific inputs. When I first joined the RADIS community, while teasing the RADIS app with different input parameters, I encountered these bugs.
- #445 Implement astropy unit conversion to rescale_path_length(). I took issue #444 which was newly reported and tried to solve it. By solving this issue I gained a lot of insights about the code structure or hierarchy of the functions and class while looking around the code and documentation.
- #442 Add some improvements in fetch_*() documentations. This pull request was an important milestone, as it made me confident to contribute for more.
- #437 Fixed inaccessible links in several documents. This was my first pull request onto RADIS, and also my very first pull request I had ever made on GitHub. At that time I still did not know that we are supposed to push after commit, which made Anand explain to me multiple times, and became one of the best explanations of setting up pre-commit on RADIS. Still cannot believe it was just 11 days ago.
- #441 Add parsers to HITRAN classes. This pull request is an attempt to provide additional parsers to HITRAN classes, and later groups if possible, according to issue #382. This is the biggest contribution I have ever made, but as currently I am totally focusing on preparation of the project proposal, I will return and finish this work after the submission deadline. Next updates include fixing current parsers, adding additional parsers for remaining groups and classes, and finally adding small tests for validation.
This April, I have just hit my third year as a bachelor student of Tokyo Institute of Technology. My major is Transdisciplinary Science and Engineering, which supports me with knowledge covering a wide range of Engineering fields. However, my heart lies in Computer Science and coding since far, far before. In grade 7, I got a Prize at the 2013 Vietnam National Youth Informatics Contest which sparked my interest in algorithms. In high school, after winning several scientific research competitions with my friends, I realized that algorithms are elegant, but programming something meaningful is fun, and I love being fun.
During my first year as a university student in Vietnam - my home country, I started on my own a new project named EmerCall. This was an Android application system implemented with Google Firebase Realtime Database API and Google Map API, which aimed to help ambulances approach the victims of an emergency case. EmerCall consisted of 3 Android applications, which were intended to be distributed to hospitals, ambulance drivers and civilians. So basically it is like slapping Uber and 911 together with 3 Android apps. I brought EmerCall to a mobile application contest in Da Nang City, and successfully won the Consolation Prize at 2018 Da Nang Mobile App Programming Contest. I uploaded the sources on my GitHub page long ago, although I have not yet properly cleaned up the repositories.
After being selected as a recipient of the Japanese Government Scholarship, I hopped on a plane to Japan. Here in Tokyo Institute of Technology, I study Engineering as my primary focus. Last week I got notified that my first research paper - “Simulated Gaze Tracking using Computer Vision for Virtual Reality” - got accepted as a short paper at The 8th International Conference of the Immersive Learning Research Network commencing on May 30. Although these two years were full of novel experience, I miss the time grinding programming contests and hackathons back in Vietnam, when I was truly a “CS student”. Then I came across GSoC, and I believe this is a perfect chance for me to rekindle the fire in my heart that has been snuffed for a long time...
- Laptop: MSI GS60 2PL.
- Operating System: Windows 10 64-bit Dual boot Ubuntu 20.04.4 LTS x86_64.
- Installed RAM: 8GB.
- CPU: Intel(R) Core (TM) i7-4720HQ CPU @ 2.60GHz.
- Preferred IDE: Visual Studio Code.
Astronomy first came to me, as a kid, with wonderful star skies and galaxies. Later, it became a part of my existential crisis, knowing that we are nothing but an unimaginably small Pale Blue Dot floating amidst an unimaginably vast, cruel void. I engaged in astronomy under different ways: joining high school astronomy club (where we hosted some stargazing night camps, teaching kids how to navigate celestial map), watching YouTube videos, playing EVE Online [7] and Kerbal Space Program [8] (although after nearly 1000 hours playing this game I still cannot orbit around Joo). The sheer interest in astronomy is why I decided to give this astronomy-related organization a try during this GSoC program.
As mentioned in the Background session, firstly I have a fair skill base in algorithm with a considerable knowledge about optimization and curve-fitting process. Secondly, just like other fellow GSoC applicants, I have an IT background and am interested in software development. But not only that, since currently I am already in a research environment, I also have experience in conducting a scientific project, from the initial steps of observation, gathering information from other researchers and the academia, to hypothesis testing and validating predictions. I believe such experience will play an important role in the success of this project.
In fact, I once asked Erwan Pannier, a RADIS mentor, whether should I choose this project or “Non-air Diluent” – another project relating to APIs and databases instead. In the end, I decided to focus on this project although it seems harder, because I believe that improving the fitting process will benefit various RADIS users in real-life research scenarios. In addition, I will gain much more experience in interacting with researchers of RADIS community, which is an academic skill I would like to strengthen. Finally, after this project is done, I plan to work with mentors in publishing a research paper about fitting evaluation on various spectra types, based on our work in this project. This will be a great feat, a wonderful addition to my academic background.
All of these make me believe I am most suitable and qualified to this project. I am more than ready to learn, to work, and carve my name into the list of major contributors of RADIS, as well as into the history of GSoC.
- Development commitment: while waiting for the results, I will finish the major pull request Add parsers to HITRAN classes which I opened and is currently under development., while actively acquiring insights about spectroscopy applications, in order to strengthen my understanding in spectroscopy and RADIS codebase for upcoming works. Upon being selected, I hereby pledge to fully commit my time and effort for deliverance of high-quality development towards RADIS. Acknowledging that my spectroscopy knowledge is not yet sufficient, I am willing to commit more time to learn and gain better understanding in the field. This will be done by interacting with the spectroscopists and researchers in the RADIS community. I will follow the guidance given by mentors, and actively ask questions if needed.
- Time commitment: up to August, I can commit 20-25 hours per week, and I am willing to allocate up to 30-35 hours if needed to ensure the schedule whenever there is a possibility of delaying progress. Starting August, I will be in my summer break and I can totally focus on the project, with up to 40-45 hours (about 6 hours per day) of commitment. In addition, if I am caught up with any work, regardless of reasons and circumstances, which might potentially miss a deadline or a weekly meeting, I will inform the mentors as soon as possible and propose a plan to adjust the progress.
- Integrity commitment: I hereby state that all the information provided in this proposal is true, and willing to provide any proof if needed.
[1] Pavia, D. L., Lampman, G. M., Kriz, G. S., & Vyvyan, J. A. (2014). Introduction to spectroscopy. Cengage learning.
[2] Pannier, E., & Laux, C. O. (2019). Radis: A nonequilibrium line-by-line radiative code for CO2 and HITRAN-like database species. Journal of Quantitative Spectroscopy and Radiative Transfer, 222-223, 12–25. https://doi.org/10.1016/j.jqsrt.2018.09.027
[3] RADIS 0.12.0 Documentation. (n.d.). Retrieved April 9, 2022, from: https://radis.readthedocs.io/en/latest/
[4] Radis. Multi-temperature Fit - RADIS 0.12.1 documentation. (n.d.). Retrieved April 17, 2022, from: https://radis.readthedocs.io/en/latest/auto_examples/plot_multi_temperature_fit.html
[5] Radis. (n.d.). GSOC 2021 application Radis Anand Kumar: Automatic Lineshape Engine · Radis/Radis Wiki. GitHub. Retrieved April 19, 2022, from: https://github.com/radis/radis/wiki/GSOC-2021-Application-RADIS-Anand-Kumar:-Automatic-Lineshape-Engine
[6] Radis. (n.d.). GSOC 2021 application Radis Gagan Aryan: Reduce memory usage · Radis/Radis Wiki. Retrieved April 13, 2022, from: https://github.com/radis/radis/wiki/GSOC-2021-Application-RADIS-Gagan-Aryan:-Reduce-Memory-Usage
[7] The #1 Free Space MMORPG: Play here now! (n.d.). Retrieved April 14, 2022, from: https://www.eveonline.com/
[8] Kerbal Space Program. (n.d.). Retrieved April 14, 2022, from: https://www.kerbalspaceprogram.com/
[9] Gomes, J. M., & Papaderos, P. (2017). Fitting Analysis using Differential evolution Optimization (FADO): Spectral population synthesis through genetic optimization under self-consistency boundary conditions. Astronomy & Astrophysics, 603, A63.