Issues on convergence

[hplan]

Dear Developers:

I have some questions about convergence. Taking FFTGvecs for example, we need do several tests on convergence and normalization to find a proper setting. When we do self-energy calculation, we can confirm convergence by checking QP gap with respect to FFTGvecs. My confusion is how can we confirm that the result is converged when we do response-calculation ? Is there any guideline for convergence testing ?

Another question is about normalization. Can we say that the output information below confirms wavefunctions are normalized ?
"

Code: Select all

[WF loader] Normalization (few states)  min/max  :0.364E-11  1.00 

"
Thank you !
Best,
Hai-Ping LAN

[Daniele Varsano]

Dear Developers:


Another question is about normalization. Can we say that the output information below confirms wavefunctions are normalized ?
"

Code: Select all

[WF loader] Normalization (few states)  min/max  :0.364E-11  1.00 

"

Yes, this is the minimum and maximum of the scalar product between few states taken as representative.
The perfect situation should be 0.00 1.00, i.e. different states are orthogonal between each other, and
normalized to 1.00.
In your case it confirms your wfs are orthonormalized.

About your first question, as other parameter you have to check your absorption spectrum, energy-loss spectrum etc with
FFTGvecs, depending on the quantity you are interested in.

Hope it helps,

Best,

Daniele

[andrea marini]

I have some questions about convergence. Taking FFTGvecs for example, we need do several tests on convergence and normalization to find a proper setting. When we do self-energy calculation, we can confirm convergence by checking QP gap with respect to FFTGvecs. My confusion is how can we confirm that the result is converged when we do response-calculation ? Is there any guideline for convergence testing ?

Dear Hai-Ping LAN,

in general Daniele is right. Peek up your quantity (absorption, QP corrections,...) and change the input file parameters until you do not find the result is unchanged. Among all variables, maybe FFTGvecs is not the one that has a major impact on the calculated quantities. It defines the size of the FFT mesh. I'd leave as it is in the default unless you do not really want to speed up your calculation and/or to reduce the memory usage of your run.

When you do a response function calculation the key parameters are the number of bands in the electron-hole summation and the number of G-vectors used in the exchange/correlation part. Moreover you should do different runs with different meshes of k-points.

Hope it helps

Andrea

[hplan]

Dear Andrea and Daniele,

Thank you for detailed instructions on this issue.
My resource is limited ,and large FFTGvecs need exhausted physical memory from my previous experience on self-energy calculations. This is the reason why i care about this parameter.