Mohy Elden

The main goal of fitting is to find the best values for unknown parameters (like temperature Tgas, mole fraction, etc.) that make your theoretical (simulated) spectrum match the experimental data as closely as possible.

This feature was not previously available in the app, but it is now (once the PR gets merged).

To use it: Activate Fit Spectrum Mode from the header to open the fitting form.

You can try this example from the RADIS docs

Step 1: Prepare a .spec file and upload it to the app

Create a file containing your experimental spectrum in one of the supported formats: .spec, .txt, or .csv. You can do this using RADIS by saving a Spectrum object.

Step 2: Fill out the form

Fitting requires filling in four form sections:

• experimental_conditionsGround-truth data about your experimental environment.
• fit_parametersParameters you want to fit (e.g. Tgas, mole fraction).
• bounding_rangesAllowed ranges for the parameters listed in fit_parameters.
• fit_propertiesAdditional settings for the fitting pipeline.

In the app, all the main input fields fall under experimental_conditions. Some fields have checkboxes next to them, activating these checkboxes marks the field as a fit parameter, and an bounding_range input will appear for it (like Tgas in the image below).

You can also adjust some fit_properties, like max loops and normalization. However, the fitting method and its parameters (e.g., tol) are currently hardcoded. The method used is least_squares.

Step 3: Click and see the results!

The app will compute the best fit, load the experimental spectrum, and show the fitting history and results through logs, as shown below.

As part of the ongoing development, we’ve now begun focusing on the frontend side of the project, improving the user experience and preparing for more database integrations.

Initial Cleanup

To ensure a clean development workflow, I started by:

• Fixing linting and type-checking issues to maintain code quality.
• Repairing frontend tests to make sure new changes are verifiable.
• This was important to establish a solid pipeline, so any new code added to the frontend can be tested and reviewed confidently.

Full Dark Mode Support

A major enhancement was implementing dark mode across the entire frontend, not just the MUI (Material UI) components, but also the plotting graph area.

This took some effort as it required:

• Migrating from Joy UI components (buttons, inputs, etc.) to Material UI components to ensure compatibility with CssVarsProvider.
• Refactoring existing styles to align with the new Material UI design system.

The result is a visually cohesive and fully functional dark mode experience!

Database Integrations on the Frontend

I’ve also added frontend support for ExoMol and NIST databases:

• ExoMol is now functional. However, it still requires optimization. Specifically, setting the broadf variable to False can help reduce unnecessary broadening downloads overhead.
• NIST and HITEMP are not yet fully working, as they require login through the HITRAN website. To address this, I’ve added a script that automatically sets the email and password in the RADIS configuration, enabling these databases to work when the application is run.

GSoC 2025 Blog — Starting the Project

Kicking Things Off

The first weeks of GSoC were all about getting familiar with the project, understanding its current state, and laying the groundwork for upcoming work. We began by listing the key features we plan to implement and prioritizing them based on impact and feasibility.

Cleaning Up the Repo

Before diving into development, we focused on improving the current state of the codebase:

• Filtered through existing PRs.
• Merged those that were ready.
• Closed duplicates or low-quality submissions.
• Requested changes when necessary.

This cleanup helped fix some bugs and made the repository more maintainable moving forward.

CI Enhancements

To ensure future contributions are smoother, we improved the Continuous Integration setup:

• Added conditional CI jobs to run frontend or backend tests only when their respective files are changed.
• Introduced Codecov comments to show coverage of newly added lines, making it easier to track test quality in PRs.

These changes should streamline reviews and reduce unnecessary CI runs.

Early Contributions

I also started contributing new features and improvements:

• Integrated ExoMol and NIST databases into the backend.

While integrating the NIST database, I encountered a tricky error related to the RADIS package:

No databank named nist in `/home/mohy/radis.json`. Available databanks: […]

It turned out that the version of RADIS in the was outdated and didn’t recognize the `nist` databank. This was fixed by upgrading RADIS:

pip install — upgrade radis

Then, another error popped up related to pandas:

No such keys(s): 'future.no_silent_downcasting'

This was caused by version incompatibility, which was resolved by upgrading pandas:

pip install — upgrade pandas

After these upgrades, the databases worked correctly on the backend. The frontend integration and performance optimizations (e.g., caching) are next on my list.

• Increased backend test coverage, especially for newly added endpoints and database integrations.

That’s a wrap for the first weeks! It’s been a productive start, and I’m excited to keep building and learning in the coming weeks. Stay tuned for more updates!