GSoC 2026 Introduction: Clean multi-step configuration & Issue hunt

[jayant]

Hi preCICE team,

I’m Jayant Chauhan, a Computer Science undergraduate with a strong focus on system-level C++ programming, and I’m very interested in contributing to preCICE for GSoC 2026.

I’ve spent time reviewing your open projects, and the Clean multi-step configuration initiative immediately stood out to me. The idea of decoupling the libxml2 parsing from object instantiation by introducing an intermediate Configuration AST is exactly the kind of architecture and compiler-adjacent refactoring I enjoy.

My Background
I have a solid foundation in C++ and software architecture, and I am comfortable navigating large codebases. I’ve been actively contributing to open-source projects, most notably gccrs (link to 15 merged PRs). Working on a compiler frontend has given me deep, practical experience with parsing, AST traversal, and multi-stage semantic validation pipelines.
Because of this, the architectural goal of this preCICE project—building a structured Configuration AST and running checker passes before instantiation—feels very familiar and exciting to me.
I’ve also contributed to GNU Octave ( link to one of refactor PR ), which has made me very comfortable with standard open-source workflows, issue tracking, and collaborative design.

My Current Action Plan
To get up to speed with the preCICE ecosystem and prove my commitment, I am currently working on the following:

1. The Entry Test: I am building preCICE from source, running the elastic tube 1D tutorial, and digging into the C++ source to improve the XML configuration error messages by mapping them to specific lines/context.

2. Familiarizing with the Workflow: To get hands-on experience with your CI/CD pipeline and code review process, I have started looking into the repo for a relevant issue . I plan to submit a solid PR in near future.

I have a quick question regarding the Configuration AST project: Will the new AST types (e.g., config::Mesh, config::VectorData) be completely independent structs, or are you envisioning them inheriting from a common AST node base class to allow for polymorphic traversal during the validation phase?

I look forward to interacting with you all and learning more about the project!

Best regards,
Jayant Chauhan
GitHub: [Link to my GitHub]

[jayant]

Update,

For the entry task of project Clean multi-step configuration , i managed to dug into the parser architecture and implemented the plumbing to pass the exact XML line number from the SAX parser up to the semantic validation macros .

earlier,

after modifications,

this is also mentioned with further explanation in PR#2456 .In addition to this , here is the changelog.

src/xml/ChangeLog:

* ConfigParser.hpp (ConfigParser::CTag): Add m_LineNumber member.
(ConfigParser::OnStartElement): Update signature to accept lineNumber.
* ConfigParser.cpp (OnStartElementNs): Extract line number from libxml2 context.
(ConfigParser::connectTags): Pass line number to XMLTag.
(ConfigParser::OnStartElement): Store line number in CTag.
* XMLTag.hpp (XMLTag): Add _lineNumber member with getter and setter.

src/mesh/config/ChangeLog:

* MeshConfiguration.cpp (xmlTagCallback): Include line number in PRECICE_CHECK error message.