[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