Fatal errors typically begin with a message Exit -1 routine-name message, indicating where and why the program failed.
Sometimes non-fatal, warning messages are given. Usually the message has “(warning)“ or something similar. If the warning is severe, there will be an accompanying exclamation mark, e.g. warning!, which will be logged. For more details see severe warnings in troubleshooting.
In the page below, common error messages are shown together with a brief explanation and solution. Some of the same messages are explained in more detail on the troubleshooting page.
Table of Contents
- unexpected value val1 for file rmt … expected val2
- Problem: this error appears when the restart file (rst.ext or rsta.ext) contains augmentation radii that conflict with the input file.
Solution: Delete the restart file.
- xlgen: added missing plat: ivck= 0 0 1 rmax= 3.856 rpad*rmax= 0.000
- Problem: The missing plat vector warning comes from the subroutine xlgen that determines lattice vectors for Ewald summations. It finds them by locating all lattice vectors inside an enclosing sphere. For accurate Ewald summations, at least one multiple of each of the 3 primitive lattice vectors.
Solution: When the cell becomes long and pencil-like, the sphere is no longer large enough to encompass the long vector, so xlgen just replicates the existing list of vectors, adding to the replica one multiple of the missing primitive lattice vector. This should resolve the problem with no user intervention needed.
- I get 2 messages from xlgen: missing 2 plat - and the code lmstr just stopped
- Problem: This difficulty is the same as the one above, only now the sphere is too small along two lattice vectors. This usually means something is unusual about your cell construction.
Solution: The sphere radius is determined by EWALD_TOL. Try setting it to a smaller number, like 10−12. That will increase the radius and it may resolve the problem.
- RSEQ : nit gt 999 and bad nodes for l=2. Sought 0 but found 1. e=-2.0811D-01
- Problem: this error may occur for a myriad of reasons.
Solution: There is no single way to resolve this problem. See troubleshooting.
- (warning): non-integral number of electrons — possible band crossing at E_f
- Problem: In finding a Fermi level the integrator assigns weights to each state. This message is printed when the sum of weights don’t add up to an integral number of electrons.
Solution: As you proceed to self-consistency it may go away. If not, you need to modify your k mesh, or switch to sampling. It is important the the number of electrons be correctly counted. See also troubleshooting.
- Exit -1 problem in locpot – possibly low LMXA, or orbital mismatch, species nam
- Problem: this error usually occurs when lmfa generate an atm file with a different valence-core partition than is specified by the input file; see description in troubleshooting.
Solution: Re-run lmfa with current conditions.
- warning! local orbital mismatch
- Problem: lmf has found that the local orbitals specified in the input file are not consistent with those in the restart file (rst.ext or rsta.ext), rendering inconsistent valence-core partitioning.
Solution: remove rst.ext and re-run lmf.
- Exit -1 zhev: zhegv cannot find all evals
- Problem: The diagonalizer was unable to calculate all of the eigenvalues. This can happen for several reasons.
Solutions: see the troubleshooting page.
- Exit -1 DIAGNO: tinvit cannot find all evecs
- Problem: The diagonalizer was unable to calculate all of the eigenvalues, using inverse iteration.
Solution: Set BZ_INVIT to false; the QL method will be used. QL is somewhat less efficient but more stable than inverse iteration.
- Exit -1 rdsigm: Bloch sum deviates more than allowed tolerance
- Problem: A failure to carry out an inverse Bloch sum of the QSGW self-energy to sufficient accuracy. This is described in more detail on the troubleshooting page.
- Exit -1 lgen: more than 1 missing plat … try reducing EWALD_TOL
- Problem: There must be at least one primitive lattice vector of each kind in the table of direct lattice vectors for Ewald summations. This error appears when one or more is missing; this can happen especially with long, pencil like cells.
Solution: increase EWALD_TOL (at a modest increase in computational time for Ewald summations).
- hsfp0 ixc=3: ecore>evalence
- Problem: Some core state is higher than the lowest valence state.
Solution: See the troubleshooting page.
- FERMI: Fermi energy lies above EMAX
- Problem: this error is produced by the Fermi level finder, heftet. and indicates that it is unable to find a sensible Fermi level.
This can occur for several reasons, but the most common one is related to a bug in the GW codes. As they are now written, all spheres must have the same augmentation l-cutoff, lmxa.
Solution: Change input file to make LMXA the same for all atoms.
- Exit -1 rdsigm unexpected value 10 for file sigm nqp … expected 64
- Problem: this error is produced when the number of k-points used to make the QSGW self-energy Σ0 is different from what lmf expects. Usually this has to do with change in symmetry, e.g. turning on spin orbit coupling.
Solution: There is more than one solution.
Start from an input file where the symmetry is consistent with sigm.ext and write a Σ0 file without symmetry operations: invoke lmf with --wsig:fbz.
This will generate a file sigm2.ext. Copy it to sigm.ext and invoke lmf with switch --rsig:fbz.
Start from an input file where the symmetry is consistent with sigm.ext and write a Σ0 in a real-space form: invoke lmf with --wsig:rs.
This generates file sigm2rs.ext. Rename this file to sigmrs.ext and invoke lmf with –rsig:rs.
Errors generated by public or system libraries
Errors may originate from generic libraries, e.g. the LAPACK or MKL libraries, or the machine-specific system libraries dealing with, e.g. memory management. Here we document messages that have been encountered by users. The error messages may depend on machine, however.
- APPLICATION TERMINATED WITH THE EXIT STRING: Killed (signal 9)
- Problem: this error was produced when running lmf in MPI mode, and occurred because the job ran out of memory.
Solution: Why lmf may use up too much memory depends on the context. It happened in this case because the user was performing an MPI calculation with 24 processors on one node, and with a very large number of k-points. He was also using BZ_METAL=5.
METAL=5 is designed to speed up the calculation, at the expense of memory consumption: it keeps all the eigenvectors in RAM for every k. In this case there were 54032 k-points, so lmf was holding on to 54032×24 eigenvector matrices.
The solution here is to switch to METAL=3. Eigenvectors are not kept in memory. There is a price however: lmf makes an initial band pass to determine the Fermi level and integration weights. Once they are known it makes a second pass generating quantities derived from the occupation numbers, such as the density. Thus lmf uses a lot less memory at the expense of making 2 band passes.