[Met_help] Problems getting MET running...bufr problems?

[John Halley Gotway]

Steve,

I've been able to compile MET and run all of the test scripts successfully on a 64-bit machine with the exception of the one for "pb2nc".  When I use the output from pb2nc from a successful run on
another machine, I'm able to run the test script for "point_stat" as well.

The error we're encountering from pb2nc does seem to reside in the BUFRLIB code.  I ran pb2nc through a debugger and found that it's choking on a fortran read statement within BUFRLIB.  Since we don't
maintain BUFRLIB, there's not much I can do about it right now.  However, I'm emailing some folks at NCEP to find out if they've had success running BUFRLIB on a 64-bit machine and if they have any
suggestions.

I'll let you know what I hear from them.

In the mean time, you should be able to run the grid_stat and mode tools on your system.  And if you run into any problems with those or have any questions, feel free to send them to met_help.

Thanks,
John

John Halley Gotway wrote:
> Steve,
> 
> Just wanted to give you an update.  In testing on a 64-bit machine, it appears that I'm able to reproduce the I/O error you're seeing when running the 'test_pb2nc.sh' script:
> 
> *** Running PB2NC on a fortran-blocked PrepBufr file ***
> PrepBufr2NC config file: config/PB2NCConfig_G212
> Opening PrepBufr file: ../data/sample_obs/prepbufr/ndas.t00z.prepbufr.tm12.20070401.nr.blk
> endfile: end of file
> apparent state: internal I/O
> last format: (I1,I2,I3)
> lately reading sequential formatted internal IO
> 
> I'll look into it, and see how we can address it.
> 
> John
> 
> Steve wrote:
>> Hi...
>>
>> I sent your group an e-mail in late August about problems I was having
>> getting the MET software to work properly.  While I am able to compile
>> all the various components without error, the test cases will not
>> sucessfully complete.  In particular, the PB2NC test fails with and end
>> of file error during an internal I/O operation, apparently while reading
>> or processing bufr data.  After several exchanges of e-mails, we felt
>> the problem was with my netCDF compilation and installation.
>>
>> After a couple of months, I have again had opportunity (and the
>> requirement) to get MET working successfully.  As I have continued to
>> look at my system, I believe that the problem is not with the netCDF
>> installation.  I get no compilation errors and all tests that come with
>> netCDF pass on my system.  I am beginning to believe that the problem is
>> with the bufr software.
>>
>> While I can compile the bufr libraries without error, I can not make any
>> program that uses BUFR data work properly.  I suspect that there may be
>> an issue with my system and OS being 64-bit.  If you "od -c" the blocked
>> prepbufr files that come with the MET package, they have a four-byte
>> fortran record length header.  I note the same header size if I download
>> blocked bufr files from NCEP.  However, if I use the cwordsh program on
>> an unblocked bufr file I get from NCEP, or if I do any FORM=FORMATTED
>> fortran open/write with my own programs, I get an eight-byte header.
>> I've attached the output from the "od -c" on one of your sample blocked
>> bufr files and a file that I blocked on my system using cwordsh.
>>
>> My system type listed by "uname -m" is "x86_64".
>>
>> I know that the bufr software is totally external to your system, but I
>> was wondering if anyone else working with the MET software has run
>> across this type of issue.  At the moment, the bufr format is the only
>> way to get observed data into MET, so I need to find a solution to this
>> problem.
>>
>> Steve Masters  smasters at cfl.rr.com
>> ENSCO, Inc.    masters.steve at ensco.com
>> Melbourne, FL
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Met_help mailing list
>> Met_help at mailman.ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/met_help
>