question on FFTGvecs and output format

[deyulu]

Dear Yambo developers:
I have several technical questions. First, does (the max value of) FFTGvecs correspond to the number of
G vectors in GS wavefunctions or the charge density? Secondly, there seems to be an inconsistency in the setups
from a2y and p2y. G-vectors[RL space] is the same as wavefunctions from a2y, while it is eight times from p2y.
Is this a problem? Finally, I was a little bit confused with the output format in the spectra calculations. What is
the difference between alpha (epsilon) and alpha_0 (epsilon_o)?
I assume one of them is obtained without local field effect. Is it correct?

Best wishes,
Deyu Lu
***************************************************************************
Deyu Lu (Ph.D)

190 Chemistry Building
University of California, Davis
One Shields Avenue
Davis, CA 95616
Office phone: (530) 754-9663
Group Webpage: http://angstrom.ucdavis.edu/

***************************************************************************

[andrea marini]

Dear Yambo developers:
I have several technical questions. First, does (the max value of) FFTGvecs correspond to the number of
G vectors in GS wavefunctions or the charge density? Secondly, there seems to be an inconsistency in the setups
from a2y and p2y. G-vectors[RL space] is the same as wavefunctions from a2y, while it is eight times from p2y.
Is this a problem?

Dear Deyu Lu, using abinit (a2y) you get only the wavefunctions G vectors, while pw (p2y) gives you the charge G vectors, indeed 8 times larger. In general it is not a problem. In some cases the wavefunctions G vectors may be not enough (for example when calculating the charge due to very localized orbitals), but in most of the cases you do not have this problem. Nevertheless it is only a matter of our laziness, as it would very simple to get the charge G vectors with abinit

Finally, I was a little bit confused with the output format in the spectra calculations. What is
the difference between alpha (epsilon) and alpha_0 (epsilon_o)?
I assume one of them is obtained without local field effect. Is it correct?

Yes, it is correct.

[Conor Hogan]

First, does (the max value of) FFTGvecs correspond to the number of
G vectors in GS wavefunctions or the charge density?

Should be for the GS wavefunctions, and you can often use a good bit less than that.

[deyulu]

Andrea and Conor:
Thank you both very much for the reply.

Best
Deyu
***************************************************************************
Deyu Lu (Ph.D)

190 Chemistry Building
University of California, Davis
One Shields Avenue
Davis, CA 95616
Office phone: (530) 754-9663
Group Webpage: http://angstrom.ucdavis.edu/

***************************************************************************

[feffeficus]

Hi all. I dont' find any other post on G-vectors, so I attach a question here:

I was lookin at all the i/o variables containing a "G-vec" suffix trying to fig out the differences. So correct me if I'm wrong:

Code: Select all

G-vectors (output variable): number of G read from pwscf calculation, relative to the charge density (8 times more than Components) 
Components (output variable):  number of G read from pwscf calculation, relative to the wavefunctions.

from pwscf output you read for example: G cutoff =30396.3551 ( 363335 G-vectors)
--> G cutoff (which value is there?) --> G-vectors ( number of plane waves for charge density? the one read in yambo)

then

Code: Select all

WF-G vectors (output): ?
MaxGvecs (input and output): should i fix this to something or not?
FFTGvecs (ouput and input): number of plane waves to use in the calculation, the value to converge for optics ad example.

so, once done the initialization, I should fix the value of FFTGvecs and converge it.

it is more or less correct?
thanks.
ff

[andrea marini]

Hi all. I dont' find any other post on G-vectors, so I attach a question here:

I was lookin at all the i/o variables containing a "G-vec" suffix trying to fig out the differences. So correct me if I'm wrong:

Code: Select all

G-vectors (output variable): number of G read from pwscf calculation, relative to the charge density (8 times more than Components) 
Components (output variable):  number of G read from pwscf calculation, relative to the wavefunctions.

from pwscf output you read for example: G cutoff =30396.3551 ( 363335 G-vectors)
--> G cutoff (which value is there?) --> G-vectors ( number of plane waves for charge density? the one read in yambo)

Dear FF, I am a bit lost In which file are you searching for these variables ? PW should give 3 fields in total: the energy cutoff, the chareg G-vectors and the wavefunction G-vectors.

Yambo uses all of them. In addition with Yambo you can tune the FFT size by changing the additional variable FFTGvecs. If you are doing an heavy calculation with a lot of G-vectors you can change FFTGvecs in order to speed up the calculation and to request less wavefunction memory.

Of course you must be carefull that normalization is not broken too much. In general GW calculations shouldn't feel the reduced number of FFTGvecs even if I would do careful checks.

Was it helpful

[feffeficus]

Dear Andrea, yesterday finally I clarified more my ideas about this argument (at least I hope)
Anyway from the lecture of ns.db1 we have:

G-vectors [RL space]: 638239
Components [wavefunctions]: 79926
WF G-vectors : 90583

from the previous pwscf calculation:

G cutoff =30396.3551 ( 638239 G-vectors)

dividing 638239/8 = 79779.875 --> so now these are the G-vectors i should use for the FFTGvecs variable (corresponding to the values of Components)

and the WF G -vectors value? (if I read in .save of pwscf the data-file.xml, I can't find this value inside.)

Thanks a lot!
ff

[Conor Hogan]

Hi FF,
Regarding the various numbers of G-vectors

G-vectors [RL space]: 638239
Components [wavefunctions]: 79926
WF G-vectors : 90583

I think this was already discussed somewhere else in the forum, anyway...
as you said:
G-vectors [RL space]: 638239 = Number of G-vector components in the charge, as determined by the PWscf calculations.
Components [wavefunctions]: 79926 = Number of G-vector components in the wavefunctions, as determined by the PWscf calculations. These two numbers are fixed, and specify the number of data written on disk in the database files.

Now the list of G-vectors themselves is stored in its own array, as set by MaxGvecs in setup, and initially it uses the largest list it can find, which in the PWscf case is the list in the file gvectors.dat.
WF G-vectors : 90583 = Number of G-vectors in the G-vector list needed to include all the G-vector components in the wavefunctions. These two numbers are not the same because one set is centred on gamma, and the other is centred on k, and there is come reordering between pwscf and yambo.
FFT G-vectors: this will be a number, by default set to the number of G-vecs in the wavefunctions (i.e. the maximum number available), that you can tune lower for convergence. Basically you are saying to not sum over all the components in the wavefunctions, but just up to some cutoff. Depending on what you are calculating this could be 20% - 70% of the total, but do some checks. Often you find that the cutoff you need for relaxation is higher than what you need for optics.
Hope that clears thing up a bit...