Hi all:
Im seeing the problem in that file where there are two grib records
that differ only in PDS byte 12 "type
of generating process". i havent seen this before, where that byte
is used to distinguish different variables, i had assumed that field
was metadata describing the generating process.
anyway, i will investigate more and get back to you. if you have any
knowledge if this is really standard practice that would be helpful.
what is RTMA ?
thanks,
John
n 10/8/2010 9:13 AM, David Miller wrote:
You should be able to ftp the following file:
ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/rtma/prod/rtma.20101008/rtma.t00z.2dvaranl_ndfd.grb2
Dave
On 10/8/2010 12:08 PM, David Miller wrote:
John,
Go up a directory to see a listing of the current directories
(the 20101005 is not available). If you click on the 20101008,
you should see a listing of files there.
Dave
On 10/8/2010 12:00 PM, john caron wrote:
im getting a "not found" error on
ftp://ftp.ncep.noaa.gov/pub/data/nccf/com/rtma/prod/rtma.20101005
can you email me a sample file?
On 10/8/2010 8: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/
===============================================================================
|