[Wien] Inconsistency in kgen

[balabi]

Dear Prof. Peter Blaha,


Thank you very much for your new fix.


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".


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).


Why is this happening? In the context of the FBZ, shouldn't the klist file contain 1000 unique k-points?


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.


Best regards,






------------------ Original ------------------
From:                                                                                                                        "A Mailing list for WIEN2k users"                                                                                    <peter.blaha at tuwien.ac.at>;
Date: Wed, Mar 20, 2024 05:48 AM
To: "wien"<wien at zeus.theochem.tuwien.ac.at>;

Subject: Re: [Wien] Inconsistency in kgen



Hi,

Yes, my fix was not correct. The bct and bco lattices are special cases 
and are also discussed in literature.

While the direct lattice vectors in bct have all the same length, the 
reciprocal lattice is face-centered tetragonal and thus they have 
different length. Nevertheless as far as I understand it is usually 
recommended to use the same divisions of them, when constructing a 
k-mesh. This was also enforced in WIEN2k, only the recent addition of 
specifying a delta-k was breaking this, but led to wrong multiplicities.
The algorithm for finding the multiplicity does not work for bct, when 
the divisions are not the same.

The present fix is to go back to the original bravai.f and use the new 
basdiv.f, which enforces equal k-divisions in the bct/bco case.


Thanks for checking.

Peter Blaha
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20240321/02ce9798/attachment.htm>