[Q-e-developers] potentially unnecessary initial computation of sc

[Paolo Giannozzi]

Hi

most likely you are right and you aren't missing anything.
It has been a long time since I made some cleaning in the
diagonalization routines and it takes some time before I
can remember all the details. Let me think a little bit 
which cases can occur and how to avoid introducing yet 
another variable or switch or condition. 

lrot was introduced to avoid diagonalization of the input
subspace at the first scf step, since what is supplied is
the result of a diagonalization of the manifold of atomic
orbitals with the starting charge. Diagonalization of the 
input subspace (the output one of the previous scf step)
seems to be helpful (according to a few tests I made many
years ago) during scf.

Thank you for your interest in QE and especially in a part
where nobody ever dares to look at!

Paolo

On Tue, 2014-01-21 at 08:16 -0600, Maxwell Hutchinson wrote:
> In cegterg, sc(i,j) = <\phi_i | S | \phi_j >, not just <\phi_i |
> \phi_j>, so ultra-softs should should result in sc = identity,
> assuming they were previously ortho-normalized.  The overlap matrix,
> S, is density independent, so wave-functions from previous SCF
> iterations should have sc = identity. 
> 
> 
> Initial wave-functions are computed as eigenvectors of the full
> [generalized] eigen-problem, so they should also be ortho-normal wrt
> S.
> 
> 
> For molecular dynamics, if using ultra-softs, the S matrix is ionic
> position dependent, so the first SCF iteration after each ionic step
> will have sc /= identity, regardless of extrapolation.
> 
> 
> For MD using norm conserving PPs (or no projectors, in my test case),
> extrapolation is the problem.
> 
> 
> In this light, I think the simplest thing to do is add the switch:
>   if (iter > 1) then
> which gives future developers the ability to break the ortho-normality
> condition currently imposed in init_wfc and only overpays no more than
> once per ionic step.  In the code, I think this could just be (.not.
> lrot).
> 
> 
> For that matter, lrot seems to be using a similar trick to re-use a
> previous diagonalization, but lrot = true in the cases above that
> break ortho-normality.  The affect should be that the first set of
> correction vectors added to the subspace aren't corrections to true
> eigenvectors, which could slow down convergence but won't cause it to
> fail.  I think I'd argue that it should be lrot = (iter > 1) as well.
> 
> 
> What am I missing?
> Max
> 
> 
> 
> 
> 
> 
> 
> 
> On Tue, Jan 21, 2014 at 2:36 AM, Paolo Giannozzi
> <paolo.giannozzi at uniud.it> wrote:
>         On Mon, 2014-01-20 at 14:13 -0600, Maxwell Hutchinson wrote:
>         
>         > In the initialization part of the Davidson solver, cegterg,
>         sc is
>         > computed from evc with a zgemm and mp_sum.  evc should be
>         coming into
>         > cegterg already orthonormalized, so this should be
>         unnecessary.  Are
>         > there cases where this is not true?
>         
>         
>         if you have ultrasoft pseudopotentials or PAW, wavefunctions
>         (evc) are
>         not orthonormal. Since the S matrix is not saved from the
>         previous
>         self-consistency step, it has to be recalculated in any case.
>         For
>         norm-conserving PP's, this should not be needed, but the way
>         it is
>         implemented now guarantees that the routine works (or doesn't
>         fail)
>         even if input wavefunctions are not normalized. I suspect that
>         this
>         is actually used in Molecular Dynamics run, when wavefunctions
>         are
>         extrapolated: ther eis no guarantee that they are orthonormal.
>         
>         P.
>         
>         > Unless very little refinement is necessary, this won't
>         affect
>         > performance much.  It's shorter, though.  See:
>         >
>         https://github.com/maxhutch/quantum-espresso/commit/69f5c2dba36945a9d0ed3f8ece5e8a768f1316a2
>         >
>         >
>         >
>         > Thanks,
>         > Max
>         
>         > _______________________________________________
>         > Q-e-developers mailing list
>         > Q-e-developers at qe-forge.org
>         > http://qe-forge.org/mailman/listinfo/q-e-developers
>         
>         --
>          Paolo Giannozzi, Dept. Chemistry&Physics&Environment,
>          Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
>          Phone +39-0432-558216, fax +39-0432-558222
>         
> 
> 

-- 
Paolo Giannozzi, Dept. Chemistry&Physics&Environment, 
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222