Re: ut_calendar and negative times

From: Dave Allured <dave.allured_at_nyahnyahspammersnyahnyah>
Date: Tue Jan 19 2010 - 21:14:40 MST

For what it's worth, testing etc., here is an alternate version of
ut_calendar which supports several model calendars. It seems to
handle Ian's case and other negative times correctly.

http://www.esrl.noaa.gov/psd/people/dave.allured/data/ncl/lib/calendar_decode2.ncl

I recently added support for the various ut_calendar output options,
with some limitations. There are two required subroutines in the
same web directory.

Dave Allured
CU/CIRES Climate Diagnostics Center (CDC)
http://cires.colorado.edu/science/centers/cdc/
NOAA/ESRL/PSD, Climate Analysis Branch (CAB)
http://www.esrl.noaa.gov/psd/psd1/

Mary Haley wrote:
> Jamie and Harry,
>
> I'll look into this. We've had some other problems with ut_calendar and
> the 360, 365, etc type of calendars. I just received a new version of
> this code 2 days ago which I'm trying to get it to work under Udunits-2.
> I'll check if it fixes this problem.
>
> --Mary
>
> On Jan 13, 2010, at 11:46 AM, Jamie Scott wrote:
>
>> I think this may be a bug. I tried the following on two platforms and
>> got two different answers:
>>
>> mytime=-39615.
>> mytime@units="days since 1970-01-01 00:00:0"
>> mytime@calendar="360_day"
>> date = ut_calendar(mytime,-1)
>> print(date)
>>
>> On my intel Mac running v5.1.1, the answer result is:
>>
>> Variable: date
>> Type: integer
>> Total Size: 4 bytes
>> 1 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [1]
>> Coordinates:
>> Number Of Attributes: 1
>> calendar : 360_day
>> (0) 172201
>>
>>
>> On an intel machine running 64bit r ed hat l swer is:
>>
>> Variable: date
>> Type: integer
>> Total Size: 4 bytes
>> 1 values
>> Number of Dimensions: 1
>> Dimensions and sizes: [1]
>> Coordinates:
>> Number Of Attributes: 1
>> calendar : 360_day
>> (0) 185912
>>
>>
>>
>> On Jan 13, 2010, at 11:10 AM, ncl-talk-request@ucar.edu
>> <mailto:ncl-talk-request@ucar.edu> wrote:
>>
>>> Date: Wed, 13 Jan 2010 18:09:44 +0000
>>> From: Ian Harris <i.harr ubject: [ncl-talk] ut_calendar and negative
>>> times
>>> To: NCL_Talk < <mailto:i.harris@uea.ac.uk >ncl-talk@ucar.edu
>>> <mailto:ncl-talk@ucar.edu>>
>>> Message-ID: <23F9075B-54BA-4ADB-90D3-5BED56FCCA2D@uea.ac.uk
>>> <mailto:23F9075B-54BA-4ADB-90D3-5BED56FCCA2D@uea.ac.uk>>
>>> Content-Type: text/plain; charset=us-ascii
>>>
>>> Hi,
>>>
>>> Leaving my 64-bit issues aside for the moment and returning to my
>>> trusty G5 Mac, still running NCL 5.1.1 though.
>>>
>>> I've found what may be a bug in ut_calendar (or may be my idiocy of
>>> course).
>>>
>>> I found that when it encountered negative values in the time field,
>>> it gave false results.
>>>
>>> Here is an example.
>>>
>>> We have a monthly 'time' variable, the first element and attributes
>>> are as follows:
>>>
>>> ncl 6> print (time(0))
>>>
>>>
>>> Variable: time (subsection)
>>> Type: float
>>> Total Size: 4 bytes
>>> 1 values
>>> Number of Dimensions: 1
>>> Dimensi ons and >Coordinates:
>>> Number Of Attributes: 5
>>> time : -39615
>>> axis : T
>>> calendar : 360_day
>>> units : days since 1970-01-01 00:00:0
>>> long_name : Time
>>> (0) -39615
>>>
>>> So we see it's 360 day years (that's not unusual for climate model
>>> work). The reference day is Jan 1st 1970, and the first time point is
>>> -39615.
>>>
>>> Remember it's monthly data, that's why the number ends in '15'
>>> (months are usually represented by a day roughly in the middle of the
>>> month).
>>>
>>> If you examine -39615, it turns out to be 110 years and 15 days (in
>>> 360-day years). So the first datum represents Jan 15th 1860, or
>>> 'January 1860', which is as expected.
>>>
>>> But what happens when we give ut_calendar this?
>>>
>>> ncl 9> date = ut_calendar(ti me(0),-1 rted-space">
>>> ncl 10> print(date)
>>>
>>>
>>> Variable: date
>>> Type: integer
>>> Total Size: 4 bytes
>>> 1 values
>>> Number of Dimensions: 1
>>> Dimensions and sizes: [1]
>>> Coordinates:
>>> Number Of Attributes: 1
>>> calendar : 360_day
>>> (0) 172201
>>>
>>> The date returned is January 1722.
>>>
>>>
>>> So, is this a known problem? Or have UKMO crash-tested ut_calendar
>>> with their archiving of the HadGEM model output?
>>
>> _______________________________________________
>> 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
_______________________________________________
ncl-talk mailing list
List instructions, subscriber options, unsubscribe:
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Tue Jan 19 21:14:46 2010

This archive was generated by hypermail 2.1.8 : Thu Feb 18 2010 - 10:33:29 MST