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

[John Halley Gotway]

Steve,

I wanted to update you with status.

I got in touch with the folks at NCEP who distribute and maintain BUFRLIB.  In fact, the head of that group is someone I recently helped with a MET_HELP question.  He looked into the issue of running
on a 64-bit machine and realized that some code changes will be necessary.  He told me that they'll "revamp" the BUFRLIB code to handle 64-bit.  Unfortunately though, I can't guarantee anything and I
don't have a timeline of when an updated version of BUFRLIB will become available.

I am glad that you were able to get MET to work - at least on a 32-bit machine.  Feel free to send any additional questions you have to met_help.

Thanks,
John

Steve wrote:
> John --
> 
> Thank you for your efforts to try to get the MET software working on the
> 64-bit systems.  I took your earlier suggestion to try to compile on a
> 32-bit system...I created a 32-bit linux system from an old laptop we
> had sitting around.  The MET executables that were made on that system
> appear to run on the 64-bit system and I was able to run the test suite
> successfully.
> 
> I can now start to learn and utilize the MET software with the
> executables I have.   Hopefully, the NCEP folks have a solution to the
> 64-bit problem with their libraries.  We have a customer who is setting
> up a large Linux cluster that is 64-bit, for which making compatible
> 32-bit executables will be more of a challenge.
> 
> --Steve Masters   smasters at cfl.rr.com
>   ENSCO, Inc.     masters.steve at ensco.com
>   Melbourne, FL
> 
> John Halley Gotway wrote:
>> 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
>>
>>
>