Questaal Home
Navigation

Frequently Asked Questions and Error Messages

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

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 B4,b={beta}.

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 follow lmf by running 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.


Q6. lmf has both a screened and an unscreened form of hamiltonian. Does the form affect the density and/or the QSGW self-energy?

A. It does not affect the density, to the extent basis set involves a simply a rotation of the hilbert space. The screened form of the basis will be a simple rotation of the unscreened one (provided the smoothing radius and energies are preserved in the screened and unscreened forms) but when the screening is extended to the Jigsaw Puzzle orbital structure, the transformation is no longer a simple rotation. In the latter case, the density will depend on the screening.

The QSGW self-energy (whether static or dynamical) involves matrix elements of the basis functions, and therefore it does depend on the shape of the basis functions. (The phases of the matrix elements also change if an atom in the basis shifts by a lattice translation vector, so it is important that you keep the basis vectors fixed between calculations.) You can use lmf to rotate between screened and unscreened forms with the switch --scrsig. An application of this switch is shown in this tutorial.


Q7. How is the product basis assembled from products of partial waves?

Each product basis function is composed of a product of two partial waves; call them occ and unocc to be explained in more detail below. They are so named with the idea that transitions occur between occupied and unoccupied states, though there is no 1-1 correspondence between the two. All possible combinations of occ and unocc are taken.

In more detail:

  1. Partial waves are divided into core and valence. The total number of partial waves is given by ncore + nval. which are respectively the number of core and valence states. A subset (occ and unocc) of all partial waves is selected out to form the constituents of the product basis.

  2. Thus there are four kinds of partial wave constituents, given by these lists:
    •  noccc  = occ for core states
    •  nunoccc  = unocc for core states
    •  noccv  = occ for core states
    •  nunoccv  = unocc for core states

    noccc ,  nunoccc ,  noccv ,  nunoccv  are lists holding which partial waves are kept, and which are excluded. They are integer arrays dimensioned  (0:lmxa,1:n,1:nat)  with the first and second indices for the l and principal (radial) quantum numbers, and the third is a site index. Each array element is set to 1 to include or 0 to exclude.

  3. There are two kinds of product basis functions: one tailored to calculation of core exchange, the other to calculate exchange+correlation of the valence.
    What constitutes  noccc ,  nunoccc ,  noccv ,  nunoccv , depends on the context.
     Valence partial waves are all selected from the GWinput file as follows
    •  noccc  = taken from the occ column of core section of GWinput
    •  nunoccc  = taken from the unocc column of core section of GWinput
    •  noccv  = taken from the occ column of valence section of GWinput
    •  nunoccv  = taken from the unocc column of valence section of GWinput
      Core partial waves are all selected are partially taken from the GWinput file. The core part is not, however.
    •  noccc  = 1 for all  (0:lmxa,1:n,1:nat)
    •  nunoccc  = 0 for all  (0:lmxa,1:n,1:nat)
    •  noccv  = same as valence product basis
    •  nunoccv  = same as valence product basis
  1. A final selection of the product basis is a new pair of lists (nocc, nunocc) obtained by merging ( noccc ,  noccv ) for occ, and ( nunoccc ,  nunoccv ) for unocc:
    •  nocc(l,1:ncore,ib)  is copied from  noccc (l,1:ncore,ib)
    •  nocc(l,1+ncore:+nval+ncore,ib)  is copied from  noccv (l,1:nval,ib)
      and similarly for  nunocc.

Note: the GW code stores information about ncore and nval in integer arrays  nrphic(l,ib)  and  nrphiv(l,ib).

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. lmchk --angles:r=3.

Band codes

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

Solution: increase HAM_RSRNGE (at a slight increase in cost) or HAM_RSSTOL (at an loss in accuracy).
HAM_RSRNGE defaults to 5 (in units of the lattice constant); HAM_RSSTOL defaults to 5×10−6.

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 extended local orbitals temporarily disabled (nonhermitian ppi)
Problem: Extended local orbitals do not stop at the MT sphere, but a tail is attached so they spill out of it. The v8 version of lmf does not have this implemented.

Solution: Convert any extended LO in the basis to a conventional one. LO’s are defined by the PZ tag, and if the 10’s digit is set, it is an extended LO. To resolve the problem, remove the 10’s git from any PZ, preserving the 1’s digit, and fractional part. (Typically basis set parameters are defined in basp.ext. If that’s where you defined them, look for PZ in that file.)

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.

GW code

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.

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

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