[MITgcm-devel] cal_time2dump
Jean-Michel Campin
jmc at mit.edu
Mon Jul 11 16:41:49 EDT 2016
Hi Martin,
I did not check carefully, but I have the impression that the behaviour
you are getting is not very different from the one you would get without
calendarDumps (which I did check).
In diagnostics pkg, using timePhase > startTime results in the first file
beeing the average over the full time-period prior to timePhase, so that
you probably want to discard this output file.
In fact, with debugLevel=2 or higher, the number of accumulated time-step used
in the averaging is written out in the STDOUT file as "Counter" value:
> Computing Diagnostic # 23 ETAN Counter: 15 Parms: SM M
so you should be able to check.
There would be some way to fix this, i.e., not to fill up the diagnostics arrays
if myTime < timePhase, like what is done for snap-shot diagnostics, from
S/R DIAGNOSTICS_SWITCH_ONOFF, but would need:
a) to be careful regarding calendarDumps option.
b) a special treatment for the first time an output file is written.
c) it might slow down the run (checking at every time-step for all
diagnostics stream with positive freq.).
Cheers,
Jean-Michel
On Fri, Jul 08, 2016 at 09:18:34AM +0200, Martin Losch wrote:
> Hi Jean-Michel,
>
> I repeated the run with startDate2 = 000000 and still get 13 files
> diag2Dm.0000108405.data
> diag2Dm.0000108498.data
> diag2Dm.0000108582.data
> diag2Dm.0000108675.data
> diag2Dm.0000108765.data
> diag2Dm.0000108858.data
> diag2Dm.0000108948.data
> diag2Dm.0000109041.data
> diag2Dm.0000109134.data
> diag2Dm.0000109224.data
> diag2Dm.0000109317.data
> diag2Dm.0000109407.data
> diag2Dm.0000109500.data
>
> The first 108405*28800sec = 3122064000sec now has the time stamp of my timePhase(4) = 3122064000.,
>
> Is this what you expect? I would have expected the first file at timePhase + frequency = (3122064000+31*86400)/28800 = 108498, which is exactly the second file. Or is this extra file diag2Dm.0000108405.data actually the average over the entire simulation until time step 108405 and should be discarded anyway?
>
> Martin
>
> > On 07 Jul 2016, at 17:01, Martin Losch <martin.losch at awi.de> wrote:
> >
> > 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
> >
> >
> > _______________________________________________
> > 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
More information about the MITgcm-devel
mailing list