[Met_help] METv2 compilation abort with 32 option on 64 machine

John Halley Gotway johnhg at rap.ucar.edu
Tue Aug 25 06:46:43 MDT 2009


Ana,

Wow.  That's some impressive work.  I'm glad you guys were able to get it working!

Regarding running WRF and WPP on a 64-bit machine, I do not forsee any problems with that, or at least I'm not aware of any issues doing that.  While you're using NetCDF4 for WRF, I believe WRF is
actually still using the "classic" NetCDF file structure - which is the same as is used in version 3.6.  Actually, I've compiled MET with NetCDF4 in the past, and it seems to work fine.  Unless you
specifically request that the "enhanced" NetCDF file structure be used for NetCDF4, it will default to behavior of 3.6.

Please proceed with your plans, and let me know if you run into any runtime problems.

Thanks,
John


Ana Cristina Carvalho wrote:
> Hello john!!
> 
> First step accomplished :-) it is installed with pgcc and pgf and it
> works. at least we were able to successufly run the script_all.sh
> 
> important things that we did in order to compile on debian linux, on a
> 64 architecture, some of that I have already mention in the previous e-mail
> 
> first of all, in order to not get any problem with the pgcc and pgf
> compilers is to follow the instructions on the pgi forum:
> final instruction of the following link:
> http://www.pgroup.com/userforum/viewtopic.php?t=1214&postdays=0&postorder=asc&start=5
> 
> 
> and
> in page
> 
> http://www.pgroup.com/userforum/viewtopic.php?t=1359&postdays=0&postorder=asc&start=0
> 
> 
> "In particular, they have updated the system "endian.h" file to directly
> include "bits/byteswap.h". This means in our version of
> "bits/byteswap.h, "endian.h" needs to be added to the list of header
> files that are allowed to call it directly. So by changing line 20 of
> "/opt/pgi/linux86/8.0-1/include/bits/byteswap.h" from:
> Code:
> #if !defined _BYTESWAP_H && !defined _NETINET_IN_H
> # error "Never use <bits/byteswap.h> directly; include <byteswap.h>
> instead."
> #endif
> to
> Code:
> #if !defined _BYTESWAP_H && !defined _NETINET_IN_H && !defined  _ENDIAN_H
> # error "Never use <bits/byteswap.h> directly; include <byteswap.h>
> instead."
> #endif
> you can work around the problem.
> 
> I've added a technical problem report (TPR#15472) and send it on to
> engineering to have the problem corrected in a future release."
> 
> After this problems solved:
> concerning the compilation of the libraries what have we done:
> BUFRLIB: we have used the options indecated in the users,
> but the path for the 32 compiler must be given (as it will be in the
> makefile of MET, and env_pgi.sh for the netcdf32 instalation).
> 
> we have followed the instructions for the gsl and everything went fine
> (rembebering all the time for the full path of the 32 bits compilers
> when needed.)
> 
> netcdf: the version is the 3.6.3 intelled with 32 bit option and flags
> included in the env_pgi.sh, in attach
> 
> for METv2 we have performed as inside the makefile in attach.
> 
> But i have some questions:
> 
> Wrf is compiled with 64 version of pgf with the netcdf4 version. do you
> forsee any problem on wrf post processor compilation and any problems
> with wrf runs? should i compile wrf also with the netcdf3.6.3 version
> with the pgi 32 bits version, as well as the mpich?
> 
> Thank's. Kind regards from the "compilation fight team"
> 
> Ana Cristina and Luis Carvalheiro
> 
> 
> 
> Em Fri, 21 Aug 2009 07:21:19 -0600
>  John Halley Gotway <johnhg at rap.ucar.edu> escreveu:
>> Ana,
>>
>> OK.  Let me know how far you get, and if/where you get stuck.
>>
>> Thanks,
>> John
>>
>> Ana Cristina Carvalho wrote:
>>> Hi!
>>> Thank you for the answer. I know that help does allways have a lot of
>>> fires to cool down :-)
>>> Ok!
>>> I will try with PGI and see what happens :-) I will keep you informed.
>>>
>>> AnaC
>>>
>>> Em Thu, 20 Aug 2009 11:58:47 -0600
>>>  John Halley Gotway <johnhg at rap.ucar.edu> escreveu:
>>>> Ana,
>>>>
>>>> Sorry for the delay in getting back to you.  I'd strongly suggest
>>>> choosing a single family of compilers before proceeding.
>>>>
>>>> You say you're using GNU C and C++ and the PGI FORTRAN compiler.  I'd
>>>> suggest using all GNU or all PGI:
>>>> GNU: g++, gfortran
>>>> PGI: pgcc, pgCC, pgf77, pgf90
>>>>
>>>> In particular, the PB2NC tool includes both C++ code and FORTRAN code
>>>> (for communicating with the BUFRLIB library).  I'd expect that you'd
>>>> have problems in PB2NC if you're using different families of
>>>> compilers.
>>>>
>>>> And for METv2.0, you should no longer need to run the cwordsh utility
>>>> to perform FORTRAN blocking.  That should now be handled by the PB2NC
>>>> tool itself.
>>>>
>>>> Please try switching over to a single family of compilers (probably
>>>> PGI), see how far you get, and then let me know where your problems
>>>> are.
>>>>
>>>> Thanks,
>>>> John Halley Gotway
>>>> johnhg at ucar.edu
>>>>
>>>> Ana Cristina Carvalho wrote:
>>>>>
>>>>> Dear MET_help
>>>>> after my first e-mail i get the help of a friend on this compilation
>>>>> terrifying compilation world.
>>>>> after some strugle in order to compile the required libraries for the
>>>>> METv2.0 and METv2.0 on a 64 machine with 32 bit option we have made
>>>>> some
>>>>> succefull steps, but owe are in the middle of the process with
>>>>> multiple
>>>>> questions...
>>>>>
>>>>> so, the linux is debian, the c and c++ are gnu, and fortran compiler
>>>>> is pgi
>>>>> for others that may experience the same problems, when compiling
>>>>> with 32
>>>>> bit options there are some stufs that must be there concerning  gnu c
>>>>> and cc++, such as the g++ multilib and the gcc dev and multilib.
>>>>>
>>>>> In order to pgf compile with the 32 bit option, some changes were
>>>>> needed,
>>>>> namely, following what we have found
>>>>> (http://www.pgroup.com/userforum/viewtopic.php?t=1214&postdays=0&postorder=asc&start=5),
>>>>>
>>>>>
>>>>> simply because the -tp=core2 option didn't work.
>>>>>
>>>>> “Hi,
>>>>>
>>>>> Can you please try edit /opt/pgi/linux86/7.1-6/localrc as follow:
>>>>>
>>>>> set DEFLIBDIR=/usr/lib32
>>>>> set DEFSTDOBJDIR=/usr/lib32
>>>>>
>>>>> and remove
>>>>>
>>>>> set EXTRAASARGS=--32.”
>>>>>
>>>>> for all compilations it was necessary to force the actual path for the
>>>>> 32 bits versions (either gcc, g++ and fortran)
>>>>> in pgi compilares is somwhere under (in our case)
>>>>>
>>>>> /opt/pgi/linux86/pgi_version/bin/
>>>>>
>>>>> Concerning netcdf, we have installed version 3.6.3 with the following
>>>>> env configuration (and it worked), following part of recomendations on
>>>>> the pgi page.
>>>>>
>>>>> export CC=/usr/bin/gcc
>>>>>
>>>>> export CFLAGS="-m32"
>>>>>
>>>>> export CPPFLAGS="-m32 -DNDEBUG -DpgiFortran"
>>>>>
>>>>> export CXX=/usr/bin/g++
>>>>>
>>>>> export CXXFLAGS="-m32"
>>>>>
>>>>> export F77=/opt/pgi/linux86/7.1-2/bin/pgf77
>>>>>
>>>>> export F90=/opt/pgi/linux86/7.1-2/bin/pgf90
>>>>>
>>>>> export FC=/opt/pgi/linux86/7.1-2/bin/pgf90
>>>>>
>>>>> export FFLAGS="-O2 -w -V"
>>>>>
>>>>>
>>>>>
>>>>> Concerning the cwordsh
>>>>> we have set
>>>>>  FC= /opt/pgi/linux86/7.1-2/bin/pgf77
>>>>> and in order to obtain the executable it only have worked this way
>>>>> (entering the name of the lib and not only the path to the lib. We
>>>>> have
>>>>> also tried with the -L option and it didn't work. May be we were
>>>>> making
>>>>> something wrong):
>>>>> $FC -o cwordsh.x cwordsh.f /home/anac/dir_BUFRLIB/libbufr.a
>>>>>
>>>>> For METv2 compilation... abborted :-(
>>>>>
>>>>> I am sending you the makefile and the make_met.log ...
>>>>>
>>>>> some questions exists that may be a little bit hiden. WRFV3 is
>>>>> compiled
>>>>> with the chem option active,  dm par option active, with netcdf
>>>>> version4, everything in 64 bits. Is there any problem that may
>>>>> arise on
>>>>> this...
>>>>>
>>>>>
>>>>> thank you so much for any help,
>>>>> anac
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Met_help mailing list
>>>>> Met_help at mailman.ucar.edu
>>>>> http://mailman.ucar.edu/mailman/listinfo/met_help
> 


More information about the Met_help mailing list