[MITgcm-support] Restart after changing deltatT

[Jean-Michel Campin]

Hi Samar,

I move to the support list since it might be of interest for many users.

I just added "baseTime" recently, that should make this restart easier:
the time that is used to decided when to write output is now:
clock-time = baseTime + delatTclock * iteration_number

The default is baseTime=0 ; 
You can set it in file "data", namelist PARM03 ;
or it will be set automatically when startTime & nIter0 
are both specified (in file "data") but are not in the ratio of
deltaTclock.

In your case you can either:
1) figure out what "baseTime" is:
0 + 43200*1080000 = baseTime + 1200*1080000 
  => baseTime=45360000000
2) or just specify:
 nIter0=1080000
 startTime=46656000000  (=43200*1080000)
But in this case, you will have carry both nIter0 & startTime 
for any of the next restart (if the second part of your run is long 
and cut in shorter segments). 

It's a new feature, not yet extensively tested, so please report any
problem you see.

Thanks,

Jean-Michel

On Mon, May 02, 2005 at 03:38:37PM -0400, samar khatiwala wrote:
> While on the subject of output timestep frequency, I've been having
> some trouble doing a pickup with a different timestep. More specifically,
> the pickup takes place but the output frequencies (dump and perm
> checkpoints) are all screwed up. As usual, I could be doing something
> totally stupid.
> 
> In particular, I do a long spinup with a time step deltaTClock=43200. A
> pickup is written at iter 1080000. Now I change deltaTClock to 1200, set
> nIter0=1080000
> nTimeSteps = 388800
> pChkptFreq= 466560000.,
> dumpFreq=   155520000.,
> 
> I expect to see dumps every 5 years and a checkpoint at 15 years (length
> of the run). But instead I get dumps and checkpoints at some odd
> frequency. Looking at ini_params.F I can sort of see how changing
> deltaTClock can mess things up (especially if the new time step is not a
> multiple of the old timestep). The solution seems to be to rename the
> pickup files and set pickupSuff, but is there a simpler/cleaner solution
> that anyone can suggest? Perhaps some combination of setting startTime,
> baseTime, etc.
> 
> Thanks, Samar
>