next up previous contents
Next: 3 Parallelism Up: 2 Installing QUANTUM ESPRESSO Previous: 2.5 Running examples Contents

Subsections

2.6 Installation tricks and problems

2.6.1 All architectures

Working fortran-95 and C compilers are needed in order to compile QUANTUM ESPRESSO. Most so-called ``fortran-90'' compilers implement the fortran-95 standard, but older versions may not be fortran-95 compliant.

If you get ``Compiler Internal Error'' or similar messages: your compiler version is buggy. Try to lower the optimization level, or to remove optimization just for the routine that has problems. If it doesn't work, or if you experience weird problems, try to install patches for your version of the compiler (most vendors release at least a few patches for free), or to upgrade to a more recent version.

If you get error messages at the loading phase that looks like ``file XYZ.o: unknown (unrecognized, invalid, wrong, missing, ... ) file type'', or ``file format not recognized for file XYZ.a'', one of the following things have happened:

  1. you have leftover object files from a compilation with another compiler: run make clean and recompile.
  2. make does not stop at the first compilation error (it may happen in some software configurations). Remove file XYZ.o and look for the compilation error.
If many symbols are missing in the loading phase: you did not specify the location of all needed libraries (LAPACK, BLAS, FFTW, machine-specific optimized libraries). If you did, but symbols are still missing, see below (for Linux PC). Remember: QUANTUM ESPRESSO is self-contained (with the exception of MPI libraries for parallel compilation). If system libraries are missing, the problem cannot be in QUANTUM ESPRESSO.

2.6.2 IBM AIX

On IBM machines with ESSL libraries installed, there is a potential conflict between a few LAPACK routines that are also part of ESSL, but with a different calling sequence. The appearence of run-time errors like
    ON ENTRY TO ZHPEV  PARAMETER NUMBER  1 HAD AN ILLEGAL VALUE
is a signal that you are calling the bad routine. If you have defined -D__ESSL you should load ESSL before LAPACK: see variable LAPACK_LIBS in make.sys.

2.6.3 Linux PC

The web site of Axel Kohlmeyer contains a very informative section on compiling and running CPMD on Linux. Most of its contents applies to the QUANTUM ESPRESSO codes as well:
http://www.theochem.rub.de/~axel.kohlmeyer/cpmd-linux.html. In particular, there is a set of ATLAS libraries, containing all of LAPACK and no external reference to fortran libraries:
http://www.theochem.rub.de/~axel.kohlmeyer/cpmd-linux.html#atlas

It is convenient to create semi-statically linked executables (with only libc/libm/libpthread linked dynamically). If you want to produce a binary that runs on different machines, compile it on the oldest machine you have (i.e. the one with the oldest version of the operating system).

If you get errors like

    IPO Error: unresolved : __svml_cos2
at the linking stage, your compiler is optimized to use the SSE version of sine, cosine etc. contained in the SVML library. Append '-lsvml' to the list of libraries in your make.sys file (info by Axel Kohlmeyer, oct.2007).

2.6.3.1 Linux PCs with Portland Group compiler (pgf90)

QUANTUM ESPRESSO does not work reliably, or not at all, with many old versions of the Portland Group compiler (in particular, v.5.2 and 6.0). Version 5.1 used to work, v.6.1 is reported to work (info from Paolo Cazzato). Use the latest version of each release of the compiler, with patches if available: see the Portland Group web site, http://www.pgroup.com/faq/install.htm#release info

2.6.3.2 Linux PCs with Pathscale compiler

Version 2.99 of the Pathscale compiler works and is recognized by configure, but the preprocessing step:

   pathcc -E
causes a mysterious error in compilation of iotk and should be replaced by
   /lib/cpp -P --traditional
The MVAPICH parallel environment with Pathscale compilers also works. (info by Paolo Giannozzi, July 2008)

2.6.3.3 Linux PCs with gfortran

Recent versions of gfortran (e.g. v.4.1 and later) are supported, but only the basic functionalities have been tested. More advanced ones may or may not work. In particular: reading files produced by previous versions of QUANTUM ESPRESSO may not work, apparently due to a gfortran bug.

2.6.3.4 Linux PCs with Intel compiler (ifort, formerly ifc)

If configure doesn't find the compiler, or if you get ``Error loading shared libraries...'' at run time, you may have forgotten to execute the script that sets up the correct path and library path. Unless your system manager has done this for you, you should execute the appropriate script - located in the directory containing the compiler executable - in your initialization files. Consult the documentation provided by Intel.

Starting from the latests v 8.1 patchlevels, the recommended way to build semi-statically linked binaries is to use the -i-static flag; for multi-threaded libraries the linker flag would be -i-static -openmp (linking libguide is no longer needed and the compiler will pick the correct one). The warning: ''feupdateenv is not implemented and will always fail'', showing up in recent versions, can be safely ignored. For previous versions, try -static-libcxa (this will give an incomplete semi-static link on newer versions).

