[Wien] Differences in band character plotting using two methods under rotated local basis

[Gavin Abo]

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/wien@zeus.theochem.tuwien.ac.at/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