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

[pluto]

Dear Yichen,

I agree with your comments.

I did not even try to understand the precise relation between lapw2 and 
qtl ;-) I think the only way to go with the orbital projections is to 
use qtl. I use lapw2 only sometimes for total for some atom.

Maybe do couple of simple cases to make sure everything behaves as 
expected. This is what I did, but I already forgot the details.

You should be careful to set the quantization axis correctly in 
case.inq. As I remember it refers to the real-space unit cell lattice 
vectors (please check), so sometimes one needs some trigonometry to get 
45deg or another angle that relates to ARPES.

I think qtl is a bit outdated and it has small bugs we just discussed, 
but I am not sure if there is anyone who would be able to refresh it...

Best,
Lukasz



On 2024-10-14 18:26, Yichen Zhang wrote:
> Dear Lukas,
> 
> Thank you very much for your comments and explanations.
> 
> 1) This could make more sense, as lapw2 -band -qtl averages out
> equivalent atoms. For all the atoms considered here, they have
> multiplicity = 2, so they are averaged with another atom in a
> different layer (related by some symmetry). x -qtl only picks the
> nonequivalent atoms in case.struct. Therefore, it gives me the local
> orbital projections I wanted to see. I will have to check the exact
> symmetry operations that connect the equivalent atoms to understand
> how lapw2 -qtl differs from x -qtl. Maybe this is the reason, but I
> don’t immediately see in the crystal structure why px and py would be
> mixed in lapw2 when averaging, as they seem to have the same local
> orientation of 45 deg rotated xy, and I assume the same loc rot matrix
> in case.struct is applied to all equivalent atoms? I don’t know if the
> loc rot matrix is also rotated by the symmetry operation between
> equivalent atoms while propagating, which could lead to averaging
> between px and py.
> 
> 2) Yes, I use Igor Pro to look at case.qtl, rather than x spaghetti.
> 
> 3) Yes, it indeed complained about not having case.in1c. I forgot to
> include that bug in the report. I just copied case.in1 to case.in1c.
> 
> 4) Yes, I now have read the threads where you and Peter, Gerhard,
> Laurence discussed about disconnecting or swapping equivalent atoms
> for hidden spin polarization. In my case, I wanted to look at orbital
> projections (locally), which has similarities to your discussion.
> 
> 5) Yes, matrix element rules in ARPES is sometimes not directly
> indicating orbitals due to multiple scattering. I have checked with
> KKR one-step calculation with light from different directions to
> simulate what was seen in experiments. The inferred orbital texture
> from one-step is qualitatively consistent with the x -qtl results from
> wien2k. (As you probably know, fully relativistic one-step calculation
> code does not conveniently project orbital projections to
> non-relativistic basis, so I resort to wien2k for explicit orbital
> projections and cross-checking). In the one-step calculations, TR-LEED
> final state and proper termination plane were used.
> 
> 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