Hello developers and knowledgeable people in general,<div><br></div><div>My first post to the list :)</div><div><br></div><div>I have searched the list for the meaning of a few things in the .in1_st files, and how to change them properly by hand, and ended up finding a post by Prof. Blaha where he posts a corrected version of the x_lapw script in Wien2k 10.1, dating from June 21. I have downloaded this version about 10 days ago; should I update the x_lapw script, or the distribution has been updated with the corrected version of x_lapw right after the discovery of the bug?</div>

<div><br></div><div>About the bug in kgen posted in the mail below, would it be safer to specify the number of k-points instead? If yes, why would it be so?</div><div><br></div><div>Best regards,</div><div><br></div><div>

Marcos Verissimo Alves</div><div>Universidad de Cantabria<br><br><div class="gmail_quote">On Sun, Jul 18, 2010 at 10:13 AM, Peter Blaha <span dir="ltr">&lt;<a href="mailto:pblaha@theochem.tuwien.ac.at">pblaha@theochem.tuwien.ac.at</a>&gt;</span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Thank&#39;s for pointing out this problem.<br>
<br>
The specification of three &quot;division numbers&quot; is apparently very dangerous and<br>
if you &quot;break&quot; the symmetry with these numbers, it will produce nonsense.<br>
This is also true for P lattices (try P cubic and 3,4,5 mesh).<br>
<br>
The subroutine  reduz  is not prepared to handle &quot;wrong&quot; divisions. It creates<br>
&quot;integer&quot; indices for a k-vector (like (2 0 0) and (0 0 2)) and if a symmetry<br>
operation transforms x into z, these k-points are &quot;equivalent&quot;, because it does not take<br>
into account that the divisors in x and z is different. (actually, these k-points would be<br>
(2/3 0 0) and (0 0 2/5) ad thus are of course NOT equivalent.<br>
<br>
I do not have a quick solution. At the moment make sure, that your mesh is<br>
compatible with lattice symmetry.<br>
<br>
mazin schrieb:<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I found strange behavior in the kgen module.<br>
<br>
In the outputkgen file there is a list of all k-points with the corresponding inequivalent points (&quot;relations&quot;). This starts with the 37th line in the case.outputkgen file. This information is quite useful for postprocessing. I found that this list is always correct if you use a non-centered lattice, that is, not body-centered, face-centered, base-centered etc, and it is always correct when the number of divisions is the same for all reciprocal lattice vectors. However, if you use a centered lattice (try fcc, for instance), and division numbers as, say, 5,5,2, the resulting list is plainly incorrect. It gives &quot;relations&quot; with numbers that exceed the number of inequivalent points. Yet the actual list of inequivalent points (case.klist) is correct. Any comments?<br>


<br>
Thanks<br>
Igor<br>
</blockquote>
<br>
-- <br></div>
-----------------------------------------<br><font color="#888888">
Peter Blaha<br>
Inst. Materials Chemistry, TU Vienna<br>
Getreidemarkt 9, A-1060 Vienna, Austria<br>
Tel: +43-1-5880115671<br>
Fax: +43-1-5880115698<br>
email: <a href="mailto:pblaha@theochem.tuwien.ac.at" target="_blank">pblaha@theochem.tuwien.ac.at</a><br>
-----------------------------------------</font><div><div></div><div class="h5"><br>
_______________________________________________<br>
Wien mailing list<br>
<a href="mailto:Wien@zeus.theochem.tuwien.ac.at" target="_blank">Wien@zeus.theochem.tuwien.ac.at</a><br>
<a href="http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien" target="_blank">http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien</a><br>
</div></div></blockquote></div><br></div>