Dear Vasilii
This and other symmetry-related questions are recurrently discussed in
this list.
It is clear the benefit of including symmetries (to different possible
degrees)
in Siesta. But it does not have a high priority: Siesta is mainly
targeted for
large/complex systems, including AIMD. In this context it becomes secondary
if not useless. That is the reason why no extra complexity is added to
the code
in that direction.
There have been however external contributions that can help considerably.
For instance the utilities developed by Lev Kantorovich at Kings College
London,
see http://www.cmmp.ucl.ac.uk/~lev/codes/lev00/node6.html
Emilio
Vasilii Artyukhov wrote:
2007/5/4, Andrei Postnikov <[EMAIL PROTECTED]
<mailto:[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
--
Emilio Artacho
Department of Earth Sciences, University of Cambridge
Downing Street, Cambridge CB2 3EQ, UK
Tel. (+44/0) 1223 333480, Fax (+44/0) 1223 333450
[EMAIL PROTECTED], http://www.esc.cam.ac.uk/~emilio
