FYI, the "Program QTL - technical report" can be found in
$WIENROOT/SRC_qtl/QTL-tehnical-report.pdf according to [1].
[1]
https://www.mail-archive.com/[email protected]/msg22157.html
On 10/15/2024 3:11 AM, pluto via Wien wrote:
Dear Yichen,
There is a document called "Program QTL - technical report" by P.
Novak, I think it is available at the WIEN2k website. I think this
document explains many details of qtl.
Did you look at this document?
Best,
Lukasz
On 2024-10-15 09:01, Peter Blaha wrote:
I'm pretty sure that the difference comes from the symmetrization
(i.e. averaging) over equivalent atoms in lapw2.
In lapw2 (l2main) there is an explicit loop over "mult", which is not
present in qtl (l2main).
You may test this by reducing the symmetry and splitting your
equivalent atoms into 2 nonequivalent ones (labelling them eg. Fe1 and
Fe2; then follow the advise from sgroup.
With such a struct file, lapw2 with your rotation matrix should be
equivalent to qtl.
PS: Could you send me a struct file + a workflow , where the problems
with x qtl -so -band (with lapw2-fermi error AND missing case.in1c
file) appears.
Messages like "sometimes a problem occurs ..." do not help me. This
points more to a user-error.
Am 15.10.2024 um 06:57 schrieb Yichen Zhang:
Dear Lukasz and Peter,
I briefly looked into the code mainly for qtl in SRC_lapw2. I
realize that the differences in x lapw2 -band -qtl and x qtl -band
may not simply arise from the averaging (or maybe more properly
speaking, summation) of the equivalent atoms. I could be wrong due
to my limited understanding of the code. I have the following notes
and questions then regarding why band character results could be
different.
1) I notice that x qtl and x lapw2 use different code for partial
charges. x qtl has its own qtlmain.f, outp.f, split.f files and so
on in SRC_qtl. They are different code than in SRC_lapw2, despite
outputing qtl files in similar format. It seems very heavy work to
compare carefully how they differ in writing qtle in qtl and writing
qtlstore in lapw2.
2) Since lapw2 gives the confusing results, I further looked into
the relevant code in SRC_lapw2. Before that, an observation on the
lapw2 band qtl results is that the atom 2 px projected bands seem
very similar to the superposition of atom 2 px + atom 3 py from qtl
programme. This crossing similarity between atom 2 and 3 holds also
for like lapw2 atom 2 py = qtl atom 2 py + qtl atom 3 px, lapw2 atom
3 px = qtl atom 3 px + qtl atom 2 py, and so on. This was a bit
strange.
3) Now coming to the work flow in lapw2 (which I could be wrong due
to limited reading of the code), it is mainly controlled by
l2main.F, which allocates qtlstore on the memory and calls
subroutines like csplit.f, psplit.f, etc. The actual case.qtl file
is written by SRC_lapw2/outp.f. From here, I could tell in line 297
of outp.f (version 23.2),
“TCATOM=qtlstore(0,jatom,jb,jk)*MULT(JATOM)”. Therefore, the orbital
weight is only multiplied by a constant, the multiplicity of the
atom. In my case here, MULT for all atoms are 2. Therefore, there
doesn’t seem to be “averaging” among equivalent atoms, but just
multiplied by its multiplicity, which shouldn’t cause px and py
mixing. Now since all the qtl results are read from qtlstore, the
place where I could find for writing qtlstore is in
SRC_lapw2/psplit.f. Particularly, for my case here with ISPLIT=8 for
all atoms, it seems to be related to the lines starting at line 139
of psplit.f (version 23.2), where IF ISPLIT(JATOM).EQ.8, PX, PY, and
PZ are calculated from APX, BPX, capx, acpx, cbpx, bcpx, etc. These
APX, BPX are further found to be calculated in SRC_lapw2/p3splt.f
that uses ALM and BLM. The p3splt.f seems to be called by csplit.f,
which is further called by l2main.F. There is one comment in
csplit.f near calling all these p, d, f split subroutines saying
‘Create “CROSS”-partial charges’. I’m not quite sure what this means
by “CROSS” partial charges.
Does this potentially correspond to the observation in 2) where
there are orbitals summed together in lapw2 qtl? I’m not sure if I’m
following the right thread of code here, or if indeed the
implementation of calculating APX, BPX, and so on led to some
summation of partial charges between different atoms on PX, PY, etc.
4) An additional note is that, in order to find symmetry operations
that relate equivalent atoms, I notice that SRC_lapw2 has specific
code and output file for that. SRC_lapw2/rotdef.f would produce
case.rotlm file. The rotlm shows the symmetry operation matrices. In
my case, in addition to identity matrix that maps to themselves,
they are
1.00000 0.00000 0.00000
0.00000 -1.00000 0.00000
0.00000 0.00000 -1.00000
meaning a 2-fold axis along x, which is of course true reading from
the crystal structure. Case.rotlm doesn’t seem documented in the UG.
5) Indeed, z and x vectors in case.inq, if I remember correctly, are
in Cartesian coordinates. For my case here (orthorhombic), I rotated
it to the geometry to be convenient to compare with ARPES. I could
recall some previous discussions about vectors in case.inq for
hexagonal and rhombohedral systems from Luckasz, et al.
I would be grateful to learning more about the workflow of qtl in
lapw2 here regarding 3) and being able to understand why the two
results were different in the subtle way described in 2).
Best regards
Yichen
_______________________________________________
Wien mailing list
[email protected]
http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
SEARCH the MAILING-LIST at:
http://www.mail-archive.com/[email protected]/index.html
