Solutions To Common Problems

Table of Contents


Generally, your directory should be cleaned after every complete simulation. For example, if you run a simulation involving si, edit the input files and then rerun the si simulation, you may get conflicts as old information about si simulation runs still exist in the directory.

It is thus good practise to clean your directory of unnecessary files before a new simulation (only files related to the material in question need be cleaned), especially cleaning the rst.* files.

Also, you should inspect the standard output! Particularly look out for the ‘warning logged’ (issue [0]).

0. Warning logged

If a Questaal program prints a warning message in the Exit message

~~ Exit xx [1 warning logged] … ~~

it means that a significant problem was encountered which should be investigated (Note: not all warnings are logged.) The standard output should have printed a message containing the string  warning!.

1. Unexpected MT radius

If you get an error similar to the following:

unexpected value # for file rmt ... expected #

it is probably because you have an mismatched restart file rst.ext which contains information from previous runs. This information, should you change your input files, could become invalid for the current simulation and thus cause errors.

Generally, when running a simulation that involves different/edited input files, you should delete the rst.* file for that simulation. E.g., if you’re running a simulation for si


2. Problems with Radial Schrodinger equation solver

A message like this may appear:

RSEQ : nit gt999 and bad nodes for l=2.  Sought 0 but found 1.  e=-2.0811D-01

This can occur for a myriad of reasons, usually because something is amiss in the potential (issue [3]), or because the linearization energy is too far out of range (issue [4]).

3. Small errors in radial integration, ASA

The Questaal codes integrate partial waves on a radial mesh.

It turns out that the algorithm it uses can become unstable in the ASA, when GGA functionals are used. This is becase very small discontinuities can appear in the second energy derivative of the partial wave, at the point where the inward- and outward- radial integrations meet. This tiny error gets amplified by the GGA, which since the potential involves gradients and laplacians of the density.

The resolution to this is to add 4 to whatever value you have selected (if any so far) to tag HAM_QASA.

This switch causes the integrator to integrate only outwards when making and . (The standard procedure is to integrate inwards and outwards to a middle point, and join the solution). Outward-only integration can be slightly erroneous when states are deep and core-like (when the wave function is decaying exponentially away from the nucleus), but in the ASA you are not likely to have a valence state where this is a significant issue.

4. Bad logarithmic derivative parameters

The linear method approximates the energy-dependent partial wave with a first-order Taylor series about a linearization energy, traditionally called . Normally you do not specify in the Questaal package, but the continuously varying principal quantum number Pl. You can specify Pl yourself (indeed on getting started an initial estimate is necessary), but normally the codes will float this quantity in the course of a self-consistency cycle.

4.1 P is too small

It may happen that Pl is floated to a value that is too small (referring to the fractional part of Pl). This can happen if the natural band center is far above the Fermi level, e.g. the Ga state. lmf mostly protects against this by not allowing Pl to fall below the free electron value but the ASA codes do not. This is intentional, because what value is acceptable depends on whether the state is folded down or not. (lmf does not have this capability yet.)

By default lmf uses as a lower bound three free electron value for Pl. This is usually adequate. If HAM_AUTOBAS_GW is true, the lower bound is set a little bit higher. This is because in the GW case, the unoccupied states also affect the potential, so there is a higher demand on the precision of states above the Fermi level.

You can also freeze Pl with token SPEC_ATOM_IDMOD.

4.2 P is too large

It may happen that Pl is floated to a value that is too large (referring to the fractional part of Pl), i.e. too close to 1. This can happen if the natural band center is very deep; this can occur when using lmf with local orbitals. Usually it is not an issue, but if it is, you can set PZ to a fixed value and freeze it with SPEC_ATOM_IDMOD.

It can also happen that the floating algorithm goes haywire and puts Pl unrealistically high. This is rare, but it occurs occasionally. A classic example appears when carrying out a QSGW calculation for Ni, where the usual floating algorithm tries to set Pd=3.96 (it should be about 3.85).

The resolution to this is to revert to lmf’s traditional floating algorithm. By default lmf’s uses a new algorithm introduced by Takao Kotani with the advent of version 7.0. We make the newer scheme the default because should in principle be slightly better (in practice there is little difference), but for reasons unknown it occasionally develops problems.

The choice of floating algorithm is buried in the second argument to this tag, input through either express_autobas_pfloat or HAM_AUTOBAS_PFLOAT. You can find a brief description of the tag by running

lmf --input

To select the traditional floating algorithm, set the second element of pfloat to zero, e.g.

express autobas[... pfloat=2,0]

Note: If you build the input file with the blm utility, you can cause it to autoselect this algorithm by invoke blm with switch  --clfloat.