Each major release of the Intel compiler differs a lot from the previous one. Do not mix compiled objects from different releases: they may be incompatible.

In case of trouble, update your version with the most recent patches, available via Intel Premier support (registration free of charge for Linux): http://developer.intel.com/software/products/support/#premier.

ifort v.10: on 64-bit AMD CPUs, at least some versions of ifort 10.1 miscompile subroutine write_rho_xml in Module/xml_io_base.f90 with -O2 options. Using -O1 instead solves the problem (info by Carlo Cavazzoni, March 2008).

"The intel compiler version 10.1.008 miscompiles a lot of codes (I have proof for CP2K and CPMD) and needs to be updated in any case" (info by Axel Kohlmeter, May 2008).

ifort v.9: The latest (July 2006) 32-bit version of ifort 9.1 works flawlessy. Earlier versions yielded ``Compiler Internal Error''.

At least some versions of ifort 9.0 have a buggy preprocessor that either prevents compilation of iotk, or produces runtime errors in cft3. Update to a more patched version, or modify make.sys to explicitly perform preprocessing using /lib/cpp, as in the following example (courtesy from Sergei Lisenkov):

   .f90.o:
           $(CPP) $(CPPFLAGS) $< -o $*.F90
           $(MPIF90) $(F90FLAGS) -c $*.F90 -o $*.o

   CPP       = /lib/cpp
   CPPFLAGS  = -P -C -traditional $(DFLAGS) $(IFLAGS)

