[Met_help] RE: MET FEEDBACK from John Huddleston

[John Huddleston]

John

I finally found out the issue past the programming issues.

The data files that you bundle in the MET data sample_obs prepbufr directory
are 64 bit. I wrote a C program to decipher the NDAS data files.

So, even though I had fixed all the programming bugs and made bufrlib little
endian, there is no provision to read a 64 bit data file. The
http://www.nco.ncep.noaa.gov/pmb/products/gfs/ files have four bytes in the
front of the file before the 'BUFR'. Your files have eight bytes before the
'BUFR'.

When I read the first eight bytes (e.g. r = read(oin,&tmp2,8);) into a long
long C program variable it correctly displayed as an integer '9912'.  Your
data is 64 bit little endian.

Yet again another reason to rewrite the bufrlib.

John 



-----Original Message-----
From: John Halley Gotway [mailto:johnhg at rap.ucar.edu] 
Sent: Monday, July 21, 2008 1:03 PM
To: jhuddleston at hughes.net; met_help
Subject: Re: MET FEEDBACK from John Huddleston


John,

Thanks for letting us know about that.  I'll change the FILEMXSTRL value to
be 512 to be consistent with the other definition.  So once you set those
values the same, were you able to successfully run 
MET through cygwin?

John Halley-Gotway

MET.FEEDBACK at rap.ucar.edu wrote:
> First Name = John
> Last Name = Huddleston
> Institution = Easy Computer Solutions
> Email = jhuddleston at hughes.net
> MET Feedback = John,
> 
> I finally got around to figuring out why the Windows CYGWIN PB2NC.EXE was
doing a core dump. There is a character boundary issue.
> 
> In your METv1.1 the size of the FORTRAN character file names are
FILEMXSTRL which is defined in src/pb2nc/readpb.prm to be 256. The CC
calling functions use the max_str_len which is defined in
lib/vx_met_util/constants.h as 512.
> 
> John Huddleston, PhD, PE
> formerly with NOAA NCEP