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

[Stefaan Cottenier]

Thanks Peter and Laurence. The suggestion on core states/Rmt value seem 
to solve it. Here are the results of the tests both of you suggested:
> 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!)
>   
Definitely nothing wrong with the struct file. All structural info is 
consistent, and the same case.struct has worked before with several 
other impurity/host lattice combinations.
> 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).
All tests along this line do cure the problem:

a) Slightly increasing the Rmt's of both Cu and Ge until they are nearly 
touching (Cu from 2.31 to 2.37, Ge from 2.05 to 2.10) and keeping Cu-3s 
and Ge-3p as valence states, does work.

b) Trading Ge size for Cu size (Cu from 2.31 to 2.26, Ge from 2.05 to 
2.10) and still Cu-3s and Ge-3p as valence states, does work.

c) Keep the original Rmt's (2.31 and 2.05), but put Cu-3s and Ge-3p in 
the core (Ecut=-6 Ry), does work.

Apparently the Cu and Ge Rmt's were too different from each other, in 
particular for deep semi-core states (I should have known this, the FAQ 
on choosing Rmt's warns they should not be more than 10-20% different 
from each other -- the present choice arose because I wanted to do 
several different Cu sites with the same Rmt-settings).

What I do not understand is why lowering the symmetry (and displacing 
one atom) did not produce the "eigenvalues below" error, for the same 
Rmt-values. Also Cu on slightly different sites in Ge ran fine. It must 
be quite a coincidence that this problem shows up. Anyway, I'll choose 
more similar Rmt values for this entire set of calculations from now on, 
to be safe.

> 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.
>   
The largest differences are 1D-15, no problems here (nice tool, by the way).
> 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.
>   
All look like this:

 0 0-1 0.00000000
 0 1 0 0.00000000
-1 0 0 0.00000000

Nowhere nonzero translations.
> 3) Look at case.scf0 and see if there are any very poor fits to Vxc.
>   
Nothing suspcious here too:

ATOM   1  AT RMT: SIGMA OF V-XC FIT:                    0.29702E-02
ATOM   2  AT RMT: SIGMA OF V-XC FIT:                    0.99336E-03
ATOM   3  AT RMT: SIGMA OF V-XC FIT:                    0.10263E-02
ATOM   4  AT RMT: SIGMA OF V-XC FIT:                    0.10271E-02
ATOM   5  AT RMT: SIGMA OF V-XC FIT:                    0.10161E-02
ATOM   6  AT RMT: SIGMA OF V-XC FIT:                    0.99735E-03
ATOM   7  AT RMT: SIGMA OF V-XC FIT:                    0.99394E-03
ATOM   8  AT RMT: SIGMA OF V-XC FIT:                    0.99534E-03
ATOM   9  AT RMT: SIGMA OF V-XC FIT:                    0.10505E-02
ATOM  10  AT RMT: SIGMA OF V-XC FIT:                    0.98391E-03

ATOM   1  LARGEST SIGMA AT R(781)= 2.310 and MAX DIFF:  0.29702E-02  
0.91750E-02
ATOM   2  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.99336E-03  
0.26818E-02
ATOM   3  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.10263E-02  
0.26926E-02
ATOM   4  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.10271E-02  
0.27565E-02
ATOM   5  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.10161E-02  
0.28470E-02
ATOM   6  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.99735E-03  
0.26202E-02
ATOM   7  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.99394E-03  
0.26300E-02
ATOM   8  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.99534E-03  
0.26776E-02
ATOM   9  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.10505E-02  
0.34587E-02
ATOM  10  LARGEST SIGMA AT R(781)= 2.050 and MAX DIFF:  0.98391E-03  
0.25929E-02
> 4) Stare at case.in2c and convince yourself that it is right.
>   
(not yet done, as Peter's reply intervened)
> 5) Maybe put more states as semicore rather than core, although it
> makes no sense to me that this should matter.
>   
For Cu, I had taken the 3s as semi-core:

  2P*      -68.81376      -68.78206
  2P       -67.30838      -67.27554
  3S        -8.85641       -8.77179
  3P*       -5.84815       -5.76476
  3P        -5.65595       -5.57332

and for Ge the 3p:

  3S       -12.36256      -12.35795
  3P*       -8.69055       -8.68506
  3P        -8.37631       -8.37071
  3D*       -2.16563       -2.15451
  3D        -2.12277       -2.11140

(twice output from case.outputst). I thought this was at the safe side 
(given the rather small sphere size of Ge), and innocent. But here was 
the problem, see reply to Peter's suggestions.
> 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.
>   
All looks fine here too (data taken from the diverging run with LAPW):

:NEC01: NUCLEAR AND ELECTRONIC CHARGE   2063.00000  2073.45604     0.99496
:NEC02: NUCLEAR AND ELECTRONIC CHARGE   2063.00000  2063.00000     1.00000
:NEC03: NUCLEAR AND ELECTRONIC CHARGE   2063.00000  2063.00001     1.00000

That's it. Thanks for your help !

Stefaan

Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm