[MITgcm-support] timing of snapshots and time averages in pkg/timeave and pkg/diagnostics

[Menemenlis, Dimitris (3248)]

Jean-Michel, thank you for helpful and detailed reply,
and also for locating your January 2005 email, which discusses this.
I tried to find but was googling with wrong search terms.
What I had missed is that you generally call diagnostics_fill
toward beginning of time step, before thermodynamics.

Thanks!

Dimitris Menemenlis

On Jan 29, 2012, at 9:53 AM, Jean-Michel Campin wrote:

> Hi Dimitris,
> 
> Regarding timeave pkg, state variables are using this half value
> at the beginning and at the end of the averaging period.
> I would say that it's an "historical" reason, hard to track
> with cvs log (I remember beginning of 2001 working on putting back 
> the time-ave utility as a standard pkg, which had been 
> disable after the merging with the atmos-branch, and it was just
> inherited from the older convention).
> But it was found to be not so practical, and later on (Oct 07, 2002)
> was added the option to weight differently the first and last time-step 
> with the run-time parameter "tave_lastIter" (parameter file "data", 
> namelist "PARM03", default value = 0.5):
> first time step of time-averaging interval: field*(1.-tave_lastIter)
> usual time step within time-averaging interval: field*1.
> last time step of the time-averaging interval: field*tave_lastIter
> Documented in PARAMS.h:
> 681 C tave_lastIter :: (for state variable only) fraction of the last time
> 682 C                  step (of each taveFreq period) put in the time average.
> 683 C                  (fraction for 1rst iter = 1 - tave_lastIter) 
> And at the end, this feature (partial fraction) was not exported 
> to pkg/diagnostics which only uses full time-step averaging.
> 
> Regarding state-variables snap-shot output from pkg/diagnostics, 
> I found an old email I wrote which try to justified the way it's
> done now:
> http://mitgcm.org/pipermail/mitgcm-devel/2005-January/001265.html
> Note that iteration number contained in the file-name suffix of 
> plain binary output is consistent between:
> a) main model snap-shot output (dumpFreq)
>   T,S,U,V.{10-digits-iter-number}.*data/meta
> b) pkg/diagnostics snap-shot output (using negative frequency & timePhase=0)
>   THETA,SALT,UVEL,VVEL.{10-digits-iter-number}.*data/meta
> But the 1 time-step time averaged output from pkg/diagnostics 
> (using positive frequency equal to the time-step) corresponds to
> the iteration suffix iter-number + 1 
> since it is assumed that pkg/diagnostics time-averaged output have 
> the iteration number that corresponds to the end of the averaging period.
> For instance, with deltaT=86400:
> diff instUVEL.0000036011.data U.0000036010.data        <- no difference
> diff instUVEL.0000036010.data averUVEL.0000036011.data <- no difference
> diff instUVEL.0000036010.meta averUVEL.0000036011.meta
> 9,10c9,10
> <  timeStepNumber = [      36010 ];
> <  timeInterval = [  3.111264000000E+09 ];
> ---
>> timeStepNumber = [      36011 ];
>> timeInterval = [  3.111264000000E+09  3.111350400000E+09 ];
> 
> Regarding snap-shot output from pkg/diagnostics of non state-variables
> fields (i.e., for intermediate fields, which are not store in pickup-files 
> and/or not available before the 1rst model time-step, but instead computed
> within one model time-step such as flux, tendencies, etc ...)
> there is the same 1.iter shift between time-averaged and snap-shot
> (when both output from pkg/diagnostics) as there is with state variables;
> but the correspondence with direct output (i.e., not from pkg/diagnostics)
> is less clear since it depends from where in the code the output
> comes from (before or after updating the iteration number) and
> from where the diagnostics has been filled.
> For instance, with staggerTimeStep=T, 
> 1.time-step averaged diag: WVELMASS{iter-number} <--> W.{iter-number}.*data
> and for a snap-shot diag:  WVELMASS{iter-number} <--> W.{iter-number + 1}.*data
> 
> I am not sure this will contribute to clarify the issue (I was hoping but ...).
> 
> Cheers,
> Jean-Michel
> 
> On Sat, Jan 28, 2012 at 01:40:59PM -0800, Menemenlis, Dimitris (3248) wrote:
>> Hello MITgcm support,
>> is a discussion of the exact timing of diagnostic snapshots and time averages available somewhere?
>> 
>> I notice that pkg/diagnostics is not consistent with the old definitions in pkg/timeave.
>> Which time-averaging definition is correct, that of pkg/timeave or that of pkg/diagnostics?
>> 
>> Specifically, in pkg/timeave, except for PHL where
>> one-time-step-average of PHL(t) = snapshot of PHL(t)
>> all other variables have
>> one-time-step-average of VARIABLE(t) = ( snapshot of VARIABLE(t-1) + snapshot of VARIABLE(t) ) / 2
>> 
>> For pkg/diagnostics the correspondence between snapshots and time averages is (from diagnostics_write.F):
>>       myItM1 = myIter - 1
>>         IF ( freqSec.LT.0. ) THEN
>> C--     write snap-shot with suffix = myIter-1 to be consistent with
>> C       state-variable time-step:
>>           wrIter = myItM1
>>           wrTime = myTime - deltaTclock
>>         ELSE
>>           wrIter = myIter
>>           wrTime = myTime
>>         ENDIF
>> that is,
>> one-tine-step-average of VARIABLE(t) = snapshot of VARIABLE(t-1)
>> 
>> Thank you,
>> 
>> Dimitris Menemenlis