Re: 19990127: grib to netcdf

• To: Melissa Richey <richeym@xxxxxxxxxxxx>
• Subject: Re: 19990127: grib to netcdf
• From: Robb Kambic <rkambic@xxxxxxxxxxxxxxxx>
• Date: Thu, 4 Mar 1999 15:41:36 -0700 (MST)

Missy,

gribtonc code didn't provide the adequate space to properly read in the
raw data.  The fix is to increase the MAX_GRIB_SIZE to 100000.  I'll
attach the grib1.h to be inserted into the src dir that has the fix.  You
need to do:

% make clean
% make

So the grib1.h file is included properly.

Robb...



On Thu, 4 Mar 1999, Melissa Richey wrote:

Hi Robb-

I know it has been a while, but we are still interested in using this
decoder to convert grib format to netcdf format. We are still having
trouble obtaining the entire water vapor mixing ratio variable. I have
tested it on some other ruc2 files, and continute to get the same
problem. The decoder successfully degribs the last 11 levels of water
vapor mixing ratio, but the first 29 levels give  'oversize GRIB
product' . Right now, we are converting the grib format into a
non-standard format used in only part of our division. This degribber
is able to degrib water vapor mixing ratio, and when I compare the
last 11 levels of wvmr to the ones in the netcdf file, the values are the
same. Becaause our degribber successfully extracts wvmr, that would

seem to imply that the raw grib file is not corrupted.

Although we are already converting grib into a usable format, it is a
format which is soon to become obsolete and no longer supported in our
division. We are interested in using netcdf format because it is a
standard format, widely supported, and is familiar to outside groups
with whom we are working.

Were you able to obtain a ruc2 file or make any more progress in
solving the mystery of water vapor mixing ratio?

Thanks,

Missy

+ + On Thu, 11 Feb 1999, Melissa Richey wrote: + + > + > Hi Robb- + > + > I have been looking at gribtonc using the debugger, so I thought I

+ > would let you know what I have found. I can't figure out why it is
+ > doing what it is doing, but I thought it might mean something to

+ > you... + > + > The function 'get_prod' controls the reading of one grib product into

+ > a buffer. In reading a normal grib product, 'look_for_mark'
+ > successfully finds the start of the product on the first
+ > try. (FOUND_START)
+ > It then successfully fills the rest of the buffer and finds the end of
+ > the product. (FOUND_END)
+ > For the bad mixing ratio product, it first finds the end of the
+ > product, then finds the start, then fills the data buffer before ever
+ > finding the end again, (NOT_FOUND) resulting in "oversize grib
+ > product."

+ + Missy, + + My first impression is that the grid for the water vapor mixing ratio is

+ somehow corrupted or the the grid immediately before is corrupted. Does

+ this happen on all your raw files, I would test it on more than one. + After looking at the code, I wonder if the FOUND header state machine code

+ is parsing correctly wvmixr grid. We don't have a raw ruc2 presently, I
+ should have one tomorrow.  Then I can take a first hand look.

+ + Robb... + + ps Have you tried od (octal dump) on the ruc2 raw file? It could be a

+ sanity check.

+ > + > Just my two cents worth. + > + > Missy + > + > + > + > + Missy, + > + + > + That's what I started to do before I found out about the conflict of 185. + > + The only suggestion I have is to use the brute force method, that is get a

+ > + raw grib file including param 185 and use a debugger on gribtonc. My
+ > + feeling gribtonc is trying to process 185 according to the NWS manner
+ > + instead of the FSL manner.  I'm not the originator of gribtonc and I have
+ > + not added/changed params before, so I would have to research this. I'll
+ > + look at the code today to see if there is something else. Also, as a guide
+ > + line I would look at how the other hybrid ruc2 variables are processed.
+ > + Have you changed the cdl wvmixr variable to match your modified gribtonc?

+ > + + > + Just some thoughts,

+ > + Robb...

+ >

==============================================================================
Robb Kambic                                Unidata Program Center
Software Engineer III                      Univ. Corp for Atmospheric Research
rkambic@xxxxxxxxxxxxxxxx                   WWW: http://www.unidata.ucar.edu/
==============================================================================