[MITgcm-support] Re: Restart after changing deltatT

[Jean-Michel Campin]

Hi Samar,

> 
> > If I understand correctly, you are starting from t=5000.y
> > (nIter0=3600000, deltaT=1200, basetime=151200000000
> >  => startTime=155520000000 = 5000.y) and you set the
> > pChkptFreq to 15.y ;
> > the 1rst multiple of 15.y after t=5000.y is t=5010.y,
> > and it's what you get. Is it right ?
> 
> That is indeed correct, and I see what you are getting at, but its
> obviously not the behavior I was expecting. Shouldn't model time
> be measured relative to baseTime (or perhaps startTime). In which case
> t=(5015-5000)=15 is a multiple of 15 y. Based on what you are saying, it
> would appear that the correct dumps I now get is simply fortituous!
> If I had picked a dump freq of 6 years as opposed to 5 years,
> I'd be back to square one.
> 

I think that what you suggest is not the "standard" interpretation
of what the model-time is:
Consider this simple exemple, where I had to restart + change 
the time-step at day 10 of the year. I still want montly average,
(12 months per year) and pickup at the end of the year, but want 
also to be in phase with the seasonal cycle. 
Right now, it's what I will get. With your interpretation, I will
have monthly average that are shifted by 10 days relative to 
the seasonal cycle (assuming that the forcing is still using 
the present definition of model time).
I can also think of changing the way the model-time is used to set 
the forcing, but then it becomes even more "stange" (you stop at
the middle of the summer, and restart + change deltaT and you get 
the forcing of the 1rst of january).

The way it's done now allows to restart a run from the same time
where it stopped, to keep the same nIter0 that corresponds to the 
pickup file, even if the time-step is different from what it was.

But I can understand that it's not what you want.

Jean-Michel