Header Ads Widget

Ab initio Calculations Using Wien2k Code

Last Posts

10/recent/ticker-posts

QTL-B Error

In some cases (mostly when the spheres are extremely small or you have heavy elements) it may even happen, that during the (first or later) scf-cycle LAPW2 stops with a QTL-B error
FORTRAN STOP L2main - QTL-B Error´
To find out more about an error (in general) you should check the "error" files:
/susi/pblaha/lapw/fccpt> lse 
0 -rw-rw-r--  1 pblaha tc  0 2005-04-21 19:26 dstart.error 
0 -rw-rw-r--  1 pblaha tc  0 2005-04-21 19:26 lapw0.error 
0 -rw-rw-r--  1 pblaha tc  0 2005-04-21 19:26 lapw1.error 
4 -rw-rw-r--  1 pblaha tc 53 2005-04-21 19:26 lapw2.error 
Since lapw2.error has non-zero length:
/susi/pblaha/lapw/fccpt> cat lapw2.error
 'l2main' - QTL-B.GT.15., Ghostbands, check scf files
Since the error is in lapw2, you need to check case.scf2:
/susi/pblaha/lapw/fccpt> cat *scf2
...
:FER  : F E R M I - ENERGY(TETRAH.M.)=   1.01765
...
   QTL-B VALUE .EQ.  120.91788   in Band of energy    1.12346   ATOM=    1   L=  2
    Check for ghostbands or EIGENVALUES BELOW XX messages
    Adjust your Energy-parameters for this ATOM and L (or use -in1new switch), check RMTs  !!!
  • The message above tells you that the problem is for an eigenvalue at an energy of 1.12 Ry , for the first atom and angular momentum l=2 .
  • Next inspect the case.scf1 file and check the corresponding energy parameters for this atom and l-value: A line like:
:E2_0001: E( 2)=    0.3000   E(BOTTOM)=   -0.066   E(TOP)= -200.000
  • tells you, that for l=2 and atom 1 it could find E(BOTTOM) but NOT E(TOP), and thus has set the energy parameter to the default 0.3 (see the UG, sect. lapw1 for more info on that).
  • If the problem occurs already in the first iteration, you have to manually change the case.in1 file. From the scf2 file above you see that the Fermi energy (and also the state where the large QTL-B value occurs) is above 1 Ryd. The default energy-parameters in case.in1 are at 0.3 Ry, and this is too far from the actual eigenvalues, so that the "linearization" is not accurate enough anymore.
    You may need to set the energy parameters in case.in1 and replace all 0.3 by 0.8 (in general, take a value about 0.2 Ry below EFermi).
  • A possible second reason for such problems is when the energy of the "APW+lo energy-parameter" and the "LO energy-parameter" are too close together. Inspection of case.in1 may show:
:E2_0001: E( 2)=    0.0100   E(BOTTOM)=   -0.966   E(TOP)= -200.000
             APW+lo
:E2_0001: E( 2)=    0.3000
             LOCAL ORBITAL
  • The energy-parameters (0.01 and 0.3) are much too close together. You can either try to increase the "LO-energy-parameter" from 0.3 to eg. 1.1 Ry (in the last line of the example below), because your EF is so high, or eventually you may simply remove the corresponding "LO-line" in case.in1 (again the last line) and reduce the "number of exceptions" for this atom (change the "6" to "5" in the first line below).
....     part of case.in1
WFFIL  EF=0.50            (WFFIL, WFPRI, ENFIL, SUPWF)
 6       10    4 (R-MT*K-MAX; MAX L IN WF, V-NMT
  0.30    6  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global APW/LAPW)
 0    0.30      0.000 CONT 1
 0   -4.30      0.001 STOP 1
 1   -2.54      0.002 CONT 1
 1    0.30      0.000 CONT 1
 2    0.01      0.001 CONT 1
 2    0.30      0.000 CONT 1
....
  • In very few cases it might be more delicate and you may have to experiment with the energy parameters. But always inspect case.scf1 and case.scf2 and compare the actual energy parameters for the problematic atom with the corresponding eigenvalue and then adapt the corresponding E-parameters in case.in1.
  • If the problem occurs in some later scf cycle, most likely the scf-cycle did diverge (grep :DIS case.scf must not show divergence!). I not, you may try the -in1new switch, but note that the -in1new switch is NOT ALWAYS SAVE and eventually the problem is somewhere else (case.struct file ?) or you have to fix the problem by hand as explained above (see also the faq SCF cycle fails after a few iterations

Post a Comment

0 Comments