I'm not an expert on crystal coordinate systems.
case.klist and case.klist_band need to use the same coordinate system,
right? Both seem to be read by inilpw.f when unit 4 is used in case.in1.
In the Wien2k 12.1 user guide for case.klist:
We use carthesian coordinates in units of 2pi/a, 2pi/b, 2pi/c for
P,C,F and B cubic, tetragonal and orthorhombic lattices, but internal
coordinates for H and monoclinic/triclinic lattices
carthesian - the h in the UG seems to be a typo
In SRC_kgen/birken.text:
USE of klist in inilpw.f of SRC_lapw1
-
...
orthogonal lattices
...
k-points in scaled cartesian coord. [2pi/a,2pi/b,2pi/c]
non-orthogonal lattices
...
k-points in fractional coordinates [b1,b2,b3]
As Ron mentioned, there is the if statement (SRC_lapw1/prtkpt.F) that
converts the 'CONVENTIONAL reciprocal vectors' (of the b-centered cell)
to the 'PRIMITIVE reciprocal vectors'.
This does seem to suggest that SRC_lapw1/inilpw.f reads 'CONVENTIONAL
reciprocal vectors', or Conventional-ITA by Bilbao Crys. Server, for the
C(monoclinic) lattice.
If the xcrysden output for C(monoclinic) needs to be CONVENTIONAL
instead of PRIMITIVE, it should be easy to change in
xcrysden-1.5.53/F/getintcoor.f.
On 10/29/2012 6:55 PM, Ronald Cohen wrote:
On Mon, Oct 29, 2012 at 8:54 PM, Ron Cohen rcohen at ciw.edu
mailto:rcohen at ciw.edu wrote:
In xcrysden there is the following code:
c
c WIENXX definition::
c
c H, R, P, C(monoclinic) -- correspond to PRIMITIVE
reciprocal vectors
c is this really true !!!
c F, B, C(orthorhombic) -- correspond to CONVENTIONAL
reciprocal vectors
So it seems the issue of coordinate systems is indeed confusing.
What exactly are they? Thanks! Ron
On Mon, Oct 29, 2012 at 6:49 PM, Ronald Cohen
cohen at gl.ciw.edu mailto:cohen at gl.ciw.edu wrote:
I am trying to do band structures for C2/c and having
difficulty figuring out the coordinate system for
klist_bands . I had to modify my structure to B2/b because
wien2k doesn't allow normal monoclinic settings. But now I
have the issue of what are the coordinates in klist_bands.
I found this in lapw1:
IF(.not.ORTHO.and.lattic(1:3).eq.'CXZ') then
sxhelp=sx
sx=sx+sz
sz=-sxhelp+sz! fixed CXZ bug
endif
So it seems only in this case is the coordinate system
changed. It seems it should be the conventional primitive
lattice kpoints, so that 100 ( 40 0 0 40 for example)
would be a reciprocal lattice point. Or is it in the
centered reciprocal lattice? If the latter, is the
transformation printed anywhere?
xcrysden seems to generate in primitive coordinates, as
does aflow, so that would be convenient.
Thank you!
Sincerely,
Ron
-- next part --
An HTML attachment was scrubbed...
URL:
http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20121109/d8f6614d/attachment.htm