[Pw_forum] pw.x generates duplicate k-points in scf mode

[Mike Mehl]

Apologies if this goes through twice, the first time I used the wrong 
email address and I don't know if the moderator will pass the message on 
or not:

Attached, if I did things correctly, are two input files.  Both of them
are used to do an scf calculation for a frozen phonon determination of
frequencies at the X point of the B11 structure of AgZr.  As such, the
primitive vectors of the unit cell look orthorhombic, but the symmetry
of the structure is monoclinic:  P2_1/c (#14).  For this particular
orientation the 4 symmetry operations are +\- (x,y,z) and +/- (x+1/2,
-y+1/2, -z).  I mention all of that because I suspect it's relevant to
the problem.

Once I've properly adjusted the FFT mesh pw.x finds 4 symmetry
operations, including the fractional ones and the inversion, consistent
with the P2_1/c space group.

The attached file X_gen.in generates the k-point mesh using:

K_POINTS (automatic)
   8 4 4 0 0 0

This results in 50 points.  I have a k-point generating routine lifted
from our old LAPW program which also computes k-points from the lattice
vectors and the space group operations.  Both programs give identical
(within a symmetry operation) k-points, so I'm sure this is correct.

For many of my calculations I want to keep the identical k-point list,
in a standard order.  So:

The attached file X_raw50.in inputs the k-points via:

K_POINTS (crystal)
50
    0.0000  0.0000  0.0000  0.01562500
    0.0000  0.0000  0.2500  0.03125000
    0.0000  0.0000 -0.5000  0.01562500
[47 lines omitted]

where the 50 k-points are the lattice coordinates of the points
generated by X_gen.in.

Here's where the problem occurs:  running pw.x on with X_raw50.in as
input generates 60 k-points.  The first 50 are identical to those
generated by the first run, except that 10 of them have different
weights.  The last 10 k-points are duplicates of points of the 10 points
which changed weights in the first part of the list.  Not points related
by symmetry, but the exact k-points.

For example, if we look at point 5 in the run generated by the first
input file, we find:

k(    5) = (   0.0000000   0.0189061   0.0198824), wk =   0.0312500

The same point in the output generated by the second input file gives:

k(    5) = (   0.0000000   0.0189061   0.0198824), wk =   0.0156250

not to worry, the rest of the weight shows up later:

k(   56) = (   0.0000000   0.0189061   0.0198824), wk =   0.0156250

Furthermore, if I take the 60 k-points of this output and use those as
input to pw.x I get 80 k-points generated.  If I use those 80 points, I
get 120 points generated.  Presumably this continues forever, the same
10 k-points and duplicates being reduplicated with every iteration.

Of course all of these runs generate the same total energy at every
iteration, and converge in the same number of iterations.

The mailing list hints that this kind of thing may happen in **nscf**
runs, where the solution is to run with nosym=.true.  I'm leery of doing
this in an scf run, since I don't know how it affects the final charge
density, and my test calculation showed a slight difference in total
energies.

One of my long-term goals for using QE is to generate, more or less
automatically, a large number of runs for frozen phonon calculations
over a variety of supercells, using k-points generated externally.  I'll
be happy to discuss the whys and wherefores off-list.  But I don't want
to take the 20% performance hit (more with larger meshes) that comes
with this k-point duplication.

So, should I run with nosym=.true.?

Alternatively, I assume that this is happening because of something in
the k-point generation routine.  Perhaps there is a tolerance factor in
comparing k-points that is set too tightly.  Is there a variable which
would allow me to adjust this tolerance?  (In kpoint_grid.f90 the
tolerance is set to 1.0d-5, which is too big to cause problems.  But
that routine doesn't seem to deal with externally generated k-points.)

-- 
Michael J. Mehl
Head, Center for Computational Materials Science
Naval Research Laboratory Code 6390
Washington DC
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: X_gen.in
Url: http://www.democritos.it/pipermail/pw_forum/attachments/20100324/dad5dd17/attachment.txt 
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: X_raw50.in
Url: http://www.democritos.it/pipermail/pw_forum/attachments/20100324/dad5dd17/attachment.asc