[ncl-talk] A bug of use cd_calendar , second = 60

Tue Feb 21 16:58:23 MST 2017

Mary,

Attached is the test script that I used to reproduce Xiaobin's original
results with NCL 6.3.0.  Please comment out the addition of 0.01 seconds to
see the original behavior with the 60 seconds bug.  I think this should
work the same for you as for me.  Look at the output labeled "TEST1.1" and
ignore the rest.

Note that it was important to add "d" suffixes inside the array constructor.

--Dave

On Tue, Feb 21, 2017 at 4:33 PM, Mary Haley <haley at ucar.edu> wrote:

> Xiaobin,
>
> As Dave said, we should have a potential fix for this in the next release,
> but I wanted to test this first.
>
> I can't quite seem to reproduce the same results as you.  Could you write
> the time array to a netCDF file and send to to me? You should be able to
> just temporarily add these two lines of code:
>
> fout = addfile("marytime.nc","c")
> fout->time = time
>
> and then send me the "marytime.nc" file.
>
> Thanks!
>
> --Mary
>
>
> On Sun, Feb 19, 2017 at 3:14 PM, Dave Allured - NOAA Affiliate <
> dave.allured at noaa.gov> wrote:
>
>> Xiaobin,
>>
>> There is a known bug in the cd_calendar function in NCL version 6.3.0.
>> For time values that are extremely close to 0 or 60 seconds, the function
>> sometimes outputs 60 seconds, and fails to increment the number of
>> minutes.  Notice in your original message, some of the output values for
>> minutes were incorrect, as well as values for seconds.  This bug should
>> be fixed in the next NCL release.
>>
>> In the meantime, you may be able to avoid the bug by adding a small
>> fraction of one minute to your time values.  This should work because it
>> seems like your intended values are even minutes with zero seconds:
>>
>>   time(:) = time(:) + (0.01 / 3600)     ; add 0.01 seconds to "hours
>> since..."
>>   print (sprintf ("%24.11f", time))
>>
>> (0)     3615141.00000277767
>> (1)     3615141.08333611069
>> (2)     3615141.16666944465
>> (3)     3615141.25000277767
>> (4)     3615141.33333611069
>> (5)     3615141.41666944465
>> (6)     3615141.50000277767
>> (7)     3615141.58333611069
>> (8)     3615141.66666944465
>> (9)     3615141.75000277767
>> (10)    3615141.83333611069
>> (11)    3615141.91666944465
>> (12)    3615142.00000277767
>> (13)    3615142.08333611069
>> (14)    3615142.16666944465
>> (15)    3615142.25000277767
>>
>> Now your code to compute hours, minutes, seconds, etc. with cd_calendar
>> seems to work okay.  When you use "tointeger", the extra 0.01 seconds is
>> removed safely:
>>
>> second = tointeger (utc_date(:,5))
>> etc.
>>
>>   print (date_str)
>>
>> (0) 2013_05_31_21_00_00
>> (1) 2013_05_31_21_05_00
>> (2) 2013_05_31_21_10_00
>> (3) 2013_05_31_21_15_00
>> (4) 2013_05_31_21_20_00
>> (5) 2013_05_31_21_25_00
>> (6) 2013_05_31_21_30_00
>> (7) 2013_05_31_21_35_00
>> (8) 2013_05_31_21_40_00
>> (9) 2013_05_31_21_45_00
>> (10) 2013_05_31_21_50_00
>> (11) 2013_05_31_21_55_00
>> (12) 2013_05_31_22_00_00
>> (13) 2013_05_31_22_05_00
>> (14) 2013_05_31_22_10_00
>> (15) 2013_05_31_22_15_00
>>
>> Please check all output values to make sure this fix works for all cases
>> in your data.
>>
>> --Dave
>>
>>
>> On Sun, Feb 19, 2017 at 1:55 AM, qiuxiaobin.tj <qiuxiaobin.tj at qq.com>
>> wrote:
>>
>>> *Dear all*
>>>
>>> *I met a bug when use cd_calendar. Some times it return second = 60.*
>>> *Here is the input time:*
>>> Variable: time
>>> Type: double
>>> Total Size: 680 bytes
>>>             85 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [time | 85]
>>> Coordinates:
>>> Number Of Attributes: 3
>>>   _FillValue : 9.969209968386869e+36
>>>   calendar : gregorian
>>>   units : hours since 1601-01-01 00:00:0.0
>>> (0) 3615141
>>> (1) 3615141.083333333
>>> (2) 3615141.166666667
>>> (3) 3615141.25
>>> (4) 3615141.333333333
>>> (5) 3615141.416666667
>>> (6) 3615141.5
>>> (7) 3615141.583333333
>>> (8) 3615141.666666667
>>> (9) 3615141.75
>>> (10) 3615141.833333333
>>> (11) 3615141.916666667
>>> (12) 3615142
>>> (13) 3615142.083333333
>>> (14) 3615142.166666667
>>> (15) 3615142.25
>>> ..............
>>>
>>> *Here is the scripts:*
>>>
>>> utc_date = cd_calendar(time, 0)
>>> ;
>>> ; Store return information into more meaningful variables.
>>> ;
>>> year   = tointeger(utc_date(:,0))    ; Convert to integer for
>>> month  = tointeger(utc_date(:,1))    ; use sprinti
>>> day    = tointeger(utc_date(:,2))
>>> hour   = tointeger(utc_date(:,3))
>>> minute = tointeger(utc_date(:,4))
>>> second = tointeger(utc_date(:,5))
>>>
>>> ; Write out strings in the format "hhZ dd mmm yyyy".
>>>
>>> date_str = sprinti("%0.4i",year) + "_" + sprinti("%0.2i",month) + "_" +
>>> sprinti("%0.2i",day) + "_" + sprinti("%0.2i",hour) + "_" +
>>> sprinti("%0.2i",minute) + "_" + sprinti("%0.2i",second)
>>>
>>> print(date_str)
>>>
>>> *Here is the output:*
>>> Variable: date_str
>>> Type: string
>>> Total Size: 680 bytes
>>>             85 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [85]
>>> Coordinates:
>>> (0) 2013_05_31_21_00_00
>>> (1) 2013_05_31_21_05_00
>>> (2) 2013_05_31_21_*09_60*
>>> (3) 2013_05_31_21_15_00
>>> (4) 2013_05_31_21_20_00
>>> (5) 2013_05_31_21_*24_60*
>>> (6) 2013_05_31_21_30_00
>>> (7) 2013_05_31_21_35_00
>>> (8) 2013_05_31_21_*39_60*
>>> (9) 2013_05_31_21_45_00
>>> (10) 2013_05_31_21_50_00
>>> (11) 2013_05_31_21_*54_60*
>>> (12) 2013_05_31_22_00_00
>>> (13) 2013_05_31_22_05_00
>>> (14) 2013_05_31_22_*09_60*
>>> (15) 2013_05_31_22_15_00
>>>
>>> *How to overcome this? Thanks a lot.*
>>>
>>> *Best,*
>>> *Xiaobin*
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20170221/c737ed2e/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.ncl
Type: application/octet-stream
Size: 2765 bytes
Desc: not available
Url : http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20170221/c737ed2e/attachment.obj 