Trying to converge X matrix size

[leoteo]

Dear forum,

I am trying to do a G0W0 calculation of a molecule with yambo 3.4.1 (using Coulomb cutoff etc. so the cell is rather large)
and I am trying to converge the X matrix size.

Below I have summarized the most important results (run time refers only to the time used to calculate X).

NGsBlkXp [Ry] = 1 2 3 4
NGsBlkXp [RL] = 921 2553 4713 7237
run time = 14 220 1360 4981
Gap [eV] = 6.921 6.848 6.870 6.869

I have two questions:

1. A very basic question about plane waves: How should one choose the grid of NGsBlkXp values to check for convergence?

If I choose my points in a way that their relative distance decreases further and further (in the 'relevant metric'), the results might appear to be near convergence although they aren't. Is the 'relevant metric' here the number of plane waves?
I.e. given that E \propto k^2, should I rather use a grid of NGsBlkXp = 1^2, 1.5^2, 2^2, 2.5^2, ... Ry ?

2. Are there any tricks to reduce the run time of the X calculation?

I guess, the dramatic increase in run time can be explained by the cost of the matrix inversion being proportional to nGsBlkX^3 (?).
So, if I cannot reduce the cell size, is there anything I can do?

Best,
Leopold

P.S.: Although the gap value seems to be well converged, some orbital energies near Fermi still change by 20meV from 3Ry to 4Ry.

[Daniele Varsano]

