-
Notifications
You must be signed in to change notification settings - Fork 256
Reformulate hydrostatic model timestepping #4811
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
src/Models/HydrostaticFreeSurfaceModels/HydrostaticFreeSurfaceModels.jl
Outdated
Show resolved
Hide resolved
src/Models/HydrostaticFreeSurfaceModels/HydrostaticFreeSurfaceModels.jl
Outdated
Show resolved
Hide resolved
| velocities :: U # Container for velocity fields `u`, `v`, and `w` | ||
| transport_velocities :: W # Container for velocity fields used to transport tracers |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the difference between "normal velocities" and "transport velocities" is unclear
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, how should we call them? They are the velocities that transport tracers around. transport is not good because it implies a multiplication times the area...
|
I am at the point here that the RK formulation is conservative both locally and globally. |
| # Synchronize model state if needed | ||
| for field in fields(model) | ||
| synchronize_communication!(field) | ||
| end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how related to this PR?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am trying to figure out how to distribute operations in time. I don't think this is necessary anymore.
src/Advection/Advection.jl
Outdated
| # `Centered(order=12`) and `UpwindBiased(order=11)`. The list can be extended in order to | ||
| # `Centered(order=10`) and `UpwindBiased(order=9)`. The list can be extended in order to | ||
| # compile schemes with higher orders; for example `advection_buffers = [1, 2, 3, 4, 5, 6, 8]` | ||
| # will compile schemes for `advection_buffer=8` and thus `Centered(order=16)` and `UpwindBiased(order=15)`. | ||
| # Note that it is not possible to compile schemes for `advection_buffer = 41` or higher. | ||
| const advection_buffers = [1, 2, 3, 4, 5, 6] | ||
| const advection_buffers = [1, 2, 3, 4, 5] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
we should compile past the recommended order. If order=9 is recommended we need order=11 to verify this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, I guess I'll take this suggestion for #4434, which, apart from this change, should be ready.
|
why are there so many changes to WENO advection, etc? |
src/Models/HydrostaticFreeSurfaceModels/pcg_implicit_free_surface_solver.jl
Outdated
Show resolved
Hide resolved
| end | ||
|
|
||
| @inline function update_grid_scaling!(σᶜᶜⁿ, σᶠᶜⁿ, σᶜᶠⁿ, σᶠᶠⁿ, σᶜᶜ⁻, i, j, grid, ηⁿ) | ||
| @inline function update_grid_scaling!(z, i, j, grid) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
| @inline function update_grid_scaling!(z, i, j, grid) | |
| @inline function update_grid_scaling!(z_coordinate, i, j, grid) |
| # First stage | ||
| # | ||
|
|
||
| compute_flux_bc_tendencies!(model) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
how are they computed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tried putting this back inside the compute_tendencies! given that these cannot be computed in update_state! anymore. I will verify everything is consistent.
|
It's really hard for me to understand how this is an improvement. I think some explanation is needed (maybe docs or a docstring...) |
|
It wouldn't be a completely crazy idea to start a new docs section on "Time steppers" which outlines how each time stepper works. Esp because there appears to be a kind of interface for using different methods, eg AB2 and RK3. |
I have merged in #4434 because I was expecting to merge it before this one. Maybe that was a mistake |
Yeah that would be nice! After this PR we can also use RK for sea ice, for example, by extending |
…nto ss/optimize-weno
…nto ss/optimize-weno
…/Oceananigans.jl into ss/reformulate-hydrostatic-model-2
…/Oceananigans.jl into ss/reformulate-hydrostatic-model-2
…/Oceananigans.jl into ss/reformulate-hydrostatic-model-2
This is a work-in-progress PR that aims to reformulate the timestepping scheme of the
HydrostaticFreeSurfaceModeltomake sure that three numerical properties are satisfied:
This is easier to achieve with an explicit discretization of the free surface (
ExplicitFreeSurfaceandSplitExplicitFreeSurface) rather than an implicit free surface discretization and with RK3 rather than AB2.However, this PR reformulates much of the timestepping algorithm, so it will be a lengthy WIP that will need to be thoroughly validated for all combinations of barotropic and baroclinic timestepping schemes.
More changes are performed to correctly abstract the timestepping schemes, which, at the moment, are tailored specifically to the
NonhydrostaticModel(for example, the timesteppers include acompute_pressure_correction!or acorrect_velocitiesfunction, which are meaningful only for a non-hydrostatic Navier Stokes solver)Edit: another objective I have is to remove any timestepping from the
update_state!function. We should be able to callupdate_state!multiple times in a row without problems and timestepping insideupdate_state!negates this possibility.TODO:
Remove timestepping fromIn another PRupdate_state!DistributedGridsImplement a semi - conservative method for AB2In another PRAddress precision errors that tend to destroy conservation for constant fieldsIn another PR