Normalizing k-point symmetry
Some open issues are contingent on an updated k-points symmetry normalization. K-points come in 2 scenarios, but should have a combined solution:
- a uniformly spaced grid. Atm, these are only parsed in
wannier90
,wien2k
,abacus
,ams
and should be extended. Still, there will be cases where the underlying grid is not mentioned, and we have to fall back on the k-points printed out. Here, symmetrization is sporadically enforced by the programs or the user and not even consistently. Thek_line_density
quantity (discussed in #1239 (closed)) assumes such a symmetry-reduced k-point set of the Brillouin zone with multiplicities accounted. - a path (along high-symmetry points) through k-space, typically used for band structure calculations. High-symmetry points are identified, but not for each Bravais lattice (mentioned in #1210 (closed)). Normalization is only applied to identified band structures, but there are scenarios where users can bypass the internal generation algorithms of the code, e.g. in #1150 (closed).
Suggested solution workflow, starting from the outputted k-points:
-
determine the Brouillin zone (for all Bravais lattices) + translate all k-points inside (can we use the real-space symmetry here?) -
apply further symmetry operations to obtain the symmetry-reduced k-point set + keep track of multiplicities -
scan for any high-symmetry points to be present (this can be resolved first, following #1210 (closed)) -
determine whether the remaining points are a linear interpolation (i.e. lie along a difference vector), in which case we are dealing with a band structure calculation, or else with a k-grid. -
repeat this procedure for FHI-aims, where band structure and DOS calculations (i.e. different k-point sets) may be combined.