Skip to content

Avoid topology-aware operators when filling halos in the SplitExplicitFreeSurface#5332

Merged
simone-silvestri merged 6 commits intomainfrom
ss/split-explicit-update
Feb 24, 2026
Merged

Avoid topology-aware operators when filling halos in the SplitExplicitFreeSurface#5332
simone-silvestri merged 6 commits intomainfrom
ss/split-explicit-update

Conversation

@simone-silvestri
Copy link
Copy Markdown
Collaborator

we already have a "fill_halo" mode for the split explicit free surface. We can use that as a prototype to implement open boundary conditions since the literature review in #5229 showed that we need to fill the halos each substep.

However, at the moment, the split explicit evolution use topology-aware operators that automatically encode boundary conditions in the barotropic mode.

This PR chooses the operators to used based on if the halos are filled (then we can use normal operators) or not (we use topology-aware operators).

A little step to start supporting #5229

After this I will open a PR that slightly refactors the "fill halo mode" of the split explicit free surface to avoid distributed halos (only_local_halos=true) and convert the necessary fill halo inputs to devices only once such that it will still be efficient (hopefully) even if we introduce open boundaries.

Copy link
Copy Markdown
Member

@glwagner glwagner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

you may want to use Val(true) / Val(false) to get compile-time selection of the operators.

@simone-silvestri simone-silvestri merged commit 4624835 into main Feb 24, 2026
75 of 78 checks passed
@simone-silvestri simone-silvestri deleted the ss/split-explicit-update branch February 24, 2026 20:40
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants