next up previous contents
Next: 3 Parallelism Up: 2 Installation Previous: 2.8 Running tests and examples   Contents


2.9 Installation tricks and problems

2.9.1 All architectures

2.9.2 Linux PC

Both AMD and Intel CPUs, 32-bit and 64-bit, are supported and work, either in 32-bit emulation and in 64-bit mode. 64-bit executables can address a much larger memory space than 32-bit executable, but there is no gain in speed. 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 is not guaranteed to work and will not give any advantage anyway.

Currently, configure supports gfortran and the Intel (ifort), NVidia (nvfortran, formerly PGI pgf90) compilers. ARM (armflang) and NAG (nagfor) compilers are supported but little tested and may or may not work. Pathscale, Sun Studio, AMD Open64, are no longer supported after v.6.2; g95, since v.6.1.

Intel MKL mathematical libraries are supported. ACML support must be considered as obsolete.

It is usually convenient to create semi-statically linked executables (with only libc, libm, libpthread dynamically linked). 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). Linux PCs with gfortran

Gfortran v.4.8.5, still found on CentOS machines, no longer compiles QUANTUM ESPRESSO v.6.6 or later, due to a gfortran bug. You need at least gfortran v.4.9.X.

"There is a known incompatibility problem between different calling convention for Fortran functions that return complex values [...] If your code crashes during a call to zdotc, recompile QUANTUM ESPRESSO using the internal BLAS and LAPACK routines (using configure options –with-internal-blas and –with-internal-lapack) to see if the problem disappears; or, add the -ff2c flag" (info by Giovanni Pizzi, Jan. 2013). You may also consider replacing the offending calls to zdotc with fortran intrinsic dot_product.

If you want to use MKL libraries together with gfortran, link -lmkl_gf_lp64, not -lmkl_intel_lp64. Linux PCs with Intel compiler (ifort)

The Intel compiler ifort produces fast executables, at least on Intel CPUs, but not all versions work as expected. In particular, ifort versions earlier than v.15 miscompile the new XML code in QE v.6.4 and later and should not be used any longer. In case of trouble, update your version with the most recent patches. Since each major release of ifort differs a lot from the previous one, compiled objects from different releases may be incompatible and should not be mixed.

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.

The warning: feupdateenv is not implemented and will always fail, can be safely ignored. Complains about ``recommended formats'' may also be ignored. Linux PCs with MKL libraries

