[Wien] QTL-B and "Eigenvalues Below..."

Mon Jul 28 15:14:37 CEST 2008

Hmmm. Some other thoughts:

1) Try "x patchsymm". It's an undocumented utility I put in with
pairhess. It will put into case.struct_new a set of atomic positions
averaged over the symmetry with an output in case.outputpatch which
will show any problems. The difference between the new/old positions
and what patchsymm gives should be less that 1D-7. Sometimes there are
subtle issues.
2) Check case.struct and ensure that the symmetry operations are what
they should be, and that there are no numerical errors giving nonzero
(inappropriate) translations.
3) Look at case.scf0 and see if there are any very poor fits to Vxc.
4) Stare at case.in2c and convince yourself that it is right.
5) Maybe put more states as semicore rather than core, although it
makes no sense to me that this should matter.
6) Check the values of :NEC to ensure that enough of the density in
the core is being retained.I once had tan erroneous value in case.in2c
which was being compensated by a rescaling but giving GIGO.

On Mon, Jul 28, 2008 at 7:58 AM, Stefaan Cottenier
<stefaan.cottenier at fys.kuleuven.be> wrote:
>
>> 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
>

-- 
Laurence Marks
Department of Materials Science and Engineering
MSE Rm 2036 Cook Hall
2220 N Campus Drive
Northwestern University
Evanston, IL 60208, USA
Tel: (847) 491-3996 Fax: (847) 491-7820
email: L-marks at northwestern dot edu
Web: www.numis.northwestern.edu
Commission on Electron Diffraction of IUCR
www.numis.northwestern.edu/IUCR_CED