ABINIT Discussion Forums

Hi, I am trying to modify the code so that the Boronsky-Niemenem positron enhacement factor (in the RPA limit, that is in the zero positron limit) includes the correction for screening of positron in semiconductors. So in the code of /src/56_xc/gammapositron.F90 in lines 178-179
Intead of:
if (rs<=20._dp) gg=gg+1.23_dp*rs+0.8295_dp*sqrs**3-1.26_dp*rs**2+0.3286_dp*sqrs**5+sixth*rs**3

I want to modify the last term in view of the article
Puska, Mäkinen, Manninen, Nieminen, Phys. Rev. B, 39, p. 7666 (1989) and M.J. Puska; J. Phys.: Condens. Matter (1991) 3 3455, to:

gg=gg+1.23_dp*rs+0.8295_dp*sqrs**3-1.26_dp*rs**2+0.3286_dp*sqrs**5+sixth*scsf*rs**3
where scsf = 1. - 1./(dtset%diemac) ; where dtset%diemac is the value of the dielectric constant declared in the input file.

Of course, this means that gammapositron subroutine has to have access to the value of the diemac, so have to track back where gammapositron subroutine is called and find out that is only called at src/67_common/poslifetime.F90 subroutine; and in that subroutine the set of values dtset is part of the input. So in line 220 of poslifetime where its states:

call gammapositron(gamma,grhocore2,grhoe2,igamma(igam),ngr,nfft,xccc3d,&
& rhonowe(:,1,1),rhonowp(:,1),usecore)

I just added dtset variable as a formal variable:

call gammapositron(gamma,grhocore2,grhoe2,igamma(igam),ngr,nfft,xccc3d,&
& rhonowe(:,1,1),rhonowp(:,1),usecore,dtset)

Obviusly I added in gammapositron.F90 dtset as a actual variable changing from:

subroutine gammapositron(gamma,grhocore2,grhoe2,igamma,ngr,npt,rhocore,rhoer,rhopr,usecore)

to

subroutine gammapositron(gamma,grhocore2,grhoe2,igamma,ngr,npt,rhocore,rhoer,rhopr,usecore,dtset)

I also include the use of some definitions parts:
use defs_abitypes
use defs_datatypes

Nevertheless I find the following error when I try to compile:
...
poslifetime.F90:220.46:

& rhonowe(:,1,1),rhonowp(:,1),usecore,dtset)
1
Error: More actual arguments than formal arguments in the call of procedure in (1)

I simply want to know how to solve this error, because I am lost. I am supposely doing all the right things nevertheless I find this problem.

Hello,

In fact the interfaces of abinit are automatically generated by a tool called abilint (you can find it in the config/script directory). In any case you can issue a */*/makemake in the root directory of abinit and it will call this tool and some others. Then you should be able to recompile abinit (the interfaces will have been changed).

The other possibity is to change the interface by hand : it is the file interfaces_56_xc.F90.

David

Dear ?
(is it possible to know to who I am speaking with?),

I'm one the authors of the gammapositron routine.

You have two possibilites:
1) you do the modification for your own usage; in that case you can do what you want.

2) You want your modification to be later included in Abinit;
you cannot implement your proposal as it is.
a) The use of the full dtset datastructure (which is a huge datastructure) is usually forbidden for low lwvwl routines; and gammapositron is one of these routines.
It is definitively not "object oriented" and avoid all re-use of the routine in another context.
At least, just pass the dtset%diemac real.
b) I you decide to do that, I would prefer that you pass it as an "optional" argument....
This will allow us to use the gammapositron routine in several other context, not knowing the value of diemac.
Then, you can implement your formula by the use of the "if present(diemac)"statement.
c) diemac is not exactly the dielectric constant; it is much more a adjustable parameter used for the preconditionning scheme of the SCF cycle. So, I'm not sure your implement will work in all cases.

Hope this helps...

Regards,

David
Thanks, that tip solved all. It is fair to say that this implementation greatly improves the lifetimes in semiconductors reaching to values very close to experimental ones. I stronlgy suggest to include this correction in a next version of ABINIT.

Dear Torrent,
My name is Sergio Ferrari and I am physicist working in positron lifetime calculations in the Univesidad Nacional de La Plata. Answering to your question: for the moment I just the modification for my own usage. Thanks you very much for the tip of how to implement the modification more formally and correctly. Since your one of the authors of the code gammapositron perhaps you should this implementation yourself and you would do it better than me (my programations skills are poor). As answering if this work: well, I firstly do a modification just entering the value of dielectric constant of ZnO directly by hand in gammapositron code, and after that I modify so to read dtset%diemac and the results were the same (using PAW and atompaw densities) the lifetime of ZnO went from 140 ps (BN in the RPA limit) to 151 ps (BN+correction for semiconductors in the RPA limit). The current experimental data on ZnO is 151 +/- 2 ps and ATSUP (atomic supeposition: a Not-self consistent method) leaves a value of 159 ps. So you can see from this results (and others I mean to calculate) that a great improvement has been made including this correction. This also proves that dtset%diemac has the correct value of the dielectric constant writen in the input file. I gently invite you then to implement this correction in the way you have described.

Kind regards

Dear Torrent,
May I have a comment of one of your statements:

c) diemac is not exactly the dielectric constant; it is much more a adjustable parameter used for the preconditionning scheme of the SCF cycle. So, I'm not sure your implement will work in all cases.

as abinit description of input variables says so about diemac (http://www.abinit.org/documentation/helpfiles/for-v6.6/input_variables/vargs.html#diemac):

diemac
Mnemonics: model DIElectric MACroscopic constant
Characteristic:
Variable type: real parameter
Default is 10^6 (metallic damping).

A rough knowledge of the macroscopic dielectric constant diemac of the system is a useful help to speed-up the SCF procedure: a model dielectric function, see the keyword dielng, is used for that purpose.

So, really diemac is the dielectric constant and usally it used

for the preconditionning scheme of the SCF cycle

as yourself say. But also it is usefull for modifying the enhacement factor in the case of Boronski-Niememinen choice, so to include the screening of the positron in semiconductors. See that if the dielectric constant is high (as the default value is), when we recover metal behaviour (BN original formulae). So instead of an optional use of diemac, I think it can be used allways (it will be user fault if he/she does not set the correct value of diemac so to obtain better values of positron lifetime.
Regards, Sergio

Dear Sergio,

Thanks for your comments.
I'll certainly take time to implement your modification.
But I'm wondering if it is better to change the default behaviour of the enhancement factor or to add a new option for the ixcpositron keyword.
I'll probably choose the second solution, in order to keep a maximal number of choices for the user.

Also, I'll probably add a new keyword for the dielectric constant: diemac is set to 10**6 by default and not automatically adjusted to the material.
It is probably better to let the user have the control of what he is doing.

Regards,

Dear Torrent,
Although the default value of diemac is 10^6, you can enter by hand the value of the dielectric constant in the input file using the input variable diemac. There is now way in principle that the program could adjust the value of the dielectric constant by itself (unless it looks the composition of the material and checks the values stored in some table or database). As far as I know, theres is no ab-initio calculation that could give the dielectric constant. So, like acell or other constants, the value of dielectric constant (diemac) is responsability of the user. Beyond that, the literature I have consulted, when calculating lifetimes with the Boronski-Niemenen enhacement factor, authors allways choose also to correct the enhacement for semiconductors; even more: as I said, the no inclusion of this correction gaves "wrong" values of the positron lifetime. Despite that, I can understand the decisition of expanding ixcpositron (or perhaps better, igamma=3 instead 2 for ixcpositron=1) so to user have the maximum posibilities of enhacements factors. To have this implementation can make ABINIT, as a positron lifetime calculation tool, much more comparable to other calculation tools, because the positron lifetime strongly depends of the enhacement factor used and for that is the importance of having the possibility of using the same enhacement factor than other programs.
Sorry for such extend of text, regards,
Sergio