What is TARDIS

TARDIS RT is an open-science software package that simulates and analyzes supernovae and other transients using a Monte Carlo radiative transfer framework. The collaboration as a whole works on Type Ia progenitor problems, nucleosynthesis in neutron star mergers, progenitors of stripped core-collapse supernovae, and cosmology using Type IIP supernovae. Data from current and next-generation telescopes and surveys gets used by the TARDIS RT framework to answer those scientific questions.

The goals of the project

The plasma module determines the ionization and excitation states of the supernova ejecta from the basic structure of the supernova - elemental abundances, densities, and radiation temperature. CodeCov, which is what TARDIS uses to track code coverage, does not accurately report coverage of the plasma. The plasma is passed as a parameter into models and simulations, so it’s indirectly covered in tests of entire simulations. CodeCov marks those lines as “covered,” but nothing is actually asserting that a given plasma property computes the right value. While some parts of the module did have direct tests, most of the module lacked direct tests that were easy to find. So the project had two goals: increase real test coverage of the plasma module, and make the tests that do exist easy to find and read.

What I did

The work split into two halves that fed each other: writing direct unit and regression tests for plasma properties, and mapping out the plasma module so that anyone could tell which parts of it are actually worth testing.

On the testing side, I wrote direct tests for the dilute Planckian radiation field, the radiative rates solver, and the basic plasma properties. For the basic properties I also set up a new tardis/plasma/properties/tests/ package with its own conftest.py. Every regression test needed matching reference data, so a good chunk of the work included generating data and pushing it to the separate tardis-regression-data repo.

The second half was the part I didn’t anticipate spending as much time on, and it ended up being the more valuable deliverable. I wrote detailed documentation about the plasma module which covered:

• How the plasma is structured as a graph.
• How the plasma gets assembled.
• A class-by-class audit of every plasma property.

To do this write up I leaned heavily on the VSCode test coverage tool. I ran only the plasma tests and then clicked into each class in the legacy property collection file of the plasma module (a file that essentially listed all the plasma properties into easy to import collections) to see whether the body of its calculate method lit up. This turned out to be the most reliable way to tell whether a property was used by the Tardis package or was simply being imported and unused.

The current state

There are now direct tests for the basic plasma properties, the dilute Planckian radiation field, and the radiative rates solver along with necessary reference data.

The documentation now shows exactly which parts of the plasma module are dead code, that either need to be refactored out of the codebase or be implemented into the codebase. Writing tests for these parts of the plasma module in its current state would be a waste of time.

I wrote all of this up as a standalone plasma module document that exists in the Tardis Google Drive, and this document will eventually be the basis for proper plasma documentation. The full thing is embedded below, and you can also open it in a new tab if the viewer doesn’t load. The document shows the complete property-by-property analysis.

What’s left to do

The most immediate gap is that TARDIS still has no published plasma documentation. The “how to create a plasma graph” docs page links to a Plasma Documentation page that doesn’t exist, which I filed as issue #3645. The document I wrote is meant to be the basis for that page.

Beyond that, the uncovered unreferenced code should come out of master. My suggestion, which could be a potential future GSOC project, is to remove dead code from the Master branch and reintroduce the code back into the Master branch in smaller PRs where the new plasma properties have example notebooks and example config files. A more ambitious approach is to fully refactor away from the NetworkX graph structure and toward solvers (a refactor process that’s halfway done that exists in the main codebase), which would need real design work with the core Tardis team first.

What got merged upstream

Four PRs were pushed onto the TARDIS master:

Four regression data PRs also merged into tardis-regression-data: #95 (fixing atom data attributes that regression tests couldn’t read), #96, #98, and #101, each carrying the reference data for the corresponding test PR.

Not everything made it to Master, and I think the ones that didn’t are worth writing down too.

#3622 was closed unmerged in August. It rewrote test_complete_plasmas.py so that instead of checking whether a property exists as a key in the stored HDF5 file, the test checks whether the plasma object actually has the attribute. The old behavior is opaque — when a test is skipped you can’t tell whether the plasma genuinely lacks the property or whether the regression data is just being read wrong. The PR also emitted an explicit warning when a property goes missing, moved every test onto the regression data sync functions instead of raw pd.read_hdf, and dropped properties from the combined list that were being skipped every single time because no plasma has them. It had test failures I didn’t get fixed in time, and the maintainers closed it with a note that it can be reopened. Its companion regression data PR, #102, is still open.

Challenges and what I learned

One of my biggest challenges throughout this project was navigating a new codebase and writing tests for it. The first tests I wrote were really redundant and unintentionally introduced a lot of code duplication. I eventually got the hang of how to write meaningful tests. Another testing challenge was finding out which covered lines truly had direct tests and which ones were being indirectly tested. I learned a lot about code coverage, documenting the outputs of pytests, and also how to step into the stack of a pytest to analyze the exact properties of a test. Throughout this whole process though, I did come to realize that when I dive into a new big codebase in the future, understanding the existing tests and coverage while simultaneously looking at code examples and documentation is a great way to understand a codebase in depth.

I also learned a lot about version control and how to properly use git when working on a large collaborative project. I had to really get into the practice of consistently pulling from main, stashing and popping changes when necessary, creating new branches per feature, and quadruple checking that my PRs only had relevant code. In the early stages of development, I pushed a lot of messy PRs with weird white space diffs, files from merges I did with branches on my own local development, and changes I accidentally pushed into one PR that should have existed solely on another PR.

Conclusion

