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?
What interests you most about our project?
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.
develop ← brightyorcerf:coupling-scheme-error-message-typos
opened 07:11AM - 14 Mar 26 UTC
## 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?
develop ← brightyorcerf:fix/xml-parser-raii
opened 05:15AM - 10 Mar 26 UTC
## 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?
develop ← brightyorcerf:improve/mesh-data-error-message
opened 10:30AM - 11 Mar 26 UTC
## Main changes of this PR
- Enhanced the error message in `MeshConfiguration… ::xmlTagCallback` when a `<use-data>` 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 <data:scalar name="Pressure"/> or <data:vector name="Pressure"/>
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?
develop ← brightyorcerf:refactor/xml-quality-refactor
opened 08:36AM - 10 Mar 26 UTC
### 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., <mfx:... >), 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?
opened 04:59AM - 10 Mar 26 UTC
closed 10:18AM - 19 Mar 26 UTC
bug
GSoC
## 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 <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.