GW self-consistency on eigenvalues

[Daniele Varsano]

Dear Samuel,

thanks a lot for reporting.
It looks some debug stuff left over in the source.
We will fix it as soon as possilbe.

Thanks,
Daniele

[anhhv]

Dear all,

Regarding to this topic, I have a question. I tried to test for Silicon. I just corrected bands 4 and 5 which are top-valence-band and bottom-conduction-band, then used the interpolation scheme for other bands as Danniel suggested from the previous posts

- ypp.in
QPDBs # [R] Quasi-particle databases
QPDB_edit # [R] Generation/editing
%QP_user_corrections # [QPDB] Correction( kp1| kp2| bnd1| bnd2| E-Eo[eV]| Img(E)[eV]| Re[Z] |)
1|1|1|4|-0.525656| 0.0081| 0.767229|
1|1|5|200| 0.103303| -0.01562| 0.769587|
............ etc

Here are what I obtained for Gamma

# K-point Band Eo E-Eo Sc|Eo
G0W0:
1.000000 4.000000 0.000000 -0.525656 0.460925
1.000000 5.000000 2.546545 0.103303 -4.035631
E_g = 2.546545 + 0.103303 + 0.525656 = 3.175504

STEP 1:
1.000000 4.000000 0.000000 -0.531999 0.464218
1.000000 5.000000 2.546545 0.230780 -3.875596
E_g = 2.546545 + 0.230780 + 0.531999 = 3.309324

STEP 2:
1.000000 4.000000 0.000000 -0.531245 0.467667
1.000000 5.000000 2.546545 0.261593 -3.838058
E_g = 2.546545 + 0.261593 + 0.531245 = 3.339383

STEP 3:
1.000000 4.000000 0.000000 -0.531142 0.468369
1.000000 5.000000 2.546545 0.267524 -3.829859
E_g = 2.546545 + 0.267524 + 0.531142 = 3.345211

STEP 4:
1.000000 4.000000 0.000000 -0.531127 0.468511
1.000000 5.000000 2.546545 0.269816 -3.827973
E_g = 2.546545 + 0.269816 + 0.531127 = 3.347488

So, it seems to get converged but what I wonder is why the correction is done for DFT band structure in every iteration? Why isn't it performed for QP band structures.

Thank you so much.

[Daniele Varsano]

Dear Viet-Anh Ha,
I'm not sure I've understood your point.
What do you mean by t

he correction is done for DFT band structure in every iteration?

According to what you report, the DFT gap is 2.546545 eV in all the iterations, while the QP gap is updated converging to 3.34eV.
If you are using the XfnQPdb and GfnQPdb keywords, the KS energies are kept fixed, then they are corrected internally in the code considering the QP correction for calculating the screening (XfnQPdb) and the GW convolution (GfnQPdb), in the output the original KS value and QP value for each iteration is reported.
I do not know if this answers your question, otherwise, please try to explain more in details.

Best,
Daniele

[anhhv]

Hi Daniele,

I am not clear at the logic under this self-consistent scheme. Maybe my understanding is wrong but I would think that

By doing self-consistence on eigenvalues, we hope that at some point we will obtain the convergence of screening and therefore, QP energies as well. So I think after each iteration, we updated QP energies and the next correction should be performed on these updated values. Please explain if I understood wrong.

Thank you so much.

[Daniele Varsano]

Dear Viet-Anh Ha,,
the QP at each step enters in the calculation of the screening and GW convolution (i.e. each time the energies enter in the equations), until convergence.
Maybe you are confused from the fact that the KS energy is reported at each step, but consider that you apply the calculated correction to this energies,
which is totally equivalent to what you are saying comparing the QP of a step to the one of the following step up to arriving at zero correction.

Best,

Daniele

[anhhv]

Hi Daniele,

Thank you very much again. I have another question relating to ypp. Now if I try to correct bands 3-->7 instead of 4 & 5 as previous example, I get "Segmentation fault" when doing

ypp -q g -J run_MPI100_OMP1

where, run_MPI100_OMP1 is the out directory of G0W0 which contains ndb.QP (for 29 kpoints and bands 3 to 7). Can you figure out what happened ?

[Daniele Varsano]

Dear Viet-Anh Ha,
actually I'm not able to reproduce your problem,
your command should generate an input file with the corrections read by the ndb.QP in the -J directory.
Can you provide some information to spot the problem?
Do you have any messages beside the segm. fault?
Is the input file generated? What happens if you rename the ndb.QP e.g. ndb.QP_?
Do ypp works if you run it without using the -J command?

Daniele

[anhhv]

I did not get anything else except "Segmentation fault (core dumped)". The ypp.in file was generated but stop after writing "QPDB_edit # [R] Generation/editing". I followed ypp and I saw that it went to "ypp/interface/QP_DBs_initialize.F" and then performed well in

PARSER_array(mode="write",VAR="Actions_and_names",&
& DESC='[QPDB] Format is "what"|"OP"|"prefactor"|"DB"|. OP can be +/-/x(only for Z)',&
& N=n_QP_dbs,M=4,CH_v=QP_db_input_control)

In this subroutine all the lines were collected (see ypp.txt I attached). So I guess something wrong with writing file.

P/S: Change ndb.QP to ndb.QP_ or not using -J option leads to default ypp.in generated
QPDBs # [R] Quasi-particle databases
QPDB_edit # [R] Generation/editing
%QP_user_corrections # [QPDB] Correction( kp1| kp2| bnd1| bnd2| E-Eo[eV]| Img(E)[eV]| Re[Z] |)
-1|-1|-1|-1| 0.000000| 0.000000| 0.000000|
%

[anhhv]

I found the point. In "src/parser/mod_itm.F", character array "ADDITIONAL_flines" was limited to size of 100. Increasing its dimension will remove the error.

[Daniele Varsano]

Dear Viet-Anh,

Great you solved the problem. The limit was set because the parser can be very slow in processing input files with many lines,
anyway the limit we set is rather stringent.

Best,
Daniele