[MITgcm-support] Re: Restart after changing deltatT

[samar khatiwala]

Hi Jean-Michel

I tried setting baseTime as you suggested (it was more attractive than
the other option of setting both nIter0 and startTime). I get
unpredictable (at least by me!) results and was wondering if you could
help me diagnose the problem.

Details:
I have a pickup file at iter=3600000 from a run with deltaTClock=43200.
I now switch to deltaTClock=1200. New data file looks like:

 nIter0  =3600000,
 baseTime =151200000000.0,
 nTimeSteps = 388800,
 deltaTClock = 1200.0,
...
 pChkptFreq= 466560000.,
 dumpFreq=   155520000.,

The baseTime I calculated using your formula:
  baseTime = 3600000*(43200 - 1200) = 151200000000.

I expect to see dumps every 5 years, and a pickup at year 15. Instead, I
get dumps at iter:
0003628800 -> (3628800-3600000)*1200/86400/360 = 1.111 year
0003758400 -> (3758400-3600000)*1200/86400/360 = 6.111 year
0003888000 -> (3888000-3600000)*1200/86400/360 = 11.111 year

and a pickup at iter:
0003888000 -> (3888000-3600000)*1200/86400/360 = 11.111 year

Note that there is no dump at the initial iteration, 0003600000.

What am I doing wrong here?

Thanks, Samar

On Mon, 2 May 2005, Jean-Michel Campin wrote:

> 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
> >
>