On Intel CPUs it is very convenient to use Intel MKL libraries (freely available at MKL libraries can be used also with non-Intel compilers. They work also for AMD CPU, selecting the appropriate machine-optimized libraries: see ``Linux PCs with AMD processors''.

configure properly detects only recent (v.12 or later) MKL libraries, as long as the $MKLROOT environment variable is set in the current shell. Normally this environment variable is set by sourcing the Intel MKL or Intel Parallel Studio environment script. By default the non-threaded version of MKL is linked, unless option configure –with-openmp is specified. In case of trouble, refer to the following web page to find the correct way to link MKL:

For parallel (MPI) execution on multiprocessor (SMP) machines, set the environment variable OMP_NUM_THREADS to 1 unless you know how to run MPI+OpenMP. See Sec.3 for more info on this and on the difference between MPI and OpenMP parallelization.

If you get a mysterious "too many communicators" error and a subsequent crash: there is a bug in Intel MPI and MKL 2016 update 3. See this thread and the links quoted therein: Linux PCs with AMD processors

For AMD CPUs you may find convenient to link AMD acml libraries (can be freely downloaded from AMD web site). configure should recognize properly installed acml libraries. UPDATE (February 2020): acml have been discontinued. There are new libraries called AMD Optimizing CPU Libraries (AOCL), tuned for the AMD EPYC processor family. `` Recently I played around with some AMD EPYC cpus and the bad thing is that I also saw some strange numbers when using libflame/aocl 2.1. (...) Since version 2020 the MKL performs rather well when using AMD cpus, however, if you want to get the best performance you have to additionally set:
which gives an additional 10-20% speedup with MKL 2020, while for earlier versions the speedup is greater than 200%. [...] Another note, there seem to be problems using FFTW interface of MKL with AMD cpus. To get around this problem, one has to additionally set
`` (Info by Tobias Klöffel, Feb. 2020)

2.9.3 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. configure should automatically recognize a properly installed parallel environment and prepare for parallel compilation. Unfortunately this not always happens. In fact:

Apart from such problems, QUANTUM ESPRESSO compiles and works on all non-buggy, properly configured hardware and software combinations. In some cases you may have to recompile MPI libraries: not all MPI installations contain support for the Fortran compiler of your choice (or for any Fortran compiler at all).

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 Sec.3.5. If you are dissatisfied with the performances in parallel execution, see Sec.3 and in particular Sec.3.5.

2.9.4 Microsoft Windows

Since February 2020 QUANTUM ESPRESSO can be compiled on MS-Windows 10 using PGI 19.10 Community Edition (freely downloadable). configure works with the bash script provided by PGI but the configure of FoX fails: use script install/ to manually compile FoX.

Another option: use MinGW/MSYS. Download the installer from, install MinGW, MSYS, gcc and gfortran. Start a shell window; run "./configure"; edit; uncommenting the second definition of TOPDIR (the first one introduces a final "/" that Windows doesn't like); run "make". Note that on some Windows the code fails when checking that tmp_dir is writable, for unclear reasons.

Another option is Cygwin, a UNIX environment which runs under Windows: see

Windows-10 users may also enable the Windows Subsystem for Linux (see here:, install a Linux distribution, compile QUANTUM ESPRESSO as on Linux. It works very well.

As a final option, one can use Quantum Mobile:

2.9.5 Mac OS

"I have had some success compiling pw.x on the newish apple hardware. Running run-tests-pw-parallel resulted in all but 3 tests passed (3 unknown). QE6.7 works out of the box:

To configure QE:
./configure FC=mpif90 CC=mpicc CPP=cpp-11 BLAS_LIBS="-L/opt/homebrew/lib
           -lveclibfort" LIBDIRS=/opt/homebrew/lib
Current develop branch needed two changes:
  1. The script external/devxlib/config/config.sub is outdated, and needs to be adjusted to correctly parse the machine information. I pulled a more up-to-date version from iains/gcc-darwin-arm64 github repo
  2. PW/src/efermig.f90 needed to be compiled without optimization -O0. No idea why at the moment."
(Info by John Vinson, NIST)

Mac OS-X machines with gfortran or with the Intel compiler ifort and MKL libraries should work, but "your mileage may vary", depending upon the specific software stack you are using. Parallel compilation with OpenMPI should also work.

If you get an error like

  clang: error: no input files
  make[1]: *** [laxlib.fh] Error 1
  make: *** [libla] Error 1i
redefine CPP as CPP=gcc -E in

Gfortran information and binaries for Mac OS-X here: and

Mysterious crashes in zdotc are due to a known incompatibility of complex functions with some optimized BLAS. See the "Linux PCs with gfortran" paragraph.

2.9.6 Cray machines

''... despite what people can imagine, every CRAY machine deployed can have different environment. For example on the machine I usually use for tests [...] I do have to unload some modules to make QE running properly. On another CRAY [...] there is also Intel compiler as option and the system is slightly different compared to the other.'' (info by Filippo Spiga)

For recent Cray machines, use ./configure ARCH=craype. This selects the ftn compiler, that typically uses the crayftn compiler but may also use other ones, depending upon the site and personal environment. ftn v.15.0.1 compiles QE properly. With the PrgEnv-cray module v.6.0.10, ftn v.14.0.3, you run into the following problems:

Workaround: compile codes esm_stres_mod.f90, Modules/qexsd*.f90, PW/src/pw_restart_new.f90 with reduced optimization, using -O0 or -O1 instead of the default -O3,fp3 optimization.

If you want to use the Intel compiler instead, try something like:

$ module swap PrgEnv-cray PrgEnv-intel
$ ./configure ARCH=craype [--enable-openmp --enable-parallel --with-scalapack]

Old Cray machines: T3D, T3E, X1, etc, are no longer supported.

next up previous contents
Next: 3 Parallelism Up: 2 Installation Previous: 2.8 Running tests and examples   Contents