[Pw_forum] implementation of variation of occupations and Fermi level with perturbations

Stefano de Gironcoli degironc at sissa.it
Wed Apr 20 22:11:58 CEST 2011


It might happen if you transform one atom into another like in the 
"computational alchemy" approach [PRL 66 2116( 1991)]
stefano

On 04/20/2011 09:51 PM, David Strubbe wrote:
> 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<degironc at sissa.it>wrote:
>
>>   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<giannozz at democritos.it>  <giannozz at democritos.it>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 listPw_forum at pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum
>>
>>
>> _______________________________________________
>> Pw_forum mailing listPw_forum at pwscf.orghttp://www.democritos.it/mailman/listinfo/pw_forum
>>
>>
>>
>> _______________________________________________
>> Pw_forum mailing list
>> Pw_forum at pwscf.org
>> http://www.democritos.it/mailman/listinfo/pw_forum
>>
>>
>
>
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.democritos.it/pipermail/pw_forum/attachments/20110420/15dafa98/attachment.htm 


More information about the Pw_forum mailing list