Change in GRIB file option defaults

From: David Ian Brown <dbrown_at_nyahnyahspammersnyahnyah>
Date: Wed, 7 Feb 2007 16:49:32 -0700

Hi all,

We are soon going to be releasing a new version of NCL with support for
the GRIB 2 file format.
As many of you know, NCEP is currently in transition to GRIB 2. During
the transition period both
GRIB1 and GRIB2 versions of the model output will be available, but
after a 6 month period starting
February 1, at least some of the NCEP data sites will no longer supply
GRIB 1. Our GRIB 2 reader
is also tested and verified to work with data generated for the TIGGE
project, a WMO-sponsored
international collaboration for sharing and archiving ensemble
forecasts (see http://tigge.ecmwf.int or
http://tigge.ucar.edu).

In anticipation of this transition, we are considering changing the
default values of two of the
GRIB file options (these are options that may be set using the
procedure 'setfileoption').
To avoid confusion, we would like to keep the option defaults the same
for both versions of GRIB.

First, as proved by testing performed by Dave Stepaniak of NCAR's Data
Support Section, we have
discovered that the cubic algorithm for expanding thinned
(Quasi-Regular) grids is more accurate than
the linear algorithm that is currently the default. Therefore we are
planning to change the default value
of the file option, "ThinnedGridInterpolation" from "Linear" to
"Cubic". A caveat is that "Cubic" is not
available for grids that have a bit map mask -- generally grids where
there is valid data only over land
or only over water. In this case the "Linear" option is used regardless
of the option setting.

Second, we have long realized that it was a mistake to use a
string-type date variable as the coordinate
variable for the 'initial time' dimension in NCL's representation of
GRIB files. They are not compatible
with CF-conventions, they cannot be converted directly to equivalents
in NetCDF (prior to version 4 at
least), and NCL (at least) considers them to lack the monotonicity
property. For these reason, awhile
ago we introduced a file option called "InitialTimeCoordinateType" that
allowed you to set the type
of the coordinate variable to "Numeric". For backwards compatibility we
kept the original "String" type
as the default value of the 'initial time' coordinate. Now, however, we
would like to change the default
to "Numeric". Note that this only changes which of the auxiliary
variables associated with the 'initial time'
coordinate is treated as the coordinate variable. Whatever the setting
of this option there are always
three auxiliary variables created for an 'initial time' coordinate:
(1) the CF-compliant numeric variable,
where time is given (in NCL's case) as a numeric offset in hours since
1800-1-1; (2) the string variable,
a human-readable date string; and (3) an encoded double where the date
is given in the form 'yyyymmddhh.hh_frac'.

We'd like to hear from anyone who would have problems adapting their
code to these changes, or
objects to either of them for any reason.
Thanks,
   -Dave Brown

_______________________________________________
ncl-talk mailing list
ncl-talk_at_ucar.edu
http://mailman.ucar.edu/mailman/listinfo/ncl-talk
Received on Wed Feb 07 2007 - 16:49:32 MST

This archive was generated by hypermail 2.2.0 : Thu Feb 08 2007 - 14:21:36 MST