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

[pluto]

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
>> Wien at zeus.theochem.tuwien.ac.at
>> http://zeus.theochem.tuwien.ac.at/mailman/listinfo/wien
>> SEARCH the MAILING-LIST at:  
>> http://www.mail-archive.com/wien@zeus.theochem.tuwien.ac.at/index.html