一篇关于wien2k编译和安装的论文

Compiling Wien2k on Intel based systems with Suse Linux. Gerhard H. Fecher Johannes Gutenberg - Universita¨t, Mainz Institut fu¨r anorganische Chemie und analytische Chemie 55099 Mainz, Germany e-mail: fecher@uni-mainz.de January 28, 2007 Abstract A short description is given about how to compile Wien2k. The present description focuses on Intel based systems and Suse Linux. The tips given below may principally work also on other processors and Linux distributions, how- ever, they were only tested with Intel and SUSE configurations. Be sure to read and understand the manuals. 1 Introduction For those who do not have a fully licensed but an unsupported (free) non-commercial version of the Intel Compiler and Intel MKL, it may not be possible to download the older versions. Newcomers starting from scratch with Wien2k and Fortran thus may not be able to make use of the options given in the siteconfig script for the older Versions. The following description does not replace the Wien2k Users Guide [1]. Visit also the Frequently Asked Questions page 1, in particular [2]. If not done already, please, read it carefully before continuing. In case of troubles, check first the posts in the Users Forum to see if your problem was not already solved a long time ago. Note that Linux systems are rather heterogeneous, so you may have to try your own way for a successful installation, I hope the following will help. Good Luck ! 1.1 Disclaimer This work is still in progress, so there will most probably be typos and errors or: whatever bad things may happen will happen. The following description was tested and runs without guarantee on German SUSE 9.2, 9.2 (US), 9.3, 10.0 and 10.1 distributions using the Intel Fortran 9.1 compiler and MKL 8.1 2. The tests were performed on Intel based systems (Notebook with Pentium M 760, 1GByte RAM, Desktop with Pentium IV 2.8GHz, 1http://www.wien2k.at/reg user/faq 2MKL 8.2 is not yet available free for non-commercial use. It is announced for early 2007. 1 2GByte RAM, Desktop with D830 3.0GHz, 1GByte RAM, and a dual-CPU Server with two Xeon 3.8GHz, 4GByte RAM). The tested Wien Versions were Wien2k 05, Wien2k 06, and Wien2k 07. The latest tested versions and systems were: Processor Wien2k SUSE IFORT MKL Date 1 Xeon 3.8 GHz 05.6 10.0 9.0.021 8.0.19 2 Pentium M 760 06.2 9.3 9.0.021 8.0.19 3 Pentium D 830 06.2 10.0 9.0.031 8.0.2.004 4 Pentium M 760 06.4 10.1 9.1.040 8.1.014 4. Jan. 06 5 Pentium D 830 07.1 10.1 9.0.041 8.1.014 27. Jan. 06 6 Pentium M 760 07.1 10.1 9.1.041 8.1.014 28. Jan. 06 This short introduction cannot, however, prevent that one has to read the manuals [3, 4, 5, 6, 7]. 2 Short The short installation instruction is given on the code download page: http://www.wien2k.at/reg user/wien2k download/. Follow the instructions there and in the scripts. Move the WIEN2k-tar.gz file(s) into a (new) directory which will become your $WIENROOT directory, uncompress the package using (0x is the downloaded version !): tar -xvf WIEN2k_0x.tar gunzip *.gz chmod +x ./expand_lapw ./expand_lapw This will expand all files and copies various shell-scripts. In $WIENROOT/SRC you find the postscript version of the users guide. Proceed with reading the chapter Installation. Supposed a proper Fortran system is installed, you can then configure and compile Wien2k using: ./siteconfig_lapw After successful installation, every user should run: ./userconfig_lapw 3 Single processor system Two steps are necessary for running Wien2k successfully: • Installing the Fortran compiler and Math Kernel Libraries. • Compiling the source code. The following suggestions are supposed to work on every single Intel processor system starting from Pentium III. They do not make benefit from the particular improvements of dual-core or quad-core CPUs (D8xx, D9xx, Txxxx or Exxxx series) (see next section). They were, however, also successfully tested on a dual-CPU Xeon and a D830 system. Principally the suggestions should also work with AMD processors, at least with some options changed, but this was not tested ! 2 3.1 Intel Fortran 9.1 and MKL 8.1 First one needs to install the compiler and the math kernel library. Both can be downloaded from www.intel.com. One needs root access during the installation, so use either the root account or - easier - open a root shell. Follow the instructions how to install the compiler and the library. During installation one may change the path for the program and library. Below, the standard path is used. /opt/intel/fc/9.1.041 for the fortran compiler and /opt/intel/mkl/8.1 for the MKL library. In the following it is assumed that these are the directories where to find the Intel devel- opment tools. The suggestions given below have to be changed if a different path is used for one or the other libraries. Note: Be sure to install the correct version of the Fortran compiler depending whether you install on a 32-bit system or on one with 64-bit extensions (em64t). This may be done by choosing the option for custom installation. After successful installation, one may tell the linker where to find the libraries. To do so, one has to edit the file /etc/ld.so.config to include the following lines. /opt/intel/fc/9.1.041/lib /opt/intel/mkl/8.1/lib/32 for 32-bit systems (Pentium III, old Pentium IV, or Pentium M). For systems with 64-bit extensions (new Pentium IV or Xeon) it should be: /opt/intel/fc/9.1.041/lib /opt/intel/mkl/8.1/lib/em64t Note 1: Use /mkl/8.1/lib/em64t but not /mkl/8.1/lib/64, the latter contains the libraries for Itanum systems. Note 2: You may also check if the path to other shared libraries is included in /etc/ld.so.config that may be needed by the linker. However, this may depend on the Linux version and installation. After editing and saving the files, run ldconfig in /etc to take the new settings into affect. The environment variables needed for compiling and linking may be set by means of the scripts given in the directories: /opt/intel/fc/9.1.041/bin for the compiler (e.g. ifortvars.sh) or /opt/intel/mkl/8.1/tools/environment for the MKL (e.g.: mklvars32.sh or mklvarsem64t.sh). Note: Check carefully if you need the .sh or the .csh versions of the scripts, depending on the used shell and Linux installation. To make the installation more comfortable one should make some additions to the file /etc/profile.local. This can be done using the suggestions given in the Intel script files. The profile.local file should then include the following lines: # PATH="/opt/intel/fc/9.1.041/bin:${PATH}" PATH="/opt/intel/idb/9.1.041/bin:${PATH}" export PATH # MANPATH="/opt/intel/idb/9.1.041/man:${MANPATH}" MANPATH="/opt/intel/fc/9.1.041/man:${MANPATH}" export MANPATH # LD_LIBRARY_PATH="/opt/intel/mkl/8.1/lib/32:$LD_LIBRARY_PATH" LD_LIBRARY_PATH="/opt/intel/fc/9.1.041/lib:$LD_LIBRARY_PATH" export LD_LIBRARY_PATH 3 # INCLUDE="/opt/intel/mkl/8.1/include:$INCLUDE" export INCLUDE # INTEL_LICENSE_FILE="/opt/intel/licenses" export INTEL_LICENSE_FILE # or similar. If there is no profile.local in /etc one has to create it (at least on SUSE systems). Alternatively, one may include the above environment variables in the (hidden) .bashrc files of all users that are supposed to work with the compiler and libraries. Note: The 32-bit MKL was used here (otherwise replace /32 by /em64t). It is also assumed that the Intel debugger is installed in /opt/intel/idb/9.1.041 Finally, open a user shell from your regular account and check if the environment variables are set correctly for example by means of echo $LD LIBRARY PATH, and so on. Option: In cases you are working more often with the Intel compiler - and not just to install Wien - it may be helpful to introduce some new environment variables in the profile.local file that point to the directories were the libraries are located. This saves some typing work and makes it easier to transport the configuration from one computer to another. The additions in profile.local or .bashrc may be: EXPORT IFLPATH=/opt/intel/fc/9.1.041/lib EXPORT MKLPATH=/opt/intel/mkl/8.1/lib/32 for the 32-bit libraries or accordingly with the correct path to the em64t libraries. Those who work with different processors may also want to set some flag for the processor specific compiler switch like XPROC=-xX. These switches may not work correctly with the Wien2k makefiles in their present form. If experienced enough, one may write easily a short script that makes use of these environment variables in order to build the OPTIONS file (see below). If everything is ok 3, the first step is finished and one can go on to set-up Wien2k. 3.2 Compiling Wien2k using siteconfig The compilation of Wien2k is managed by siteconfig. The script siteconfig lapw changes the makefiles for all programs, runs make and copies the executables into the Wien2k directory. The makefiles contain all necessary information how the programs have to be compiled and linked. The script may not be suited for the latest version of the compiler and math libraries because updates or new processors appear rather frequently. However, it can easily be changed for particular needs. The following are the most important options that need to be set correctly: • Compiler to be used • Compiler options • Linker options • Options for the Math Kernel Libraries The performance of Wien2k will depend strongly on the correct settings, thus one should carefully prepare these options. Note: Running the script for the first time, you may see warnings during the compilation of the programs that clean does not find files to be removed. This is clear, at the first compilation there are no object files that can be deleted. However, all other errors should be taken serious. 3I recommend to test first with a smaller Fortran program whether everything works well, before starting with Wien2k 4 3.2.1 Compiler options (FOPT): These options tell the compiler ifort how to process the fortran files i.e.: *.f. In principal, the only compiler option being essentially needed is -FR (same as -free). It tells the Fortran compiler ifort that the files are in free-form format. However, there are more useful compiler switches, in particular those who are responsible how the program is optimised and those controlling the numerical accuracy of the compilation. Recommended options are: -FR -w -mp1 -prec_div -pad -ip These settings should be save. Note 1: In cases of doubt check the Intel Fortran manuals for particular switches and their use, there are plenty lots of them. Note 2: For a particular processor one may add the switch -xProcessor. The possible switches are -xK, -xW, -xN, -xB, or -xP depending on the target processor. These switches should be used together with the switch -O3 for a higher optimisation level (-O2 is used as default and needs not to be given). The program compiled with a -xX switch may not run on computer with a processor being not supported by that switch. It may also be necessary to link libsvml if these compiler switches are used. Note 3: The switches -mp1, -prec div, -pad are used to maintain floating point precession in the calcula- tions. The switch -w suppresses that warnings are printed during compilation. Note 4: The switch -ip performs single-file inter procedural optimisation, that is optimisation between subroutines located in the same .f file. Note 5: Presently, it seems that only the subroutine SRC lapw1/hamilt.f makes use of the macro IN- TEL VML, therefore the switch -DINTEL VML is not given in the options, at the present stage. Note 6: Some switches being suggested in the original (or some older versions) siteconfig lapw script are not used here for different reasons: -pc80 is the default and thus not needed. -Vaxlib is from very old versions of the Intel compiler and not longer in use. The compiler options with optimisation for a Pentium M processor may look like: -FR -w -mp1 -prec_div -pad -ip -DINTEL_VML -O3 -xB Note 1: The use of these options may need some additional libraries (see below). Note 2: Replace -xB by -xP if the target processor is a PIV with em64t extensions or a Xeon. 3.2.2 Linker options (LDFLAGS): These options are passed from the compiler ifort to the Linux linker ld in order to make the executables from the object files (*.o). They also tell the linker which non-standard libraries should be used. For dynamic linking of the libraries use: (-no-ipo) -L/opt/intel/mkl/8.1/lib/32 -lguide -lpthread Note: These settings should be save. Depending on the compiler switches, in particular for optimisation, one may need to give more libraries. (See also the following notes.) The switch -no-ipo - indeed, without brackets - is not necessary on some systems. It prevents some Linker errors (see Section 3.2.3). For static linking of the Intel provided libraries one may use: -L/opt/intel/fc/9.1.041/lib -i-static -lguide_stats -lsvml -lpthread 5 Note 1: -L/PATH tells the linker ld where to search for the library files. On some systems, ld searches in -L/PATH first for shared libraries libxyz.so and then for static libraries libxyz.a. If it finds the shared library then it will perform dynamic linking even so a static library is present (see also note below). Note 2: One probably needs to give -L/opt/intel/fc/9.1.041/lib because there one finds the libguide stats, and it will not be found if only giving the path to MKL, like used in the dynamic example. Note 3: The switch -i-static tells ifort that only the Intel libraries should be linked statically. Note 4: The switch -lsvml is used for the processor specific optimisation like -O3 -xB or -O3 -xP. Note 5: libguide is found in both the ifort and the MKL library path. It seems that at least the static versions are identical at present. This may change with other versions of the compiler and MKL. Note 6: libpthread is not an Intel provided library and should be found in the standard linker path. Note 7: The switch -static-libcxa being suggested in the siteconfig lapw script is not used here, as it seems that libcxa is not used in all parts of the program. This switch is used to link the C++ compatibility libraries statically. The alternative switch is -dynamic-libcxa (see also Intel manuals). WARNING: The switch -static-libcxa does not work with gcc on a 64-bit SUSE 10.0 with multiprocessor kernel ! Note 8: For static linking of a particular library one may also give the static library file with its full path explicitly like for example MKLPATH/libguide.a instead of -lguide. On the other hand, the type of linking can be changed by using the switches -Bdynamic for dynamic linking and -Bstatic for static linking. These switches are always acting on the library given after the switches. That means: -L/opt/intel/mkl/8.1/lib -Bstatic -lguide -Bdynamic -lpthread links libguide statically and libpthread dynamically. Note 9: The behaviour of ld depends also on the settings in /etc/ld.so.config as regards shared libraries. (ldconfig -p reports which shared libraries are known in the linker cache.) 3.2.3 Linker problem with ifort 9.x and SUSE 10.1: There is a problem with this combination as well as with other distributions, the compiler may report the following error: IPO Link error: file not found "(" In case that this appears, you may like to add one of the switches -no-ipo or -O0 to the linker flag (not to the compiler flags !) such that it looks like: -no-ipo -L/opt/intel/fc/9.1.041/lib -lguide -lpthread It seems that some parameter is incorrectly passed to the linker, or interpreted wrong by it. Usually the interprocedural optimization are not used for the Wien2k compilation. In case you like to do experiments with the -ipo flag during compilation, you may need to create in each directory the two empty files: ( and AS NEEDED, e.g. by using: echo NULL > \( echo NULL > AS_NEEDED It helps, but I do not like to know why ! 3.2.4 BLAS-LAPACK options (R LIBS): These are special options for the linker concerning the MKL or other blas-lapack libraries. These libraries are not needed in all of the Wien2k programs but only in some particular ones. In case of a 32-bit system, the switches: (-no-ipo) -L/opt/intel/mkl/8.1/lib/32 -lmkl_lapack -lmkl_ia32 -lguide -lpthread 6 should be save. Note 1: The switch -no-ipo is not necessary on some systems. It prevents some Linker errors (see Section 3.2.3. Note 2: For Pentium processors with 64-Bit extensions one may use -L/opt/intel/mkl/8.1/lib/em64t and -lmkl em64t. Note 3: For some of the Suse 9.3 (or newer) installations, there was no need to give the libpthread library explicitly, thus one may drop the -lpthread switch, it is probably somewhere in the linker path. On 64-bit SUSE 10.0 systems, the 64-bit version of the library will be chosen automatically in the case of dynamic linking. Note 4: The reason to give some libraries twice (in LDFLAGS and R LIBS ) is the behaviour of the Linux linker ld that needs to have the libraries given in a particular series if using the -lxyz form. In that case it searches -L/PATH only once. For example libmkl lapack needs libmkl ia32 (or libmkl em64t) and libguide, so libmkl ia32 and libguide have to be given after libmkl lapack - like in the example given above - otherwise the linker complains about missing routines. On the other hand, the libmkl lapack is only needed in few makefiles, but libguide or libpthread may be needed in other subroutines without libmkl lapack. Therefore some libraries are needed in LDFLAGS and as R LIBS comes in the make files after LDFLAGS, one may need to give some libraries another time. At the command line, this type of searching behaviour of ld may be overcome by using -( libraries -) causing that the -L/PATH is searched multiply. libraries may be explicit files or -l options. This does not work, however, across different flags like used for example in the makefiles of Wien (LDFLAGS, R LIBS ). It should be noted that ifort passes command line options to ld making use of the switch -Bl. The above given options link the MKL libraries, at least some parts, statically even without use of the -static switch! The reason is that the static and dynamic versions of the MKL libraries have different names. For dynamic linking of the MKL one needs to link the shared libraries libzyx.so instead of libxyz.a, these have slightly different names, such that the R LIBS options may look like: -L/opt/intel/mkl/8.1/lib/32 -lmkl_lapack64 -lmkl -lmkl_p4 -lvml Note: If any errors occur during the link process complaining about missing subroutines, one can easily check which of the static library archives (libxyz.a) contains the missing subroutine. This is usually very helpful even so one may have to check a lot of files if the missing routine is in one of the general or Gnu libraries. If there is a shared library (libxyz.so) with the same name then it should usually contain the same routines like the archive, and thus may be added to the list of libraries to be linked dynamically. Moreover, finding the correct library may prevent to write patches just because a subroutine is moved - for whatever reason - from one to another library. This was for example the case some time ago with libpthread were the missing subroutine (pthread atfork) was moved to libpthread nonshared, at least for SUSE systems (see in /usr/lib). 3.2.5 Making Wien2k Follow the installation instructions given on the Wien2k code download page 4. a) Running site config for the first time If installing Wien2k the first time, one has to set correctly all options in site config as suggested above. Among others, site config will create a file OPTIONS where all the information about the compiler is stored. This file is very helpful for later changes, see next step. 4http://www.wien2k.at/reg user 7 b) Changing options and recompiling Before using the script siteconfig (siteconfig lapw) repeatedly, one may change the file OPTIONS in the Wie