Re: [netcdfgroup] Behaviour of ncdump -t option

• To: netcdfgroup@xxxxxxxxxxxxxxxx
• Subject: Re: [netcdfgroup] Behaviour of ncdump -t option
• From: Cathy Smith <cathy.smith@xxxxxxxx>
• Date: Tue, 07 Jun 2011 11:54:42 -0600

Philip

I just ran into this problem this morning with time bounds in one of our
files. In addition to specifying a variable, it would also be nice to be
able to specify an attribute; specifically something like

ncdump -v time:actual_range -t time myfile.nc  (or whatever for syntax;
I'm not picky).

where we have actual_range encoded in udunits. I was told it would be
too hard for ncdump -t to figure out which attributes to decode but if
one could specify the variable on the command line then it doesn't need
to decide.

Cathy Smith
NOAA/ESRL PSD

On 6/7/11 9:48 AM, Bentley, Philip wrote:
>
> Hi folks,
>
> With the 4.x version of ncdump one can use the -t option to request
> output of time data as human-readable date-time strings rather than as
> 'raw' numbers (e.g. days since reference_date).  This works well when
> one is querying a primary time coordinate variable that possesses the
> requisite netCDF attributes, e.g. units and calendar (as shown in the
> CDL snippet below).
>
> But it doesn't work so well for CF-compliant boundary variables (e.g.
> time_bnds in our example) used to specify the cell bounds of
> coordinate variables.  The reason being that such boundary variables
> typically do not replicate the relevant attributes attached to the
> 'parent' coordinate variable.
>
> dimensions:
>         time = UNLIMITED ; // (1800 currently)
>         lat = 216 ;
>         lon = 360 ;
>         bnds = 2 ;
> variables:
>         double time(time) ;
>                 time:bounds = "time_bnds" ;
>                 time:units = "days since 1859-12-01" ;
>                 time:calendar = "360_day" ;
>                 time:axis = "T" ;
>                 time:long_name = "time" ;
>                 time:standard_name = "time" ;
>         double time_bnds(time, bnds) ;
>                 // no attributes
>  
> This shortcoming can readily be overcome by duplicating the units and
> calendar attributes on the time_bnds variable (usng, say, the ncatted
> utility). But one can see that doing this would become a chore after a
> while!
>
> Naturally it wouldn't be right (or would it?) to encode CF rules
> within the base netCDF libraries, so I wonder if there's a case for
> enhancing the -t option in some way such that the user could specify
> the associated variable from which to read requisite attributes. For
> example, the extended command to print out the date-time strings of
> the time_bnds variable might appear thus:
>
> $ ncdump -v time_bnds -t time myfile.nc
>
> Or, if it was necessary to maintain the unadorned -t option for
> backwards compatibility:
>
> $ ncdump -v time_bnds -T time myfile.nc
>
> Any mileage in this suggestion?
>
> Regards,
> Phil
>
>
> _______________________________________________
> netcdfgroup mailing list
> netcdfgroup@xxxxxxxxxxxxxxxx
> For list information or to unsubscribe,  visit: 
> http://www.unidata.ucar.edu/mailing_lists/ 

-- 
----------------------------------------------
NOAA/ESRL PSD and CIRES CDC
303-497-6263
http://www.esrl.noaa.gov/psd/people/cathy.smith/

Emails about data/webpages may get quicker responses from emailing 
esrl.psd.data@xxxxxxxx

• References:
  • [netcdfgroup] Behaviour of ncdump -t option
    • From: Bentley, Philip