<meta http-equiv="Content-Type" content="text/html; charset=GB18030"><div><div style=""><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">Dear Prof. Peter Blaha,</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">Thank you very much for your new fix.</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">I have another question. When we generate an fbz 10x10x10 non-shifted kmesh for CaFe2As2, the klist file contains 1000 points. However, many of these points fall outside the 10x10x10 range. For example, the 560th point is listed as "14 14 10".</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">I guess applying the modulo operation by 10 is necessary, so "14 14 10" would be equivalent to "4 4 0," correct? However, when I apply modulo to all k-points, I find that many k-points are missing (e.g., {0,0,1}, {0,0,3}) and duplicated (in terms of modulo).</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">Why is this happening? In the context of the FBZ, shouldn't the klist file contain 1000 unique k-points?</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">Specifically, the 556th k-point is "10 10 10," which should be equivalent to "0 0 0" according to modulo. However, I checked the "0 0 0" k-point in output1 file has different eigenvalues compared to the 556th "10 10 10" k-point. I am confused by this discrepancy. Which k point "10 10 10" really refers? Please help. Thank you very much.</font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei"><br></font></div><div style=""><font face="lucida Grande, Verdana, Microsoft YaHei">Best regards,</font></div></div></div><div style="position: relative;"><div><br></div><div><br></div><div style="font-size: 12px;font-family: Arial Narrow;padding:2px 0 2px 0;">------------------ Original ------------------</div><div style="font-size: 12px;background:#efefef;padding:8px;"><div><b>From:</b>                                                                                                                        "A Mailing list for WIEN2k users"                                                                                    <peter.blaha@tuwien.ac.at>;</div><div><b>Date:</b> Wed, Mar 20, 2024 05:48 AM</div><div><b>To:</b> "wien"<wien@zeus.theochem.tuwien.ac.at>;<wbr></div><div></div><div><b>Subject:</b> Re: [Wien] Inconsistency in kgen</div></div><div><br></div>Hi,<br><br>Yes, my fix was not correct. The bct and bco lattices are special cases <br>and are also discussed in literature.<br><br>While the direct lattice vectors in bct have all the same length, the <br>reciprocal lattice is face-centered tetragonal and thus they have <br>different length. Nevertheless as far as I understand it is usually <br>recommended to use the same divisions of them, when constructing a <br>k-mesh. This was also enforced in WIEN2k, only the recent addition of <br>specifying a delta-k was breaking this, but led to wrong multiplicities.<br>The algorithm for finding the multiplicity does not work for bct, when <br>the divisions are not the same.<br><br>The present fix is to go back to the original bravai.f and use the new <br>basdiv.f, which enforces equal k-divisions in the bct/bco case.<br><br><br>Thanks for checking.<br><br>Peter Blaha<br><br><br><br></div>