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:
ON ENTRY TO ZHPEV PARAMETER NUMBER 1 HAD AN ILLEGAL VALUEis 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.
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_cos2at 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).
Version 2.99 of the Pathscale compiler works and is recognized by configure, but the preprocessing step:
pathcc -Ecauses a mysterious error in compilation of iotk and should be replaced by
/lib/cpp -P --traditionalThe MVAPICH parallel environment with Pathscale compilers also works. (info by Paolo Giannozzi, July 2008)
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.
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.
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.
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:
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.oIf nothing works, you may need to recompile the libraries with your fortran compiler, or to use the internal (slow) copy.
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
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.
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
Newer Mac OS-X machines with Intel CPUs are supported by configure, with gcc4+g95, gfortran, and the Intel compiler ifort with MKL libraries.
"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)
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)