Table of Contents
- 0. Warning logged
- 1. Unexpected MT radius
- 2. Problems with Radial Schrodinger equation solver
- 3. Small errors in radial integration, ASA
- 4. Bad logarithmic derivative parameters
- 5. Inconsistent treatment of local orbitals
- 6 Non-integral number of electrons
- 7 Inexact Inverse Bloch transform
- G1 Error message ecore>evalence encountered
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. 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
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
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 ---- ERROR EXIT!
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.
Edit This Page