[MITgcm-devel] major_changes in forward_step
Jean-Michel Campin
jmc at ocean.mit.edu
Tue May 4 09:48:40 EDT 2004
Hi everybody,
The problem (in short):
when mass (or volume) is added to the model
(E-P + RealFreshWater + (NLFS or OceanicP), see e.g. external_forcing_surf.F)
E-P needs to be incorporated in SOLVE_FOR_PRESSURE before it's used in
THERMODYNAMICS.
The way I did it, saving EmPmR (used in SOLVE_FOR_PRESSURE)
into PmEpR (used in THERMODYNAMICS) before loading the new E-P
is not really good, since the effect of E-P is lagging 1 time step
behind Qnet, which is odd, and might cause problems when
Heating/Cooling and freshwater forcing are strongly coupled
(e.g., with sea-ice).
I talk to Alistair (few months ago) about this, and the conclusion
we came to was that we "simply" have to move all the forcing call(s)
(including sea-ice) in forward_step, from the beginning of forward_step.F
down to the middle, just before solve_for_pressure.
I started to test this new way to do the forcing with the coupled model,
and it seems OK (with either thSIce or RealFreshWater, but not both
simultaneously). However, it's not so easy since the forcing fields
need to be part of the pickup file for a restart.
But I would like to sort out this problem rapidly, to know if
the pickup with forcing fields needs to be part of the coupling
interface (as tested now) or part of the main model (as it will
be when the forcing is moved down in forward_step).
Here is what I propose:
distingues 3 cases:
a) Coupled or with Sea-Ice (for now thSIce only, just to test,
and may be later with SEAICE pkg),
b) not (a) but with mass (or volume) added to the model
(i.e. P-E + RealFreshWater + (NLFS or OceanicP))
c) not (a) and not (b).
Case (c), forcing is loaded where it is now.
Case (b), forcing is loaded where it is now only at the 1rst iteration
(nIter=nIter0) after a restart.
and always loaded before Solve_for_pressure corresponding to
nIter+1, myTime+deltaT. - no additional pickup needed.
Case (a), forcing is loaded from a pickup file (pLoad,fu,fv,SST,SSS,
Qnet,Qsw,saltFlux,EmPmR) after a restart.
and loaded before Solve_for_pressure corresponding to
nIter+1, myTime+deltaT.
and need to see what makes sense for 1rst iteration of
the run (nIter=0)
The 2 advantages I can see:
1) we avoid the pickup of all forcing fields, unless it's really
necessary.
2) in case (c), nothing is changed, so that we can easely swith back
to the "old" implementation.
Now, I just discover a new related problem:
The sea-ice mass loading (not yet implemented, but should go into pLoad)
is not at the right place:
If I move external_forcing_load just before solve_for_pressure,
since pLoad has to be synchronous with E-P (this is really crucial),
it means that grad(pLoad) cannot stay in u*,v* (in dynamics.F)
but has to be added later (in solve_for_pressure), as an additional
term in the momentum equation (conbined with grad(g.eta) ?).
Comments ?
Jean-Michel
PS: A detail: Can we move (in forward_step) the time & timestep
incrementation before solve_for_pressure instead of after ?
More information about the MITgcm-devel
mailing list