"NaN" for "E-E0" and "Sc(E0)"

[lesheng]

Dear all,

I was running convergence test on Si for training, and I met two following problems. Hope someone can help me on this.

(1). One of the output files shows me the following information:

# K-point Band Eo E-Eo Sc(Eo)
#
1.00000 1.00000 -12.07311 NaN NaN
1.000000 2.000000 0.000000 NaN NaN
1.000000 3.000000 0.000000 NaN NaN
1.000000 4.000000 0.000000 NaN NaN
1.000000 5.000000 2.575740 NaN NaN
1.000000 6.000000 2.575740 NaN NaN
1.000000 7.000000 2.575740 NaN NaN

Here the "GbnRnge" was changed to test convergence. The "l" file shows me the calculation is done. Is there anything wrong with my calculation? The input and output files are attached as prefix name "1".

(2). During my calculation, some of the calculations "stop" when the "l" file shows:

<19s> [08] Dyson equation: Newton solver
<19s> [08.01] G0W0 : the P(lasmon) P(ole) A(pproximation)
<19s> [FFT-SC] Mesh size: 12 12 12
<19s> [WF-SC loader] Wfs (re)loading | | [000%] --(E) --(X)
<19s> [WF-SC loader] Wfs (re)loading |####################| [100%] --(E) --(X)

but the CPUs are still running, and no error report, it just stops. What happened here... The input and output files are attached as prefix name "2".

Thank you all for your kind attention,
Lesheng Li

Archive.zip

[Daniele Varsano]

Dear Lesheng,
looking at your input and report, I can see that you have stored in the electronic structure database 50 bands:

Code: Select all

RD./SAVE//ns.db1]------------------------------------------
  Bands                           :  50
  K-points                        : 29
  G-vectors             [RL space]: 2085
  Components       [wavefunctions]: 273
  ......

while in your input you are asking to sum-up 80 bands in the GW calculation:

% GbndRnge
1 | 80 | # [GW] G[W] bands range
%

I do not know if this is the problem, but this can surely cause some conflicts. You cannot use more band than you calculated in the Ground state calculations.

About point (2) it is not easy to understand what is going on, I did not find any inconsistency in the input file.

Cheers,

Daniele

[lesheng]

Dear Lesheng,
looking at your input and report, I can see that you have stored in the electronic structure database 50 bands:

Code: Select all

RD./SAVE//ns.db1]------------------------------------------
  Bands                           :  50
  K-points                        : 29
  G-vectors             [RL space]: 2085
  Components       [wavefunctions]: 273
  ......

while in your input you are asking to sum-up 80 bands in the GW calculation:

% GbndRnge
1 | 80 | # [GW] G[W] bands range
%

I do not know if this is the problem, but this can surely cause some conflicts. You cannot use more band than you calculated in the Ground state calculations.

About point (2) it is not easy to understand what is going on, I did not find any inconsistency in the input file.

Cheers,

Daniele

Dear Daniele,

Thank you for the comments. So the "GbndRnge" should not be more than the ground band number I calculated in previous pw calculation, right? I must have a misunderstanding on this, I thought I should keep increasing the number to get a converged result. OK, now I get it, thank you.

As to the second one, it is very confusing, since I was changing the "BndsRnXp" to test convergence, and other calculations are ok, but this one is stopped there...

Anyway, thank you for your kind help. Still, I need to study the GW method more carefully, otherwise some "silly" problem like the "GbndRnge" I had at this time will happen again.

Best,
lesheng

[Daniele Varsano]

Dear Lesheng,

I must have a misunderstanding on this, I thought I should keep increasing the number to get a converged result. OK, now I get it, thank you.

This is in principle right, but you cannot tell the code to use wavefunctions that have not been calculated before, just because they are not there!!!
As a common rule, perform the ground state calculations with a lot of bands. So they are stored once for all.
Next you check the convergence adding more and more bands, (of course the limit is the number of bands stored in the database).

Cheers,

Daniele

[lesheng]

Dear Lesheng,

I must have a misunderstanding on this, I thought I should keep increasing the number to get a converged result. OK, now I get it, thank you.

This is in principle right, but you cannot tell the code to use wavefunctions that have not been calculated before, just because they are not there!!!
As a common rule, perform the ground state calculations with a lot of bands. So they are stored once for all.
Next you check the convergence adding more and more bands, (of course the limit is the number of bands stored in the database).

Cheers,

Daniele

Dear Daniele,

