Beyond the Plasmon-Pole approximation in LiF inout database

[kopinjol]

Here are the input files I forgot to attach to the previous email.

[Daniele Varsano]

Dear Kopjnol,

figured out a way to run yambo so that it will recognize the input variables such that "MaxGvecs" . The way to make sure that yambo sees the input variable in the input file (01init.in) is to remake the database (p2y -N) before every init run. So every time I change the input value MafGvecs I remake the database and run yambo and yambo sees the input variable.

OK, but in principle you do not need to do that, p2y should be run once to build up the electronic structure database (ns,db1, ns.wfc), next you can change set your MaxGvecs to build up the Gvectors table (ns.gops) and work with that maximum number for the following runs. Again it seems to me there is something confusing with previous calculations.

Having said that, I ran yambo for several values of MaxGvecs, everytime remaking the database, but I still found the same value for the homo-lumo gap. The various values of MaxGvecs are order of magnitude different and so finding the same value for the homo-lumo gap seems incorrect. Am I missing something? My system is a silver +1 ion.

What HOMO-LUMO gap you are talking about? the Kohn-Sham homo-lumo gap? In this case, the KS energies are read from the quantum-espresso calculations by the p2y interface and stored in ns.db1. They are reported in every report and are totally independent on the MaxGvecs, as they are not calculated by yambo. If you are talking about GW homo-lumo gap, please be sure yambo is calculating it, and not reading from previous calculations, look in the report if the database (ndb.QP) is read (RD) or written (WR).

Cheers,

Daniele

[Daniele Varsano]

Dear Kpjinol,
I just had a look at your reports, you are looking at setup runs. In this run yambo order the Gvectors taking intou account
the symmetries for the next runs. Here the gap, is calculated from the KS energies calculated by Quantum espresso, so it is independent
on the Gvecs. Anyway I noticed the warnings:

[WARNING]Incompatible serial number for ./SAVE//ndb.kindx

Be careful, Yambo is reading databases generated in previous runs, from different databases ns.db1. This is probably because you are running p2y more than once. I suggest you to run p2y once. Next in order to make yambo read the input correctly, just name it yambo.in and run yambo without using the -F and -J option. I have the impression there is some confusion in your run directories.

Cheers,

Daniele

[kopinjol]

Hi Daniele,

I was just about to email you again when i saw your reply. I had just realized that issue with the homo-lumo gaps that they were read from the pwscf and not calculated. It was a stupid question.

Thanks for the quick reply. I did run p2y several times. As that was only way I could make yambo read in the input values. I am going to try out your suggestion and let you know what i get.

Thanks again for the reply,
kopinjol

[kopinjol]

Hi Daniele,

I followed your advice and ran yambo without the -F option. Instead I made the file yambo.in and called yambo with just a -J option. The jobs were running pretty well with this new recipe. But I just noticed some ERROR messages in the output files, specifically in the "r-03-BSE-cpl_optics_bse_bss" file. I am attaching all the files, including yambo.in. I was wondering if you could take a look at it direct me to the source of the error.

Thanks in advance,
kopinjol

[Daniele Varsano]

Dear Kopjnol.
do not worry, nothing strange.
You are running a calculation on top of a previous one.
Yambo see the old database, and recognize that your input specification are different from the
previous one. As you can see the error are ona read section:
[RD./SAVE//ndb.BS_Q1]

Code: Select all

     |Correlation        [res]:yes
 *ERR*    |Kernel`s coupling       :no
 *ERR*    |Exchange           [cpl]:no
     |W interaction is bare   :no
     |Correlation        [cpl]:no
     |ALDA kernel in R-space  :no
     |RL vectors    [exchange]: 29855
 *ERR*    |RL vectors [correlation]:  515

IN the new calculation with respect the previous you have included the coupling part of the matrix and the Gvectors in the correlation.
Yambo recognize it, warn you about that, and recalculate the matrix according with the input file. So the output you finally get
refers to the new parameters, as you can see at the end of the output file where the input parameteres are reported.

Cheers,

Daniele

[kopinjol]

Hello Daniele,

Thanks for the quick reply. It all makes sense now.

I was running some convergence tests by varying MaxGvecs, ExxRLvcs and NGsBlkXs. I have essentially left ExxRLvcs = MaxGvecs since my system is small. Then I ran some calculations for different values of MaxGvecs and NGsBlkXs. I was wondering if that is the correct way to go about it.

Also I noticed that the above variables only appear in a GW calculations but not in a BSE calculation. For a BSE calculation we have a new set of variables, BSENGexx and BSENGBlk. Are these two variables the same as ExxRLvcs and NGsBlkXs? If I keep MaxGvecs and FFTGvecs fixed, the only parameters that we can vary are the two mentioned above, right?

I am a little confused about these variables. I was wondering if you could help me out.

Thanks again,
kopinjol

[Daniele Varsano]

Dear Kopinjol,
you can find here the expression of the BSE kernel and you can
see the meaning of the BSENGexx and BSENgblk variable. They are the amount of Gvecs you have to converge for the exchange and direct term of the excitonic matrix. These are the variable you have to converge, but they are not the *same* of the variable that controls the GW calculation, in the sense that you cannot keep the same values you found to converge the GW. In general you can use a high value for BSENGexx as the computation of the exchange term it is not an heavy part of the calculation, while you will se that rising BSENgblk will be heavier. Here you have to invert the static dieletric matrix in order to calculate the screend potential.
Depending on the system, may be you have also to check the impact of the coupling term in the excitonic hamltonian, ususally (not always) for bulk system the resonant approximation (Tamm Dancoff) is valid, while for finite systems (molecules) the coupling plays a role.
Hope it helps,

Best,

Daniele

[kopinjol]

Hello Daniele,

thanks for the reply. I will look into the tutorials. My question was actually if the variables BSENGexx and BSENGBlk and MaxGvecs, ExxRLvcs and NGsBlkXs are equivalent. I think i got the answer. I understand that i cannot keep them at the same value converge each set separately. Which makes sense.

Thanks again for your quick reply. I really appreciate it.

Kopinjol

[Daniele Varsano]

Dear Kopjnol,
just a remark: MaxGvecs, tells you the maximul Gvec available in the all calculations, you can keep fixed to an high value.
Next for a BSE calculation, the variables to be converged are BSENGexx and BSENGBlk. Of course they cannot bigger than MaxGvecs.
In my post what I was saying is that you cannot keep the values obtained for ExxRLvcs and NGsBlkXs in the GW convergence as they have a different meaning.

Cheers,
Daniele