Closed glwagner closed 1 year ago
If the barotropic mode is not used in the AB2 scheme, which I presume is the case, then I agree it makes sense to compute it elsewhere.
update_state!
seems like a good place to me.
If the barotropic mode is not used in the AB2 scheme, which I presume is the case, then I agree it makes sense to compute it elsewhere.
update_state!
seems like a good place to me.
Basically we have to calculate the barotropic mode before doing the free surface update if we are using a SplitExplicitFreeSurface
. But I think we can regard the barotropic mode as part of the "auxiliary state" of the problem. The rest of the auxiliary state is calculated in update_state!
, so I think that's the appropriate place to calculate the barotropic mode as well.
I like that plan.
I think the only potential issue would be the first time step. Otherwise this seems okay to me
We always calculate update_state!
before the first time-step!
For reference, update_state!
:
update_state!
is called:
run!
, or also time_step!(simulation)
when simulation.initialized == false
)set!(model, ...)
@simone-silvestri ?
This part of the code has been removed. The initial barotropic mode is calculated now as part of the initialize_free_surface! function called at initializatiom
We currently calculate the barotropic mode inside the AB2 step:
https://github.com/CliMA/Oceananigans.jl/blob/e27988039e65e9244a84d241b70c2dcdeac93309/src/Models/HydrostaticFreeSurfaceModels/hydrostatic_free_surface_ab2_step.jl#L18-L22
I'm wondering if it makes more sense to calculate this inside
update_state!
.Our algorithm calculates
update_state!
at the end of a time-step, which means that after callingtime_step!(model)
the model auxiliary and prognostic state are all concurrent, which is useful for output.cc @sandreza @simone-silvestri