[QE-developers] questions and possible bug on exx calculations

[Lorenzo Paulatto]

I add to what already said by Paolo

>  1. On routines PAW_newdxx and PAW_xx_energy, the code is only executed
>     on ionode which I believe is a bug when k-point and/or band
>     parallelization is used.

The code is only executed in ionode, and the result added into 
deexx,later on in exx.f90 there is

IF (okvan) THEN
     CALL mp_sum( deexx(:,ii), intra_egrp_comm )
ENDIF

Which means that if we compute that part on all CPUs, the contribution 
would be multiplied by the number of CPUs. It would be better to majke 
PAW_newdxx parallel, but as it is inexpensive I did not bother. Bugs are 
always possible. Same story of PAW_xx_energy, which is added to energy, 
which is then summed over all CPUs
     CALL mp_sum( energy, inter_egrp_comm )
     CALL mp_sum( energy, intra_egrp_comm )
     CALL mp_sum( energy, inter_pool_comm )



>  2.  From what I see, tqr=.true. is not implemented for exx routines
>     when k-points are used.

It is implemented. To clarify: there is a part of code that is common to 
PAW and Ultrasoft, this part depends on the value tqr and is computed by 
either newdxx_r or newdxx_g. Than there is a part which is paw-only, 
which does not depends on the value of tqr; this is computed by 
PAW_newdxx. Also note that when okpaw=.true. also okvan is true.


>     The phases of the pair densities need be
>     added, probably inside addusxx_r for this to be correct. In a
>     handful of cases I've tested, I get significantly different results
>     with/without tqr with hybrid functionals and kpoints. Gamma point or
>     single kpoint runs, of course, is fine. It would probably be better
>     to perform a runtime check and abort if necessary.

There are probably some bugs in that part, but not what you think. 
Actually as the PAW specific part is identical with and without tqr, I 
would suspect the bug is in the Ultrasoft code.


cheers#
-- 
Lorenzo Paulatto - Paris