[ncl-talk] calendar_decode2: is this a bug?
Dennis Shea
shea at ucar.edu
Wed Nov 19 15:39:02 MST 2014
DaveA is correct. It is best to use "seconds/minutes/hours/days since ...",
cd_calendar is a replacement for ut_calendar.
It supports model calendars.
===========
https://www.ncl.ucar.edu/Document/Functions/Built-in/cd_calendar.shtml
ncl 0> a = 1
ncl 1> a at units = "months since 1600-01-01 00:00:00"
ncl 2> print(cd_calendar(a,0))
Variable: unnamed (return)
Type: float
Total Size: 24 bytes
6 values
Number of Dimensions: 2
Dimensions and sizes: [1] x [6]
Coordinates:
Number Of Attributes: 1
calendar : standard
(0,0) 1600
(0,1) 2
(0,2) 1
(0,3) 0
(0,4) 0
(0,5) 0
On Wed, Nov 19, 2014 at 2:55 PM, Dave Allured - NOAA Affiliate <
dave.allured at noaa.gov> wrote:
> Stefan,
>
> It is not an NCL bug. I would call it a design problem.
>
> Since months in the real calendar have different lengths, a unit
> specification of "months since ..." is ambiguous. Several NCL calendar
> support functions are based on the UDUNITS software package, and UDUNITS
> has chosen a fixed non-integer value for the length a month. This is the
> reason for your odd result values.
>
> Please refer to the ut_calendar function documentation, in the section
> "Caveats of UDUNITS-2", for more details. It starts by saying:
>
> "The length of a month is fixed at 1/12 of a tropical year
> or 2629743.831225 seconds."
>
> This is the same issue for both UDUNITS-1 and UDUNITS-2 versions. I think
> this is also discussed somewhere in UDUNITS original documentation:
>
> http://www.unidata.ucar.edu/software/udunits/
>
> But please notice, this is not really a UDUNITS problem either. In my
> opinion, best practice is to never use variable length base units such as
> month and year. Such usage is dangerous and leads to much user confusion
> and subtle errors. Stick with "days since", "hours since", etc. to avoid
> problems.
>
> There are artificial "model calendars" with fixed length months or years,
> e.g "360_day". Only in these calendar systems does it make sense to use
> "months since" or "years since". HTH.
>
> --Dave A.
> Author of calendar_decode2
>
> On Wed, Nov 19, 2014 at 2:00 PM, Stefan Muthers <ncl at z107.de> wrote:
>
>> Dear all,
>>
>> I have a problem with calendar_decode2 and do not know whether this is a
>> bug or whether I maybe missunderstand something.
>>
>> Consider the following example:
>>
>> --------------------------
>>
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_code.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/gsn_csm.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/csm/contributed.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/calendar_decode2.ncl"
>>
>> a=1
>> a at units = "months since 1600-01-01 00:00:00"
>> printVarSummary(a)
>> ;
>> ;Variable: a
>> ;Type: integer
>> ;Total Size: 4 bytes
>> ; 1 values
>> ;Number of Dimensions: 1
>> ;Dimensions and sizes: [1]
>> ;Coordinates:
>> ;Number Of Attributes: 1
>> ;units : months since 1600-01-01 00:00:00
>>
>> print(""+calendar_decode2(a, -5))
>> ;(0,0) 1600
>> ;(0,1) 1
>> ;(0,2) 31
>> ;(0,3) 10
>> ;(0,4) 29
>> ;(0,5) 3
>>
>> --------------------------
>>
>> I would expect the calendar_decode2 function to return 1600-02-01. Why
>> is 1600-01-31 returned here?
>>
>> thanks you and best regards,
>> Stefan
>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> List instructions, subscriber options, unsubscribe:
>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>
>
>
> _______________________________________________
> ncl-talk mailing list
> List instructions, subscriber options, unsubscribe:
> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ucar.edu/pipermail/ncl-talk/attachments/20141119/383a8a30/attachment.html
More information about the ncl-talk
mailing list