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

[Peter Blaha]

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

-- 
-----------------------------------------------------------------------
Peter Blaha,  Inst. f. Materials Chemistry, TU Vienna, A-1060 Vienna
Phone: +43-158801165300
Email: peter.blaha at tuwien.ac.at
WWW:   http://www.imc.tuwien.ac.at      WIEN2k: http://www.wien2k.at
-------------------------------------------------------------------------