[Met_help] Problems getting MET running...bufr problems?
John Halley Gotway
johnhg at rap.ucar.edu
Mon Nov 5 15:56:31 MST 2007
Thanks for sending all of the good information. I agree with you that running MET on a 64-bit OS is likely problematic. In addition to the BUFR library, there may be issues with running the MET code
itself on a 64-bit machine. MET was developed on a 32-bit version of Debian Linux, and we have not yet ported it to a 64-bit OS. This is the first time that the need to port to a 64-bit machine has
The vast majority of our machines here are running 32-bit OS's, but we do have one 64-bit machine available. I will try copying the code over, compiling, and running the test cases to see where the
issues are. It may or may not turn out to be a straight-forward task of getting MET to run on a 64-bit machine.
In the mean time, if you have a 32-bit machine available - even just for testing purposes - I'd try building MET on there.
I'll be on travel from Wednesday through Friday of this week. But I hope to have more news for you sometime next week.
John Halley Gotway
johnhg at ucar.edu
> 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