On some versions of RedHat Linux, you may get an obscure error: IPO link: can not find ``(`` ... , due to a bad system configuration. Add option -no-ipo to LDFLAGS in file make.sys.

ifort v.8: Some releases of ifort 8 yield "Compiler Internal Error". Update to a more patched version: 8.0.046 for v. 8.0, 8.1.018 for v. 8.1.

There is a well known problem with ifort 8 and pthreads (that are used both in Debian Woody and Sarge) that causes "segmentation fault" errors (info from Lucas Fernandez Seivane). Version 7 did not have this problem.

ifc v.7: Some releases of ifc 7.0 and 7.1 yield "Compiler Internal Error". Update to the last version (should be 7.1.41).

Warnings "size of symbol ... changed ..." are produced by ifc 7.1 a the loading stage. These seem to be harmless, but they may cause the loader to stop, depending on your system configuration. If this happen and no executable is produced, add the following to LDFLAGS: -Xlinker -noinhibit-exec.

Linux distributions using glibc 2.3 or later (such as e.g. RedHat 9) may be incompatible with ifc 7.0 and 7.1. The incompatibility shows up in the form of messages "undefined reference to 'errno' " at linking stage. A workaround is available: see http://newweb.ices.utexas.edu/misc/ctype.c.

2.6.3.5 Linux PCs with MKL libraries

On Intel CPUs it is very convenient to use Intel MKL libraries. They can be also used for AMD CPU, selecting the appropriate machine-optimized libraries, and also together with non-Intel compilers. If configure doesn't find MKL, try configure -enable-shared. Note that ifort 8 fails to load with MKL v. 5.2 or earlier versions, because some symbols that are referenced by MKL are missing There is a fix for this (info from Konstantin Kudin): add libF90.a from ifc 7.1 at the linking stage, as the last library. Note that some combinations of not-so-recent versions of MKL and ifc may yield a lot of "undefined references" when statically loaded: use configure -enable-shared, or remove the -static option in make.sys. Note that pwcond.x works only with recent versions (v.7 or later) of MKL.

MKL contains optimized FFT routines and a FFTW interface, to be separately compiled. For 64-bit Intel Core2 processors, they are slightly faster than FFTW (MKL v.10, FFTW v.3 fortran interface, reported by P. Giannozzi, November 2008).

Important: for parallel (MPI) execution on multiprocessor (SMP) machines, set the environmental variable OMP_NUM_THREADS to 1 unless you know what you are doing. See the section on parallelism for more info on this and on the difference between MPI and OpenMP parallelization.

2.6.3.6 Fun with precompiled libraries

Since there is no standard fortran compiler for Linux, different compilers have different ideas about the right way to call external libraries. As a consequence you may have a mismatch between what your compiler calls ("symbols") and the actual name of the required library call. Use the nm command to determine the name of a library call, as in the following examples:
      nm /usr/local/lib/libblas.a | grep -i 'T daxpy'
      nm /usr/local/lib/liblapack.a | grep -i 'T zhegv'
where typical location and name of libraries is assumed. Most precompiled libraries have lowercase names with one or two underscores (_) appended. configure should select the appropriate preprocessing options in make.sys, but in case of trouble, be aware that: Another potential source of trouble is the incompatibility between I/O libraries used by different fortran compilers. This manifests itself under the form of missing routines with strange names (like s_wsfe, do_fio...) at linking stage. Possible workarounds include If you choose the latter workaround, locate the library containing this routine using nm, for instance:
            nm /path/to/your/libs/libf77blas.a | grep 'T xerbla'
and replace the object xerbla.o in the library with the one you will compile. In flib/:
            make xerbla.o
            ar rv /path/to/your/libs/libf77blas.a xerbla.o
If nothing works, you may need to recompile the libraries with your fortran compiler, or to use the internal (slow) copy.

2.6.4 AMD 32-bit CPUs

AMD Athlon CPUs can be basically treated like Intel Pentium CPUs. You can use the Intel compiler and MKL with Pentium-3 optimization.

Konstantin Kudin reports that the best results in terms of performances are obtained with ATLAS optimized BLAS/LAPACK libraries, using AMD Core Math Library (ACML) for the missing libraries. ACML can be freely downloaded from AMD web site. Beware: some versions of ACML - i.e. the GCC version with SSE2 - crash PWscf. The "nosse2" version appears to be stable. Load first ATLAS, then ACML, then -lg2c, as in the following example (replace what follows -L with something appropriate to your configuration):

   -L/location/of/fftw/lib/ -lfftw \
   -L/location/of/atlas/lib -lf77blas -llapack -lcblas -latlas \
   -L/location/of/gnu32_nosse2/lib -lacml -lg2c

2.6.5 64-bit CPUs

64-bit CPUs like the AMD Opteron and the Intel Itanium are supported and should work both in 32-bit emulation and in 64-bit mode. Both the Portland and the Intel compiler (v8.1 EM64T-edition, available via Intel Premier support) should work. 64-bit executables can address a much larger memory space, but apparently they are not especially faster than 32-bit executables. The Intel compiler has been reported to be more reliable and to produce faster executables wrt the Portland compiler. You may also try g95 or gfortran.

Beware: the default integer type for 64-bit machine is typically 32-bit long. You should be able to use 64-bit integers as well, but it will not give you any advantage and you may run into trouble.


2.6.6 Linux PC clusters with MPI

PC clusters running some version of MPI are a very popular computational platform nowadays. QUANTUM ESPRESSO is known to work with at least two of the major MPI implementations (MPICH, LAM-MPI), plus with the newer MPICH2 and OpenMPI implementation. The number of possible configurations, in terms of type and version of the MPI libraries, kernels, system libraries, compilers, is very large. QUANTUM ESPRESSO compiles and works on all non-buggy, properly configured hardware and software combinations. You may have to recompile MPI libraries: not all MPI installations contain support for the fortran-90 compiler of your choice (or for any fortran-90 compiler at all!). See Axel Kohlmeyer's web site for precompiled versions of the MPI libraries. Very useful step-by-step instructions can be found in the following post by Javier Antonio Montoya:
http://www.democritos.it/pipermail/pw_forum/2008April/008818.htm .

If QUANTUM ESPRESSO does not work for some reason on a PC cluster, try first if it works in serial execution. A frequent problem with parallel execution is that QUANTUM ESPRESSO does not read from standard input, due to the configuration of MPI libraries: see section ''Running on parallel machines'' and Axel Kohlmeyer's web site for more info.

If you are dissatisfied with the performances in parallel execution, read the section on ''Parallelization issues''. See also the following post from Axel Kohlmeyer:
http://www.democritos.it/pipermail/pw_forum/2008-April/008796.html

2.6.7 Intel Mac OS X

Newer Mac OS-X machines with Intel CPUs are supported by configure, with gcc4+g95, gfortran, and the Intel compiler ifort with MKL libraries.

2.6.7.1 Intel Mac OS X with ifort

"Uninstall darwin ports, fink and developer tools. The presence of all of those at the same time generates many spooky events in the compilation procedure. I installed just the developer tools from apple, the intel fortran compiler and everything went on great" (Info by Riccardo Sabatini, Nov. 2007)

2.6.7.2 Intel Mac OS X 10.4 and 10.5 with g95 and gfortran

The stable and unstable versions of g95 are known to work. Recent gfortran versions also work, but they may require an updated version of Developer Tools (XCode 2.4.1 or 2.5), that can be downloaded from Apple. Some tests fails with mysterious errors, that disappear if fortran BLAS are linked instead of system Atlas libraries. Use:

   BLAS_LIBS      = ../flib/blas.a -latlas
(Info by Paolo Giannozzi, jan.2008)


next up previous contents
Next: 3 Parallelism Up: 2 Installing QUANTUM ESPRESSO Previous: 2.5 Running examples Contents
Paolo Giannozzi 2009-10-01