<div dir="ltr"><div dir="ltr">On Sat, Mar 28, 2020 at 7:51 PM Morales-Silva, Miguel A. <<a href="mailto:moralessilva2@llnl.gov" target="_blank">moralessilva2@llnl.gov</a>> wrote:</div><div dir="ltr"><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr">The augmentation functions in real space (e.g. <code><span>tabxx</span><span>(</span><span>ia</span><span>)</span><span>%</span><span>qr</span><span></span></code>(...)) 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.</div></blockquote><div><br></div><div>The phase in G-space, exp[i(k-k')\tau] I guess, comes from the structure factor that translates the augmentation function at the atomic position. There is something not right in the current real-space expression: the augmentation term as it is written now seems to be periodic, while the rest has a
exp[i(k-k')*r] dependence
</div><div><br></div><div>Paolo</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
best, <br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div id="m_-901877557581436472gmail-m_2517958673875178092Signature">
<div id="m_-901877557581436472gmail-m_2517958673875178092divtagdefaultwrapper" dir="ltr" style="font-size:12pt;color:rgb(0,0,0);font-family:Calibri,Helvetica,sans-serif">
<div style="font-family:Tahoma;font-size:13px">*************************************<br>
Miguel A. Morales<br>
Quantum Simulations Group, Physics Division<br>
Lawrence Livermore National Laboratory<br>
phone: 925-423-4956<br>
*************************************<br>
</div>
</div>
</div>
</div>
<div id="m_-901877557581436472gmail-m_2517958673875178092appendonsend"></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<hr style="display:inline-block;width:98%">
<div id="m_-901877557581436472gmail-m_2517958673875178092divRplyFwdMsg" dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>From:</b> developers <<a>developers-bounces@lists.quantum-espresso.org</a>> on behalf of Lorenzo Paulatto <<a>paulatz@gmail.com</a>><br>
<b>Sent:</b> Saturday, March 28, 2020 10:00 AM<br>
<b>To:</b> <a>developers@lists.quantum-espresso.org</a> <<a>developers@lists.quantum-espresso.org</a>><br>
<b>Subject:</b> Re: [QE-developers] questions and possible bug on exx calculations</font>
<div> </div>
</div>
<div><font size="2"><span style="font-size:11pt">
<div>I add to what already said by Paolo<br>
<br>
> 1. On routines PAW_newdxx and PAW_xx_energy, the code is only executed<br>
> on ionode which I believe is a bug when k-point and/or band<br>
> parallelization is used.<br>
<br>
The code is only executed in ionode, and the result added into <br>
deexx,later on in exx.f90 there is<br>
<br>
IF (okvan) THEN<br>
CALL mp_sum( deexx(:,ii), intra_egrp_comm )<br>
ENDIF<br>
<br>
Which means that if we compute that part on all CPUs, the contribution <br>
would be multiplied by the number of CPUs. It would be better to majke <br>
PAW_newdxx parallel, but as it is inexpensive I did not bother. Bugs are <br>
always possible. Same story of PAW_xx_energy, which is added to energy, <br>
which is then summed over all CPUs<br>
CALL mp_sum( energy, inter_egrp_comm )<br>
CALL mp_sum( energy, intra_egrp_comm )<br>
CALL mp_sum( energy, inter_pool_comm )<br>
<br>
<br>
<br>
> 2. From what I see, tqr=.true. is not implemented for exx routines<br>
> when k-points are used.<br>
<br>
It is implemented. To clarify: there is a part of code that is common to <br>
PAW and Ultrasoft, this part depends on the value tqr and is computed by <br>
either newdxx_r or newdxx_g. Than there is a part which is paw-only, <br>
which does not depends on the value of tqr; this is computed by <br>
PAW_newdxx. Also note that when okpaw=.true. also okvan is true.<br>
<br>
<br>
> The phases of the pair densities need be<br>
> added, probably inside addusxx_r for this to be correct. In a<br>
> handful of cases I've tested, I get significantly different results<br>
> with/without tqr with hybrid functionals and kpoints. Gamma point or<br>
> single kpoint runs, of course, is fine. It would probably be better<br>
> to perform a runtime check and abort if necessary.<br>
<br>
There are probably some bugs in that part, but not what you think. <br>
Actually as the PAW specific part is identical with and without tqr, I <br>
would suspect the bug is in the Ultrasoft code.<br>
<br>
<br>
cheers#<br>
-- <br>
Lorenzo Paulatto - Paris<br>
_______________________________________________<br>
developers mailing list<br>
<a>developers@lists.quantum-espresso.org</a><br>
<a>https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
</div>
</span></font></div>
</div>
_______________________________________________<br>
developers mailing list<br>
<a>developers@lists.quantum-espresso.org</a><br>
<a rel="noreferrer">https://lists.quantum-espresso.org/mailman/listinfo/developers</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div>Paolo Giannozzi, Dip. Scienze Matematiche Informatiche e Fisiche,<br>Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone +39-0432-558216, fax +39-0432-558222<br><br></div></div></div></div></div></div>