-
Notifications
You must be signed in to change notification settings - Fork 188
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
Some issue(s) with SplitExplicitFreeSurface
#3238
Comments
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 We're waiting for #3125 to do this since there are some changes introduced there |
I'd only change the kwarg arg to be |
(@simone-silvestri, until we implement the refactor and/or changes, what's the best way forward using v0.87.1?) |
I don't like |
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 thenOceananigans.jl/src/Models/HydrostaticFreeSurfaceModels/split_explicit_free_surface.jl
Lines 305 to 307 in 29a99a0
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
Oceananigans.jl/src/Models/HydrostaticFreeSurfaceModels/split_explicit_free_surface_kernels.jl
Line 324 in 29a99a0
since
settings
is not provided tocalculate_substeps
.cc @djlikesdjs
The text was updated successfully, but these errors were encountered: