Page 1 of 1

G0W0 @ HSE

Posted: Thu Mar 22, 2018 4:24 pm
by mferri
Dear developers,

I would like to perform a G0W0 calculation on top of HSE06 eigenvalues and eigenfunctions.

I've checked some old topics in this forum (e.g.viewtopic.php?f=14&t=421), in which it was written that the DFT contribution has to be removed manually.
What I understood is that only the local part of the DFT exchange-correlation potential is calculated in < nk | Vxc | nk > and the non-local one shouid be subtracted by hand. Is it still so in the latest version of Yambo?

In a more recent topic, viewtopic.php?f=10&t=1090&start=10, it is stated that the missing [x,V_xc(HSE)] term could induce a small but negligible error in the screening at q=0.
Therefore, if the error in the Σx and Σc due the [x,V_xc(HSE)] is negligible, the only possible source of error is eventually the non-local < nk | Vxc | nk > ?

I've already performed some tests and the effect of G0W0 is to overestimate a gap that is already close to the experiment at the DFT-HSE level.

Thank you in advance.
Best,

Matteo

Re: G0W0 @ HSE

Posted: Thu Mar 22, 2018 6:33 pm
by Daniele Varsano
Dear Matteo,
yes the situation is what you say.
It is possible that for HSE the <Vxc> it is calcuataed by the libxc, you can have a try.
For sure it is something that at the best of my knowledge has not been tested so far, me personally I never tried.
You should recognize from the report if the wfs are correctly seen as HSE wfs and if the Vxc is calculated.

The [x,V_xc(HSE)] non local term for GW it is possible it is not so important, while for absorption it should be.

Code: Select all

the only possible source of error is eventually the non-local < nk | Vxc | nk > ?
...the effect of G0W0 is to overestimate a gap that is already close to the experiment at the DFT-HSE level
I would not say eventually, if you do not subtract it you end up with nonsense results as you are somehow double counting exchnage and correlation contribution,
so your gap it is highly overestimated beside of not being a consistent calculation.

Sorry, but to not be more useful than that.

Best,
Daniele

Re: G0W0 @ HSE

Posted: Fri Mar 23, 2018 12:48 am
by mferri
Dear Daniele,

thank you for your reply.
I checked the report of one calculation, attached to this post, and the wavefunctions and the energies are actually seen as HSE06.
Then the xc functional is calculated by LIBXC as you said.

Code: Select all

  Functional HSE06(XC)
  LIBXC used to calculate xc functional
So, in any case, I have to subtract the non-local contribution in order to have a reasonable result.
Thank you again.

Best,

Matteo

Re: G0W0 @ HSE

Posted: Fri Mar 23, 2018 9:51 am
by Daniele Varsano
Dear Matteo,
it seems that the libxc calculate the <Vxc> contribution, in this case yambo perform the subtraction.

Code: Select all

Eqp=Eks+Z(<sigma>-<Vxc>)
where sigma=

Code: Select all

Sigma_x+Sigma_c
This is reported in the report, something like:

Code: Select all

QP [eV] @ K [1] (iku): 0.00      0.00      0.00
   B=72 Eo= -0.67 E= -1.14 E-Eo= -0.46 Re(Z)=0.75 Im(Z)=-.1661E-2 nlXC=-25.60 lXC=-21.15 So= 3.836
   B=73 Eo=  1.51 E=  1.61 E-Eo=  0.10 Re(Z)=0.75 Im(Z)=-.1469E-2 nlXC=-19.64 lXC=-22.68 So=-2.894
Here:

Code: Select all

nlXC=Sigma_x
So=Sigma_c
and

Code: Select all

lXC=<Vxc>
Here it is called as local as it is thought for local functional.
Now as I wrote you above this has never been tested, so I do not know if it gives you reasonable results.

Best,
Daniele

Re: G0W0 @ HSE

Posted: Fri Mar 30, 2018 5:32 pm
by Davide Sangalli
Ciao Matteo,
we found the bug.

To fix it you should replace in io_DB1

Code: Select all

   variable_exist(ID,"EXX_FRACTION") 
with

Code: Select all

(variable_exist(ID,"EXX_FRACTION").or.write_is_on(ID))
Same for the

Code: Select all

   variable_exist(ID,"EXX_SCREENING") 
Also the

Code: Select all

else if (ver_is_gt_or_eq(ID,revision=3997)) then 
should be replaced with

Code: Select all

endif
if (ver_is_gt_or_eq(ID,revision=3997)) then 


Then you need to recompile p2y and reconvert the ndb from QE.

We will release the fix in the next patchlevel.

Best,
D.