Hello preCICE community!
My name is Pranjal Manhgaye, and I’m a software engineering student with a strong interest in scientific computing and DevOps workflows.
Over the past few days I’ve been actively contributing to the preCICE tutorials repository on GitHub. I’ve had a couple of pull requests merged already — for example, improvements to cleaning scripts so they work from the root directory, and fixes in the systemtests framework — and I’m currently working on simplifying how failing systemtests can be reproduced locally after a CI run using rerun scripts and portable artifacts. These changes aim to make development and debugging smoother for everyone working with preCICE tutorials and tests.
I’m would love to participate in Google Summer of Code with preCICE, but my contributions are not limited to that — I genuinely enjoy digging into the infrastructure around preCICE, helping improve workflows, and making things easier for new contributors.
Outside of that, I’m interested in containerised workflows (Docker), CI automation, and improving reproducibility in scientific software.
Looking forward to connecting with you all here — and if you have questions about tutorials, systemtests, or GitHub workflows, feel free to ask!
3 Likes
Hi,
I’m working on system tests in the preCICE tutorials repository and have opened two PRs. Below is what each does and what I learned along the way.
PR #732 – Source test cases from other repositories (Closes #538**)**
What it does: System tests can now use tutorials from external git repositories and archives instead of only the local repo.
Previously, tutorials had to live in precice/tutorials. With this change, you can point to a URL and ref in tests.yaml, so adapters or forks can be tested against tutorials they don’t host directly.
What I learned:
-
How the systemtests.py pipeline flows: TestSuite.from_yaml → Systemtest → Docker Compose generation
-
Why metadata and reference-result paths matter for portability and CI
-
Handling edge cases (e.g. main → develop → master fallback when a branch doesn’t exist)
PR #733 – Gate gather-refs on trigger-system-tests label (Fix #682**)**
What it does: The System tests (PR) workflow only runs gather-refs when the label is trigger-system-tests, instead of on every label add.
Previously, labeling a PR with “bug” or “GSoC” still triggered gather-refs and 7 API calls, even though system tests only run for trigger-system-tests. That led to unnecessary API usage and rate-limit issues.
What I learned:
-
How the PR workflow uses nmbgeek/github-action-get-latest-commit and where rate limits come from
-
The value of splitting fixes: MakisH suggested doing the conditional gating first and deferring auth to see if it’s enough
-
That a single-line, well-placed condition can reduce CI cost and noise
-
The importance of following maintainer feedback (e.g. removing authentication and keeping only the conditional)
Why this matters for system tests
These changes address long-standing issues: #538 (external sources) and #682 (API usage). They make the system tests framework more flexible and reduce unnecessary CI load.
I’m aiming for GSoC 2026 on System Tests Improvements, and working on these PRs has given me a good feel for the architecture and how maintainers approach changes.
I’m happy to discuss anything here , and I’m open to iterating further based on review.
Thanks,
Pranjal
1 Like
I’ve completed the entry task for System Tests Improvements.
PR: Add heat-exchanger-simplified to system tests (GSoC entry task) by PranjalManhgaye · Pull Request #736 · precice/tutorials · GitHub
What I did: Added the heat-exchanger-simplified tutorial to the system tests (new suite heat_exchanger_simplified_test in tests.yaml) and fixed Docker/Ubuntu 24.04 compatibility so the suite runs locally. Build and the coupled run complete; it only fails at field comparison because the reference archive for the new case isn’t generated yet (expected). The reference can be generated in CI or by a maintainer.
Happy to update anything based on feedback.
I recently worked on PR #743, which implements issue #440 in the preCICE tutorials repository. Here’s a short recap of what I learned , hope this helps ==>
i spent time on tutorials system tests running full coupled simulations with different solver combinations (e.g. OpenFOAM + CalculiX) and compare results to reference data. That helps catch regressions across the ecosystem when dependencies or adapters change.
The change adds archiving and hash comparison for precice-*-iterations.log from implicit coupling runs. These logs record iterations per time window; if something changes in the coupling scheme or acceleration, iteration counts can shift even when final fields still pass fieldcompare. Comparing hashes of these logs lets us detect that kind of regression.
while working i learned more about the systemtest harness: how Systemtest.py runs build → run → fieldcompare, how reference data is generated and stored in tars, and how CI triggers these tests. The implementation uses a sidecar .iterations-hashes.json so we stay backwards compatible and can extend it (to other files later.)
This should be useful for the upcoming system tests GSoC project–>better iteration-log checks mean we catch coupling changes earlier and make CI more reliable as we add more tests.
PR=> Archive and compare iterations.log for implicit coupling (fixes #440) by PranjalManhgaye · Pull Request #743 · precice/tutorials · GitHub
@makish i have been spending time in tools/tests/systemtests ( mainly systemtest.py , systemtestarguments.py and testsuite.py ) and i’m trying to understand where the boundary is between PUBLIC API and internal implementation for the system tests ,
from outside i could see that things like tests.yaml ,reference_versions.yaml , some build_args (example python_bindings_ref ,precice_ref ) feels nice and stable at the same time but parts of systemtests itself (like config overrides , log archieving , etc) look more easier to change ,
when adding features like max_time overrides or the iterations-log hashing , i’m never sure how much backward compatibility i should assume at this layer .
do you have rough guidance for which pieces you consider a stable contract vs things we might freely reshape between releases , ig i was not able to find out a thread for this discussion so i thought i should ask here .
Thanks