9. Spex FAQ¶
Configuration stops with “MPI-3 compiler requested, but couldn’t use MPI-3.”
Your MPI compiler does not support the MPI-3 standard, which is required for the parallelized version. Make sure that the correct compiler is used. You can specify the compiler with the environment variables
MPIFC, e.g., directly on the command line
./configure --enable-mpi MPIFC=mpif90.
Configuration stops with “Could not compile with HDF5.”
This problem occurs quite often. It can be caused by one of the following reasons: (1) you do not have the HDF5 library, (2) you have HDF5, but it is not installed in a standard directory (then, use the option
--with-hdf5to specify the HDF5 root directory, e.g.,
./configure --with-hdf5=<path-to-hdf5>, which should contain “<path-to-hdf5>/lib” and “<path-to-hdf5>/include”; alternatively, you can specify the location of the include file “hdf5.mod” with the option
--with-includedir=<path-to-hdf5-include>), or (3) you have the HDF5 library, but it has been compiled with a different compiler than the one you are using for compiling Spex. In the latter case (3), please note that you might be using a different compiler than you think. (For example, even after loading a particular compiler module, some systems still use a different Fortran compiler, often GFortran, by default if you do not specify otherwise.) Then, you should use the environment variables
MPIFCas described before.
Configuration stops with “Could not link HDF5 library.”
The linker does not find the HDF5 library. This can happen if the HDF5 library is installed in a non-standard directory (as is the case with many computer systems). In this case, you can use the option
--with-hdf5=<path-to-hdf5>(see above) or you specify the location of the HDF5 library with the option
--with-libdir=<path-to-hdf5-lib>. Consult your system administrator to inquire about the correct path.
Configuration stops with “Could not link parallel HDF5 library.”
Your HDF5 library has been compiled without parallelization support. This is actually not an error anymore. Spex can be compiled with the serial HDF5 version.
You can get further information from the file “config.log”.
My compiler fails to compile the source.
In case of compiler errors, the first thing to try is cleaning up with
make cleanbefore running
make. If this does not solve the problem, please inform us. We have successfully compiled and run the code with the Intel Fortran compiler (since version 12.1.3), GFortran (since version 4.9), and NAG Fortran (since version 6.2 6214). As of May 2018, PGI compilers have a bug (TPR 23745) that prevents compilation of the Spex code. For the parallelized version, we have used Intel MPI, MPICH, and Open MPI.
My compiler fails to link the object files.
If the configuration step has run successfully (with the same system configuration), linking the object files should work. In any case, before reporting a problem, please try cleaning up before compilation:
make clean ; make.
I want to interface Spex to my own DFT program.
The data transfer between the DFT program and Spex is controlled by the routines in “readwrite_PROG.f” (where PROG stands for the name of the DFT program). You will have to create this file (if it does not exist yet). A template file “readwrite_tmpl.f” with explanations is provided with the source. The new file “readwrite_PROG.f” is included in the build process by reconfiguring (
./configure) with the option
Spex needs too much memory.
Try reducing the maximally allowed memory storage with the keyword
MEM. Have a look at the parameters of your calculation. Too high parameters can easily exhaust the computer memory. For example, the calculation of spectra usually requires the storage of large (polarization) matrices for each frequency of the mesh. Dividing the large frequency mesh into several smaller ones (see Sec. Section 5.3) might help in this case. Furthermore, note that the keyword
STOREBZrequires a lot of memory.
Degenerate quasiparticle states have slightly different energies or I get slightly different results at equivalent k points
There are several possible reasons for this:
- In your DFT output groups of degenerate states are cut at the top. Then you should specify
- In the calculation of the susceptibility groups of degenerate states are split into different packets. This can only be avoided with a larger
- The tetrahedron method breaks the symmetry. You can use
GAUSSto test this.
My GW calculations converge badly wrt the k-point set.
This might be caused by using the keyword
ZEROfor systems with small band gaps (e.g. GaAs). In this case, try without
ZERO, which should guarantee a smooth (but slower) convergence.
My calculations do not converge wrt the number of bands.
The parameters are not completely independent. If you increase the number of bands, you might need a higher G cutoff (
MBASIS). You might also have to increase the number of frequencies for sampling the spectral function. Instead, you can also specify the value of the first nonzero frequency point as the first argument to
FSPEC. Then the number of frequencies automatically increases as you increase the number of bands.
The real-space (reciprocal-space) summation in the routine structureconstant takes very long.
There are jumps in the band structure.
Band structures should be calculated without the keyword
ZERO. In the case of a metal a jagged band structure (especially in Hartree-Fock) might also be caused by the tetrahedron method. Then you must improve the k-point sampling. Alternatively, you may try the Gauss integration method (
9.4. Error Messages¶
This is not a complete list of errors. In many error messages a possible solution is already indicated. These are not listed.
The program might also stop at places where this is not supposed to happen. Then, the error message starts with
SPEX-BUG (see Section 3.3).
In this case you should contact the developers. Error messages have the form
SPEX-ERROR (source.f:0123) Error message, where
“source.f” is the name of the source file and 0123 is the respective line where the error occurred. We shorten this to
(source.f) Error message in this list.
(read_write.f) k-point sets inconsistent (check …)
This error usually occurs if the k-point set defined in “spex.inp” (keyword
BZ) conflicts with the one the DFT program has used for writing the input data. Make sure that the k-point sets are identical by generating the k-point set with Spex and running the one-shot DFT calculation in the proper order (steps 2 and 3 in Section 2). (Only for older versions:) The error can also be caused by the internal structure of the direct-access binary file containing the wavefunction data. Make sure that Spex and the DFT code are compiled in such a way that these files are treated identically.
(global.f) argument not an element of k-point set.
This error can be caused by inconsistent k-point sets, too. (See previous error message!) The error might also occur if the k points defined by
KPTare not elements of the set (labels other than
+), for example, if you use a definition with square brackets (such as
KPT A=[1,1,0]), but the lattice constant is not properly defined (such definitions are interpreted with respect to the lattice constant). It is recommended to use internal coordinates (such as
KPT A=(0,0,1)). See Section 5.1.2.
(coulombmatrix.f) Negative eigenvalue.
Your Coulomb matrix seems to be underconverged. Try to increase the parameter
LEXP. If this does not solve the problem, the reason might be that the LAPACK routine fails to solve the general eigenvalue problem because of a nearly singular overlap matrix. Then you might try the option
CUTZEROwhich removes linear dependencies from the overlap matrix and reattempts the diagonalization. The accuracy of the Coulomb matrix can be tested with the (undocumented) keywords
STEPRAD(all in section
(getinput.f) Defective symmetry transformation matrix.
A calculated symmetry transformation matrix turned out to be non-unitary. This is usually caused by insufficient precision of the lattice basis vectors provided by the DFT program. The obvious solution is to make sure that the lattice basis vectors are defined with sufficient precision in the DFT calculation. In particular, they have to conform to the crystal symmetries with a precision of at least twelve significant digits.
(getinput.f) Symmetry operation … rotates spin quantization axis.
Similarly to the previous one, this error is caused by insufficient precision: Spex expects the spin-quantization axis to be invariant with respect to the crystal symmetries in the case of non-collinear magnetism. Obvious solution: Make sure that the spin-quantization axis is defined with sufficient precision in the DFT run.
Both errors are caused by eigenstates (read from the DFT output) that are symmetry broken, i.e., they do not reflect sufficiently the crystal symmetries. This could be a problem of the DFT code. At the moment, there is no general solution to this problem. The second error can be circumvented by setting the parameter
irrep_thresholdin “irreps.f” to 0, which might lead to slower calculations. As a last resort, you can set the keyword
NOSYM(Section 4.2.9), which switches off usage of symmetry.
(quasiparticle.f) Solution of quasiparticle equation did not converge after 5000 iterations.
If you use analytic continuation (
CONTINUE), you probably have poles very close to the real frequency axis (normally with a small weight). Usually a slight change of parameters solves the problem. You can also try to use the keyword
SMOOTH(Section 5.1.9). In the case of contour integration (
CONTOUR), strong spectral structure in the self-energy can cause this problem. For example in metallic systems, a small Drude frequency can give rise to a delta-like peak in the self-energy. A possible solution in this case is to use
PLASMA METAL(Section 5.2.3).
(Hwrapper.f) Fatal HDF5 error.
An error in the HDF5 library has occurred. There will be more informative error messages issued by the library itself. A possible reason could be that the HDF5 file misses a particular data set or attribute. In this case, make sure that the DFT program and Spex are called in the proper order (Section 2 and Section 8). If this does not solve the problem, please report the error. (Note that the same error can also occur in the source files “read_write.f”, “correlation.f”, and “correlation_wannier.f”.)
The following error messages are displayed when the program run was terminated abnormally by the operating system.
error while loading shared libraries: lib…: cannot open shared object file: No such file or directory
The library “lib…” is not found in standard directories. In this case, the location of the library has to be defined in the environment variable
LD_LIBRARY_PATHof the shell. (Consult your Unix or Linux manual.)
A forbidden area of memory was accessed during the program run. First, you should make sure that the operating system allows unlimited size of stack memory. You can set the stack size from the shell (BASH:
ulimit -s unlimited, CSH:
limit stacksize unlimited). As an alternative, some compilers provide options to prevent the usage of stack memory (e.g.,
-heap-arraysin the Intel Fortran Compiler). If this does not solve the problem, it is possible that the error is caused by a real bug in the Spex code. Please report such an error. You can help the developers by running the same calculation again with a Spex executable that has been compiled with
make ADD=-DCHECK(slower execution). Please send the resulting output. Unfortunately, compilers and libraries can have bugs themselves. It is not unlikely that the “segfault” is caused by such a bug. Therefore, it is worthwhile to recompile with different compilers and/or libraries and run the program again.