Re: cd_calendar with 360_day calendar

From: Ufuk Utku Turuncoglu (BE) <u.utku.turuncoglu_at_nyahnyahspammersnyahnyah>
Date: Tue Aug 27 2013 - 13:09:24 MDT

Thanks for your help. After upgrading, the problem solved.

Regards,

--ufuk

On 8/27/13 7:39 PM, Dave Allured - NOAA Affiliate wrote:
> Ufuk,
>
> If you do not want to upgrade, then try the calendar_decode2 function
> in place of cd_calendar. The function arguments are the same.
>
> I noticed that in NCL 6.1.2, there was a change to cd_calendar that
> seems to have fixed the symptom that you reported.
>
> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/calendar_decode2.ncl"
>
> begin
> time = (/ \
> 564537600.00d, 564624000.00d, 564710400.00d, 564796800.00d, \
> 564883200.00d, 564969600.00d, 565056000.00d, 565142400.00d, \
> 565228800.00d, 565315200.00d, 595382400.00d, 595468800.00d, \
> 595555200.00d, 595641600.00d, 595728000.00d, 595814400.00d, \
> 595900800.00d, 595987200.00d, 596073600.00d, 596160000.00d, \
> 596246400.00d, 596332800.00d, 596419200.00d, 596505600.00d, \
> 596592000.00d, 596678400.00d /)
>
> time@units = "seconds since 0001-01-01 00:00:00"
> time@calendar = "360_day"
>
> opt = 4
> ; yf1 = cd_calendar (time, opt)
> yf1 = calendar_decode2 (time, opt)
>
> nt = dimsizes (yf1)
> df = new (nt, double)
> df(0) = -99
> df(1:) = yf1(1:) - yf1(0:nt-2)
>
> print (sprintf ("%14.2f", time) + sprintf ("%10.3f", yf1) \
> + sprintf ("%12.5f", df))
> end
>
> Output:
> NCAR Command Language Version 6.1.0-beta
> (0) 564537600.00 19.150 -99.00000
> (1) 564624000.00 19.153 0.00278
> (2) 564710400.00 19.156 0.00278
> (3) 564796800.00 19.158 0.00278
> (4) 564883200.00 19.161 0.00278
> (5) 564969600.00 19.164 0.00278
> (6) 565056000.00 19.167 0.00278
> (7) 565142400.00 19.169 0.00278
> (8) 565228800.00 19.172 0.00278
> (9) 565315200.00 19.175 0.00278
> (10) 595382400.00 20.142 0.96667
> (11) 595468800.00 20.144 0.00278
> (12) 595555200.00 20.147 0.00278
> (13) 595641600.00 20.150 0.00278
> (14) 595728000.00 20.153 0.00278
> (15) 595814400.00 20.156 0.00278
> (16) 595900800.00 20.158 0.00278
> (17) 595987200.00 20.161 0.00278
> (18) 596073600.00 20.164 0.00278
> (19) 596160000.00 20.167 0.00278
> (20) 596246400.00 20.169 0.00278
> (21) 596332800.00 20.172 0.00278
> (22) 596419200.00 20.175 0.00278
> (23) 596505600.00 20.178 0.00278
> (24) 596592000.00 20.181 0.00278
> (25) 596678400.00 20.183 0.00278
>
> --Dave
>
> On Tue, Aug 27, 2013 at 9:03 AM, Ufuk Utku Turuncoglu (BE)
> <u.utku.turuncoglu@be.itu.edu.tr> wrote:
>> Hi Mary,
>>
>> I am using 6.1.0-beta. So, i have to upgrade the version to solve this
>> problem. Right?
>>
>> --ufuk
>>
>> On 8/27/13 4:47 PM, Mary Haley wrote:
>>> Hi Ufuk,
>>>
>>> I was able to reproduce the problem using V6.0.0 of NCL, but not with V6.1.0 or V6.1.2.
>>>
>>> I believe that V6.0.0 of cd_calendar may not have recognized this particular calendar.
>>>
>>> Which version are you using?
>>>
>>> Here was my little test:
>>>
>>> time = (/ 564537600.00, 564624000.00, 564710400.00, 564796800.00, \
>>> 564883200.00, 564969600.00, 565056000.00, 565142400.00, \
>>> 565228800.00, 565315200.00/)
>>> time@units = "seconds since 0001-01-01 00:00:00"
>>> time@calendar ="360_day"
>>>
>>> t = cd_calendar(time,4)
>>> print(t)
>>>
>>> And got:
>>>
>>> Variable: t
>>> Type: double
>>> Total Size: 80 bytes
>>> 10 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [10]
>>> Coordinates:
>>> Number Of Attributes: 1
>>> calendar : 360_day
>>> (0) 19.15
>>> (1) 19.15277777777778
>>> (2) 19.15555555555556
>>> (3) 19.15833333333333
>>> (4) 19.16111111111111
>>> (5) 19.16388888888889
>>> (6) 19.16666666666667
>>> (7) 19.16944444444444
>>> (8) 19.17222222222222
>>> (9) 19.175
>>> --Mary
>>>
>>> On Aug 27, 2013, at 5:17 AM, Ufuk Utku Turuncoglu (BE) wrote:
>>>
>>>> Hi,
>>>>
>>>> I am getting some strange results from the cd_calendar if i use a time array with following attributes
>>>>
>>>> long_name : time since initialization
>>>> units : seconds since 0001-01-01 00:00:00
>>>> calendar : 360_day
>>>> field : time, scalar, series
>>>>
>>>> in this case the function gives wrong results for 30th of February. It calculates zero for the fraction of the year. The simple output of the time array vs. fraction of year can be found as follows,
>>>>
>>>> ind time fraction
>>>> of year
>>>> ....
>>>> ....
>>>> (0) 1494 564537600.00 19.151
>>>> (0) 1495 564624000.00 19.153
>>>> (0) 1496 564710400.00 19.156
>>>> (0) 1497 564796800.00 19.159
>>>> (0) 1498 564883200.00 19.000
>>>> (0) 1499 564969600.00 19.000
>>>> (0) 1500 565056000.00 19.162
>>>> (0) 1501 565142400.00 19.164
>>>> (0) 1502 565228800.00 19.167
>>>> (0) 1503 565315200.00 19.170
>>>> ....
>>>> ....
>>>> (0) 1851 595382400.00 20.142
>>>> (0) 1852 595468800.00 20.145
>>>> (0) 1853 595555200.00 20.148
>>>> (0) 1854 595641600.00 20.150
>>>> (0) 1855 595728000.00 20.153
>>>> (0) 1856 595814400.00 20.156
>>>> (0) 1857 595900800.00 20.158
>>>> (0) 1858 595987200.00 20.161
>>>> (0) 1859 596073600.00 20.000
>>>> (0) 1860 596160000.00 20.164
>>>> (0) 1861 596246400.00 20.167
>>>> (0) 1862 596332800.00 20.169
>>>> (0) 1863 596419200.00 20.172
>>>> (0) 1864 596505600.00 20.175
>>>> (0) 1865 596592000.00 20.178
>>>> (0) 1866 596678400.00 20.180
>>>> ....
>>>> ....
>>>>
>>>> I just wonder that is there anybody face this kind of problem before? There might be a bug in the function.
>>>>
>>>> Best regards,
>>>>
>>>> --ufuk

_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Tue Aug 27 13:09:45 2013

This archive was generated by hypermail 2.1.8 : Fri Aug 30 2013 - 14:04:57 MDT