[Met_help] Problem compiling METv1.0

[John Halley Gotway]

Thomas,

I'm glad you were able to get it working... even without PB2NC.  Compiling that tool has given us the most difficulties since it mixes fortran and C++ code and BUFRLIB isn't 64-bit compatible.

We are interested in working with you to enable the use of ECMWF BUFR point observations.  Unfortunately, my next few months are really booked in getting the release of METv1.1 ready, implementing 
some new things for the next release, and getting ready for a couple of tutorials.

To use ECMWF BUFR observations, I'd suggest trying to reformat them to a NetCDF format like the output of "pb2nc" (which I know you don't have).  Then the reformatted NetCDF could could be used as 
input to the "point-stat" tool.  However, I'd suggest waiting to do anything on this until METv1.1 is out.  We've modified the NetCDF output of "pb2nc" slightly to get rid of unused fields.

Let's talk again once METv1.1 is available.  And we'll figure out how to go about using ECMWF observations in MET.

Thanks,
John

Thomas Schwitalla wrote:
> John Halley Gotway schrieb:
>> Thomas,
>>
>> Here are a few thoughts...
>>
>> Have you tried removing "-lgfortran" from the Makefile?  It may be the 
>> case that it is not necessary on your system.  We only recently 
>> upgraded to Debian release Etch on which the gfortran compiler is 
>> available.  I was really surprised that we had to supply the 
>> -lgfortran compiler option.  So please try removing it.
>>
>> I have attached the Makefile I used for building with gfortran as you 
>> requested, but it really doesn't look much different than yours.
>>
>> Regarding 64-bit, I expect that you'll experience a run-time error 
>> from the BUFRLIB code.  Everything should compile fine, but when the 
>> "pb2nc" tool calls the BUFRLIB routine to read the input PrepBufr 
>> file, you'll likely encounter an error.  This means that you won't be 
>> able to run the PB2NC tool at this time.  We've been in touch with 
>> NCEP and requested that they make BUFRLIB compatible with 64-bit 
>> machines, but they have not worked on it yet.  However, you will still 
>> be able to run the PCP-Combine, Grid-Stat, MODE, VSDB-Analysis, and 
>> MODE-Analysis tools with no problem.  The Point-Stat tool would work 
>> as well, but currently you'd need the output of the PB2NC to serve as 
>> input to Point-Stat.  In the next release, we're providing an ASCII2NC 
>> tool to remove the dependence on BUFRLIB.
>>
>> For the time being, let's make sure we can get MET to compile on your 
>> system.  And then we can address the other issues that arise.
>>
>> So please try removing -lgfortran, and let me know what you find.
>>
>> If you continue having problems with the compilation of PB2NC, you 
>> could try skipping that compilation step, by commenting out (or 
>> deleting) the following line from the Makefile:
>>
>> #        @ cd $(PB2NC);           make CPP_COMPILER=$(CPP_COMPILER) 
>> F77_COMPILER=$(F77_COMPILER) FLAGS="$(FLAGS)" PGI_LIBS="$(PGI_LIBS)" 
>> --no-print-directory
>>
>> Thanks,
>> John
>>
> 
> John,
> 
> if I comment out the pb2nc line, everything works fine (both the 
> compilation and the test_all.sh).
> I think, if we want to use MET at our Institute, we will try to use 
> ECMWF Bufr, if we once have enough time....
> 
> If I should/can do several tests for you, let me know!
> 
> Thomas
>> Thomas Schwitalla wrote:
>>> John Halley Gotway wrote:
>>>> Thomas,
>>>>
>>>> I apologize for the delay in getting back to you.
>>>>
>>>> When we released METv1.0, gfortran was not a supported compiler 
>>>> option.  However, since then, we've successfully built and tested 
>>>> MET with gfortran.
>>>>
>>>> There are 3 minor changes you'll need to make to get METv1.0 to 
>>>> compile with gfortran:
>>>> (1) Replace the file METv1.0/src/pb2nc/readpb.prm with the version 
>>>> of that file attached to this message.
>>>> (2) Replace the file METv1.0/src/pb2nc/readpb.f with the version of 
>>>> that file attached to this message.
>>>> (3) In your Makefile, add "-lgfortran" to the line for "F2C_LIBNAME".
>>>>
>>>> Then do a "make clean", followed by a "make >& make_met.log".
>>>>
>>>> Please let me know if that does the trick for you.  If so, I'll post 
>>>> these fixes to the known issues page on the MET website 
>>>> (http://www.dtcenter.org/met/users/support/known_issues/METv1.0/METv1.0_known_issues.php).  
>>>> We're currently working toward a release of METv1.1 which will 
>>>> include these changes I've sent to you.  So we shouldn't experience 
>>>> these issues with gfortran in the future.
>>>>
>>>> Thanks and sorry again for the delay in getting back to you.
>>>>
>>>> John Halley-Gotway
>>>>
>>>> Thomas Schwitalla wrote:
>>>>> Dear MET-Team,
>>>>>
>>>>> I try to compile METv1.0  with the resolved issues at home using 
>>>>> the gfortran (version 4.2.1) compiler.
>>>>> I get several warnings (as every time..) but also one error message 
>>>>> (log-file is attached).
>>>>> Because I'm absolutely not familiar with C/C++, any help is highly 
>>>>> appreciated.
>>>>>
>>>>>
>>>>> I'm using 64bit Ubuntu 7.10 and installed the f2c and GSL libraries 
>>>>> with the package manager.
>>>>>
>>>>>
>>>>> Regards from Germany
>>>>> Thomas
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------ 
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Met_help mailing list
>>>>> Met_help at mailman.ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/met_help
>>>
>>>
>>> John,
>>>
>>> I put your modifications into the directory, but it's still not 
>>> working :-(
>>> I finally get the message "/usr/bin/ld: cannot find -lgfortran", 
>>> which confuses me a little bit, because gfortran is also installed 
>>> via package manager :-\
>>> Can this be a problem of a 64bit system, because on the webpage it's 
>>> mentioned, that there are several problems using 64bit?
>>> Can you send me your Makefile for using the gfortran compiler?
>>>
>>> I will answer your query and test it further as soon as possible, but 
>>> this week it may take some time.
>>>
>>> Thomas
>>>
>>>
> 
>