[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NCDC W&CT



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/
===============================================================================