[ncl-talk] Sub: cd_calendar help

dale zuri dalezuri at gmail.com
Sun Oct 8 21:44:14 MDT 2017


Hi ,

Thank you very much!

DZ

On Sun, Oct 8, 2017 at 7:23 PM, Dennis Shea <shea at ucar.edu> wrote:

> See attached
>
> %> ncl rd_tmp2m.ncl
>
> ===
> For GRIB & HDF files, NCL does **not* *create an array dimension of size
> one. A dimension of size one is sometime called a "degenerate dimension."
> NCL does this to make the dimension structure simpler.
>
> Originally, I did not like this behavior. Now, more often than not, I
> consider it a feature of NCL.  :-)
>
> ===
> Please look at the file via:
>
> %> ncl_filedump tmp2m.1995053100.time.grb2  | less
>
> What do you see?
>
> --------------------------------------------------------------------------
> [snip]
>    dimensions:
>
> *      forecast_time0 = 1224   <=== 2400 forecast times*      lat_0 = 190
>       lon_0 = 384
>    variables:
>       float *TMP_P0_L103_GGA0 ( forecast_time0, lat_0, lon_0 )*
>          center :    US National Weather Service - NCEP (WMC)
>          production_status :    Operational products
>          long_name :    Temperature
>          units :    K
>          _FillValue :    1e+20
> [snip]
>          i
> *nitial_time :    05/31/1995 (00:00)   <=== no time info 'lost'*
>
> *
> just returned differently*
> [snip]
>         *integer* forecast_time0 ( forecast_time0 )
>          long_name :    Forecast offset from initial time
>          *units :        hours                            <=====*
> ------------------------------------------------------------
> ----------------------------------
> Now look at:
>
> %> ncl_filedump tmp2m.1995053100.time.grb2  *-itime* | less
>
> [snip]
>    dimensions:
>
> *      initial_time0_hours = 1   <===       forecast_time0 = 1224*
>       lat_0 = 190
>       lon_0 = 384
>
>      float
>
> *TMP_P0_L103_GGA0 ( initial_time0_hours, forecast_time0, lat_0, lon_0 )*
> [snip]
>
> *         double initial_time0_hours ( initial_time0_hours )         *long_name
> :    initial time
> *         units :        hours since 1800-01-01 00:00      *<---
> cd_calendar style
>
>
> *-----------------------------------------------------------------------*
>
> This gives both the initial-time of the forecast & the 2400 forecast
> times. For this application, I prefer that NCL include the degenerate
> dimension. How to do this programmatically?  Our 'friend' ...
>
>
> *setfileoptionhttps://www.ncl.ucar.edu/Document/Functions/Built-in/setfileoption.shtml
> <https://www.ncl.ucar.edu/Document/Functions/Built-in/setfileoption.shtml>*
> See Example 6
>
> -------------------------------------------------------------------
> NOTE:
>
>   (a) initial_time0_hours is type 'double'
>   (b) forecast_time0 is type 'integer'
>   (c) cd_calendar *requires* units such as: "hours/days/minutes/seconds
> since..."
>
> What to do? The attached script contains:
>
>   itime   = tmp&initial_time0_hours  ; hours since 1800-01-01 00:00
>   printVarSummary(itime)               ; typeof(itime)  ="double"
>
>   ftime   = f->forecast_time0       ; Forecast **offset** from (hours)
> initial time
>                                                    ; typeof(ftime)  =
> *"integer*"
>   printVarSummary(ftime)           ; (2400)
>
> If I tried to 'rebase' the forecast times via:
>
>   ftime  *= *itime + ftime           ;  (double + integer)
>
> NCL will not allow because (double + integer)  returns a 'double'.
> However, since ftime is type integer, *NCL which is a strongly typed
> language* default  will not allow the type double right-hand-side to
> overwrite an existing variable of type integer.
>
> How to 'solve'?  Use our other 'best friend', the reassignment operatoe
> *:=*
>
>   ftime  *:= *itime + ftime           ; double *:=* (double +
> integer)
>   ftime at units   = itime at units ; same units as itime but rebased
>
>
> I really like the *:=  *operator. I like the fact that upon seeing the
> syntax, a user is aware that 'something' might change:  size, shape, type,
> etc.  In some other interpreted languages, this is the default behavior.
> IMHO, this can lead to unexpected errors.
>
> -------------------------------------
> Cheers
> D
>
>
> On Sun, Oct 8, 2017 at 7:09 PM, Alan Brammer <abrammer at albany.edu> wrote:
>
>> Forecast time in your file will be hours since simulation started.  e.g.
>> 0,6,12,18.  Without any guidance the cd_ routines will think this is hours
>> since 1979-01-01.
>>
>> I don't want to download a 300MB file just to see if there is another
>> time variable inside, so working with what I can see in the email, you can
>> grab the initialisation date from the file name using cd_inv_string()
>> incldued in 6.4.0 http://www.ncl.ucar.edu/Document/Functions/User_contri
>> buted/cd_inv_string.shtml
>>
>>
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/cd_inv_string.ncl"
>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/cd_string.ncl"
>>
>> fname="tmp2m.2002050100.time.nc"
>> a = addfile(fname, "r")
>> init_time = cd_inv_string(fname, "tmp2m.%Y%N%D%H.time.nc" )
>>
>> ;  Then either add the forecast times to the initial_time, or set the
>> calendar for the forecast times so that it is appropriate.
>>
>> forecast_hours =  a->forecast_time0
>> forecast_hours at units = cd_string(init_time, "hours since %Y-%N-%D %H:%M")
>>
>> total_time = init_time + forecast_hours
>> total_time at units = init_time at units
>>
>>
>>
>> Good luck
>>
>> Alan
>>
>>
>>
>>
>> On Sun, Oct 8, 2017 at 3:48 PM, dale zuri <dalezuri at gmail.com> wrote:
>>
>>> Hi ,
>>> This result is almost similar to cd_calendar result.
>>> (0)    Forecast for 1 Jan. 1979 at 06:00
>>> (1)    Forecast for 1 Jan. 1979 at 12:00
>>> (2)    Forecast for 1 Jan. 1979 at 18:00
>>> (3)    Forecast for 2 Jan. 1979 at 00:00
>>> (4)    Forecast for 2 Jan. 1979 at 06:00
>>> I am confused with 1979 year .
>>> But the initial_time :    05/31/1995 (00:00)
>>>
>>> Thanks
>>>
>>> DZ
>>>
>>> On Sun, Oct 8, 2017 at 11:24 AM, Guido Cioni <guidocioni at gmail.com>
>>> wrote:
>>>
>>>> You need this in your preamble:
>>>> load "$NCARG_ROOT/lib/ncarg/nclscripts/contrib/cd_string.ncl”
>>>>
>>>>
>>>>
>>>> Il giorno 08 ott 2017, alle ore 21:23, dale zuri <dalezuri at gmail.com>
>>>> ha scritto:
>>>>
>>>> Hi ,
>>>> Thanks for your reply. I need to create a time array with the actual
>>>> date associated with each forecast time.
>>>> fatal:Undefined identifier: (cd_string) is undefined, can't continue
>>>> error
>>>> t=cd_string(time, "%H:%M")
>>>>
>>>> DZ
>>>>
>>>> On Sun, Oct 8, 2017 at 9:32 AM, Guido Cioni <guidocioni at gmail.com>
>>>> wrote:
>>>>
>>>>> You should really take a look at the starting guide of NCL and to the
>>>>> documentation of the individual functions before posting questions here.
>>>>>
>>>>> I’ve just checked your file and it seems that the time variable has
>>>>> the right attributes.
>>>>>
>>>>> Something like this should work (NOT TESTED)
>>>>>
>>>>> a=addfile("tmp2m.1995053100.time.grb2","r”)
>>>>> time=a->forecast_time0
>>>>>
>>>>> date_title= "Forecast for "+cd_string(time, "%d %c. %Y")+" at "+
>>>>> cd_string(time, "%H:%M")+" UTC”
>>>>>
>>>>> Cheers
>>>>>
>>>>> Il giorno 08 ott 2017, alle ore 11:40, dale zuri <dalezuri at gmail.com>
>>>>> ha scritto:
>>>>>
>>>>> date = cd_calendar(r, -3)
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> _______________________________________________
>>> ncl-talk mailing list
>>> ncl-talk at ucar.edu
>>> List instructions, subscriber options, unsubscribe:
>>> http://mailman.ucar.edu/mailman/listinfo/ncl-talk
>>>
>>>
>>
>> _______________________________________________
>> ncl-talk mailing list
>> ncl-talk at ucar.edu
>> 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/20171008/43decb25/attachment.html>


More information about the ncl-talk mailing list