Closed navidcy closed 7 months ago
On the user interface side, @simone-silvestri discussed a refactor that would implement something like:
# To fix the number of substeps at 200
free_surface = SplitExplicitFreeSurface(time_step=FixedNumber(200))
# To fix the number of substeps according to CFL criteria, given the time-step passed to simulation
free_surface = SplitExplicitFreeSurface(time_step=FixedNumber(simulation_Δt=2minutes, cfl=0.7))
# Fixed time-step (variable number of substeps)
free_surface = SplitExplicitFreeSurface(time_step=FixedSize(cfl=0.7))
Do you have any feedback on that? Partly, this was motivated by my own confusion with the API. (Note, we also discussed some internal changes like getting rid of settings
.) One detail is that we shouldn't have to pass grid
because the free surface already must be "materialized" on the model grid in order to allocate memory for fields. My opinion is that we either should pass grid
and cut out the materialization, or we should not pass grid
and materialize under the hood. But not both because that's the worst of both words (less convenient for users, complicated under the hood).
We're waiting for #3125 to do this since there are some changes introduced there
I'd only change the kwarg arg to be barotropic_time_step = FixedNumber(200)
, etc.
(@simone-silvestri, until we implement the refactor and/or changes, what's the best way forward using v0.87.1?)
I don't like barotropic
because not everyone knows what that is, not to mention that it can even be confusing to people who know what "barotropic" means, because oceanographers sort of abuse the term. Really, this is the time-step for the free surface solver (further interpretation requires fairly detailed understanding of the physics). What might be a less technical name?
I thought just saying "time step" was good because the context is already there (it's being specified inside the free surface type, thus we have to delve into the docs for that type to find further information)
Yeah, there a couple of bugs with the adaptive time step that I meant to fix with #3125 that reworks the internals of the split explicit solver to enable overlayed communication, but that is taking a bit too much, and we want to refactor the constructor (and internal structure) anyway so it's better to do it in a separate (maybe quicker) PR
I can adapt #3125 later
So initially me and @djlikesdjs were trying to use the
SplitExplicitFreeSurface
with the adaptive barotropic step based on CFL.This:
errors
This seems counter-intuitive to me because we had actually prescribed a
cfl
. We figured that the error was becausesubsteps
has a default value of 200 so when we also prescribe acfl
kwarg thenhttps://github.com/CliMA/Oceananigans.jl/blob/29a99a0c235b2f6bf0cec525f2249125ad254ccc/src/Models/HydrostaticFreeSurfaceModels/split_explicit_free_surface.jl#L305-L307
gets triggered. A solution was to add
substeps = nothing
. This is a bit counter-intuitive though. Is there a different way we should have done it? If not, perhaps a good idea is to add a note in theSplitExplicitFreeSurface
dostring....Moving on, we got another error down the road. Running this:
spits out
Most probably this is due to a bug at
https://github.com/CliMA/Oceananigans.jl/blob/29a99a0c235b2f6bf0cec525f2249125ad254ccc/src/Models/HydrostaticFreeSurfaceModels/split_explicit_free_surface_kernels.jl#L324
since
settings
is not provided tocalculate_substeps
.cc @djlikesdjs