Astrochemical Modeling GUI

The project

What problem did your project aim to solve? Running complex, Fortran-based astrochemical models traditionally requires writing tedious Python boilerplate scripts and manually extracting data. This creates a steep learning curve for researchers and makes running multi-parameter sweeps incredibly slow and error-prone.

How does your product work? We built a resilient Python web application (using Panel) that abstracts the coding layer entirely.

• Dynamic UI: Automatically generates the correct input widgets based on the chosen physical model (e.g., Cloud, JShock).
• Asynchronous Engine: Uses isolated multiprocessing to run heavy Fortran simulations in the background. The UI stays fully responsive, featuring live, unbuffered terminal log streaming.
• Automated Grid Runner: Allows users to configure, queue, and chain multi-dimensional parameter sweeps with just a few clicks.
• Instant Visualization: Automatically parses output data into interactive Plotly graphs, tileable dashboards, and reproducible exports (YAML configs and HDF5 archives).

What impact does your solution have for the client or users?

• Speed: Reduces the time to configure, run, and visualize complex parameter grids from hours of scripting to minutes of clicking.
• Accessibility: Allows scientists to focus purely on astrophysics rather than debugging command-line wrappers.
• Reproducibility: Standardized state-saving guarantees that any experiment can be perfectly replicated and shared across teams.

The customer

Our client is the Leiden observatory tied to Leiden University. Our direct contact is Gijs Vermariën. He is a PhD student at the observatory and he has strong connections to UCLCHEM and the code. Before we started the project, he oversaw the code surrounding the UCLCHEM program. Several python wrapper functions and dictionaries for storing variables were created by him.

The communication with the client consisted of structured biweekly meetings for status updates and a whatsapp group for more urgent questions. Communications went smoothly as Gijs sympathized with our student schedules and listened to us about what features were reasonable. Because he had good insight about the code, we could ask more technical questions and still expect a detailed response that helped us give structure to the project. Overall, working with Gijs was great because of a mutual understanding of the code and a relaxed atmosphere.

The team

Our team consisted of six members similar to most teams, working on a graphical user interface for UCLCHEM, an astrochemical simulation framework, for our client Gijs. We organised ourselves using Scrum, with Márton Gebe acting as Scrum Master (facilitating our sprint ceremonies and keeping the board moving) and Péter Benke serving as Product Owner (owning the backlog and acting as the main point of contact with the client). The remaining members formed the development team, though in practice everyone contributed to both planning and implementation.

We divided the work into sprints, splitting each set of product backlog items into two or three sub-teams so that larger features, such as connecting the UCLCHEM code to the GUI, multi-stage modelling, interactive plotting, and shock implementation, could be tackled in parallel. We tracked everything on a shared GitHub Projects board and coordinated day-to-day through a dedicated Discord server, alongside regular scrum meetings (twice a week), biweekly client meetings with Gijs, and TA check-ins. This mix of asynchronous updates and face-to-face syncs kept everyone aligned even when we were working on separate parts of the codebase.

The biggest challenge we overcame was building on top of UCLCHEM while its development branch kept changing underneath us; updates would repeatedly break our integration. We solved this by pinning to a stable release candidate, which gave us a reliable foundation for development. Early on, we also struggled with communication, which we addressed by setting up structured Discord channels and a WhatsApp Group. Later, we worked through the complexity of getting UCLCHEM’s Fortran build to run reliably in our continuous integration pipeline.

What we are most proud of is delivering a working, easy-to-use (user-friendly) GUI that lets astronomers with little to no coding experience run and visualise UCLCHEM simulations, turning a process that previously required editing text files and running terminal commands into something approachable and interactive.

The technologies

Languages:

• Python: front-end of the application

Important frameworks and libraries:

• UCLCHEM, the backend that handles simulations
• Panel, dashboard framework for heavy data flow
• Plotly, generates and display plots

Tooling:

• Ruff: linting and formatting of Python code (also used in CI)
• pytest: automated testing (also used in CI)

Deployment:

• The frontend is served locally when running the software, and can be accessed by any browser