Alternatively, you can freeze Pl with token SPEC_ATOM_IDMOD, but usually the floating algorithm will make a better choice.

4.3 PZ is too large

The local orbital’s version of P (called PZ) can occasionally become too large for deep lying states. If you freeze it with SPEC_ATOM_IDMOD, both PZ and the usual valence P are frozen. For an example see this tutorial

5. Inconsistent treatment of local orbitals

5.1 Inconsistent contents of local orbitals in the restart file

When reading the restart file, lmf may produce a message like this:

         site   1:Se      :file pz  is  0.00  0.00  0.00  0.00
                          given pz  is  0.00  0.00  3.90  0.00
                          warning!  local orbital mismatch

it is telling you that the local orbitals you specify in the input file are not consistent with those in the restart file. If this happens, remove rst.ext and re-run lmf.

This mismatch flags a warning, which is logged

5.2 Error in reading the atm file

When reading the file atm.ext, lmf may abort with an error message like this:

 is=1 qsc0=10 qsca=10 qc=28 qc0=28
 Exit -1 problem in locpot -- possibly low LMXA, or orbital mismatch, species Se

It can happen for more than one reason, but the most common is that lmfa generated the atm file with a valence-core partitioning different from what lmf expects. Usually this means you invoked lmfa with a different set of local orbitals than you are using now. The solution is to run lmfa again with the same input conditions as lmf expects.

6 Non-integral number of electrons

You may encounter this message, especially when using the tetradron method

 (warning): non-integral number of electrons --- possible band crossing at E_f

It probably means that there is a band crossing close to the Fermi level that confused the tetrahedron integrator. See this page for further description.

The resolution to this is to change the number of k divisions. In can happen that the problem will resolve itself in the course of the self-consistency cycle, as the potential changes.

7 Inexact Inverse Bloch transform

This error may appear when the (static) self-energy Σ0 is read from disk, causing the program to stop

 Oops!  Bloch sum deviates more than specified tolerance:
   i   j      diff              bloch sum                file value
   1   1    0.000020     -0.020464    0.000000     -0.020443    0.000000
 Try increasing HAM_RSRNGE or HAM_RSSTOL

This occurs when the inverse Bloch sum of to the real space is inexact. (Here T is a lattice translation vector.) The reader performs the inverse Bloch transform using FFT techniques. It is followed by a forward Bloch sum and compared against the original .

For the inverse sum, a cluster of points around each atom is generated. The radius of the cluster is printed out in a line similar to

 hft2rs: make neighbor table for r.s. hamiltonian using range = 4.9237 * alat

The number of pairs (connecting vectors) it finds within spheres around each atom of radius  range  is printed out in lines like these:

 hft2rs: found 1020 connecting vectors out of 1024 possible for FFT
 symiax: enlarged neighbor table from 1020 to 1452 pairs (48 symops)

The first line tells you how many pairs it found out, and also the number pairs it requires for the FFT to be exact. (The second tells you how many pairs it “padded” by adding equivalent boundary points to the original list, but it is not important here). The (backward,forward) process should be exact provided enough pairs are available. In the lines above, only 1020 pairs were found, while 1024 pairs are needed so as not to lose any information in the process.

To resolve this problem, increase  HAM_RSRNGE. You can use as large a number as you like, but the larger the number, the slower the calculation. Best to increase  HAM_RSRNGE just enough (say 4.9237→6) so that the error does not appear. Alternatively, you can increase the acceptable tolerance in the error (HAM_RSSTOL).

G1 Error message ecore>evalence encountered

hsfp0 may produce this error:

 ---- hsfp0 ixc=3: ecore>evalence

This means that some core state is higher than the lowest valence state.

If you look near the bottom of the output you should fnd a messaage similar to the following:

 hsfp0 core level ecore(  4,1) =  -2.3631 lies above bottom of valence band = -21.4956

It says that core level #4, spin 1 is the offender. Look at the core table in the GWinput file. In this instance it reads

  atom   l    n  occ unocc   ForX0 ForSxc :CoreState(1=yes, 0=no)
    1    0    1    0    0      0    0    ! 1S *
    1    0    2    0    0      0    0    ! 2S
    1    0    3    0    0      0    0    ! 3S
    1    0    4    1    0      0    0    ! 4S

The fourth core level is the 4s state (it is a Sr atom).

To fix this problem, include the 4s in the valence as a local orbital. (You will also have to include the 4p state: it is higher than the 4s) If you are using a basp file, do something like

 Sr RSMH= ... PZ= 14.9338 14.9148

lmfa should find this state automatically if HAM_AUTOBAS_LOC is set.

See Table of Contents

Edit This Page