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

Subsections

2.7 Installation tricks and problems

2.7.1 All architectures

2.7.2 Intel Xeon Phi

For Intel Xeon CPUs with Phi coprocessor, there are three ways of compiling: "You can take advantage of the offload mode using the libxphi library. This library offloads the BLAS/MKL functions on the Xeon Phi platform hiding the latency times due to the communication. You just need to compile this library and then to link it dynamically. The library works with any version of QE. Libxphi is available from https://github.com/cdahnken/libxphi. Some documentation is available therein.

Instead, if you want to compile a native version of QE, you just need to add the -mmic flag and cross compile. If you want to use the symmetric mode, you need to compile twice: with and without the -mmic flag". "[...] everything, i.e. code+libraries, must be cross-compiled with the -mmic flag. In my opinion, it's pretty unlikely that native mode can outperform the execution on the standard Xeon cpu. I strongly suggest to use the Xeon Phi in offload mode, for now" (info by Fabio Affinito, March 2015).

2.7.3 Cray machines

(This section is likely obsolete)

For Cray XE machines:

$ module swap PrgEnv-cray PrgEnv-pgi
$ ./configure --enable-openmp --enable-parallel --with-scalapack
$ vim make.inc
then manually add -D__IOTK_WORKAROUND1 at the end of DFLAGS line.

''Now, 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. So my recipe should work, 99% of the cases.'' (info by Filippo Spiga)

For Cray XT machines, use ./configure ARCH=crayxt4 or else configure will not recognize the Cray-specific software environment.

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

2.7.4 IBM BlueGene

The current configure was working on the machines at CINECA and at Jülich. For other machines, you may need something like

  ./configure ARCH=ppc64-bg BLAS_LIBS=...  LAPACK_LIBS=... \
              SCALAPACK_DIR=... BLACS_DIR=..."
where the various *_LIBS and *_DIR "suggest" where the various libraries are located.

2.7.5 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 Intel (ifort), NAG (nagfor), PGI (pgf90) and gfortran compilers. Pathscale, Sun Studio, AMD Open64, are no longer supported after v.6.2: g95, since v.6.1.

Both Intel MKL and AMD acml mathematical libraries are supported, the former much better than the latter.

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).

2.7.5.1 Linux PCs with gfortran

You need at least gfortran v.4.4 or later to properly compile QUANTUM ESPRESSO.

"There is a known incompatibility problem between the calling convention for Fortran functions that return complex values: there is the convention used by g77/f2c, where in practice the compiler converts such functions to subroutines with a further parameter for the return value; gfortran instead produces a normal function returning a complex value. If your system libraries were compiled using g77 (which may happen for system-provided libraries in not-too-recent Linux distributions), and you instead use gfortran to compile QUANTUM ESPRESSO, your code may crash or produce random results. This typically happens during calls to zdotc, which is one the most commonly used complex-returning functions of BLAS+LAPACK.

For further details see for instance this link:
http://www.macresearch.org/lapackblas-fortran-106#comment-17071
or read the man page of gfortran under the flag -ff2c.

If your code crashes during a call to zdotc, try to recompile QUANTUM ESPRESSO using the internal BLAS and LAPACK routines (using iconfigure 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).

Note that a similar problem with complex functions exists with MKL libraries as well: if you compile with gfortran, link -lmkl_gf_lp64, not -lmkl_intel_lp64, and the like for other architectures. Since v.5.1, you may use the following workaround: add preprocessing option -Dzdotc=zdotc_wrapper to DFLAGS.

2.7.5.2 Linux PCs with Intel compiler (ifort)

IMPORTANT NOTE: ifort versions earlier than v.15 miscompile the new XML code in QE v.6.4 and later. Please install this patch:
https://gitlab.com/QEF/q-e/wikis/Support/Patch-for-old-Intel-compilers.

The Intel compiler ifort http://software.intel.com/ produces fast executables, at least on Intel CPUs, but not all versions work as expected. 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.

The Intel compiler is no longer free for personal usage, but it is still for students and open-source contributors (https://software.intel.com/en-us/qualify-for-free-software).

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. Warnings on ``bad preprocessing option'' when compiling iotk and complains about ``recommended formats'' may also be ignored.

2.7.5.3 Linux PCs with MKL libraries

On Intel CPUs it is very convenient to use Intel MKL libraries (freely available at https://software.intel.com/en-us/performance-libraries). MKL libraries can be used also with non-Intel compilers. They work also for AMD CPU, selecting the appropriate machine-optimized libraries, but with reduced performances.

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:
http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/.

For parallel (MPI) execution on multiprocessor (SMP) machines, set the environment variable OMP_NUM_THREADS to 1 unless you know what you are doing. 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: http://www.mail-archive.com/pw_forum@pwscf.org/msg29684.html.

2.7.5.4 Linux PCs with ACML libraries

For AMD CPUs, especially recent ones, you may find convenient to link AMD acml libraries (can be freely downloaded from AMD web site). configure should recognize properly installed acml libraries.


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


2.7.7 Microsoft Windows

MS-Windows users may compile QUANTUM ESPRESSO on MinGW/MSYS. Download the installer from https://osdn.net/projects/mingw/, install MinGW, MSYS, gcc and gfortran. Start a shell window; run "./configure"; edit make.inc; 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
http://www.cygwin.com/.

Finally, Windows-10 users may enable the Windows Subsystem for Linux (see here:
https://docs.microsoft.com/en-us/windows/wsl/install-win10), install a Linux distribution, compile QUANTUM ESPRESSO as on Linux. It works very well.

2.7.8 Mac OS

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.

Gfortran information and binaries for Mac OS-X here: http://hpc.sourceforge.net/ and https://wiki.helsinki.fi/display/HUGG/GNU+compiler+install+on+Mac+OS+X.

Mysterious crashes, occurring when zdotc is called, are due to the same incompatibility of complex functions with some optimized BLAS as reported in the "Linux PCs with gfortran" paragraph. Workaround: add preprocessing option -Dzdotc=zdotc_wrapper to DFLAGS.


next up previous contents
Next: 3 Parallelism Up: 2 Installation Previous: 2.6 Running tests and   Contents
Paolo Giannozzi 2019-04-18