[Wien] fold2bloch: problem with K - path in hexagonal lattice

Wolszczak, Weronika wolszcw at wfu.edu
Fri Nov 20 01:54:44 CET 2020


Dear Wien2k users,

I am trying to unfold a hexagonal 2x2x2 superlattice with fold2bloch tool,
but I am having difficulty with getting the right k-path. As my path is
rather complicated (GAMMA->M(1/2 0 0)->K(1/3 1/3 1/3)->GAMMA->A(0 0
1/2)->L(1/2 0 1/2)->H(1/3 1/3 1/3)->A(0 0 1/2)), I tried to use the script
which was previously advised here (fold.m)

https://github.com/rubel75/fold2Bloch-VASP/blob/master/utils/fold.m

in the following message:
https://www.mailarchive.com/wien@zeus.theochem.tuwien.ac.at/msg18482.html
However, this doesn't work properly (I'm having empty gaps in the unfolded
diagram). I tried a much simpler path, like M->GAMMA->K, with the following
input:

%% User input

kpath = [1/2 0 0; 0 0 0;  1/3 1/3 0]; % desired k-path after unfolding
npath = [16 16]; % # of points along each segment
folds = [2 2 2]; % multiplicity used to create a supercell

but this also results is a strange list of k-points:

         1         0         0         0         1 1.00
         2        -1         0         0        15 1.00
         3        -2         0         0        15 1.00
         4        -1         0         0         5 1.00
         5        -4         0         0        15 1.00
         6        -1         0         0         3 1.00
         7        -2         0         0         5 1.00
         8        -7         0         0        15 1.00
         9         7         0         0        15 1.00
        10         2         0         0         5 1.00
        11         1         0         0         3 1.00
        12         4         0         0        15 1.00
        13         1         0         0         5 1.00
        14         2         0         0        15 1.00
        15         1         0         0        15 1.00
        16         2         2         0        45 1.00
        17         4         4         0        45 1.00
        18         2         2         0        15 1.00
        19         8         8         0        45 1.00
        20         2         2         0         9 1.00
        21         4         4         0        15 1.00
        22        14        14         0        45 1.00
        23        16        16         0        45 1.00
        24         2         2         0         5 1.00
        25         4         4         0         9 1.00
        26        22        22         0        45 1.00
        27        -7        -7         0        15 1.00
        28       -19       -19         0        45 1.00
        29       -17       -17         0        45 1.00
        30        -1        -1         0         3 1.00

First 15 points seem to be fine, it goes from GAMMA (0,0) to -M ( -7/15, 0,
0) and then from M(7/15, 0, 0) back to GAMMA (1/15, 0, 0). However, the
next part it doesn' go to K point (1/3, 1/3, 0), but rather overshoots
(22/45, 22/45, 0), and there are only 4 points on the negative side, while
points between (-1/3 -1/3 0) and (0 0 0) are missing. It seems to me that
something is wrong here. Can someone comment if this is a correct output? I
did the same part of the path -K -> GAMMA -> K with XCrysDen and it goes
from (-1/3 -1/3 0) to (1/3 1/3 0) without any gaps, and this seems to be
reasonable but it doesn't agree well with the output of fold.m.

I'm not familiar with Matlab, but it seems to me that fold.m doesn't work
with a hexagonal lattice nor with more complicated paths like (0 0 0 -> 1/2
0 0 -> 1/3 1/3 0 -> 0 0 0). Can someone suggest how I can get the right
path? I suppose I can manually split the whole path into segments in
XCrysDen and stitch them all together  manually, but then how to treat
points which are not going through GAMMA, but which are on the surface of
BZ, like M->K? Shall I include a path which goes symmetrically around a*
reciprocal lattice vector or rather symmetrically around GAMMA (-K -> M ->
K or -K -> -M)? If I will generate a proper k-path manually, is it going to
work with fold2bloch and ubs_dots_w2k_octave.m or is it also going to cause
some troubles when plotting sections which are at the surface of BZ?


Best regards,
Weronika

-- 
Weronika Wiktoria Wolszczak
Postdoctoral researcher
TU Delft/Wake Forest University
LinkedIn <https://www.linkedin.com/in/weronika-wolszczak-6a8087a2>/Research
Gate <https://www.researchgate.net/profile/Weronika_Wolszczak>/Google
Scholar <https://scholar.google.com/citations?user=RKjzu0EAAAAJ&hl=en&oi=ao>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://zeus.theochem.tuwien.ac.at/pipermail/wien/attachments/20201119/9954b82a/attachment.htm>


More information about the Wien mailing list