the latest release(4.2.20101012.2207) should now work on these datasets. let me know
if you see any more problems.
John
On 10/11/2010 9:28 PM, John Caron wrote:
appears that we've confused the GRIB1 "generating process id" (PDS
byte 6), which is metadata, with the GRIB2 "type of generating
process" (PDS byte 12 for most templates), which may be intended
to modify the parameter meaning more directly.
however, i dont have any other examples of this usage (same PDS
differing only by generating process type) in my sample GRIB2
data. i am continuing to investigate.
On 10/8/2010 9:01 AM, Robb Kambic wrote:
Hi Steve,
Thanks for reporting the problem, it will be on the list of Grib
problems to fix. For future reference, I'm no longer working on
the Grib library but included the Grib library developer in this
response.
Robb...
On Thu, 7 Oct 2010, Steve Ansari wrote:
Hi David, Jack,
I've cc-ed Robb at Unidata who I believe is the lead GRIB guy.
Robb - see below - we have having issues reading some RTMA
GRIB files.
Thanks!
Steve
David Miller wrote:
Steve,
The only thing I can think of is that the Java API may be
getting
confused between the Dewpoint temperature and the Dewpoint
temperature
error that are both in the file. There's a subtle
difference that
distinguishes the two and that is the generation process,
which is
contained in GRIB2 template 4.0, Table 4.3, Octet 12. The
parameter
category is still the same (template 4.0, table 4.2-0-0,
Octet 11),
and that's 6 - Dew point Temperature. Here is the first
table I'm
referring to.
http://www.nco.ncep.noaa.gov/pmb/docs/grib2/grib2_table4-3.shtml
I see from what you gave in ncdump that this generation
process isn't
mentioned. For regular dew point grids, it is 6 but for
error
analysis it is 7. So, if the Java API isn't expecting to
deal with
this within the file, it may be getting confused here
because it can't
distinguish between the two.
The MDL degribber handles this okay, BTW. So must be
something in the
Java API and may be related to what I just stated.
The error grids are not contained in the 2dvarges grids and
this is
perhaps another indication that the error grids are causing
the
problem in the 2dvaranl grids.
Dave
On 10/6/2010 5:45 PM, Steve Ansari wrote:
Hi Dave, Jack,
I've been trying to debug the RTMA problems and I'm
running into some
trouble.
I'm using the NetCDF for Java API, which supports GRIB1
and GRIB2.
However, I'm getting errors reading the actual files and
it seems
that the API is getting lost somewhere inside the file. I
updated my
NetCDF for Java version to the new stable 4.2 release,
this seems to
have solved the errors. However, the invalid dew point
temperatures
still exist for the 2dvaranl files. The '2dvarges' files
seem to be ok.
I'm attaching the 'ncdump' below which should show some of
the GRIB
parameters. I'm working with the current files available
on:
ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/rtma/prod/rtma.20101005
I'm not sure what to make of this. I don't think there is
much else
I can do on my end to configure the GRIB decoders, but
feedback can
be given to Unidata, who develop and maintain the API.
Thanks,
Steve
rtma.t23z.2dvaranl_ndfd.grb2:
float Dew_point_temperature(time=1,
height_above_ground1=1, y=689,
x=1073);
:units = "K";
:long_name = "Dew_point_temperature @
height_above_ground";
:missing_value = NaNf; // float
:grid_mapping = "Lambert_Conformal";
:GRIB_param_discipline = "Meteorological_products";
:GRIB_param_category = "Temperature";
:GRIB_param_name = "Dew_point_temperature";
:GRIB_param_id = 2, 0, 0, 6; // int
:GRIB_product_definition_template = 0; // int
:GRIB_product_definition_template_desc =
"Analysis/forecast at
horizontal level/layer at a point in time";
:GRIB_level_type = 103; // int
:GRIB_level_type_name = "height_above_ground";
:GRIB_VectorComponentFlag = "gridRelative";
rtma.t23z.2dvarges_ndfd.grb2:
float Dew_point_temperature(time=1,
height_above_ground1=1, y=689,
x=1073);
:units = "K";
:long_name = "Dew_point_temperature @
height_above_ground";
:missing_value = NaNf; // float
:grid_mapping = "Lambert_Conformal";
:GRIB_param_discipline = "Meteorological_products";
:GRIB_param_category = "Temperature";
:GRIB_param_name = "Dew_point_temperature";
:GRIB_param_id = 2, 0, 0, 6; // int
:GRIB_product_definition_template = 0; // int
:GRIB_product_definition_template_desc =
"Analysis/forecast at
horizontal level/layer at a point in time";
:GRIB_level_type = 103; // int
:GRIB_level_type_name = "height_above_ground";
:GRIB_VectorComponentFlag = "gridRelative";
Jack Settelmaier wrote:
Dave,
I just popped open a new instance of the W&CT and
pointed to the
RTMA data directory, and this time I got no errors ( I
think the
errors that popped up earlier were cache errors, and it
still
displayed after that “warning”), and a pop-up window
immediately
showed me the available fields, time steps, etc., to
select to
display so I’m guessing we just hit a burp when we
tested this
earlier, and this functionality to reveal the fields and
time steps
in the GRIB file exists. I’ll retry your LAMP data file
next and
paste below this image; actually I’ll put that in the
next email, to
save from having too much in one email shipment.
Unfortunately, what I’m seeing in this 1^st screen
capture, Steve,
is that I’m supposedly displaying RTMA Dewpoint from
12UTC this
morning (you can see the place/file I’m pointing to),
but yet the
units displayed in the legend, and apparently, to my
eye, what is
displayed in the image is not observed dewpoint, but
perhaps more
likely the dewpoint uncertainty field.
Now that I think about I, these RTMA Analysis files
contain both the
observed field and the uncertainty in the observation,
and my guess
is, in the GRIB, they don’t properly distinguish between
those two
different fields, hence your code only shows me one of
them (likely
the uncertainty) in the field listing.
In fact, in using deGRIB on this RTMA file, you can see
the
differing short and long name fields in the GRIB file,
but my guess
is, Steve, your code only looks at some other “column”
of
information and can’t distinguish between short names
TMP and
TMPERR, and only lists the latter listing (errors) in
your list.
Can you take a look at this and see if this is a bug in
your code,
or bad coding on behalf of these GRIB creators?
BTW, Steve, Dave Miller and I will be working together
on some of
his GRIB data (see next email), and we expect to use
your Beta code
and feedback things we find to you. I honestly haven’t
toyed with
your code since I was more on this back in the spring
and early
summer. But Dave has reinvigorated me to explore your
command line
functionality for potential automated KML/KMZ creation.
I can’t
recall if this functionality is expected to work from
the command
line or not.
Thanks for any comments you can provide on what I’ve
described here,
and command line functionality and KML/KMZ expectations.
--
Steve Ansari
Physical Scientist
NOAA's National Climatic Data Center
Veach-Baley Federal Building
151 Patton Avenue
Asheville, NC 28801
Ph: 828-271-4611
Fax: 828-271-4328
--
Steve Ansari
Physical Scientist
NOAA's National Climatic Data Center
Veach-Baley Federal Building
151 Patton Avenue
Asheville, NC 28801
Ph: 828-271-4611
Fax: 828-271-4328
===============================================================================
Robb Kambic Unidata Program Center
Software Engineer III Univ. Corp for Atmospheric
Research
http://www.unidata.ucar.edu/
===============================================================================
|
