GW correction is NaN for some k-point grids

[Christian Koenig]

Hi all,

I'm calculating the GW correction for a slab but the results are NaN for all k-points. However, this only happens for specific k-point grids and only if the X terminator is not used.

For example a k-point grid of 6x6x1 or 18x18x1 works and I get somehow reasonable values. For 12x12x1 and 24x24x1 the results are NaN if no X terminator is used. This suggests that there are certain k-points in the input data which are troublesome.
The Quantum Espresso input data is calculated from the same self consistent run and only the number of k-points in the nscf run is changed. The output of the latter does not contain any errors or NaN.

The part of the output file where NaN appears is copied below.

I noticed that the static database ns.kb_pp_pwscf_fragment_1 (only fragment 1) contains two NaN but this is also true for the calculations which don't have any problems. What is actually saved in this database?

Where would you recommend to look for the problem?


Best,

Christian


################# from output of 12x12x1 k-points calculation #################


[08.02] QP properties and I/O
=============================

Legend (energies in eV):
- B : Band - Eo : bare energy
- E : QP energy - Z : Renormalization factor
- So : Sc(Eo) - S : Sc(E)
- dSp: Sc derivative precision

- lXC: Starting Local XC (DFT)
-nlXC: Starting non-Local XC (HF)

QP [eV] @ K [1] (iku): 0.00 0.00 0.00
B=90 Eo= -0.21 E= NaN E-Eo= NaN Re(Z)= NaN Im(Z)= NaN nlXC=-12.32996 lXC=-11.19937 So= NaN
B=91 Eo= 0.00 E= NaN E-Eo= NaN Re(Z)= NaN Im(Z)= NaN nlXC=-11.61813 lXC=-11.24564 So= NaN

QP [eV] @ K [7] (iku): 0.000000 -0.500000 0.000000
B=90 Eo= -0.65 E= NaN E-Eo= NaN Re(Z)= NaN Im(Z)= NaN nlXC=-11.64957 lXC=-10.42431 So= NaN
B=91 Eo= 0.18 E= NaN E-Eo= NaN Re(Z)= NaN Im(Z)= NaN nlXC= -9.01291 lXC=-10.32767 So= NaN

[Daniele Varsano]

Dear Christian,
thanks for reporting, this is quite unusual, and it is also strange the problem appears for specific sampling.
The ns.kb_pp_pwscf contains the KB projector needed to build the commutator [r,Vnl] with the non local part of the pseudopotentials, needed to compute the dipoles matrix elements. This term usually has a small effect and can be also neglected.
Can you try to repeat your calculations having deleted your previous ndb* databases and renamed the ns.kb_pp_pwscf file (e.g. ns.kb_pp_pwscf_).
In this way, this will be ignored and we can see if this is the problem.
If the problem persists please send your input file (qe+yambo) and pseudopotentials, so that we can reproduce your problem and see what is going wrong. If you can, please try to reproduce your problem with loose parameters in order to have a fast reference.
If the case the problem is in that databases (ns.kb_pp_pwscf _fragment*), please send the scf/nscf qe and pseudo files so we can see what is going wrong in the p2y conversion.

Thanks a lot,
Daniele

[Christian Koenig]

Dear Daniele,

First of all, a calculation with 30x30x1 k-points finished in the meantime and gives reasonable results as expected.

While I prepared an example with parameters set to the bare minimum the effect disappeared again. Increasing each single parameter to the values I used before still did not produce NaN. Based on this observation I reset all parameters to what they were before (with the exception of EXXRLvcs and the parallelization structure) - still no NaN. I tested the parallelization which didn't make any difference.

However, when I run this calculation again with the old database I get NaN. The only difference in the databases should be that I decreased the number of bands which are calculated in the nscf part for the example (these are not enough for a full convergence study). I don't think that these excess bands should be used in the calculation. Let me check if there are any further changes which I missed.


Best,

Christian

[Christian Koenig]

Hi Daniele,

Ok, so this appears to be an interesting one. I have two versions of a pseudopotential which are supposed to be the same. As it turns out, the databases generated with one of them lead to the NaN error, the other ones don't and at first glance give reasonable results. So the problem seems to be the database generated from whatever pseudopotential and for the moment I consider this to be fixed. The two NaN in the database ns.kb_pp_pwscf_fragment_1 remain.
Thanks, I wouldn't have found this otherwise. If there is any reason to believe that the error is something else I will let you know.


Best,

Christian

[Daniele Varsano]

Dear Christian,
thanks for reporting, should you have again the problem please let us know and we can investigate which is the source of the problem in the faulty pseudopotentials.

Best,
Daniele

[Christian Koenig]

Dear Daniele,

Seems like the issue persists for 24x24x1 k-points (previously I only checked 12x12x1). I have an example with basically default settings and only a few conduction bands. There are still quite a lot of valence bands so the calculation isn't that fast - 4.5 h on 40 cores. If you reduce BndsRnXp to the number of valence bands (92) and GBndRnge to 50, then the calculation takes only about 35 min but of course these are very low values and I'm not sure if these might cause any other issues. The files for both cases are attached including the o-* and r-* output. Note that the issue remains with Coulomb cutoff and random integration which is not included in the simplified example.
Could you please check what's going wrong?


Best,

Christian

[Daniele Varsano]

Dear Christian,
I'm not sure I well understood the situation.
Is the problem arising for a particular pseudo, or it is independent from that? In the first case can you also attach the "good" and the "bad/ugly" pseudo?

Thanks,
Daniele

[Christian Koenig]

Dear Daniele,

The problem exists for both. The full calculations were done with the "bad" pseudopotential and I get NaN for 12x12x1 and 24x24x1 k-points. I switched to the other version of the pseudopotential and got NaN only for 24x24x1. The reason I changed the version of the pseudopotential is simply that I'm sure I can post the second/"good" one here as it is available for everyone to download.
The example includes the "good" pseudopotential.


Best,

Christian

[Daniele Varsano]

Dear Christian,
unfortunately at the moment I do not have adequate resources to test your system.
I will try by reducing the kinetic energy cutoff to a ridicolous value.
Anyway, just a few comments, most probably not related to the issue:
In your nscf input a wf_collect=.true. is missing, if you did a nscf calculation in parallel, I do not know if this can cause some problem to the p2y.
Your system is metallic, some empty bands are needed in the calculation of X and Sigma.

Best,
Daniele

[Daniele Varsano]

Dear Christina,

I've performed a calculation using very sloppy parameters on my laptop and I could not reproduce your problem.
I've just realized that you are using an old version of the yambo code (4.4). Before going on investigating the problem let me encourage you to upgrade to a newer version of yambo (4.5) and see if the problem persists. Also for debugging reason it is more comfortable for us to rely on the latest release. In passing to the new version, it is recommendable to generate new inputs as some variables could have slightly changed the name. If the problem persists we will try to reproduce your problem that did not show up by using minimal parameters.

Even if this is a minor problem, it is better to perform calculations using pseudopotential without the non linear core correction for the same reason that they are not fully compatible in QE with hybrids functional as it is not clear how to take into account the non-linear core correction in the exchange term, anyway this is a very minor issue.

Best,

Daniele