<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#ffffff">
It might happen if you transform one atom into another like in the
"computational alchemy" approach [PRL 66 2116( 1991)]<br>
stefano<br>
<br>
On 04/20/2011 09:51 PM, David Strubbe wrote:
<blockquote
cite="mid:BANLkTi=LfMazNDDe+XuB+nDawXU2D_uRoQ@mail.gmail.com"
type="cite">
<pre wrap="">Stefano,
Thank you for the explanation. Things are clear now. Is there a circumstance
in which Delta n_ext(q=0) is nonzero?
David Strubbe
UC Berkeley
On Wed, Apr 20, 2011 at 1:12 AM, Stefano de Gironcoli <a class="moz-txt-link-rfc2396E" href="mailto:degironc@sissa.it"><degironc@sissa.it></a>wrote:
</pre>
<blockquote type="cite">
<pre wrap=""> Dear David Strubbe,
eq. 79 is a general formula; in the phonon code Delta n_ext(q=0) is always
vanishing because the perturbation is neutral (atoms are displaced but their
charge is not changed), still Delta Vscf is in general non zero so one has
to do something
Let's look at the scf variation of rho that is something like
Delta rho(r) = sum_i f_i (phi_i* Delta_phi_i +cc) + d f_i/de *(Delta e_i -
Delta e_F) |phi|^2
As said, eq. 79 is the condition of charge neutrality of the perturbation
which is due ONLY to the last term involving changes in occupation of states
(remember that Delta phi is always orthogonal to the unperturbed phi so in
no case Delta phi can contribute to the total charge variation)
if you work out the expression ...
total charge = Delta n_ext + Delta_n induced by Delta e_i (defined in terms
of the potential change) + Delta_n induced by the Fermi energy shift..
and the neutrality condition reads
0 = Delta_n_ext + \int n(e_F,r) Delta Vscf - n(e_F) * Delta e_F
which is eq. 79.
HOWEVER, delta rho that enters ef_shift has been computed without the
contribution coming from the (then unknown) Fermi energy shift Delta e_F
that is (see above)
- n(e_F,r) * Delta e_F
this is how ef_shift routine icomputes Delta e_F: it calculates the G=0
component of Delta rho before the shift ( which amount to be \int n(e_F,r)
Delta Vscf ) and define Delta e_F in such a way that after the term -
n(e_F,r) * Delta e_F is added the final Delta rho is neutral.
I hope the procedure is a bit clearer now.
stefano
On 04/20/2011 12:08 AM, David Strubbe wrote:
Paolo,
Thanks for the response. This gives me some more insight into what is going
on, but I still don't understand.
As far as I can tell, the drhoscf in ef_shift is still the change in the
density rather than the change in the potential, because the calls in
solve_linter to dv_of_drho are using a copy of the density response rather
than drhoscf itself:
call zcopy
(nrxx*nspin_mag,drhoscfh(1,1,ipert),1,dvscfout(1,1,ipert),1)
call dv_of_drho (imode0+ipert, dvscfout(1,1,ipert), .true.)
The heart of the matter is the lines in ef_shift:
delta_n = delta_n + omega*drhoscf(nl(1),is,ipert)
def (ipert) = - delta_n / dos_ef
delta_n does not seem to refer to \Delta n_{ext} or the integral of the LDOS
with \Delta V_{SCF}, as in the numerator of Eq. 79. Do those quantities
exist in the calculation here?
Thanks,
David Strubbe
UC Berkeley
On Tue, Apr 19, 2011 at 1:44 PM, Paolo Giannozzi <a class="moz-txt-link-rfc2396E" href="mailto:giannozz@democritos.it"><giannozz@democritos.it></a> <a class="moz-txt-link-rfc2396E" href="mailto:giannozz@democritos.it"><giannozz@democritos.it></a>wrote:
On Apr 8, 2011, at 20:39 , David Strubbe wrote:
Eq. 79 refers to a quantity \Delta n_{ext} and an integral of the LDOS
with \Delta V_{SCF} to calculate the shift in Fermi level. However in
ef_shift it appears that the density response drhoscf is used instead
of these quantities in the numerator, which doesn't seem like the
same thing.
it doesn't, but it is. The (dirty) trick is well hidden in the call
to routine dv_of_drho:
it accepts in input the variation of the charge density, returns in
output the
variation of the potential, overwritten on the former. It was done a
looong time
ago in order to spare some memory, when machines had much less ram and
the code was much simpler and smaller (occasional dirty tricks were
under
control, sort of). A comment in the code would have spared you (and me)
some time. Unfortunately comments in code tend to belong to one of the
following categories: 1) useless, 2) misleading, 3) obsolete, 4)
nonexistent
P.
---
Paolo Giannozzi, Dept of Chemistry&Physics&Environment
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
Phone +39-0432-558216, fax +39-0432-558222
_______________________________________________
Pw_forum mailing <a class="moz-txt-link-abbreviated" href="mailto:listPw_forum@pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum">listPw_forum@pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum</a>
_______________________________________________
Pw_forum mailing <a class="moz-txt-link-abbreviated" href="mailto:listPw_forum@pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum">listPw_forum@pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum</a>
_______________________________________________
Pw_forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pw_forum@pwscf.org">Pw_forum@pwscf.org</a>
<a class="moz-txt-link-freetext" href="http://www.democritos.it/mailman/listinfo/pw_forum">http://www.democritos.it/mailman/listinfo/pw_forum</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
Pw_forum mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Pw_forum@pwscf.org">Pw_forum@pwscf.org</a>
<a class="moz-txt-link-freetext" href="http://www.democritos.it/mailman/listinfo/pw_forum">http://www.democritos.it/mailman/listinfo/pw_forum</a>
</pre>
</blockquote>
<br>
</body>
</html>