Open opportunities for contributing to preCICE

Context

In case you skipped the home page, preCICE is a coupling library for numerical simulations (think meshes, iterative solution, FEM, CFD) and an ecosystem of related components. Scientists take independent numerical simulation codes and make them work together on a more complex simulation, which none of the individual codes could do alone. For this, they use one of the many adapters (think plugins for various simulation codes), or directly the core library. While the latter is written in C++, more languages are relevant (Python, Julia, Matlab, C, Fortran, and Rust). preCICE is primarily used on Linux systems, with a growing user-base on macOS and Windows.

Most of the preCICE development has been happening in a university context, and student projects have played a vital role: Just look at the list of contributors. We are working on GitHub, and we accept contributions by everyone. We review pull requests trying to improve their quality together and bring them in line with the current project needs, which can sometimes be a long but rewarding experience. In the university context, we also closely mentor students, we encourage participation in team events such as our coding days, and several students have so far participated in workshops, conferences, and publications, or even done their PhD in the team.

If you want to contribute with a student project (typically a thesis), see the university groups behind preCICE. This page highlights a few specific projects that are not directly suitable for a thesis (thesis-suitable issues in the core library), but are also a bit more than a good first issue. Some of these projects we advertise publicly, in programs such as the Google Summer of Code.

Google Summer of Code

The Google Summer of Code is “a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors.”.

For 2026, we have prepared the following topics, for different sets of skills. Since this is our first year, and since we are a rather small project, we might not be able to accommodate applicants to all of these projects. Before applying, introduce yourself in the forum and let us know more about your background and motivation:

  • What motivates you spend this summer in GSoC instead of doing anything else?
  • What interests you most about our project?
  • Will you have any other commitments (e.g., work or study) while working on the project?
  • What previous experience do you have with the respective technologies?
  • What previous experience with Git and GitHub do you have, if any?

Additionally, show us what you have tried already (see “entry test” in each project and feel free to go beyond that), to support your application. If you have contributed anything to any preCICE repository, definitely mention this here.

We will contact you via replies and/or private messages in the forum, to find out together if these topics are a good fit. You can alternatively ask quick questions in the Matrix chat. Don’t miss the guidelines at the bottom of this page.

Project: Website modernization

This website is built with Jekyll, a straight-forward static site generator that has served us well, but now starts to feel a bit restrictive (GitHub repository, [documentation]docs-meta-overview.html)). We envy the dark theme, the nice footer that showcases contributions, and the nice search engine support when we look at the documentation of other community projects, such as GitLab or Docker. We also required some hacky jekyll plugins to integrate multiple repositories into one jekyll website, which are a bit error-prone. Our technology stack is also a bit outdated: For example, the front-end is using Bootstrap 3.3.7, with some custom CSS on top. We have done some preliminary work porting to hugo, but web development is not what we are good at. As a first step, we would like to upgrade to a newer Bootstrap version. After that, we would like to switch to the Hugo static site generator, aiming to have a framework that we can upgrade and maintain with minimal effort.

Entry test: To figure out if this is for you, try building the website locally and adding and styling some new element in the landing page. Be creative!

  • Skills required: Web development (Jekyll/Hugo + CSS, JS)
  • Project size: Medium (175h)
  • Difficulty: Easy/Intermediate - Requires upgrading the front-end framework and porting existing content from one framework and stack to another, but will be driven primarily by you on the “how”.
  • Mentors: Frédéric Simonis and Gerasimos Chourdakis

Project: System tests improvements

While the core library has several unit and integration tests, some issues only show up when running complete simulations. For this reason, preCICE has system tests, which choose and install components from the ecosystem in Docker containers, run complete simulations, and compare the numerical results against references. These tests are integrated into the GitHub Actions CI infrastructure of preCICE. While the system tests are already running every night and on many pull requests, several improvements are possible (related issues): running (much) faster test cases, running multiple test cases in parallel, better communicating what went wrong, integrating more repositories, and the list of possibilities goes on.

Entry test: To figure out if this is for you, run the system tests locally and add one more tutorial to the tests.

  • Skills required: Python, Docker, GitHub Actions
  • Project size: Medium (175h) - Depending on the availability, small or large are also possible
  • Difficulty: Intermediate - Requires combining multiple technologies and has an impact in multiple repositories, but includes mostly small and clear work packages.
  • Mentors: Gerasimos Chourdakis - Fallback: Frédéric Simonis

Project: Error messages with configuration context

The core library needs a preCICE configuration file, which currently needs to be written manually (we are working on higher-level configuration tools as well). When one configures something wrong, preCICE throws an error message with details and recommendations (think git). In this project, we want to attach context to these error messages, referring to specific lines in the configuration file (similarly to how a compiler would refer to code lines with errors): see the related issue.

Entry test: To figure out if this is for you, try building preCICE from source, running the elastic tube 1D tutorial, and modifying the configuration file to trigger an error (e.g., remove one of the <data> tags). Then, locate and modify the error message in the source code, to provide more information.

  • Skills required: C++
  • Project size: Small (90h)
  • Difficulty: Intermediate - Requires significant modifications to the C++ codebase, but with limited impact to/from other work.
  • Mentors: Frédéric Simonis - Fallback: Benjamin Uekermann

Project: Clean multi-step configuration

The core library parses its configuration file using the libxml2 library. The way this currently works is a bit rigid and the configuration of objects is directly tied to this parsing. Instead, we could do this in multiple stages, introducing an additional abstract syntax tree, which we could then use as a layer for additional checks, or to parse the configuration in a predefined order. In this project, we want to refactor the configuration code to introduce a confguration AST (structured types), generated from the XML AST (nested tags and their attributes) built with libxml2. See the related issue.

Entry test: To figure out if this is for you, try the same as in the project idea above.

  • Skills required: C++
  • Project size: Medium (175h)
  • Difficulty: Intermediate/Hard - Requires refactoring or modifying large parts of the C++ codebase, but with limited impact to/from other work.
  • Mentors: Frédéric Simonis - Fallback: Benjamin Uekermann

General guidelines

  1. Be creative, be proactive, and make your project your own.
  2. When writing (e.g., a pull request description), think of writing to colleagues with the same questions as you when you started.
  3. We welcome all kinds of modern tools for assisting with code development, but we do value the human factor: we want to see your work, in your own words, and we trust that you understand what you contribute. No need to impress, we are happy to help understand every concept together!