[Met_help] Problems getting MET running...bufr problems?
John Halley Gotway
johnhg at rap.ucar.edu
Tue Nov 13 13:01:53 MST 2007
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
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.
John Halley Gotway wrote:
> 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.
> Steve wrote:
>> 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
>> 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
More information about the Met_help