Dear Leopold,
finally is the number of PW that matter, having the cutoff value in energy it is useful as it is independent of your cell size.
About the timing, you can have a look to your standard output l_*, if the most consuming part is the building of the matrix (Xo), or the inversion to build the X, indicated by "X". Looking at your dimension, I presume that the inversion start to be problematic. If the most time consuming part is X^0, you can exploit parallelism.
You say you cannot reduce the cells size, I imagine because you are using the Coulomb Cutoff, please note that the condition between system size, cell size, cutoff ratio, sometimes can be not totally fulfilled and the error is very small. I do not know what shape of cutoff you are using (if you are using a box, be careful with the cutoff edge size, there is an hidden factor two *still have to fix*. (ie an xcut in the input correspond to a xcut/2 in the reality: search in the forum).
Next, 20meV it is not big variation for a G^0W^0 calculation. It looks you are in the right way!
Hope it helps,

Daniele

[leoteo]

Dear Daniele,

thanks a lot for the prompt reply!

So, as you suggest, I will make the grid linear in the number of plane waves rather then linear in the energy.
By the way, I noticed that yambo interprets NGsBlkXp=2.25 Ry as NGsBlkXp=2 Ry (or 0.5Ry as 0Ry), i.e. converting the floating point number into an integer value of Rydbergs. Isn't that a bit dangerous?

As for the timings: Yes, the numbers in the first post were extracted from the l_* file and refer only to the "X" time.
The inversion to build the X matrix strongly dominates the overall runtime (for 4Ry it takes 83 out of 87 minutes). Unfortunately this problem will only get worse when I try to go to larger molecules, which is the aim...

For the Coulomb cutoff I am using a box (the factor of two was already included). Do I understand correctly that you suggest to test reducing the size of the Coulomb cutoff below the 'safe' values and check e.g. the quasiparticle energies?

Best,
Leopold

[Daniele Varsano]

Dear Leopold,

By the way, I noticed that yambo interprets NGsBlkXp=2.25 Ry as NGsBlkXp=2 Ry (or 0.5Ry as 0Ry), i.e. converting the floating point number into an integer value of Rydbergs. Isn't that a bit dangerous?

Yes, it is!!! Many thanks for reporting, we will fix it as soon as possible. Are you using the last release of the code (3.4.1)?

you suggest to test reducing the size of the Coulomb cutoff below the 'safe' values and check e.g. the quasiparticle energies?

Well this does not help with convergences. I mean to try to soft the condition so to try a smaller supercell (this is what help), and consequently a smaller Coulomb cutoff, and yes, look at the final quantity you want to calculate, QP energies.

Best,
Daniele

[leoteo]

Dear Daniele

Are you using the last release of the code (3.4.1)?

Yes, I am using 3.4.1 Revision 3187.

I mean to try to soft the condition so to try a smaller supercell (this is what help)

Ok, this is clear.
For the reduction of the cutoff, is it more important that the electron still feels all the other electrons on the same molecule or is it more important that it doesn't feel the electrons at the next replica of the molecule?
So, should the cutoff e.g. be reduced linearly with the cell size or should it be kept fixed in order to still contain the molecule? (can it be larger than the cell?)

Also, is there some rule of thumb (e.g. some particular density-isovalue) that is commonly used to define the 'size of the electron cloud'?

Thanks a lot for your help!

Best,
Leo

[Daniele Varsano]

Dear Leopold,
ok, it is the last release and we will check there the bug in the Blk given in Rydberg.
The cutoff cannot be bigger than the cell, you are at gamma point, so in plane wave, the interaction |r-r'| has the periodicity of the cell.
Cutoff bigger than the cell does not make much sense. There is not any thumb rule, or at least I do not know it, but as the tail of the density decrease exponentially you can softer the condition. Try to reduce cell and cutoff linearly and see if this does not damage too much your final results.
This is not guaranteed, anyway it could be a compromise between performance and accuracy.
Anyway, in the case your system is charged, this get things more delicate.
Best,
Daniele

[leoteo]

Dear Daniele,

thanks a lot, I will do that.

Best,
Leopold

[yunhailiseu]

Dear Daniele，

In your above reply you mentioned that the truncate size of coulomb interaction was actually half the size of that specified in input file if box-type truncation is used. Can this be fixed by modifing the source code?

I have checked the source code. It seems that yambo uses a unified appproach to read variables from input file (mod_itm.F parser.c under src/parser directory), thus additional post-process to variables "CUTGeo" and "CUTBox" is diffcult. However, the following line is found in src/coulomb/cutoff_box.F (line 671):

Code: Select all

F_box=F_box*2.*sin((v1(i_s)-v2(i_s))*box_length(i_s)/2.)/(v1(i_s)-v2(i_s))

Since this line of code is the only one that involes box_length and a factor of 2, I guess it is closely related to the truncate size problem mentioned above.

Is this the case? Can it be fixed by removing the denominator of 2.0 from the sine function?

Best,
Yunhai

[Daniele Varsano]

Dear Yunhai,
Yes, sure the source should be modified. Generally before touching the function I would redo analytical calculation. Anyway most probably what you suggest does the work. If you want to try, you can activate the variable CUTCol_test in the input:
http://www.yambo-code.org/input_file/ya ... rimcut.php
when calculating the coulomb cutoff. This is a test variable that produce you potential in real space, so you can have a look at it. As the output comes from a reverse FFT you will need a lot of G vector to have a nice profile, but the cutoff distance most probably can be seen easily.

Best,
Daniele

[Davide Sangalli]

There Leopold,

By the way, I noticed that yambo interprets NGsBlkXp=2.25 Ry as NGsBlkXp=2 Ry (or 0.5Ry as 0Ry), i.e. converting the floating point number into an integer value of Rydbergs. Isn't that a bit dangerous?

I agree that this is a bit dangerous. However I would not say that it is a bug.
The point is that the variable "NGsBlkXp", as the name itself suggests (= Number(N) of Gvectors(Gs) ) is an integer. The reason is that, originally, it was meant to be given in RL units. The capability to interpret other units came later. I guess it could be possible to change the situation, but it is not a priority.

I can suggest to use, instead of "Ry", either "eV", "mHa" or "mRy" to avoid this effect.

Also in this case you may notice that yambo could slightly change the number you gave in input, becouse it rounds the number to the closer value that gives a "closed shell" of G-vectors. In the r_setup file you can find some of the values yambo can use under the section: "Shells, format: [S#] G_RL(eV)"
I.e. the line: [S54]:2085( 802.8984) [S53]:1989( 787.3586) [S52]:1917( 766.6385) [S51]:1893( 761.4586)
means that for ~803 eV you have a closed shell with 2085 g-vectors, the same is true for (~787 eV, 1989 RL), (~767 eV, 1917 RL), etc ...
These shells are indeed created either by abinit or pwscf.
Thus if you give in input 790 eV, yambo will likely use the shell with 1989 RL
(This is also why an integer input variable is ok provided you do not use "Ry" or "Ha".)

As Daniele suggested, while the energy cut-off is not box dependent, the number of RL=PW is.

Best regards,
Davide