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.bl...@tuwien.ac.at&gt;;
Date:&nbsp;Wed, Mar 20, 2024 05:48 AM
To:&nbsp;"wien"<wien@zeus.theochem.tuwien.ac.at&gt;;

Subject:&nbsp;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
_______________________________________________
Wien mailing list
Wien@zeus.theochem.tuwien.ac.at
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:  
http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html

Reply via email to