The main goal was adding support for the Kurucz atomic database, which is now complete. This laid the basic structure for adding new atomic databases, and a PR is now open for adding NIST.

A number of side issues have arisen throughout the course of the project and been tended to within those PRs, whereas independent issues and PRs have been opened for other issues:

• The non-equilibrium linestrength calculation for both atoms and molecules now uses the Einstein Coefficient instead of the reference linestrength, thereby allowing weaker spectra to be seen
• The issue was also raised as to whether RADIS should be automatically modifying the user config file, and if so then how. That has been tended to in the Kurucz and NIST implementation so far and could be expanded to the molecular databases too.
• fixing the removal of ‘object’ type columns from the line dataframe
• Debugging a docstring example that didn’t actually work

Prior to the project starting, a PR was also opened to allow users to specify the minimum linestrength at which to cut off weaker lines by specifying them as the weakest x% of lines.

I integrated the API for atomic Kurucz linelists into the Common API, and in doing so the issue related to truncation and optimization seems to have been resolved.

The main differentiating aspect so far in the Common API for Kurucz is that new versions of linelists and lab lines aren’t available for all species, the result being that the url from which to download the Kurucz linelist isn’t known with certainty before actually attempting to download it, so the possibilities are ranked and attempted in order of preference and the first to return a valid response is used.

After examining the work done so far in that PR, I merged it onto the latest develop branch with few conflicts to resolve. There are a number of errors and/or placeholders in the previous code that are gradually being corrected.

I began looking into an outstanding issue from the previous work which was implementing Lorentzian broadening for atomic lines, as RADIS has previously catered mainly for molecular databases. ExoJax provides 5 functions to choose from for this, the results of which can differ from each other by up to an order of magnitude. The gamma_vald3 function is the one regularly used in ExoJax and we chose to use it as a basis for the default function in RADIS. I have been reviewing its handling of Stark broadening in particular as some corrections were required.

Considering the numerous different formulae that have been proposed for Lorentzian broadening of atomic lines, and the significantly different results they produce, I also added a parameter in the SpectrumFactory class for a user to specify their own function to use instead of gamma_vald3. I also added a similar parameter in calc_spectrum (a typical entry point for the end user) for a user to specify a class to use in place of SpectrumFactory, which allows them even more flexibility and control over other parts of the spectrum calculation too.

I started a PR for this project to enquire about an issue related to the truncation parameter used in calculating the lineshape and the differing results depending on the choice of optimization method.

I’ve also been looking into third-party tools to generate plots of spectra for the same atoms for comparison with the results being generated in RADIS and to potentially indicate through any discrepancies whether there’s an error to be resolved.