I've two suspicions:
a) Some problem with the struct file. It could be identical positions of 
one atom, wrong symmetry operations, wrong multiplicity,...
Make sure that the analysis from nn, sgroup and symmetry fit to each 
other. You may also remove case.vns temporarely to check if the problems 
may come from the Fourier coefficients (symmetry!)
b) The low lying Cu-3s (and maybe Ge-p) states. Definitely one does not 
need the Cu-3s states as valence for a large Cu sphere, and I'm not even 
sure that the Ge-p states are necessary. At least I'd test this and 
remove them temporarely to see of the "states below" are gone. 
Eventually, you may slightly change RMTs (larger Ge sphere at the cost 
of Cu).

Stefaan Cottenier schrieb:
>> The only times I have seen things like this is when, for whatever
>> reason, the case.clmsum was messed up. I would check that lstart and
>> dstart worked OK, and that the output from lapw0 looks reasonable. If
>> all else fails, perhaps move to an LAPW basis set until you have at
>> least partially converged the calculation.
>>
>>   
> Thanks, Laurence. Nothing suspicious in case.outputst, for sure. In 
> case.outputd and case.output0, I see at least no error messages or 
> anything particularly unfamiliar, but I admit I do not know about every 
> number printed there what exactly it means. Changing completely to LAPW 
> got it through the first iteration, although there was still the message 
> that one eigenvalue was below -12 Ry in case.output1 (only 1, not 8). 
> And eventually, the scf cycle never converged with LAPW, obviously due 
> to that 'eigenvalue below' problem.
> 
> Meanwhile, I got the same structure converged after artificially 
> lowering the symmetry. But that is not how things should be done. This 
> case isn't something very exotic (a substitutional Cu impurity in a 
> 64-atom Ge supercell), it should be possible to run this in a normal 
> way, isn't it?
> 
> Any other hints...?
> 
> Stefaan
> 
> 
>> On Fri, Jul 25, 2008 at 10:18 AM, Stefaan Cottenier
>> <stefaan.cottenier at fys.kuleuven.be> wrote:
>>   
>>> Dear wien2k community,
>>>
>>> I ran into a case that gave a QTL-B error in the first iteration.
>>> Following the FAQ, I therefore set the default 0.30 linearization energy
>>> to about 0.2 Ry below the :FER that is found in case.scf2, and adjust
>>> the linearization energies of the deeper states to the eigenvalues found
>>> in case.scf1. I have then the following case.in1c (the first atom is Cu,
>>> the second is Ge):
>>>
>>> WFFIL        (WFPRI, SUPWF)
>>>  6.15       10    4 (R-MT*K-MAX; MAX L IN WF, V-NMT
>>>  0.10    5  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
>>> APW/LAPW)
>>>  0    0.10      0.000 CONT 1
>>>  0   -8.12      0.002 STOP 1
>>>  1    0.10      0.000 CONT 1
>>>  1   -4.99      0.005 STOP 1
>>>  2    0.10      0.010 CONT 1
>>>  0.10    5  0      (GLOBAL E-PARAMETER WITH n OTHER CHOICES, global
>>> APW/LAPW)
>>>  1    0.10      0.000 CONT 1
>>>  1   -7.76      0.002 STOP 1
>>>  2   -1.42      0.005 CONT 1
>>>  2    0.10      0.000 CONT 1
>>>  0    0.10      0.000 CONT 1
>>> (snip)
>>>
>>> Nevertheless, the same QTL-B error reappears (last lines from case.output2):
>>>
>>>   QTL-B VALUE .EQ. **********   in Band of energy   -8.93817   ATOM=
>>> 2   L=  2
>>>
>>> I'm a bit puzzled by this, as atom nr. 2 (Ge) should have no states near
>>> that energy, certainly no d-states.The linearization energies used for
>>> this second trial are nicely consistent with the content of the new
>>> case.scf2 and case.scf1:
>>>
>>> grep :FER case.scf2 ==> :FER  : F E R M I - ENERGY(TETRAH.M.)=   0.33183
>>>
>>> case.scf1:
>>>
>>> :EIG00001:      -8.1239527   -7.7633883   -7.7633873   -7.7633873
>>> -7.7633588
>>> (snip)
>>> :EIG00186:      -7.7595614   -7.7595564   -7.7595506   -7.7595506
>>> -7.7595488
>>> :EIG00191:      -4.9882067   -4.9882067   -4.9882066   -1.4337422
>>> -1.4337422
>>> :EIG00196:      -1.4335714   -1.4333581   -1.4332873   -1.4332873
>>> -1.4332455
>>>
>>> A second inspection shows there is a message "8 EIGENVALUES BELOW THE
>>> ENERGY  -12.00000" in case.output1 (actually in case.output2_3 of a
>>> k-point parallel run, which corresponds to the case.output2_3 where I
>>> got the QTL-B message). That message is there with and without adjusting
>>> the linearization energies. There should not be any eigenvalues so deep,
>>> and changing Emin in case.in1c to a very low value of -20.0 leads to the
>>> same message (now 8 eigenvalues below -20.000). This message is probably
>>> the source of the error, rather than the linearization energies. But I
>>> do not understand where it comes from...?
>>>
>>> Another observation is that in case.scf2_3 there are many '****'
>>> strings, for all atoms:
>>>
>>> :POS002: AT.NR.  -2 POSITION = 0.37456 0.12507 0.12507  MULTIPLICITY = 12
>>>
>>>       LMMAX 28
>>>       LM=   0 0  1 1 -1 1  2 0  2 2 -2 2  3 1 -3 1  3 3 -3 3  4 0  4 2
>>> -4 2  4 4 -4 4  5 1 -5 1
>>>         5 3 -5 3  5 5 -5 5  6 0  6 2 -6 2  6 4 -6 4  6 6 -6 6
>>>
>>> :CHA002: TOTAL CHARGE INSIDE SPHERE   2 = ************
>>> :PCS002: PARTIAL CHARGES SPHERE =  2
>>> S,P,D,F,PX,PY,PZ,D-Z2,D-X2Y2,D-XY,D-XZ,D-YZ
>>> :QTL002:************************************************************************************
>>>        Q-s-low E-s-low   Q-p-low E-p-low   Q-d-low E-d-low   Q-f-low
>>> E-f-low
>>> :EPL002:******** -8.8617  ******** -8.8746  ******** -8.8802  ********
>>> -8.8790
>>>        Q-s-hi  E-s-hi    Q-p-hi  E-p-hi    Q-d-hi  E-d-hi    Q-f-hi  E-f-hi
>>> :EPH002:  0.3394 -0.2555    0.3053  0.1277    0.0300 -0.4098    0.0014
>>> -0.0723
>>>
>>>                      QXX         QXY         QYY         QZZ       UP TO R
>>>
>>> :VZZ002:        ************************************************       2.050
>>>
>>> It may be useful to mention the sphere radii, as they are rather small
>>> for Ge (due to atoms that lie close to each other):
>>>
>>> RMT = 2.31 for Cu, which leads to this in case.outputst:
>>>
>>>  TOTAL CORE-CHARGE:                   10.000000
>>>  TOTAL CORE-CHARGE INSIDE SPHERE:     10.000000
>>>
>>> RMT = 2.05 for Ge, which leads to this in case.outputst:
>>>
>>>  TOTAL CORE-CHARGE:                   12.000000
>>>  TOTAL CORE-CHARGE INSIDE SPHERE:     11.999832
>>>
>>> Both seem OK for me.
>>>
>>> I have ran many similar cases without problems, only this particular
>>> structure (and a few variants of it) lead to trouble. I'm out of ideas.
>>> Does anybody have a hint?
>>>
>>> Thanks,
>>> Stefaan
>>>
>>>
>>>
>>> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
>>>
>>> _______________________________________________
>>> Wien mailing list
>>> Wien at zeus.theochem.tuwien.ac.at
>>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>>>
>>>     
>>
>>
>>   
> 
> 
> Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm
> 
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien

-- 
-----------------------------------------
Peter Blaha
Inst. Materials Chemistry, TU Vienna
Getreidemarkt 9, A-1060 Vienna, Austria
Tel: +43-1-5880115671
Fax: +43-1-5880115698
email: pblaha at theochem.tuwien.ac.at
-----------------------------------------

Reply via email to