Make assignment replacement with trixi_include recursive

[efaulhaber]

In TrixiParticles.jl, we often define recursive trixi_include calls in our example files.
We have a base "dam break 2D" file and then more files like "dam break 2D GPU" and "dam break 2D IISPH", which just define a few lines that changed and then use trixi_include to include the base file with these changes to avoid duplicate code.

This PR allows changing variables defined in the base file when including the special file:

trixi_include("special_file.jl", cfl=0.9)

even if cfl is not defined in the special file but only in the base file.

[Copilot]

Pull Request Overview

This PR implements recursive assignment replacement for the trixi_include function, allowing keyword arguments to be passed down through nested trixi_include calls. This enables overriding variables that are defined in base files when including special files that reference them.

Key changes:

• Added recursive keyword argument passing to nested trixi_include calls
• Enhanced validation to warn instead of error when assignments are not found in files with nested calls
• Added comprehensive test coverage for recursive assignment scenarios

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
src/trixi_include.jl	Implements recursive kwarg passing by detecting nested calls and adding missing kwargs, plus enhanced validation with warnings
test/trixi_include.jl	Adds extensive test coverage for recursive assignment scenarios including multi-level nesting and various kwarg patterns

---

_{Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.}

[codecov]

Codecov Report

❌ Patch coverage is 98.96907% with 1 line in your changes missing coverage. Please review.
✅ Project coverage is 92.82%. Comparing base (ad6d62c) to head (6d37ef7).
⚠️ Report is 2 commits behind head on main.

Files with missing lines	Patch %	Lines
src/trixi_include.jl	97.56%	1 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #54      +/-   ##
==========================================
- Coverage   97.27%   92.82%   -4.46%     
==========================================
  Files           5        5              
  Lines         147      237      +90     
==========================================
+ Hits          143      220      +77     
- Misses          4       17      +13     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[efaulhaber]

Tests are only failing because of the Coveralls upload.

[JoshuaLampert]

Yes, coveralls seems to be down at the moment. I noticed this also in another PR.

[JoshuaLampert]

Coveralls is alive again, I reran the tests, and CI is passing now, but code coverage reports that find_assignment is not covered now. Can this be removed with this PR?

[efaulhaber]

code coverage reports that find_assignment is not covered now. Can this be removed with this PR?

Yes. It was never actually tested. It was just covered because before I added validate_assignments, the validation code was just calling find_assignment. But there was no actual test for it, especially no test verifying the return value.
I think it makes more sense to add specific tests for find_assignment in a new PR.

[JoshuaLampert]

Ok, but do we need find_assignment at all? It's never called anymore, right? And it's not public or exported. So can't we just remove it?

[efaulhaber]

AFAIK, it is used by Trixi.jl in the convergence test to read the initial refinement level, which is then increased in each iteration. At least this was the case a while ago. Not sure if it is still used there.

[JoshuaLampert]

Good point. Yes, it's still used there. In this case, let's proceed as you suggested and add tests for it in a separate PR.

[sloede]

LGTM but it would be great if someone with more macro experience such as @vchuravy or @ranocha could review as well.

[sloede]

LGTM, but I'd still wait for another review by someone with macro experience before merging...

[vchuravy]

I have no comments on the macro implementation, but I am generally not a fan of the loss of referential transparency and pushing things through to the lowest-level.

I can see a real use-case for a name reuse between recipes, as an example the inner example calculating a reference solution and the outer example using a different solver.

Now passing sol=nothing would break the outer recipe (assuming that it captures the reference solution from the inner recipe).

[efaulhaber]

I can see a real use-case for a name reuse between recipes, as an example the inner example calculating a reference solution and the outer example using a different solver.

Now passing sol=nothing would break the outer recipe (assuming that it captures the reference solution from the inner recipe).

Why would you pass sol=nothing then? Usually, I would pass sol=nothing to disable the simulation, so that I just load the variables (like initial conditions) into the name space, then I'll modify them, like defining a different method for the simulation, and then call trixi_include again, overwriting the used method. In this case, I would just overwrite the line(s) that calculate a reference solution as well to avoid an error.

[vchuravy]

I think my question to you is "Why do you assume that the name sol, dt, etc" ought to be equivalent across a recursive call to trixi_include.

I would rather have something that conveys that I am setting dt on a different nesting instead of blindly recursing, but I am also not your user for trixi_includ in general.

[efaulhaber]

blindly recursing

I now made the recursive feature optional (disabled by default).
Default behavior should stay exactly the same with this PR as on main.

[sloede]

Again, I cannot vouch for the macro implementation, but the explicit intent with its descriptive variable names is a nice touch 🙏

[efaulhaber]

@vchuravy could you please have a look?