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

[leoteo]

Hi Davide,

thanks a lot for your kind offer. I will provide a suitable collection of inputs this evening, if I fail to find the solution until then.

In the meanwhile, I was looking a bit into the code, in particular into interfaces/p2y/PP_PWscf_comp.F .

Regarding to the two databases I uploaded in the previous post:
The reason, why PP_KB is identically zero for the intel version is that the kb_E variable

Code: Select all

kb_E = psp%d(ibeta)/basis%struct%a_omega*0.5_SP  ! 0.5 = Ry2Ha
! psp%d(ibeta) =   1.8086597E-37
! basis%struct%a_omega =    53446.88

is identically zero in single-precision (which makes also pp_kb and pp_kbd zero).

For the gfortran version

Code: Select all

kb_E = psp%d(ibeta)/basis%struct%a_omega*0.5_SP  ! 0.5 = Ry2Ha
! psp%d(ibeta) =    1.02059998E-37
! basis%struct%a_omega =    53446.8750
! kb_E =    9.55685553E-43

kb_E seems to be stored in higher precision and is therefore not identically zero.
I.e. the difference between the two databases can probably be neglected; the question is whether they are both correct or both incorrect.

The reason why pp_kbd(1)=NaNf in both versions is that KpG_norm(1)=0. The calculation of pp_kbd involves KpG_norm(:npw)**(l-1) and with l=0 this yields infinity for pp_kbd(1).
I need to stress, however, that this NaNf does not lead to problems in the yambo calculations (no NaN for the QP energies). So maybe it can be ignored.

Unfortunately I cannot test gfortran on the machine, where p2y produces the random results. I will try to go on a third machine, where I can also test both intel and gfortran.

Is there a reference that could help me to understand the pp_kb and pp_kbd terms?

Best,
Leo

[Davide Sangalli]

Dear Leopolt,
thank you very much for your analysis.

Indeed 'psp%d(ibeta)' was not correctly set for your pseudo. I've just released a patch. If you are using the yambo version obtained via svn you can simply run "svn up" and the code should update. The bug was in qexml_4.0.F

For the term pp_kbd(1)=NaNf, it should be harmless.
Indeed when pp_kbd is used in the code the element 1 is never considered.

Best regards,
Davide

[leoteo]

Dear Davide,

thank you very much for the quick fix!

I have tested the new code on my 'good' machine, compiling p2y with intel and gfortran compilers. The contents of the ns.kb_pp_pwscf_fragment_1 databases generated by p2y now agree up to relative accuracy better than 1e-3 in the individual components (as a bad example, 0.2428378 vs 0.2427631 in PP_KB). I guess this is good enough(?).

I am not yet completely sure that this also solves all problems on my 'bad' machine, but I don't have access at the moment. If anything comes up, I will report again.

Thanks again,
Best,

Leopold

[Davide Sangalli]

Glad it worked. Thank you for giving us feed-back on the code.

The contents of the ns.kb_pp_pwscf_fragment_1 databases generated by p2y now agree up to relative accuracy better than 1e-3 in the individual components (as a bad example, 0.2428378 vs 0.2427631 in PP_KB). I guess this is good enough(?).

In single precision (which is the default for yambo) the code should have a precision of ~1.e-8. However when accumulating many number the relative precision is bound to decrease. In practice for example the relative error on integrated variables is ~1.e-5. If to compute the PP_KB yambo has to deal with numbers of the order of 1, the precision is given by the difference: 0.2428378-0.2427631 = ~7.5e-5 which I would consider reasonable, although a bit higher than expected. In any case I would not expect such an error to give any appreciable difference in your results.

Davide