<div dir="ltr"><div dir="ltr">On Thu, Mar 26, 2020 at 7:39 AM Morales-Silva, Miguel A. <<a href="mailto:moralessilva2@llnl.gov">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">I apologize if this is incorrect or discussed somewhere else</div></blockquote><div><br></div><div>it is neither incorrect nor discussed somewhere else (well, partially, see below). Apologies for the late reply: your message had ended up in the spam folder, at least for me.<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)">
<div>
<div>
<ol>
</ol> 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<br></div></div></div></div></blockquote><div> </div><div>not necessarily so, as long as the results are properly broadcast <br></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)"><div><div>From what I see, tqr=.true. is not implemented for exx routines when k-points are used. <br></div></div></div></div></blockquote><div><br></div><div>quite possible. Some time ago I made a few tests on the US/PAW hybrid-functional code, and this was the situation:</div><div><a href="https://gitlab.com/QEF/q-e/-/issues/9">https://gitlab.com/QEF/q-e/-/issues/9</a> . I never found the time and motivation to investigate (motivation more than time: I wonder whether hybrid functionals for US/PAW will ever be competitive with respect to plain NC-PP)<br></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)"><div><div>
Many of the executables in the PP/src folder rely on read_file to initialize/setup the calculation. The routine init_us_1() is called inside. When uspp/paw are used in combination with finite kpoints in qvan_init(...) (e.g. as in exx routines), qnorm needs
 to be set correctly to get the interpolation grid of qrad set properly. Unfortunately, I can't calculate the necessary value of qnorm without knowing the kpoints, which are also read in read_file. <br></div></div></div></div></blockquote><div> </div><div>This is an old and known (at least to me) problem. The proper solution is in my opinion the following:<br></div>- the allocation and calculation of the interpolation table must be moved to a separate routine, to be called later</div><div class="gmail_quote">- the interpolation table is allocated for and computed up to some qmax, that must be already known when the routine is called</div><div class="gmail_quote">- if for some reason qmax is found to be not sufficient during the calculation (may happen in variable-cell relaxation) we re-inizialize the interpolation table. Alternatively, we define a larger qmax than needed at the startup (for instance, twice as much): this is what the "cell_factor" variable does. Alternatively: we use extrapolation for q > qmax.<br></div><div><br></div><div>Paolo<br></div>-- <br><div dir="ltr" class="gmail_signature"><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>