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

20010620: GRIB decoder for McIDAS (cont.)

>From: Bill Fingerhut <address@hidden>
>Organization: Lyndon State
>Keywords: 200106111555.f5BFtJp07220 McIDAS XCD gribdec


>I did not get back to you sooner because its summer, and I
>am not in every day. Not to say I don't work every day; I
>just don't come in to LSC every day.

OK.  I have been working on my house, so I have not been here 100%

>I downloaded gribdec.tar.Z from the unix/760/testcode 
>directory, not unix/770, because we are still running
>McIDAS 7.6 . Okay ???

Yup.  The package is the same.

>The build went okay.
>I grabbed a test data file from the server, from
>wxp/models, named 01062001_ruc.grib ,
>which was received thru the ldm. 

OK.  RUC decoding should work.

>And from ~fingerhutb/mcidas/data I ran 
>../bin/gribdec.k 01062001_ruc.grib 2005 .
>Grids were created, 
>as shown by igg.k LIST GRIDF=2001,
>with reasonable day, hour, parameter...
>but not in gridfile 2005 aka file GRID2005. Instead they
>appeared in GRID2001. Not what I expected ???

What gribdec.k does is use the base number you specify and then change
the last digit to match the last digit of the Julian day of the data.

>I continued to try one of my archived 'grib files', but
>could not find any McIDAS grids. So, I backed up to the
>begining. The file I tried is named 'YOQA20.12'; so, I see
>that the format of the 'file name' is different.
>Is this okay ???

The file name should have nothing to do with gribdec.k working with the
exception that the file name (including any directory) must be less
than or equal to 80 characters (I just read the code in gribdec.pgm).

>Next, I peeked at the contents of the file. 
>   head -4 YOQA20.12 
>   739
>   YOQA20 KWBE 011200
>   GRIB ...
>   head -4 01062001_ruc.grib
>   982 
>   YOQA20 KWBC 200100
>   GRIBUEVeR5TUUVugffg  ...
>The first line is different; apparently blank in 
>01062001_ruc.grib ???

This shouldn't matter since the code in the McIDAS grib decoder reads
in characters until 'G', 'R', 'I', and then 'B' are found.  It then
knows that it has found the beginning of a GRIB message.  I till continue
to read data as part of the GRIB message until 7777 is found.

>The messages come from 2 different sources, KWBE and KWBC ???

This shouldn't make a difference.

>The date fields are different ???


>The 3rd line in YOQA20.12 looks garbled (lots of extended
>characters) after "GRIB" ???

Your output seems to indicate that the third line from >   head -4 01062001_ruc
has lots of extended characters.

>So, what would you conclude ???

Try running the exact same invocation but specifying that you want debug

../bin/gribdec.k YOQA20.12 2005 DEB=15 DEV=CCC

It is possible that the grib file you have is one that is not supported
by McIDAS decoding.  What is the GRIB file supposed to contain?  Is it
possible for me to grab a copy of it?  You could ftp the file to
ftp.unidata.ucar.edu using the passworded McIDAS-X user name and
password and put the file in the incoming/data directory.  If you
decide to do this, make sure to FTP the file in binary mode.  I would
then take a closer look at the file here at the UPC (or at home on my
Linux box).


>From address@hidden Mon Jun 25 08:36:50 2001
>Subject: Re: 20010620: GRIB decoder for McIDAS (cont.)


I reran the gribdec command *with debug info*, and everything
looks good (:-) Last time, I could not find the output grid so
I asked for your help. The debug info tells me where the output
went, so I could find it etc. I contoured the output grid
and it seems reasonable.

Thanks, Bill

< Bill Fingerhut, Professor              PHONE: 802-626-6257 >
< Meteorology Dept                       FAX:   802-626-9770 >
< Lyndon State College                                       >
< Lyndonville, Vt 05851                                      >
<                                                            >
< EMAIL:     address@hidden                     >
<            address@hidden                     >
< WWW:       http://apollo.lsc.vsc.edu/                      >
<                                                            >
< disclaimer: I know nothing - I only work here.             >

NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.