[MITgcm-devel] major_changes in forward_step

[Chris Hill]

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
>