I just tried the work without parallel calculation (using "yambo -N -F name.in"), and the second problem is solved. Do you think it's something wrong with my mpirun? But I don't have mpirun problem when I carried out pw calculations.

In addition, I did another test on Si with k-point set to be gamma, different from previous calculations, the "GbndRnge" can be set larger than the band number of ground state, but as you can see from the output file, the result are totally wrong. Why is this situation happening... The r_setup, input, and output files are attached.

Best,
lesheng

Archive.zip

[Daniele Varsano]

Dear Lesheng,
please post the report file corresponding to the GW calculation otherwise I cannot have a look on that.
As I was telling you in the previous post, I noticed the conflict but I'm not sure that it is the problem for the Nan.
About the problem of stopping calculation, I cannot say if it is an mpirun problem, or parallel compilation.
It looks that some run it works and other not (am I right?). Try to repeat the calculations from
scratch and tell us in which case you experience the problem.

Cheers,
Daniele

[lesheng]

Dear Lesheng,
please post the report file corresponding to the GW calculation otherwise I cannot have a look on that.
As I was telling you in the previous post, I noticed the conflict but I'm not sure that it is the problem for the Nan.
About the problem of stopping calculation, I cannot say if it is an mpirun problem, or parallel compilation.
It looks that some run it works and other not (am I right?). Try to repeat the calculations from
scratch and tell us in which case you experience the problem.

Cheers,
Daniele

Dear Daniele,

Sorry about the report file, it is attached this time.

Yes, you are correct, some of the calculations work, but some do not. I'll try to repeat that and will post here.

Best,
lesheng

Archive.zip

[Daniele Varsano]

Dear Lesheng
OK, this is quite strange.
Could you post what is the output of the
>yambo -D command?
This command will read the header of your databases. The report file indicates you are using 20 bands,
which is a nonsense. It is reporting what is written in the input file, but it cannot use more than 10.
I'm bit confused.
The associated report file of your run should be:
./r-Gb20_HF_and_locXC_em1d_ppa_gw0
as reported by the report itself, did you renamed it?
Morever, you have the keyword in the input file:

Code: Select all

%QPkrange                    # [GW] QP generalized Kpoint/Band indices
  1|  1|  1| 10|
%
%QPerange                    # [GW] QP generalized Kpoint/Energy indices
  1|  1| 0.0|-1.0|

repeated many times, it is the code that generate it?

Let us know,

Daniele

[lesheng]

Dear Lesheng
OK, this is quite strange.
Could you post what is the output of the
>yambo -D command?
This command will read the header of your databases. The report file indicates you are using 20 bands,
which is a nonsense. It is reporting what is written in the input file, but it cannot use more than 10.
I'm bit confused.
The associated report file of your run should be:
./r-Gb20_HF_and_locXC_em1d_ppa_gw0
as reported by the report itself, did you renamed it?
Morever, you have the keyword in the input file:

Code: Select all

%QPkrange                    # [GW] QP generalized Kpoint/Band indices
  1|  1|  1| 10|
%
%QPerange                    # [GW] QP generalized Kpoint/Energy indices
  1|  1| 0.0|-1.0|

repeated many times, it is the code that generate it?

Let us know,

Daniele

Hi Daniele,

The following is what is shown after input Yambo -D :

[RD./SAVE//ns.db1]------------------------------------------
Bands : 10
K-points : 1
G-vectors [RL space]: 2085
Components [wavefunctions]: 259
Symmetries [spatial+T-rev]: 48
Spinor components : 1
Spin polarizations : 1
Temperature [ev]: 0.000000
Electrons : 8.000000
WF G-vectors : 259
Max atoms/species : 2
No. of atom species : 1
- S/N 002113 ---------------------------- v.03.02.05 r.*** -
[RD./SAVE//ns.wf]-------------------------------------------
Bands in each block : 10
Blocks : 1
- S/N 002113 ---------------------------- v.03.02.05 r.*** -
[RD./SAVE//ndb.kindx]---------------------------------------
Polarization last K : 1
QP states : 1 1
X grid is uniform :yes
BS scattering :no
- S/N 002113 ---------------------------- v.03.02.05 r.*** -

Yes, I renamed the report file's name.

And the repeated keyword are indeed generated by the code itself.

Best,
lesheng

[Daniele Varsano]

Dear Lesheng,

And the repeated keyword are indeed generated by the code itself.

This is a sign that something went wrong in the parallel compilation, and yambo in parallel is not working properly.

Cheers,

Daniele