# GSoC 2026 | Tejaansh **URL:** \ **Category:** Google Summer of Code\ **Tags:** gsoc-configuration, gsoc-period-reachout\ **Created:** [March 10, 2026, 8:08am UTC](https://precice.discourse.group/t/gsoc-2026-tejaansh/2816 "2026-03-10T08:08:43Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![brightyorcerf](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/brightyorcerf/32/3344_2.png) [@brightyorcerf](https://precice.discourse.group/u/brightyorcerf)\ **Post date:** [March 10, 2026, 8:08am UTC](https://precice.discourse.group/t/gsoc-2026-tejaansh/2816/1 "2026-03-10T08:08:44Z")
Hi @fsimonis and @Makis, 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. ---
**Author:** ![brightyorcerf](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/brightyorcerf/32/3344_2.png) [@brightyorcerf](https://precice.discourse.group/u/brightyorcerf)\ **Post date:** [March 11, 2026, 11:30am UTC](https://precice.discourse.group/t/gsoc-2026-tejaansh/2816/2 "2026-03-11T11:30:51Z")
Update: The RAII fix is **[PR #2501: Implement RAII for xmlParserCtxt in ConfigParser](https://github.com/precice/precice/pull/2501)** (I accidentally referenced #2500, which is the issue). I’ve also opened two more PRs since my initial post: **[PR #2502: Remove redundant CTag state and improve diagnostic coverage](https://github.com/precice/precice/pull/2502)** **[PR #2515: Improve error message when mesh references undefined data](https://github.com/precice/precice/pull/2515)** (entry test: improved `MeshConfiguration::xmlTagCallback` to list currently defined data tags and provide the exact XML needed to fix the issue). ---
**Author:** ![brightyorcerf](https://yyz2.discourse-cdn.com/free1/user_avatar/precice.discourse.group/brightyorcerf/32/3344_2.png) [@brightyorcerf](https://precice.discourse.group/u/brightyorcerf)\ **Post date:** [March 30, 2026, 7:10am UTC](https://precice.discourse.group/t/gsoc-2026-tejaansh/2816/3 "2026-03-30T07:10:39Z")
Hi preCICE team! (reintroduction, because I wanted to edit) 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. > > > \## Main changes of this PR > Fixed three categories of issues in src/cplscheme/co…nfig/CouplingSchemeConfiguration.cpp: > > \- Corrected a typo in the error message for addResidualRelativeConvergenceMeasure: residul-relative-convergence-measure → residual-relative-convergence-measure. This tag name appears verbatim in the error message that users see, so the typo would cause confusion when users try to locate the tag in their configuration. > \- Removed trailing whitespace from two identical warning messages in addRelativeConvergenceMeasure and addResidualRelativeConvergenceMeasure. > \- Fixed inconsistent capitalisation in substeps warnings: substeps="False" → substeps="false" in both serial-explicit and parallel-explicit coupling scheme warnings. XML attribute values in preCICE use lowercase, so the capitalised version in the warning message would produce an invalid configuration if copied directly. > > > \## Motivation and additional information > > While exploring the configuration pipeline as part of understanding how preCICE processes and validates coupling scheme configurations, I noticed these inconsistencies in the error and warning messages. The substeps="False" case is particularly impactful — a user following the warning's advice would introduce a new configuration error since preCICE XML attribute values are lowercase. The typo in the tag name would similarly cause confusion when a user tries to locate the referenced tag in their configuration file. > > > \## Author's checklist > > \* \[x\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[x\] I stuck to C++17 features. > \* \[x\] I stuck to CMake version 3.22.1. > \* \[x\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change) > > \## Reviewers' checklist > > > > \* \[\] Does the changelog entry make sense? Is it formatted correctly? > \* \[\] Do you understand the code changes? > > > \## Main changes of this PR > > \- Wrapped the raw \`xmlParserCtxtPtr\` in \`std::uniq…ue\_ptr\` with \`xmlFreeParserCtxt\` as a custom deleter, ensuring the context is freed during stack unwinding if an exception occurs. > \- Added a \`PRECICE\_CHECK\` to guard against a null return from \`xmlCreatePushParserCtxt\` before parsing begins. > > \## Motivation and additional information > > \`ConfigParser::readXmlFile\` relied on manual cleanup of the libxml2 parser context. If \`xmlParseChunk\` or a SAX callback threw an exception, \`xmlFreeParserCtxt\` would be skipped, leaking the context. Additionally, the return value of \`xmlCreatePushParserCtxt\` was not checked, risking a null pointer dereference on failed initialization. > > \## Author's checklist > \* \[x\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[x\] I stuck to C++17 features. > \* \[x\] I stuck to CMake version 3.22.1. > \* \[x\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change) > > \## Reviewers' checklist > \* \[\] Does the changelog entry make sense? Is it formatted correctly? > \* \[\] Do you understand the code changes? > > > \## Main changes of this PR > > \- Enhanced the error message in \`MeshConfiguration…::xmlTagCallback\` when a \`\\` tag references an undefined data name. > \- The new message includes the mesh name, lists all currently defined data tags, and provides the exact XML to fix the issue. > > \## Motivation and additional information > > Previously, the error only repeated the missing name back to the user: > \`\`\` > Data with name "Pressure" used by mesh "Fluid-Nodes-Mesh" is not defined. > Please define a data tag with name="Pressure". > \`\`\` > > The improved message gives actionable context: > \`\`\` > Data "Pressure" used by mesh "Fluid-Nodes-Mesh" is not defined. > Currently defined data tags are: CrossSectionLength. > Please add \ or \ > to your configuration. > \`\`\` > > This helps users immediately understand what data exists and exactly > what XML to add, rather than just restating the problem. > > \## Author's checklist > > \* \[x\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[x\] I stuck to C++17 features. > \* \[x\] I stuck to CMake version 3.22.1. > \* \[x\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change) > > \## Reviewers' checklist > > > > \* \[\] Does the changelog entry make sense? Is it formatted correctly? > \* \[\] Do you understand the code changes? > > > \### Main changes: > > \- Refactor: Removed the redundant m\_Used boolean from CTag.… The configuration state is already robustly managed by the XMLTag hierarchy and the parsing loop, making this extra flag unnecessary overhead. > > \- Enum Exhaustiveness: Added the missing OCCUR\_ARBITRARY\_NESTED case to getOccurrenceString, ensuring the Printer output is complete. > > \- Diagnostic Improvement: Enhanced the error message in areAllSubtagsConfigured to include the specific tag name when a namespace is present. Previously, it would only report the namespace (e.g., \), which obscured the actual missing component. > > OCCUR\_ARBITRARY\_NESTED is currently unassigned in the codebase but defined in the enum, this change ensures getOccurrenceString handles all defined cases defensively rather than returning an empty string silently > > \### Motivation: > These changes were identified during a code audit of the XML configuration pipeline. By removing redundant state and hardening the diagnostic output, we simplify the codebase in preparation for the upcoming multi-step configuration refactor. > > \## Author's checklist > > \* \[x\] I used the \[\`pre-commit\` hook\](https://precice.org/dev-docs-dev-tooling.html#setting-up-pre-commit) to prevent dirty commits and used \`pre-commit run --all\` to format old commits. > \* \[\] I added a changelog file with \`make changelog\` if there are user-observable changes since the last release. > \* \[x\] I added a test to cover the proposed changes in our test suite. > \* \[\] For breaking changes: I documented the changes in the appropriate \[porting guide\](https://precice.org/couple-your-code-porting-overview.html). > \* \[x\] I stuck to C++17 features. > \* \[\] I stuck to CMake version 3.22.1. > \* \[x\] I squashed / am about to squash all commits that should be seen as one. > \* \[\] I ran the systemtests by adding the label \`trigger-system-tests\` (may be skipped if minor change) > > \## Reviewers' checklist > \* \[\] Does the changelog entry make sense? Is it formatted correctly? > \* \[\] Do you understand the code changes? > > > \## Describe your setup > Operating system: macOS (Intel) > preCICE Version: develop… branch (Latest commit) > > \### Describe the problem > In src/xml/ConfigParser.cpp, the libxml2 parser context (xmlParserCtxtPtr) is managed manually within the readXmlFile function. > > \### The Risk: > xmlCreatePushParserCtxt is called and stored as a raw pointer, followed by xmlParseChunk. If an exception is thrown during parsing, execution will skip the manual xmlFreeParserCtxt(ctxt) call, leaking the parser context and its associated buffers. Additionally, the return value of xmlCreatePushParserCtxt is never checked for nullptr, meaning a failed context creation would cause a null pointer dereference on the subsequent xmlParseChunk call. > > \### Steps To Reproduce > > \- Introduce a temporary throw std::runtime\_error("Simulated Failure"); inside OnStartElementNs. > \- Run preCICE with any valid configuration file. > \- Observe (via Valgrind or similar) that memory allocated by xmlCreatePushParserCtxt is not reclaimed because ---xmlFreeParserCtxt is never reached. > > \### Expected behaviour > \- preCICE should follow the RAII pattern for all C-style resources. > \- The xmlParserCtxtPtr should be wrapped in a std::unique\_ptr -with a custom deleter (xmlFreeParserCtxt) so that the context is automatically freed during stack unwinding. A PRECICE\_CHECK should also guard against a null context before parsing begins. > > \### Additional context > The relevant code is in src/xml/ConfigParser.cpp within readXmlFile. The fix is a minimal, non-breaking change that requires no interface modifications. **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 ``and `` 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.