Automatic setting of FFTGvecs

[lilian]

Dear developers and users,

I am trying to understand how FFTGvecs are automatically set.

I have built a first database from a QE calculation and the r_setup file shows "G-vectors : 76163 [RL space]" (same as the output of nscf). However, r_setup also shows:

Code: Select all

  [WARNING] Found non closed shells. Max cutoff will be reduced.

  [WARNING] Set Gthresh>1.E-5 in input to avoid this. Too big Gthresh will pack shells together
  Full and reduced cutoff:   11635.2      299813.    [mHa]

And indeed, nG charge indicates 579 and so does MaxGvecs.

So I tried to increase Gthresh and did the initialization again and now all 76163 G-vectors appear in nG charge and MaxGvecs doesn't appear at the end of r_setup, as expected.

However, when I generate a script for an optical (RPA) calculation, the variable FFTGvecs is set to 11153 RL (when I should have 76163 G-vectors usable). And if I remove this line and run the simulation, the input file at the end of the output shows FFTGvecs = 11153 RL. And even if I try to set FFTGvecs to 76163 RL, the result is the same.

Could you please clarify why it seems that the FFTGvecs variable is automatically set to a lower value than what is available in the SAVE database?

Many thanks in advance!

(I can provide a minimal test on request)

[Daniele Varsano]

Dear Lilian,

76163 G-vectors refers to the wfs or the density energy cutoff?
Yambo by default set the FFT grid to the WF cutoff.

Best,

Daniele

[lorenzo.sponza]

Hello Daniele,
I'm working with Lilian on this subject. Thanks for the clarification.

So if we understood well, the highest number is the charge cutoff, ecutrho in QE, which in our example corresponds to 76163 planewaves, see below. This is read but actually never used by YAMBO, is it correct?

What is read and actually used is the global cutoff on the wavefunctions (ecutwfc, for us 11430) which defines the FFTGvecs cutoff and represents the highest cutoff for all practical uses (matrix size, wf representation). Though, I imagine that internally and for specific tasks YAMBO may use higher cutoffs based on FFTGvec. I'm thinking at the eh basis set, for example. Am I right so far?

Now, what about the third set of G vectors appearing in the ns.db1 database, i.e. the "Components" set (for us 9578 planewaves)? We understood that the actual number of planewaves used by QE (the WF components) depends on the k-point. The value reported in the database appears to be the highest among them. Is it actually used by YAMBO, or it is provided just for reference, as we have the impression?

Code: Select all

[RD./SAVE//ns.db1]--------------------------------------------------------------
...
  G-vectors                                        :   76163 [RL space]
  Components                                       :   9578 [wavefunctions]
...
  WF G-vectors                                     :  11430

Many many thanks

[Daniele Varsano]

Dear Lorenzo,

So if we understood well, the highest number is the charge cutoff, ecutrho in QE, which in our example corresponds to 76163 planewaves, see below. This is read but actually never used by YAMBO, is it correct?

Well, it is used when needed for instance in the evaluation of the density to calculate Vxc[\rho], or in all the algorithms where the G-G' si needed, e.g. terminators...

What is read and actually used is the global cutoff on the wavefunctions (ecutwfc, for us 11430) which defines the FFTGvecs cutoff and represents the highest cutoff for all practical uses (matrix size, wf representation). Though, I imagine that internally and for specific tasks YAMBO may use higher cutoffs based on FFTGvec. I'm thinking at the eh basis set, for example. Am I right so far?

Yes, you can use higher cutoff as e.g. in the exchange part of the self energy....

About the components:

As you can see in io/io_DB1.F
this has been added in ver. 3.0.3 to correctly handle PW use of igk indexes.

wf_ng = maxval(wf_igk) > wf_ncx

Actually, they are both used to set the wf grid size depending on the operation to be done.

Best,

Daniele