[MITgcm-devel] calendar checkdate

[Martin Losch]

Hi Jean-Michel,

for me it turns out that I have to explicitly set xx_${ctrlvar}startdate1/2 for each of the ctrl variables that I use, even if the xx_${ctrlvar}period = 0, to make the model runs. This was my suspicion anyway for all the warnings of this type:
(PID.TID 0000.0001) *** ERROR *** cal_CheckDate: Calendar date before predef. reference date
that I used to get, I just never bothered to check, because in these experiments the ctrl variables are contant in time (period=0). 
All of these errors occur in ctrl_init.F, specifically in S/R CTRL_INIT_REC that I once introduced in an attempt to make S/R CTRL_INIT shorter. I will add code (basically print the name of the ctrl variable before cal_fulldate is called) to make it easier to track down which variable is the culprit.

Martin

On Apr 10, 2012, at 9:40 PM, Jean-Michel Campin wrote:

> Hi Martin and others,
> 
> One thing that would be nice, when you have time, would be to check
> that you can run your set-up with the current code, with the stops that 
> I already added (which I think are necessary); and at the same time, try 
> to record the warnings you get from cal_CheckDate, such as:
>> cal_CheckDate: Calendar date before predef. reference date
> so that we can figure out (if you send me the relevant part of the
> set-up, I could take a look) what is really needed in term of check & stop.
> 
> Dimitris, I am not sure this is what you have in mind when you wrote:
>> One question I have is whether it is possible to do the changes that you 
>> have in mind while keeping the user interface, the CPP options and the 
>> runtime parameters unchanged?
> I did not really change the user interface (neither the argument list
> of pkg/cal subroutines, except for the internal initialisation stage),
> but it might help also if you could go through the same check as mentioned 
> above.
> 
> Thanks,
> Jean-Michel
> 
> On Tue, Apr 10, 2012 at 11:14:06AM +0200, Martin Losch wrote:
>> Hi Jean-Michel,
>> 
>> thanks for putting all this effort into cleaning up pkg/cal. Comments below, M.
>> 
>> On Apr 8, 2012, at 10:52 PM, Jean-Michel Campin wrote:
>> 
>>> Hi,
>>> 
>>> I made some changes in the way CAL_CHECKDATE works: 
>>> - in cal_fulldate.F (currently the only routine which calls CAL_CHECKDATE) 
>>> always stop if CAL_CHECKDATE returns valid=F (fatal error).
>>> - and only the most serious errors in CAL_CHECKDATE switch "valid" to F.
>>> I also added a stop for invalid month index (this was a frequent 
>>> source of access to out-of-bounds array), change the valid weekday
>>> to be less or equal to 7 (was 8 before), and (with warning only) check 
>>> separately for validity of the 3 pieces of date(2) (=hhmmss).
>>> 
>>> I would like also change the warning to a stop when date(1) < refDate(1) 
>>> (i.e., date before the reference date), since this causes a problem 
>>> when finding the day of the week (in cal_fulldate.F, I disabled this part).
>> (without irony:) This will be problematic for a few of my set ups where I always get this error message, probably in connections with data.ctrl, but because the errors used to be so difficult to track down, I often did not bother to do so. I am looking forward to having cleaned up namelists although the process will be a little painful. I assume that others will have similar problems. Again, it's good that I am finally forced to do this so go ahead an do it.
>>> And have 2 questions:
>>> 1) Does someone knows why the stop (in cal_fulldate.F) was commented out 
>>> in v.1.3 (Apr 19, 2004), to just give a warning when CAL_CHECKDATE detects
>>> an error ? Martin made this modification (but it's not very recent).
>> I guess I introduced code to actually use the flag "valid", but I did not want to disrupt anyone's working set-up.
>>> 2) negative date seems to be a problem (equivalent to a date before 
>>> reference date when TheCalendar='model'), e.g. in cal_timepassed.F. 
>>> So if we decide not to stop when date(1) < refDate(1), I would propose 
>>> at least to stop when the date is negative.
>>> 
>>> Cheers,
>>> Jean-Michel
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> 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