GW convergence

[arb83@cam.ac.uk]

Dear Daniele

Many thanks for this. I assume there is no way to speed up convergence with respect to Bands? For the 1600 band simulation I needed 8000 core hours hence the question. I guess not but worth checking in case I'm missing something obvious!

All the best,

Alan

[Daniele Varsano]

Dear Alan,
the best option is to choose a parallelization strategy over bands in your input files:

X_and_IO_CPU= "1 1 1 Nc Nv" # [PARALLEL] CPUs for each role
X_and_IO_ROLEs= "q g k c v" # [PARALLEL] CPUs roles (q,g,k,c,v)
DIP_CPU= "1 Nc Nv" # [PARALLEL] CPUs for each role
DIP_ROLEs= "k c v"

Here Nc*Nv=total number of cores you are using, choose a number such that occupied_bands/Nv ~ empty_bands/Nc
Next in order to see if the anomaly disappears, I would do tests using a small cutoff in NGsBlkXp, and I would neglect the non local commutator in the dipole calculations as this slows the calculation. This is done by renaming the ns.kb_pp_pwscf database as e.g.
mv ./SAVE/ns.kb_pp_pwscf ./SAVE/ns.kb_pp_pwscf_

Best,
Daniele

[arb83@cam.ac.uk]

Dear Daniele

I reduced NGsBlkXp to 1 Ry and carried out convergence over the bands. I found that there was no divergence in this case:

Bnds Evb Ecb Eg
1000 0.3853 3.9635 3.5782
1200 0.438 3.9588 3.5208
1400 0.4613 3.9631 3.5018
1600 0.4757 3.9658 3.4901
1800 0.4852 3.9709 3.4857

What do you think the explanation for the divergence with larger NGsBlkXp could be? Just to confirm, there's no possibility of it being related to interaction between different blocks in the non-periodic direction due to using the potential energy cutoff?

Best wishes,

Alan

[Daniele Varsano]

Dear Alan,

there's no possibility of it being related to the interaction between different blocks in the non-periodic direction due to using the potential energy cutoff?

The fact you use a coulomb cutoff is meant exactly to avoid interaction among images. Moreover, here you are not experiencing the problem using the same bands, and a shorter dielectric matric cutoff. Larger cutoff corresponds to shorter range interaction.
The only way to relate to the coulomb cutoff is that something went wrong in the calculation of the large G component of the potential, you can verify this adding the flag l_col_test in the input when calculating the potential. You need to recalculate it (deleting the ndb.cutoff file) and you will have the G components of the potential in the output. My impression anyway is that you would have experienced strange behaviour also in the exchange part of the self-energy (you can check the convergence of Sigma_x which is very fast).

Bands and Gblk aren't independent.
You can try to repeat the same test you are doing here looking at the convergence bands and NGsBlkXp (1,3,5 ..Ry) together as it is done here:
PHYSICAL REVIEW B 84, 241201(R) (2011)
See Fig.1

Best,
Daniele

[arb83@cam.ac.uk]

Dear Daniele

Many thanks for the helpful comments. I didn't see any issues in the HF energy convergence so it sounds like this isn't the problem.

I have had another look through the output files and noticed something else. For all simulations I set FFTGvecs= 100000 RL (while the maximum is 179993RL), as I found this didn't change HF energies. However, for the simulations involving 1400 BndsRnXp or higher the FFTGvecs value was not shown in the report file. I also see the divergence for this number of bands or higher. Might the two be related?

Best wishes,

Alan

[Daniele Varsano]

Dear Alan,
you can check the number of G vectors considered in each database (ndb.HF*, ndb.pp, ndb.dipoles) they are reported in the report
after the reading (or writing) of each database as "RL vectors ".
If they do differs, you may check the effect of rasing the FFTGvecs.

Best,
Daniele

[arb83@cam.ac.uk]

Dear Daniele

This didn't differ between the calculations - why is the FFT value not reported in the higher bands files? Is it something to do with the fact I had to restart the calculation part way through (due to time limits on the computer) for the larger number of bands?

Best wishes,

Alan

[Daniele Varsano]

Dear Alan.

FFT is used to calculate dipoles, if dipoles are not calculated but read from previous database hye are not used, hence not reported.

Best,
Daniele

[haseebphysics1]

Dear Dr. Daniele,

I have a couple of questions regarding GW calculations.

1: Can we use the same values for the following parameters in GW and BSE?

BndsRnXp (in GW) and BndsRnXs (in BSE static screening) and similarly NGsBlkXp (in GW) and NGsBlkXs (in BSE)?

2: If I have calculated the dynamical matrix from GW via PPA, then will it be read in the BSE automatically and the only change I need to make is to set the path of the QP database in KfnQPdb? and will taking the (omega =0) component yield the same result as if I would have been done BSE after computing static screening? I mean, does BSE on top of GW affect the intensity of the absorption in the BSE?

3: And finally, I am having some issues with the GW calculation. The calculation is stopping without giving any serious error apart from this: " [ERROR] DIPOLES database not correct or not present"

There are no new dipole fragment files created in the -J directory apart from the single "ndb.dipoles" file. The relevant calculations files are attached.

Thanking you in anticipation,

[Daniele Varsano]

Dear Haseeb,

1: Yes
2: Yes, calculating the static screening or reading the static part of ppa is exactly the same. In input file you need to insert ppa instead of em1s using the same parameters you used to calculate the ppa (NGsBlkp, BndsRnXp).
3: Not easy to understand what happened there, as the dipole calculation seems to be completed.
My advise: update to the latest yambo source 5.0.x:
git clone git@github.com:yambo-code/yambo.git yambo

if the problem persists, please report it here.

Best,
Daniele