[MITgcm-devel] major_changes in forward_step

[Patrick Heimbach]

Chris,

could you re-activate twain.
sea is down, i.e. no taf available right now...

Thanks
-p.



Quoting Chris Hill <cnh at MIT.EDU>:

> J-M etc...,
> 
>  Can we make a checkpoint and verify that the adjoint is stabilized
> **before** all the changes?
>  I think the adjoint is up to date so I don't think it's a big deal, but it
> needs doing.
> 
> Chris 
> 
> > -----Original Message-----
> > From: mitgcm-devel-bounces at mitgcm.org 
> > [mailto:mitgcm-devel-bounces at mitgcm.org] On Behalf Of 
> > Jean-Michel Campin
> > Sent: Tuesday, May 04, 2004 9:49 AM
> > To: MITgcm-devel at mitgcm.org
> > Subject: [MITgcm-devel] major_changes in forward_step
> > 
> > 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 ?
> > 
> > _______________________________________________
> > MITgcm-devel mailing list
> > MITgcm-devel at mitgcm.org
> > http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> > 
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://dev.mitgcm.org/mailman/listinfo/mitgcm-devel
> 


_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Patrick Heimbach     Massachusetts Institute of Technology
FON: +1/617/253-5259                    EAPS, Room 54-1518
FAX: +1/617/253-4464               77 Massachusetts Avenue
mailto:heimbach at mit.edu                 Cambridge MA 02139
http://www.mit.edu/~heimbach/                          USA