[Wien] About recent bugs

[Marcos Veríssimo Alves]

Hello developers and knowledgeable people in general,

My first post to the list :)

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?

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?

Best regards,

Marcos Verissimo Alves
Universidad de Cantabria

On Sun, Jul 18, 2010 at 10:13 AM, Peter Blaha
<pblaha at theochem.tuwien.ac.at>wrote:

> Thank's for pointing out this problem.
>
> The specification of three "division numbers" is apparently very dangerous
> and
> if you "break" the symmetry with these numbers, it will produce nonsense.
> This is also true for P lattices (try P cubic and 3,4,5 mesh).
>
> The subroutine  reduz  is not prepared to handle "wrong" divisions. It
> creates
> "integer" indices for a k-vector (like (2 0 0) and (0 0 2)) and if a
> symmetry
> operation transforms x into z, these k-points are "equivalent", because it
> does not take
> into account that the divisors in x and z is different. (actually, these
> k-points would be
> (2/3 0 0) and (0 0 2/5) ad thus are of course NOT equivalent.
>
> I do not have a quick solution. At the moment make sure, that your mesh is
> compatible with lattice symmetry.
>
> mazin schrieb:
>
>  I found strange behavior in the kgen module.
>>
>> In the outputkgen file there is a list of all k-points with the
>> corresponding inequivalent points ("relations"). 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 "relations" with numbers that
>> exceed the number of inequivalent points. Yet the actual list of
>> inequivalent points (case.klist) is correct. Any comments?
>>
>> Thanks
>> Igor
>>
>
> --
> -----------------------------------------
> Peter Blaha
> Inst. Materials Chemistry, TU Vienna
> Getreidemarkt 9, A-1060 Vienna, Austria
> Tel: +43-1-5880115671
> Fax: +43-1-5880115698
> email: pblaha at theochem.tuwien.ac.at
> -----------------------------------------
>
> _______________________________________________
> Wien mailing list
> Wien at zeus.theochem.tuwien.ac.at
> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20100720/60744803/attachment.htm>