[Pw_forum] matdyn.x: why are input/output k-points in the units of 2pi/a_0?

[Serge Nakhmanson]

Dear PWSCF developers,

I have used espresso 3.* and 4.* to do phonon calculations
at various individual k-points in the BZ. My typical
routine was

   pw.x (scf) + pw.x (k, nscf) + ph.x (k) + dynmat.x (k)

PW manual for phonon calculations with &PHONON namelist
calls for units of 2pi/a for xqq(i). As I understand, these
are what you call "crystal coordinates" for k-points. So,
for example, xqq = (0.5, 0.5, 0.5) for a tetragonal system
would bring me into a corner of my BZ. All my experience
confirms that this procedure works well and gives me phonons
at the appropriate k-points.

Currently, I am using version 4.0.2 to learn how to compute
phonon dispersions across the BZ. Here, my routine is the
following:

   pw.x (scf) + ph.x (k_grid) + q2r.x (to get IFC(r))

Then I use my own script (not kpoints.x) to generate k-point paths
that I feed into matdyn.x to produce the dispersions. The description
of matdyn input says the following about the k-points:

   !     (q(i,n), i=1,3)    nq q-points in 2pi/a units

I automatically assumed that matdyn.x also expects input
k-points in the "crystal coordinates" and produces output
in the same coordinate system. However, now my impression is
that it actually works with k-points that are in what you
call "cartesian in units of 2pi/a_0." E.g., in tetragonal
systems with c != a, when I feed my "crystal" k-points to
matdyn.x, I either do not get full dispersion curves or I
get them repeated many times over (depending on my c/a ratio),
when the Z direction is involved.

I don't know whether such an arrangement is intentional or a
bug (I did not see this among the 4.0.3 bug fixes) but it
surely is confusing and inconvenient (for me, at least), and
it also seems to be inconsistent with the rest of the code.
I fixed my own copy of matdyn.f90 to work in "crystal" coordinates
(simple!) and I dare to suggest that it may be a good idea to make
this change "official," since it will still be a drag fixing this
each time a new version of espresso comes out. However, if it
*has to* operate in 2pi/a_0 units, at least it would be prudent
to put an expanded comment about this into matdyn.f90. A
great alternative option would be to make matdyn.x recognize
both coordinate systems by flipping an input switch.

I have trolled the forum looking for any previous reports of
this problem but found nothing. Still, if you are already aware
of this issue or consider it somewhat insignificant, I would like
to apologize for taking so much of your time (it turned out to be
a relatively long post). And seriously, thank you for your
effort!

THX,

Serge

-- 
*********************************************************
  Serge M. Nakhmanson               phone: (630) 252-5205
  Assistant Scientist                 fax: (630) 252-4798
  MSD-212, Rm. C-224
  Argonne National Laboratory
  9700 S. Cass Ave.
  Argonne, IL 60439
*********************************************************