<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:\7B49\7EBF;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:"\@\7B49\7EBF";
panose-1:2 1 6 0 3 1 1 1 1 1;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
text-align:justify;
text-justify:inter-ideograph;
font-size:10.5pt;
font-family:\7B49\7EBF;}
p.MsoCaption, li.MsoCaption, div.MsoCaption
{mso-style-priority:35;
margin-top:0cm;
margin-right:0cm;
margin-bottom:10.0pt;
margin-left:0cm;
text-align:justify;
text-justify:inter-ideograph;
font-size:9.0pt;
font-family:\7B49\7EBF;
color:#44546A;
font-style:italic;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:\7B49\7EBF;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:\7B49\7EBF;}
/* Page Definitions */
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="ZH-CN" link="#0563C1" vlink="#954F72" style="word-wrap:break-word;text-justify-trim:punctuation">
<div class="WordSection1">
<p class="MsoNormal"><span lang="EN-US">Dear QE developers,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" align="left" style="text-align:left"><span lang="EN-US">I am a postdoc researcher working at the Brookhaven National Lab under the supervision of Dr. Deyu Lu. My current research project involves benchmark calculations of Ti K-edge XANES
using the XSpectra code (QE 6.5 and 6.6), which was compiled on our local cluster using intel/psxe suite, mvapich2 and intel mkl library.<o:p></o:p></span></p>
<p class="MsoNormal" align="left" style="text-align:left"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal" align="left" style="text-align:left"><span lang="EN-US">I believe that I found a bug in XSpectra, which could cause inconsistent results using different k point parallelization for xspectra.x. Below is an example based on a super cell of
rutile TiO<sub>2</sub>. The calculation was done in two sequential steps: the first one is a scf calculation using only 1 k point at Gamma (1 1 1 0 0 0), and the second one is an xspectra calculation using 3x3x3 unshifted mesh. As shown in the Figure below,
the polarization averaged spectra are different, depending on the choice of the k point parallelization in the second step (nk 1; nk 2; nk 12) using QE 6.6. Note that in QE 6.5, the code will crash when I used k point parallelization for xspectra.x, as no
k point parallelization was used in the scf calculation. The effect is better demonstrated using a neutral potential for the absorber (i.e., independent particle calculation under the initial state rule), while the effect is less severe when running the calculation
using the core hole PAW potential. The input files used for the calculations are attached in this post for reproducing our results.<o:p></o:p></span></p>
<p class="MsoNormal" align="center" style="text-align:center;page-break-after:avoid">
<span lang="EN-US"><img width="321" height="257" style="width:3.3385in;height:2.6718in" id="Picture_x0020_1" src="cid:image001.png@01D807F2.27D96BB0" alt="Chart
Description automatically generated with medium confidence"></span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoCaption" align="center" style="text-align:center"><span lang="EN-US" style="font-style:normal">Figure
</span><span lang="EN-US" style="font-style:normal">1</span><span lang="EN-US" style="font-style:normal">. Ti K-edge XANES of rutile TiO<sub>2</sub> calculated using neutral potential with different k point parallelization schemes.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" align="left" style="text-align:left"><span lang="EN-US">Clearly the spectra shouldn</span>’<span lang="EN-US">t change using different nk values. After I examined the XSpectra code, I figured out the issue that is related to the Fermi energy.
After XSpectra reads the Fermi energy from scf calculation, it is reset as the HOMO for semiconductor using subroutine
<span style="color:black;background:#D9D9D9">get_homo_lumo</span> in <span style="color:black;background:#D9D9D9">
PW/src/print_ks_energies.f90.</span> This subroutine, however, only store the Ef=HOMO for the ionode, while the Fermi energies on other cores are unchanged. The Fermi energy was not broadcasted among different pools. Therefore, it will raise an issue if running
XSpectra using different pools in k point parallelization as the other pools have a different Fermi energy compared to the pool containing the ionode.
<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">To fix this issue, I have modified the xspectra.f90 source code, and inserted a line
<span style="color:black;background:#D9D9D9">CALL mp_bcast(ef, ionode_id, world_comm)</span> right after the Fermi energy is redetermined at subroutine
<span style="color:black;background:#D9D9D9">calculate_and_write_homo_lumo_to_stdout(ehomo,elumo)</span>. I also attached the modified xspectra.f90 file compatible for QE 7.0 in this post. If this issue and bug fix are confirmed, shall I submit request to commit
this change to the QE master branch?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Another concern is in file <span style="color:black;background:#D9D9D9">
plot_xanes_cross_sections.f90</span>. When gathering the results from different pool, subroutine
<span style="color:black;background:#D9D9D9">mp_sum (Intensity_coord, inter_pool_comm)</span> is called. I am wondering if we need a
<span style="color:black;background:#D9D9D9">mp_barrier</span> before this call to synchronize all the pools to perform the mp_sum?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Fanchen<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
</div>
</body>
</html>