[MITgcm-support] Using pkg/calendar with diagnostics

[Samar Khatiwala]

Hi Jean-Michel,

Thanks for looking into this. You're right, the time stamps indicate the length of the month is correct. 

Here you go (these are for ECCO v4 if it helps):

data:
 nIter0=1,
 nTimeSteps=17568,
 deltaTClock =3600.,

data.cal:
 TheCalendar='gregorian',
 calendarDumps=.TRUE.,
 startDate_1=19920101,
 startDate_2=120000,

Good idea to look at data.cal. I was thinking in terms of calendar months rather than the model start time (startDate_2). 
But now the 1/2-day shift makes sense (i.e., why the second output file is at 59.5 days rather than at 60, etc). I think.

Thanks very much!

Samar

On Mar 22, 2014, at 12:21 PM, Jean-Michel Campin <jmc at ocean.mit.edu> wrote:

> Hi Samar,
> 
> The calendar round off of monthly frequency is not taken into account
> when writing timeInterval into the meta file.
> This is something that needs to be fixed (but would imply to
> store in common block when the storage array is reset, rather than
> to try to guess, at the time the output is written, when the timeInterval 
> started).
> 
> So, for now, let focus on the time stamps of the output files.
> It looks like the length of each month is right (assuming you are
> starting on a leap year), but it's shifted by half a day.
> 
> What is deltaTClock and other timing parameters (PARM03 in data)
> and data.cal + relevant output params from data.diagnostics
> that you are using ?
> 
> Cheers,
> Jean-Michel
> 
> On Fri, Mar 21, 2014 at 03:57:02PM -0400, Samar Khatiwala wrote:
>> Hi Dimitris,
>> 
>> I don't understand the logic either but I'm assuming what is written in the .meta file is correct. Good idea 
>> to look at the time stamps of the output files. This is what I get:
>> 
>>   30.5   59.5   90.5  120.5  151.5  181.5  212.5  243.5  273.5  304.5  334.5  365.5
>>  396.5  424.5  455.5  485.5  516.5  546.5  577.5  608.5  638.5  669.5  699.5
>> 
>> Clearly something funny. Sounds like an issue previously reported in this thread: 
>> http://mitgcm.org/pipermail/mitgcm-support/2012-June/007789.html
>> 
>> And, yes, I do have endTime such that there should be 2 years of output.
>> 
>> Thanks,
>> 
>> Samar
>> 
>> On Mar 21, 2014, at 3:33 PM, Dimitris Menemenlis <dmenemenlis at gmail.com> wrote:
>> 
>>> Hi Samar, I am not very familiar with the timeInterval logic.
>>> But I if you look at the time stamps of your output files,
>>> if you start integration from January 1, they should be
>>> 31, 59, 90, 120, 151, etc. days for normal years and
>>> 31, 60, 91, 121, 152, etc. days for leap years.
>>> Maybe the "timeInterval" computation is off?
>>> 
>>> To get 2 years of output you need to make sure
>>> that endTime >= 31536000 for normal years
>>> and endTime >= 31633400 for leap years.
>>> 
>>> On Mar 21, 2014, at 10:38 AM, Samar Khatiwala <spk at ldeo.columbia.edu> wrote:
>>> 
>>>> Thanks Dimitris!
>>>> 
>>>> I gave it a try but am puzzled by the output. I ran the model for 2 years expecting to find 24 output files 
>>>> but instead got 23. Also, the timeInterval stamp in the .meta files looks odd. For example, compare the 
>>>> second digit in the 2d line with the first digit in the 3d line. There's a gap which seems to explain why 
>>>> none of the averaging intervals exceeds 29.5 days (except the first one). Any thoughts as to what I'm 
>>>> doing wrong?
>>>> 
>>>> Thanks, Samar
>>>> 
>>>> timeInterval = [  3.600000000000E+03  2.635200000000E+06 ]; 30.4583  <-- number of days
>>>> timeInterval = [  2.635200000000E+06  5.140800000000E+06 ]; 29
>>>> timeInterval = [  5.270400000000E+06  7.819200000000E+06 ]; 29.5
>>>> timeInterval = [  7.905600000000E+06  1.041120000000E+07 ]; 29
>>>> timeInterval = [  1.054080000000E+07  1.308960000000E+07 ]; 29.5
>>>> timeInterval = [  1.317600000000E+07  1.568160000000E+07 ]; 29
>>>> timeInterval = [  1.581120000000E+07  1.836000000000E+07 ];
>>> 
>>> 
>>> _______________________________________________
>>> MITgcm-support mailing list
>>> MITgcm-support at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-support
>> 
>> 
>> _______________________________________________
>> MITgcm-support mailing list
>> MITgcm-support at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-support
> 
> _______________________________________________
> MITgcm-support mailing list
> MITgcm-support at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-support