Tests included in the release test suite

[MakisH]

Since June 2026 (precice/precice#2570), most tutorials are included by default in the release test suite. To integrate more, we need to implement additional components.

Note: I am continuously editing this comment to remove what has already been addressed.

Components

Included

• bare (preCICE)
• Python bindings
• CalculiX adapter
• DUNE, DUNE-FEM, and DuMux adapters
• FEniCS adapter
• FEniCSx adapter
• MercuryDPM
• Micro-Manager
• OpenFOAM adapter, including solids4foam
• SU2 adapter

Not yet included, but in tutorials

• Julia bindings
  • resonant-circuit/[capacitor|coil]-julia
  • We need a way to override which version of the Julia bindings is installed.
• Rust bindings
  • elastic-tube-1d/[fluid|solid]-rust
• G+Smo adapter (external)
  • partitioned-heat-conduction/[dirichlet|neumann]-gismo
  • partitioned-heat-conduction-direct/[dirichlet|neumann]-gismo
  • perpendicular-flap-stress/ (G+Smo)

Blocked by issues

Further tutorial cases currently not tested are:

• MATLAB bindings (would need a license on a licensed runner)
  • resonant-circuit/[capacitor|coil]-matlab
  • There is a CI on the matlab-bindings, but it is based on the setup-matlab action.
  • There is an official Docker image, but it still needs a license.
• code_aster adapter (currently unmaintained: Outdated code_aster version code_aster-adapter#29)
  • flow-over-heated-plate-steady-state/ (code_aster)

Tested but without regression checks

• aste-turbine: see comments in Add ASTE to the system tests #876, aste-turbine runs are non-reproducible #877
• external cases without reference results:
  • partitioned-heat-conduction-robin_left-openfoam_right-openfoam
  • partitioned-heat-conduction-mixedbc_left-openfoam_right-openfoam
• monolithic cases:
  • partitioned-burgers-1d_monolithic-scipy
  • partitioned-pipe-two-phase_monolithic-openfoam
• The elastic-tube-3d OpenFOAM-FEniCS still shows issues, see https://github.com/precice/openfoam-adapter/actions/runs/29340801559?pr=405

[MakisH]

We should also make a table of test cases x components/features, to discover blind spots on what we are not testing.

[MakisH]

First priority (currently missing) should be the Quickstart, since this is the first case users run. We can handle it similarly to the nutils tutorials.

[MakisH]

@fsimonis also wanted to have the solverdummies included here.

[uekerman]

Documentation on how to add testcases and components: https://precice.org/dev-docs-system-tests.html

[nithin434]

Hi! I’m exploring this issue for a potential GSoC proposal and would like to start with a well-scoped, high-impact contribution. My initial goal is to add the Quickstart tutorial as a system test following the developer documentation, including generating reference results and automated comparison. After that, I’m interested in extending the work toward a feature–test coverage table to understand what is currently not tested.
Please let me know if this is a good starting point or if there’s a specific missing case you’d prefer I focus on first.
@MakisH @fsimonis

[MakisH]

Welcome, @nithin434! Adding the Quickstart would be great. That tutorial would also require thinking what to do with the solid-cpp, which does not use an adapter. You could treat it similarly to the elastic-tube-1d.

Since most of the work here would be running the tests and seeing that the these work, I would appreciate some logs in the respective PR. The CI does not currently let us test changes to the system tests themselves submitted from forks.

[nithin434]

Thanks for the pointers! I’ll start working on adding the Quickstart as a system test and treat the solid-cpp case similar to elastic-tube-1d. I’ll run everything locally and include the logs in the PR. I’ll open a draft PR soon for early feedback @MakisH