<div dir="ltr">Sounds good. I'm happy to do the actual cleaning/re-writes and push my changes upstream. I just don't want to invest that kind of effort if they're going to be rejected, so let me know what you want to see done and I'll do it.<div>
<br></div><div>While you're reloading into mental cache, here's another thing to think about: spsi of evc doesn't change between SCF iterations, so it (or just becp%k) could be saved and re-used. Most of the big systems I look at have lots of vacuum and are thus shifted towards vloc more than calbec/spsi, so I'm not sure how much of an impact it would have.</div>
<div><br></div><div>Max</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jan 22, 2014 at 12:42 PM, Paolo Giannozzi <span dir="ltr"><<a href="mailto:paolo.giannozzi@uniud.it" target="_blank">paolo.giannozzi@uniud.it</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
most likely you are right and you aren't missing anything.<br>
It has been a long time since I made some cleaning in the<br>
diagonalization routines and it takes some time before I<br>
can remember all the details. Let me think a little bit<br>
which cases can occur and how to avoid introducing yet<br>
another variable or switch or condition.<br>
<br>
lrot was introduced to avoid diagonalization of the input<br>
subspace at the first scf step, since what is supplied is<br>
the result of a diagonalization of the manifold of atomic<br>
orbitals with the starting charge. Diagonalization of the<br>
input subspace (the output one of the previous scf step)<br>
seems to be helpful (according to a few tests I made many<br>
years ago) during scf.<br>
<br>
Thank you for your interest in QE and especially in a part<br>
where nobody ever dares to look at!<br>
<span class="HOEnZb"><font color="#888888"><br>
Paolo<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Tue, 2014-01-21 at 08:16 -0600, Maxwell Hutchinson wrote:<br>
> In cegterg, sc(i,j) = <\phi_i | S | \phi_j >, not just <\phi_i |<br>
> \phi_j>, so ultra-softs should should result in sc = identity,<br>
> assuming they were previously ortho-normalized. The overlap matrix,<br>
> S, is density independent, so wave-functions from previous SCF<br>
> iterations should have sc = identity.<br>
><br>
><br>
> Initial wave-functions are computed as eigenvectors of the full<br>
> [generalized] eigen-problem, so they should also be ortho-normal wrt<br>
> S.<br>
><br>
><br>
> For molecular dynamics, if using ultra-softs, the S matrix is ionic<br>
> position dependent, so the first SCF iteration after each ionic step<br>
> will have sc /= identity, regardless of extrapolation.<br>
><br>
><br>
> For MD using norm conserving PPs (or no projectors, in my test case),<br>
> extrapolation is the problem.<br>
><br>
><br>
> In this light, I think the simplest thing to do is add the switch:<br>
> if (iter > 1) then<br>
> which gives future developers the ability to break the ortho-normality<br>
> condition currently imposed in init_wfc and only overpays no more than<br>
> once per ionic step. In the code, I think this could just be (.not.<br>
> lrot).<br>
><br>
><br>
> For that matter, lrot seems to be using a similar trick to re-use a<br>
> previous diagonalization, but lrot = true in the cases above that<br>
> break ortho-normality. The affect should be that the first set of<br>
> correction vectors added to the subspace aren't corrections to true<br>
> eigenvectors, which could slow down convergence but won't cause it to<br>
> fail. I think I'd argue that it should be lrot = (iter > 1) as well.<br>
><br>
><br>
> What am I missing?<br>
> Max<br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
><br>
> On Tue, Jan 21, 2014 at 2:36 AM, Paolo Giannozzi<br>
> <<a href="mailto:paolo.giannozzi@uniud.it">paolo.giannozzi@uniud.it</a>> wrote:<br>
> On Mon, 2014-01-20 at 14:13 -0600, Maxwell Hutchinson wrote:<br>
><br>
> > In the initialization part of the Davidson solver, cegterg,<br>
> sc is<br>
> > computed from evc with a zgemm and mp_sum. evc should be<br>
> coming into<br>
> > cegterg already orthonormalized, so this should be<br>
> unnecessary. Are<br>
> > there cases where this is not true?<br>
><br>
><br>
> if you have ultrasoft pseudopotentials or PAW, wavefunctions<br>
> (evc) are<br>
> not orthonormal. Since the S matrix is not saved from the<br>
> previous<br>
> self-consistency step, it has to be recalculated in any case.<br>
> For<br>
> norm-conserving PP's, this should not be needed, but the way<br>
> it is<br>
> implemented now guarantees that the routine works (or doesn't<br>
> fail)<br>
> even if input wavefunctions are not normalized. I suspect that<br>
> this<br>
> is actually used in Molecular Dynamics run, when wavefunctions<br>
> are<br>
> extrapolated: ther eis no guarantee that they are orthonormal.<br>
><br>
> P.<br>
><br>
> > Unless very little refinement is necessary, this won't<br>
> affect<br>
> > performance much. It's shorter, though. See:<br>
> ><br>
> <a href="https://github.com/maxhutch/quantum-espresso/commit/69f5c2dba36945a9d0ed3f8ece5e8a768f1316a2" target="_blank">https://github.com/maxhutch/quantum-espresso/commit/69f5c2dba36945a9d0ed3f8ece5e8a768f1316a2</a><br>
> ><br>
> ><br>
> ><br>
> > Thanks,<br>
> > Max<br>
><br>
> > _______________________________________________<br>
> > Q-e-developers mailing list<br>
> > <a href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
> > <a href="http://qe-forge.org/mailman/listinfo/q-e-developers" target="_blank">http://qe-forge.org/mailman/listinfo/q-e-developers</a><br>
><br>
> --<br>
> Paolo Giannozzi, Dept. Chemistry&Physics&Environment,<br>
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>
> Phone <a href="tel:%2B39-0432-558216" value="+390432558216">+39-0432-558216</a>, fax <a href="tel:%2B39-0432-558222" value="+390432558222">+39-0432-558222</a><br>
><br>
><br>
><br>
<br>
--<br>
Paolo Giannozzi, Dept. Chemistry&Physics&Environment,<br>
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>
Phone <a href="tel:%2B39-0432-558216" value="+390432558216">+39-0432-558216</a>, fax <a href="tel:%2B39-0432-558222" value="+390432558222">+39-0432-558222</a><br>
<br>
</div></div></blockquote></div><br></div>