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

[Morales-Silva, Miguel A.]

Regarding #1, the contributions from ionode to the energy and to deexx are properly broadcasted,
the problem comes with pool and band parallelization in exx. In this case, ionode only operates
on a subset of the (xkq,xkp) kpoint pairs and on a subset of the (ibnd,jbnd) band pairs.
Contributions not assigned to ionode are not included. This can be easily seen by accumulating
the result from PAW_xx_energy on a separate variable and looking at its value as a function of npools.
Results clearly vary with the number of kpoint pools. These contributions are typically so small, that at
the end it probably doesn't matter.

Regarding #2, it is correct that the problem is in the charge augmentation, common to both PAW and USPP.
There are clear differences in runs with nkpts>1 with and without tqr. The augmentation functions in real space
(e.g. tabxx(ia)%qr(...)) do not depend on the specific k-points of the orbital pair densities being augmented.
This, I believe, is incorrect. The phase factor coming from (xkp-xkq) is added in addusxx_g, but not in addusxx_r.

best,

*************************************
Miguel A. Morales
Quantum Simulations Group, Physics Division
Lawrence Livermore National Laboratory
phone: 925-423-4956
*************************************

________________________________
From: developers <developers-bounces at lists.quantum-espresso.org> on behalf of Lorenzo Paulatto <paulatz at gmail.com>
Sent: Saturday, March 28, 2020 10:00 AM
To: developers at lists.quantum-espresso.org <developers at lists.quantum-espresso.org>
Subject: Re: [QE-developers] questions and possible bug on exx calculations

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
_______________________________________________
developers mailing list
developers at lists.quantum-espresso.org
https://lists.quantum-espresso.org/mailman/listinfo/developers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20200328/02ead0c1/attachment-0001.html>