[GSoC 2026 Introduction] Rajdeep Kushwaha — System Tests Improvements

Jobs & theses market GSoC
1

[GSoC 2026 Introduction] Rajdeep Kushwaha — System Tests Improvements

Hi preCICE community! :waving_hand:

My name is Rajdeep Kushwaha. I am a third-year B.Tech student in Computer Science and Engineering at Amity University. I am applying for the GSoC 2026 project “System Tests Improvements” and this post is my introduction along with a detailed account of what I tried for the entry test.

A bit about me

I have been writing Python for about two and a half years — it was the first language I used seriously beyond basic coursework, starting with data structures assignments and then moving into scripting, automation, and API work. Over the past year I have used it for building small CLI tools, parsing YAML/JSON configs, and writing test scripts, which aligns closely with what the system tests codebase does.

My exposure to Docker started about a year ago when I had to containerize a Flask application for a college project. Since then I have worked with Dockerfiles, multi-stage builds, Docker Compose, and volume mounts in a few projects — nothing at the scale of the preCICE system tests, but enough to read and reason about the Jinja2-templated docker-compose files in this repo without getting lost.

For Git and GitHub I have been using them daily since my second year — branching, rebasing, resolving merge conflicts, reading diffs, and reviewing PRs on group projects. I am comfortable with the fork-and-PR workflow.

Other relevant skills:

  • YAML — I write and read it regularly (CI config, Docker Compose, config files)
  • Bash scripting — familiar with the kind of run.sh scripts used throughout the tutorials
  • CI/CD — I have set up GitHub Actions workflows for a couple of personal projects (Python linting, automated test runs), so the .github/workflows/ structure here was readable to me on first look
  • Linux — my primary development environment is WSL2 on Windows, so I am comfortable on the command line

Why GSoC, and why preCICE?

Honestly, my first reason for looking at GSoC was pretty simple — I wanted to spend the summer doing something that would push me technically beyond what university coursework offers. A lot of GSoC projects are either too beginner-friendly or require a very narrow specialization I do not have yet. preCICE was different.

What caught my attention was the system tests paper (System Regression Tests for the preCICE Coupling Ecosystem | Electronic Communications of the EASST). Reading it made me realise this is not just “write some test cases” — it is a real infrastructure problem with interesting constraints: Docker layer caching for speed, fieldcompare for numerical result validation, Jinja2 templating to compose multi-participant simulations, and GitHub Actions orchestration across multiple adapter repositories. That combination of DevOps and scientific computing infrastructure is genuinely unusual and interesting to me.

The second reason is that the open issues are concrete and tractable. They are not vague feature requests. Issues like #404 (missing reference results causing a raw exception instead of a helpful message), #674 (pipe characters breaking the GitHub step summary markdown table), and #402 (no way to set a timeout from the command line) are the kind of small but impactful quality-of-life problems I enjoy solving. I already worked through three of them while doing the entry test.

Summer availability

I will be fully available over the summer. No internship, no exams, no other commitments during the GSoC period. I can commit to the full 175-hour timeline without interruption.

Entry test — what I did, what I learned, what failed

Step 1 — understand the codebase

I spent time reading through the core files before touching anything:

  • tools/tests/systemtests.py — the CLI entry point
  • tools/tests/systemtests/Systemtest.py — the main class that generates Docker Compose files from Jinja2 templates and drives the three phases: build → run → fieldcompare
  • tools/tests/metadata_parser/metdata.py — how metadata.yaml files are parsed into Tutorial, Case, CaseCombination, and ReferenceResult objects
  • tools/tests/tests.yaml — how test suites are declared
  • tools/tests/components.yaml — how solver adapters are defined with their build arguments and Docker template paths
  • Existing metadata.yaml files in elastic-tube-1d/, flow-over-heated-plate/, heat-exchanger-simplified/ to understand the expected format

Step 2 — add partitioned-heat-conduction to the system tests

I picked partitioned-heat-conduction because it had no metadata.yaml yet and covers three adapter types (FEniCS, Nutils, OpenFOAM) in a relatively simple Dirichlet-Neumann coupling setup that is well-documented.

I created partitioned-heat-conduction/metadata.yaml:

name: Partitioned heat conduction
path: partitioned-heat-conduction
url: https://precice.org/tutorials-partitioned-heat-conduction.html

participants:
  - Dirichlet
  - Neumann

cases:
  dirichlet-fenics:
    participant: Dirichlet
    directory: ./dirichlet-fenics
    run: ./run.sh
    component: fenics-adapter

  dirichlet-nutils:
    participant: Dirichlet
    directory: ./dirichlet-nutils
    run: ./run.sh
    component: nutils-adapter

  dirichlet-openfoam:
    participant: Dirichlet
    directory: ./dirichlet-openfoam
    run: ./run.sh
    component: openfoam-adapter

  neumann-fenics:
    participant: Neumann
    directory: ./neumann-fenics
    run: ./run.sh
    component: fenics-adapter

  neumann-nutils:
    participant: Neumann
    directory: ./neumann-nutils
    run: ./run.sh
    component: nutils-adapter

  neumann-openfoam:
    participant: Neumann
    directory: ./neumann-openfoam
    run: ./run.sh
    component: openfoam-adapter

