This page bundles together answers to frequently asked questions, and also error messages users have encountered.
As for the latter, 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.
Common error messages are shown together with a brief explanation and solution here, and some of the same messages are explained in more detail on the troubleshooting page.
Table of Contents
- Frequently asked questions
- General error messages
- Band codes
- GW code
- Errors generated by public or system libraries
Frequently asked questions
Q1. When I draw the energy bands, the position of Fermi isn’t where it should be. In particular when I use
plbnds -ef=0 ... the Fermi level is not at zero as I expect. What is wrong?
A. The fermi level is read from file wkp.ext. If conditions change so that the fermi level changes, run
lmf --quit=rho ... to update wkp.ext for the current setup. Rerun
lmf --band... with the same setup. See also the troubleshooting page.
Alternatively you can modify the Fermi level in wkp.ext by hand (it appears on the first line). It is printed in the standard output of lmf.
Q2. I ran a Questaal code like lmgf, and it stops with an error message while the input file is being read. How to I find the problem?
A. If a program stops, try running, e.g.
lmgf --show=2: it will print out each tag it parses until it gets to the one where it fails. Using this switch possibly in conjunction with
lmgf --input, which lists all the tags it would read in order it would read them, helps you to isolate the the problem.
Q3. My ctrl file has these lines
% const beta=0.3 EXPRESS mix= B4,b=beta
Yet codes like lmgf crashes when parsing this input. What is wrong?
A. beta is declared as a preprocessor variable. This is distinct from variables declared in the CONST category. Expressions using preprocessor must be enclosed in curly brackets, so in the above example the argument should read
Alternatively you can include beta in a CONST category, viz
CONST beta=0.3 EXPRESS mix= B4,b=beta
Q4. Some codes like lmstr successfully read an input file successfully, but others like lmgf stop with an error. How can that be?
A. One program may parse an input file while another fails because each code reads its own set of tags.
Q5. Codes like lmf print out the total DOS at the Fermi level, but not resolved by spin. Is is possible to get the spin-resolved DOS at EF ?
A. lmf cannot do this, but you can run lmdos with the
--totdos switch, and it will make the DOS resolved by spin. From the generated DOS, you have to select the energy you need, e.g. EF.
General error messages
- Exit -1 SGROUP: ng greater than ###
- Problem: this error (or similar errors) can appear when the site positions are slightly incompatible with space group operations. The solution is to refine the positions of the lattice vectors. The codes have --tidy switch that fixes most problems, but sometimes the switch alone is not enough. See this tutorial or the troubleshooting page.
Related messages are:
Exit -1 FIXPOS: positions incompatible with symgrp (see this example)
Exit -1 SGROUP: ng greater than ngmx=… (see this example)
Exit -1 GRPGEN: too many elements (see this example)
Exit -1 BRAVSY : inconsistent threefold rotations (specific to blm; see this example)
Exit -1 CVPLAT : : could not calculate platcv (specific to blm; see this example)
Exit -1 bug in pfixplat (see this page)
MKSYM (warning): generators create more than ngmx=… group ops
Warning! symmetry operations not consistent with Bravais lattice! (see this example)
- Exit -1 m_rdctrl: parse in parmxp failed
- Problem: this error (or similar errors) appear when the parser unsuccessfully attempts to read an algebraic expression.
Solution: Correct the expression. For an example, see Q2 above.
- Exit -1 rdfiln: endif encountered before if
- Problem: Preprocessor instructions to the input file have an unbalanced % if … % endif block.
Solution: Balance the conditional blocks. If you have trouble locating the problem (this often happens if you have nested blocks or loops), try putting a line % trace 4 before the offending block. The preprocessor will tell you what it is doing while as reads each line.
- 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.
- NGHBOR: too many pairs …
- Problem: this may happen in different contexts, e.g. running
lmchk --angles. The default radius for creating neighbor tables (tables of atom pairs) is too small, which may occur if the length of one or more of the lattice vectors (PLAT) are signifcantly larger than unity.
Solution: A general solution is to modify the input file by scaling PLAT by some factor less than unity, and scaling ALAT by its inverse.
In some contexts you can fix the problem by increasing the radius fed to the neighbor table maker, e.g.
- (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).
- Exit -1 pairc: table exceeds input maximum size, nnnn
- Problem: This can occur when an executable such as lmchk runs out of memory when building a neighbor table, e.g. doing something like
lmchk --shell:tab .... It should rarely occur, but it can happen that the internal algorithm which chooses a maximum allocation is working outside normal conditions.
Solution: For most applications, the default cluster size is selected from a characteristic radius. There is a default value, but you can set this variable manually in the ctrl file with tag STR_RMAXS. In the special case you encounter a problem running
lmchk --shell:tab, add a modifier
lmchk --shell:tab:mxcsiz=nnnn. If you pick nnnn large enough the problem should go away.
- 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.