[aklocker42]

With ZStarCoordinate and a SplitExplicitFreeSurface, a tracer that starts at c ≡ 1 (and has value 1 at the boundary) doesn't stay at 1 next to open boundaries. In the interior it does, to round-off.

The cause is that σ and w̃ see different boundary transports. σ is advanced with η, and η is stepped with the substep U/V after the halo fill and transport pin. The filtered transport Ũ/Ṽ, which sets w̃ through ∂t σ = −∇·Ũ/H, disagrees with that at the boundary faces in two ways:

1. Ũ/Ṽ are accumulated in the velocity kernel, before the substep fill/pin. So face 1 gets pre-fill values, and face N+1 is outside the kernel range and never accumulated.
2. After substepping, fill_halo_regions!((Ũ, Ṽ)) overwrites the boundary faces with the open-boundary value.

So (σⁿ⁺¹ − σⁿ)/Δt ≠ −∇·Ũ/H in the boundary rows only. Because the tracer update divides by σ, the result is a multiplicative error in every tracer there.

This PR:

• moves the Ũ/Ṽ accumulation into the free-surface kernel, using U★ (the same transport that advances η);
• also accumulates face N+1 when the right side is Closed;
• builds Ũ/Ṽ with boundary conditions that drop NormalFlow sides, so the post-substep fill keeps the accumulated faces.

Fixing only (1) gives results bit-identical to main, because (2) overwrites the faces anyway.

In a small channel (SplitRungeKutta3, GravityWaveRadiationBoundaryCondition on both open sides, 200 steps), max |c − 1| goes from ~2e-5 on main to ~3e-15.
The new test in split_explicit_boundaries.jl runs c ≡ 1 under z★ through open north/south and west/east boundaries. It fails on main (|c − 1| ≈ 7e-6) and passes here (< 1e-12).

In a 16-day realistic regional run with open boundaries, the fix also removes the spurious bottom-cell jets that develop along the open boundaries without it.

This is a fix for SplitRungeKutta3. Under QuasiAdamsBashforth2, z★ doesn't keep c ≡ 1 even with closed walls (~4e-5 after 50 steps, identical on main and here). With open boundaries there is an extra boundary error of similar size (~1e-4), which this PR doesn't fix.

Related: #5812 changes the same kernel.

🤖 Generated with Claude Code

[codecov]

Codecov Report

❌ Patch coverage is 76.47059% with 8 lines in your changes missing coverage. Please review.
✅ Project coverage is 74.39%. Comparing base (591b0cf) to head (c235b35).

Files with missing lines	Patch %	Lines
...itFreeSurfaces/step_split_explicit_free_surface.jl	75.00%	6 Missing ⚠️
src/MultiRegion/multi_region_models.jl	50.00%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6362      +/-   ##
==========================================
- Coverage   75.70%   74.39%   -1.31%     
==========================================
  Files         452      452              
  Lines       29091    29097       +6     
==========================================
- Hits        22022    21647     -375     
- Misses       7069     7450     +381     

Flag	Coverage Δ
buildkite	71.76% <100.00%> (+0.02%)	⬆️
distributed/output_combining	20.19% <43.75%> (+0.01%)	⬆️
distributed/tripolar	20.19% <43.75%> (+0.01%)	⬆️
julia	71.76% <100.00%> (+0.02%)	⬆️
makie	?
metal	16.25% <46.87%> (+0.02%)	⬆️
reactant	?
sharding	?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 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.

[simone-silvestri]

There are a couple of fixes required. I will merge main, then push here directly.

[simone-silvestri]

I have cleaned up a bit, however, I am a bit hesitant to merge any open boundary fix before #6277 gets merged. I think we are close there to a merge, so I would keep this PR a sec to figure out if there is a better way to do this once radiation schemes do not use fill halo anymore