[MITgcm-devel] cal_time2dump

[Martin Losch]

Hi Jean-Michel,

mitgcm.org has been down so much that I didn’t get a chance to check this, but now I find this:

Basically, I do 100 years (365days each) + 1 time step with a 8h asynchronous time step (see below data&PARAM03) and my data.diagnostics settings are:
  frequency(4) = 2628000.,
  timePhase(4) = 3122064000.,
  filename(4) = 'diag2Dm',
  fields(1,4) = 'MXLDEPTH','ETAN    ',
                'SIarea  ','SIheff  ','SIhsnow ',
                'SIuice  ','SIvice  ‘,

cat data.cal
&CAL_NML
 TheCalendar='noLeapYear',
 calendarDumps=.TRUE.,
#TheCalendar='model',
 startDate_1=19480101,
# I am not sure why this is here. Maybe that’s the problem?
 startDate_2=120000, 
&

Then I get 13 output files diag2Dm.*.data instead of 12 (as with my version of cal_time2dump):
diag2Dm.0000108404.data <- this is the extra file
diag2Dm.0000108497.data
diag2Dm.0000108581.data
diag2Dm.0000108674.data
diag2Dm.0000108764.data
diag2Dm.0000108857.data
diag2Dm.0000108947.data
diag2Dm.0000109040.data
diag2Dm.0000109133.data
diag2Dm.0000109223.data
diag2Dm.0000109316.data
diag2Dm.0000109406.data
diag2Dm.0000109499.data

 &PARM03
 nIter0=0,
 nTimeSteps = 109501,
 forcing_In_AB=.FALSE.,
 momDissip_In_AB=.FALSE.,
# asynchronous time stepping:
 deltaTmom   =1200.,
 deltaTtracer=28800.,
 deltaTfreesurf=28800.,
 deltaTClock =28800.,
 doAB_onGtGs=.FALSE.,
 alph_AB=0.5,
 beta_AB=0.281105,
 pChkptFreq  =315360000.0,
 chkptFreq   = 2628000.0,
 monitorFreq = 86400.0,
 dumpInitAndLast = .FALSE.,
&

Do you expect that? Is the startDate_2=120000, the problem (I guess it should be 000000)?
I’ll try again.

Martin

> On 01 Jul 2016, at 01:01, Jean-Michel Campin <jmc at mit.edu> wrote:
> 
> Hi Martin,
> 
> I added the same type of condition in cal_time2dump.F
> as ithe one in diff_phase_multiple.F for the case calendarDumps=F.
> I did not checked (yet) that this fix the problem.
> plese let me know if you find something strange.
> 
> Cheers,
> Jean-Michel
> 
> On Tue, Jun 21, 2016 at 02:03:40PM +0200, Martin Losch wrote:
>> not so important, but it would be nice to fix it. Any comments?
>> 
>> M.
>>> On 07 Jun 2016, at 10:20, Martin Losch <Martin.Losch at awi.de> wrote:
>>> 
>>> Hi there,
>>> 
>>> I think there is a bug in cal_time2dump.F
>>> 
>>> When I specify in data.diagnostics:
>>> frequency = 1 month
>>> timePhase = 99 years
>>> I expect that the monthly averages start in year 100, ie. 99year + 1month would be the first monthly averagy that I get.
>>> 
>>> This does not work if calendarDumps=.True. in data.cal, because cal_time2dump computes
>>>       shTime = myTime - phase
>>>       prTime = shTime - step
>>>       CALL CAL_GETDATE( myIter, shTime, thisDate, myThid )
>>>       CALL CAL_GETDATE( myIter, prTime, prevDate, myThid )
>>> and then evaluates the difference between thisDate and prevDate. But shTime and prTime both contain ???-phase???, so that the model starts writing averages in the first year. Since I don???t know these packages very well and I don???t want to break anything, I???d like to know what to do here. Is this intentional? If not, should it be fixed by adding something to the if-statement ( myTime.GE.phase )? Or should cal_getdate actuall return something special if shTime<0, and the problem is in that routine?
>>> 
>>> Martin
>>> 
>>> 
>>> _______________________________________________
>>> MITgcm-devel mailing list
>>> MITgcm-devel at mitgcm.org
>>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
>> 
>> 
>> _______________________________________________
>> MITgcm-devel mailing list
>> MITgcm-devel at mitgcm.org
>> http://mitgcm.org/mailman/listinfo/mitgcm-devel
> 
> _______________________________________________
> MITgcm-devel mailing list
> MITgcm-devel at mitgcm.org
> http://mitgcm.org/mailman/listinfo/mitgcm-devel