search

zerothi / sisl

Electronic structure Python package for post analysis and large scale tight-binding DFT/NEGF calculations
https://zerothi.github.io/sisl
Mozilla Public License 2.0
201 stars 60 forks source link

Spin-orbit in sisl #123

Closed samlipton closed 5 years ago

samlipton commented 5 years ago

Describe the feature

Spin-orbit (SO) is currently implemented as an 8-sized vector. I'm guessing that it is actually a 4-sized vector for the real and imaginary parts, as the pyx codes do not handle complex numbers yet (see issue #104). Therefore, is it correct that we have : 

SO = [Re(upup) Re(dndn) Re(updn) Re(dnup) Im(upup) Im(dndn) Im(updn) Im(dnup)] ?

If SO is treated that way, are there any changes to make when diagonalizing the matrix at k ? e.g when doing : 

band = sisl.BandStructure(H,HSk,nkpt,label)
bs = band.asarray().eigh() ?
zerothi commented 5 years ago
  1. Yes, SO is currently implemented as an 8-sized real vector
  2. These 8 real values correspond to the 2x2 spinor complex box by storing real and imaginary parts separately.
  3. Currently, sisl follows the siesta convention in terms of how the values are stored. If I remember correctly: [Re(upup) Re(dndn) Re(updn) -Im(updn) Im(upup) Im(dndn) Re(dnup) Im(dnup)] The reason for the apparent weird layout is because in the non-colinear case one only needs the first 4 elements, and in that case the 2x2 spin-box is Hermitian enabling -Im(updn) to be used as Im(dnup).

However, when doing H.eigh or band.eigh the method automatically knows whether it is a spin-orbit coupling matrix, non-colinear, spin-polarized or non-polarized calculation and does the appropriate thing. So basically, there is never need to change any routines when switching from a non-polarized to any other spin-configuration. sisl auto-detects this and does the correct thing, if the method hasn't been implemented an issue will be raised (otherwise it should be considered a bug). :)

zerothi commented 5 years ago

@samlipton did this answer your question? I.e. can I close the issue? :)

zerothi commented 5 years ago

@samlipton I'll close this as resolved. If it hasn't been resolved, please let me know :)

samlipton commented 5 years ago

Sorry for the late reply. I was testing SO in graphene and TMDs with the implementation : [Re(upup) Re(dndn) Re(updn) -Im(updn) Im(upup) Im(dndn) Re(dnup) Im(dnup)] (1)

As far as I'm concerned, this issue is closed if SO is indeed described by (1)

zerothi commented 5 years ago

In 6ac2a79c2ccac2e678fb8b951898f21c8b2f9e80 I have changed this the spin-orbit to hold:

[Re(upup) Re(dndn) Re(updn) Im(updn) Im(upup) Im(dndn) Re(dnup) Im(dnup)]

FYI!