I am a Tejaansh, a third-year CS student. I’ve been following preCICE for some time; my interest in the project stems from a lifelong fascination with physics and the intersection of computational science and distributed systems.
What I’ve done so far
I’ve been reading through the XML parsing pipeline and opened PR #2500 fixing exception-unsafe resource management in ConfigParser.cpp — wrapping xmlParserCtxtPtr in a std::unique_ptr with a custom deleter and adding a null check on context creation. It’s currently under review.
Reading through readXmlFile, the SAX callbacks, and connectTags to understand that PR gave me a clear picture of the current architecture.
How I’m thinking about the project
The core constraint is that connectTags both walks the tag tree and fires configuration callbacks in a single pass — meaning objects are being constructed while parsing is still happening. There’s no stage where you can validate the complete tree before anything gets configured, and no way to reorder configuration steps independently of XML structure.
An intermediate AST layer with proper ownership semantics would decouple these two concerns cleanly.
I’m currently doing the entry test and will share findings here shortly. Before then, two specific questions:
Is the intent to keep CTag as-is and introduce a new AST layer above it, or replace CTag entirely with a modern ownership model?
Is preserving the current xmlTagCallback firing order a hard constraint, or is reordering explicitly a goal to solve dependency issues?
Looking forward to contributing, I’m entering this a bit late so hopefully I can catch up.
My name is Tejaansh, and I’m a third-year CSE student. I’ve spent the last month “living” inside the xml module, and I’m interested in the “Clean multi-step configuration” project.
I’ve been active in the core repository recently (currently ranked as the #2 committer over the last 30 days in precice repo) and I’m eager to turn this momentum into a full architectural refactor of our configuration heart.
What motivates you to spend this summer in GSoC instead of doing anything else?
GSoC with preCICE is uniquely prestigious because it isn’t a standard web / app project but an opportunity to contribute to the gold standard of multi-physics coupling software used by the global scientific community. I’m ready to trade a comfortable summer for the challenge of modernizing the preCICE pipeline and continue my journey of learning and trying something new.
What interests you most about our project?
What fascinates me most is the chance to build a “living blueprint” for the library. The idea of giving the computer “X-ray vision” to validate every cross-tag relationship before a single object is instantiated is just fundamentally cool to me. I want to explore how we can capture that fleeting XML context into a persistent, strongly-typed AST
Will you have any other commitments while working on the project? No. I have 0 academic or work commitments during the GSoC period.
What previous experience do you have with the respective technologies? My foundation in C++ is built on a background in competitive programming. I have spent the last few weeks proving my ability to navigate the preCICE codebase through several contributions.
What previous experience with Git and GitHub do you have? I have been active on GitHub for a few years. I always align myself with maintainer feedback, have correct formatting for my markdowns, and keep a clean commits history.
My Entry Test Progress (Structural & UX focus):
For the entry test, I moved beyond hardcoded strings to improve the Developer Experience (DX) of preCICE configuration. I’ve submitted PR #2515, which transforms a passive error into an actionable guide:
Dynamic Suggestions: Instead of just reporting a missing data name, I modified MeshConfiguration::xmlTagCallback to cross-reference DataConfiguration.
Implementation: I used fmt::join to list all currently defined data tags, providing the user with immediate context on what is available.
Actionable Fixes: The error message now suggests the exact XML syntax needed (offering both <data:scalar>and <data:vector> options) to resolve the conflict.
Why this matters for the AST project: Working on this fix in MeshConfiguration highlighted a core architectural pain point: because there is no persistent AST, I had to manually gather “currently defined data” from a sibling configuration object. In a decoupled, multi-step pipeline, this information would be inherently available in the Configuration AST, making these kinds of “smart diagnostics” the library standard rather than a manual workaround.