2007/5/4, Andrei Postnikov <[EMAIL PROTECTED]>:
On Fri, 4 May 2007, Vasilii Artyukhov wrote:
| I was wondering how to make k-space sampling in SIESTA efficient.
Dear Vasilii:
it is efficient enough...
Well I'd say it's efficient in, for example, ABINIT, while SIESTA doesn't
seem to use symmetry at all, besides the time reversal.
| Since the
| code doesn't use symmetry to generate the k-points in the IBZ only,
using
| origin-centered Monkhorst-Pack grids seems a major waste of effort.
It is "a major waste" if you have few k-points; with more k-points
it becomes a moderate waste - but yes, there are (always?) less
irreducible k-points when they are shifted, than when they are unshifted,
for a given mesh density. But take care that in a shifted mesh, one
loses the information about band features at symmetric points
(e.g., band edges), which sometimes might be important to take into
account properly.
What I meant was to get fewer 'reducible' points in order to make the
sampling effectively denser at the same expense, given that SIESTA doesn't
care much for the symmetry.
| Now, as
| I understand, the grid could be shifted to make all k-points
inequivalent,
| giving a better sampling (up to 2x2x2 = 8 times better) at the same
| computational effort.
The idea is exactly the opposite - by shifting the points you make them
equivalent with more other points then while keeping them high-symmetric.
Think about a cube from -1 to 1 (in units of pi/2a) along each axis,
and having cubic symmetry around zero. You define 2 divisions, and
(unshifted) you get four non-equivalent points
(0,0,0), (1,0,0), (1,1,0), (1,1,1),
out of 8 in total.
Okay, so maybe it's time someone explained to me how does SIESTA build the
k-point grids. When I run the calculation with a 4x4x4 grid (unshifted), the
resulting .KP file contains 48 k-points. Their coordinates span the set {-
0.5, 0, 0.5, 1} X {-0.5, 0.0, 0.5, 1} X {0.0, 0.5, 1}, if I understand the
units in the file correctly. What I would have expected is a uniform grid of
64 points covering the whole BZ (-1,1] X (-1,1] X (-1,1]. In what I see,
SIESTA has thrown out 16 points at c=-0.5, as they would be equivalent to
those with c=0.5, but it decided to keep the a=-0.5 and b=-0.5 points. That
doesn't seem to make much sense, in fact, that's more or less why I've
started looking for a way to ensure, at least manually (with the shifts),
that SIESTA doesn't waste its time on that kind of thing!
In a shifted mesh, you'll have just one point (0.5, 0.5, 0.5)
which is equivalent to 7 others.
If you have just inversion, out of symmetry operations (as in Siesta),
you'll have (seems to... I might be wrong) all 8 unequivalent points
unshifted
and 4 points shifted.
| Is it correct? Should then my kgrid block
| look like this?
|
| %block kgrid_Monkhorst_Pack
| 4 0 0 .125
| 0 4 0 .125
| 0 0 4 .125
| %endblock
No. The displacement (in the last column) is given in units of
k-mesh step (that resulting from the division of reciprocal lattice
vector by 4, in your example). Defining a strange number of 0.125
will ensure every your k-point to become non-equivalent with
any other. This is completely legal but will leave you with 4*4*4=64
points, and no gain from the symmetry (inversion) at all.
In real life, you'd never want to use any other number
for the displaceent than 0. or 0.5.
Okay, then what I meant was actually 0.5, I just used the wrong units.
Anyway, how do I ensure that SIESTA doesn't make calculations at a number of
equivalent k-points like it would do in the above?
Conclusing this issue, I think it is long due (for someone... :-)
to programm tetrahedron integration in Siesta, it should be not so
difficult..?
In my experience, this is only efficient with really dense meshes, which is
not exactly what SIESTA is best at or has been developed for...
Thanks for the help,
Vasilii