Working with Tardis for GSoC was incredible! I absolutely loved the Tardis community. On top of learning how to develop open source code for science, I learned about a wide variety of topics in scientific computing, got to refresh some of my astrophysics knowledge from undergrad, and I learned a lot about how cool supernovae are. Any questions I had about either the codebase or the science were answered basically immediately on Slack, and I felt like I jumped straight into the community doing really important work by getting to work with a fellow GSoC contributor on unpinning the Tardis environment. Overall, this GSoC 2026 was such a meaningful experience that I’ve learnt so much from.

So I did what I should have done before even attempting to train - I performed EDA in a Jupyter Notebook. I also went ahead and put the most interesting insights of that EDA into a streamlit dashboard: album-per-year.streamlit.app

If the deployed dashboard is not working - which is an issue on the server side of streamlit and is not an issue with my dashboard - here are the instructions to run the dashboard on your local machine:

git clone https://github.com/RishmitaR/Album-Per-Year-Data-Dashboard.git
cd Album-Per-Year-Data-Dashboard.git
pip install -r requirements.txt
streamlit run app.py

You can optionally create a annoconda or virtual environment to install the python packages in.

Here’s a representation of a louvian community generated from the genre co-occurance network built during EDA. I think these genre communities are the coolest pieces of visualization in the dashboard.

Electronic Music Genre Network

I also took making this dashboard as an oppurtunity to practice vibe-coding with Cursor’s free trial and Copilot on VsCode. I wrote a majority of functions that manipulate pandas data frames and create charts, and I asked AI agents to format it all into a dashboard based on what I’ve already done in my notebook. I think this was a good exercise in making sure I don’t frivolously prompt AI as I actually ran out of Cursor credits pretty quickly - though I do think if I had known how many calls I can make in the free version I would have prompted way less. I want to make sure I strike a balance between understanding and automation. Generally I tried to prompt with very specific instructions i.e “get the genre co-occurances by doing a groupby album_name on this data frame and plot it on a horizontal bar plot”. When I forgot to be specific and got too comfortable with the capabilities of the AI I noticed I was spending a lot of time on fixing minor issues with formatting discrpencies and ugly colors that could have been mitigated if I had given hard styling rules at the top of the prompt. As I type this all out it feels obvious, but I’m trying to give myself some slack because I’m pretty new to coding like this. I’ve used AI to supplement my coding before, but it was typically for debugging or for when I was learning a new package and needed information quickly on how to use it.

Now that it’s the era of generating code I’ve decided to start developing prompting strategies and a personal AI use philosophy. If I generate code that I don’t understand with packages I’ve never heard or if I ask the agents to write code I couldn’t think of how to write myself it’s super important I learn how the package the AI generated works, understand the code the agent generated (what all the parameters and returns are every function are, what data structures used, etc), and I should be able to make fine adjustments to generated code myself without the agent.

Overall this was a good exercise in developing my own vibe-coding strategies and philosophy, and it makes me think that I should start making prompting “cheat sheets” for different systems that I tend to build for my projects a lot (dashboards, front-end, back-end apis).

Example of the trend

Project Status This project is currently a WIP

• Core backend and Spotify API integration
• PostgreSQL database populated with user and album data
• Frontend: barebones UI for login, birthday input, and album selection
• Simple chart rendering
• Integrate Last.fm API
• TensorFlow Recommenders model trained and functional (IN PROGRESS)
• Machine learning integration with backend (IN PROGRESS)
• Deploy live version (IN PROGRESS)

How The Final Product Will Work

1. Login & Setup: Users authenticate through Spotify or Last.fm, granting the app permission to access limited profile and listening data.
2. Enter Your Birthday: The app determines the range of years to include — one album for each year you’ve been alive.
3. Choose Your Albums: For each year, the user selects a favorite album fetched from Spotify. The backend retrieves release metadata (artist, title, year) for each selection.
4. Generate the Chart: Once complete, the app creates a Topsters-style album chart, listing each album’s title, artist, release year

Machine Learning Component

Training Data: 40,000+ users from the ListenBrainz dataset with artist, genre, and release information from MusicBrainz

Goal: Recommend albums that fit each user’s listening habits based on limited profile information (e.g., recent plays, top artists).

Prediction Workflow:

1. User logs in with Spotify or Last.fm
2. Backend generates a user feature vector
3. TensorFlow Recommenders model predicts likely-loved albums
4. Recommended albums are displayed visually on the chart

This feature is designed to enhance the experience for users who may not have saved albums but still want an accurate reflection of their musical tastes.

The code for the model is currently being developed in a jupyter-notebook stored at this repository: https://github.com/RishmitaR/Lifetime_Albums_TF_Reccomendor

To run current web application code:

Setup & Installation Prerequisites Node.js (v18 or later) npm PostgreSQL

1. Clone the Repository

   git clone https://github.com/RishmitaR/Album-Per-Year.git
   cd album-per-year
   

2. Install Dependencies

   npm install
   

3. Setup Environment File in the server folder

   SPOTIFY_CLIENT_ID=your_spotify_client_id
   SPOTIFY_CLIENT_SECRET=your_spotify_client_secret
   SPOTIFY_REDIRECT_URI=http://localhost:3000/callback
   

   Obtain Spotify credentials by creating a developer app at the Spotify Developer Dashboard

Flowchart of Agents in Final Working Product

This project is currently very WIP, I’d ideally like to turn this into a web application with a mock UI fed with real class syllabi before pitching this to my boss as something to implement on our live website. I also want to do more development on the live website (read more about how I’m updating the PLC website here) before introducing agents to the PLC - so for now the agents live in my local development space!

Flowchart of Ideal Website Workflow

The next big step is to update our SQL database with our labratory inventory and non demo materials.