Glenn,
NCEP is a big place and some people do a better job of writing grib2
files
than others. There is no grib police to enforce standards. Someone showed
me "Ordered Sequence of Data" once. The first time it is relative to some
frequency. The second time it is relative to a different frequency and
so one.
What are the frequencies? I don't know. I may even be totally wrong;
you have
to consult the developers of the product.
John Caron wrote:
Hi Glenn:
Ive had a look at your files and Im cc'ing Bob Simons for the ERDDAP
perspective and Wesley Ebisuzaki for wgrib POV.
The fields 10-0-87 10-0-8, and 10-0-9 in the file you sent me use
level type 241, which is in the "local table" section of table 4.5.
For Center 7 we use NCEP local tables, and 241 is called "Ordered
Sequence of Data".
GRIB is a collection of 2D records; the CDM tries to put the data back
into 3 (time), 4 (level) or 5 (ensemble) dimensional arrays. So all
records that have the same parameter and level type are placed in one
variable, with a level coordinate variable that distinguishes the
records. From that POV, it looks like the code is doing the right thing.
wgrib2 is an NCEP library
Wgrib2, while written at NCEP, is more of an independent
implementation. Using the "-g2clib 0" option turns
off any use of the NCEP libraries.
that apparently is doing something special with level type 241,
apparently keeping each level in a seperate variable.
Nothing special was done by wgrib2. They are separate grib
message/records with the same metadata. (At least according
to my memory.) I don't think that this is allowed by the grib
standard. To access the file, you have to look for the Nth
occurrence of XYZ. Most grib software won't be able to support the file.
Wesley
There's nothing in the GRIB spec (that I know of) that indicates that,
so theres no way for the CDM to do the same thing without some special
handling. Furthermore, theres nothing I can find in NCEP documentation
that would indicate this kind of special handling. I guess that this
is one of those "you just have to know" cases. Ive cc'ed Wesley in
case he wants to comment on that.
I assume that ERDDAP can handle the "Ordered Sequence of Data" level
coordinate, and you can see both records? If thats the case, Id be
inclined to say that its a different, but equally valid way of
presenting the GRIB data in netCDF.
Regards,
John
On 6/17/2011 5:27 AM, Comiskey, Glenn wrote:
Hi,
Have an issue with publishing GRIB v2 datasets via ERDDAP which my
current understanding is due to a way NetCDF-Java reads GRIB v2 files.
Had set-up a Tomcat v6.0.32/ERDDAP v1.28 server on Windows and run
the GenerateDatasetsXml.bat to generate the XML for inclusion into
datasets.xml. Specified option EDDGridFromNcFiles and pointed it to a
forcast GRIB v2 file with records WIND, WDIR, UGRD, VGRD, HTSGW,
PERPW, DIRPW, WVHGT, SWELL (1 in sequence), SWELL (2 in sequence),
WVPER, SWPER (1 in sequence), SWPER (2 in sequence), WVDIR, SWDIR (1
in sequence), SWDIR (2 in sequence) for every 3 hours 0 - 180 from
reference time. GenerateDatasetsXml.bat, which I understand uses
NetCDF-Java to read the file, recognised the dimensions time, lat,
lon and therefore reported data variables for WIND, WDIR, UGRD, VGRD,
HTSGW, PERPW, DIRPW, WVHGT, WVPER, WVDIR without any problem, but
only reported a single data variable for SWELL (1 in sequence), SWELL
(2 in sequence) and similarly for SWPER and SWDIR (which when
accessing the data via ERDDAP appeared to relate to the "2 in
sequence" record), i.e. it was only possible to access GRIB v2
records SWELL (2 in sequence), SWPER (2 in sequence) and SWDIR (2 in
sequence).
However, having set-up a Tomcat v6.0.32/ERDDAP v1.32 server on
Windows and run GenerateDatasetsXml.bat on the same GRIB v2 file and
selected option EDDGridFromNcFiles it now appears to recognise
dimensions time, ordered_sequence_of_data, lat, lon, and as a result
only reports data variables SWELL, SWPER and SWDIR due to the fact
that they are the only one that share the recognised dimesions -
which is a requirement of ERDDAP.
Given my understanding of how GRIB v2 files are constructed, and how
that data is meant to be interpeted, I am expecting
GenerateDatasetsXml.bat to generate XML entries for three dimensions
(time, lat, lon) and data variables for all 16 records; with SWELL (1
in sequence) and SWELL (2 in sequence) being distinctly seperate data
variables as with SWPER and SWDIR. This is to say that for any given
location (lat, lon) and forcast time, or time period, then SWELL (1
in sequence) and SWELL (2 in sequence) etc. should be reported.
Why is it that NetCDF-Java does not appear to be able to understand
that a GRIB v2 file can have records that have common dimensions and
distinctly seperate data variables that represent that same data type.
Kind regards,
Glenn Comiskey
Data System Administrator
Fugro Global Environment & Ocean Sciences
Fugro House, Hithercroft Road
Wallingford, Oxfordshire OX10 9RB, UK
Registration No: 2985431 / VAT No: GB 655475606
Tel: +44 (0) 1491 820500 (Switchboard) / Tel: +44 (0) 1491 820559
(Direct) / Fax: +44 (0) 1491 820599
E-mail: g.comiskey@xxxxxxxx <mailto:g.comiskey@g.comiskey@xxxxxxxx> /
Website: www.geos.com <http://www.geos.com/>
Please note:
*
The information contained in this message is privileged and
confidential and intended only for the use of the addresses.
If you are not the intended recipient you should not read,
copy, distribute or otherwise use the information;
*
Fugro Global Environment & Ocean Sciences accepts no
responsibility for loss or damage of any kind arising from the
use of this message;
*
If you have received this message in error, please note the
sender immediately and delete the message.
_______________________________________________
netcdf-java mailing list
netcdf-java@xxxxxxxxxxxxxxxx <mailto:netcdf-java@xxxxxxxxxxxxxxxx>
For list information or to unsubscribe, visit: http://www.unidata.ucar.edu/mailing_lists/