And added a `partitioned_heat_conduction_test` suite in `tests.yaml` covering the three homogeneous combinations (same solver on both sides), which is the right choice for stable numerical regression testing:
partitioned_heat_conduction_test:
  tutorials:
    - path: partitioned-heat-conduction
      case_combination:
        - dirichlet-fenics
        - neumann-fenics
      reference_result: ./partitioned-heat-conduction/reference-results/dirichlet-fenics_neumann-fenics.tar.gz
    - path: partitioned-heat-conduction
      case_combination:
        - dirichlet-nutils
        - neumann-nutils
      reference_result: ./partitioned-heat-conduction/reference-results/dirichlet-nutils_neumann-nutils.tar.gz
    - path: partitioned-heat-conduction
      case_combination:
        - dirichlet-openfoam
        - neumann-openfoam
      reference_result: ./partitioned-heat-conduction/reference-results/dirichlet-openfoam_neumann-openfoam.tar.gz

## Step 3 — local validation with `print_case_combinations.py`

Running `python print_case_combinations.py` from `tests` confirmed the metadata is parsed correctly:

partitioned-heat-conduction:
- (dirichlet-fenics, neumann-fenics)
- (dirichlet-fenics, neumann-nutils)
- (dirichlet-fenics, neumann-openfoam)
- (dirichlet-nutils, neumann-fenics)
- (dirichlet-nutils, neumann-nutils)
- (dirichlet-nutils, neumann-openfoam)
- (dirichlet-openfoam, neumann-fenics)
- (dirichlet-openfoam, neumann-nutils)
- (dirichlet-openfoam, neumann-openfoam)



All 9 combinations (3 Dirichlet × 3 Neumann) are discovered correctly.

## Step 4 — reference result generation

Reference result generation requires running actual Docker containers on Linux. I tried this via WSL2 with Docker Desktop's WSL2 backend. The `generate_reference_results.py` script launched correctly, but the build step for the Docker images (pulling the preCICE and adapter layers) takes a long time on a first run and requires a stable internet connection throughout. I was not able to complete a full build during my testing window, so the `.tar.gz` archives are not yet committed — I have left a `reference-results/.gitkeep` placeholder with documentation on how to generate them. I understand this is something that can be done through CI once the PR is open.

## Step 5 — three additional bug fixes I found while reading the code

While studying `Systemtest.py` I noticed three separate issues that had already been filed:

### Issue #404 — raw exception instead of user-friendly error when reference results are missing

`__unpack_reference_results()` called `tarfile.open()` directly without checking if the file existed. When the archive is missing, the exception message is cryptic. I added an existence check that raises a `FileNotFoundError` with a message explaining what the file is, where it should be, and how to generate it. `_run_field_compare()` catches this and returns a clean `FieldCompareResult(exit_code=1)`.

### Issue #674 — the GitHub step summary table is broken when test names contain Markdown-special characters

The code reused the same fixed-width plain-text string (built with Python's f-string alignment padding) for both the terminal output and the `GITHUB_STEP_SUMMARY` Markdown output. This is a problem because:  
(1) extra spaces collapse in Markdown,  
(2) pipe characters in cell content break the GFM table structure, and  
(3) characters like `_` and `*` trigger unwanted formatting.  
I separated the two rendering paths completely and added a `_escape_markdown_cell()` helper.

### Issue #402 — no way to set a timeout from the command line

The 900-second limit was hardcoded as a module-level constant with no way to override it per run. I added a `timeout: int = GLOBAL_TIMEOUT` field to the `Systemtest` dataclass and a `--timeout` CLI argument to `systemtests.py`. All three `process.communicate()` calls now use `self.timeout`.

My work-in-progress is on my fork:  
[https://github.com/RajdeepKushwaha5/tutorials/tree/gsoc2026/system-tests-improvements](https://github.com/RajdeepKushwaha5/tutorials/tree/gsoc2026/system-tests-improvements)

## Questions from the guidelines I want to answer upfront

### What motivates you to do GSoC instead of anything else this summer?

I want structured, mentored open-source experience on a real production codebase — not another internship where I spend three months on ticket backlog items I will never see deployed. GSoC with preCICE gives me both a specific technical problem space and direct contact with the people who maintain the system.

### What interests you most about this project?

The architecture of the system tests themselves — the fact that a correct simulation is as much about infrastructure (Docker layer caching, deterministic numerical outputs, cross-repo triggering) as it is about the physics code. That intersection is unusual and genuinely interesting to me.

### Any other commitments during the summer?

None. I am fully available for the entire coding period.

### Previous experience with Python, Docker, GitHub Actions?

- **Python** — yes, ~2.5 years.  
- **Docker** — yes, ~1 year (Dockerfiles, Compose, multi-stage builds).  
- **GitHub Actions** — yes, have written workflows for personal projects.  
- **Git/GitHub** — daily use since second year.

Looking forward to feedback on the entry test and the PR. Happy to revise anything or try a different tutorial if partitioned-heat-conduction is not a good fit.

— Rajdeep
1 Like