❓ Separate spin-orbit coupling from SpinType?

[mbercx]

Currently we have 4 different SpinType options:

• NONE: Non-polarised calculation
• COLLINEAR: Collinear spin-polarised calculation
• NON_COLLINEAR: Non-collinear calculation
• SPIN_ORBIT: Non-collinear calculation with spin-orbit activated

During the subgroup discussion on DFT inputs, it was suggested to separate the spin-orbit coupling input, since it's not really a different SpinType, but rather should be a flag that activates the use of the spin-orbit interaction.

---

I'm not sure if this change is really necessary. For me, it was quite intuitive to have SPIN_ORBIT as an additional SpinType, since it only makes sense to activate spin-orbit coupling when performing a non-collinear calculation anyways. Adding an extra input would just complicate the interface and also require extra validation.

[d-wortmann]

I do not understand the comment that the Spin-Orbit is tied to a treatment magnetism. While of course the SOC adds spin-offdiagonal contributions to the Hamiltonian the system nevertheless can be non-magnetic in the end. This can be utilized in different treatments. So if one want to combine this we should have NONE and NONE+SOC, COLLINEAR and COLLINEAR+SOC etc...

[qiaojunfeng]

So if one want to combine this we should have NONE and NONE+SOC, COLLINEAR and COLLINEAR+SOC etc...

SOC always requires a noncollinear calculation, at least this is what QE is doing. One thing worth considering is that when doing a SOC calculation there can be no magnetization (even it's a noncollinear calculation), also there can be magnetization together with SOC. So the current SPIN_ORBIT includes these two cases (or maybe cause some confusion?).

[d-wortmann]

SOC always requires a noncollinear calculation, at least this is what QE is doing.

But isn't this exactly the point here? Just because these features are tied in QE does not mean that all codes treat it this way or that it has to be treated like this. After all, we talk here about common WFs. We (FLEUR) have different modes to include SOC in different situations. Of course the Non-collinear+SOC case is the most general, but with this argument we could simply always do non-collinear magnetic calculations even for non-magnetic setups :-)

[qiaojunfeng]

but with this argument we could simply always do non-collinear magnetic calculations even for non-magnetic setups :-)

If you want to do non-collinear magnetic calculation for non-magnetic setup, I think the current SpinType allows you to do this: you specify SpinType.NON_COLLINEAR, and specify the initial magnetic moment as 0 (I guess there should be an input tag to specify the initial magnetic moment for the calculation in FLEUR?)

So the current SpinType only specifies what underlying equations will be used (scaler or spinor wavefunctions), and there is still an initial magnetization to be specified.

[giovannipizzi]

Indeed, just to clarify (we discussed extensively this morning in a group discussion with @sphuber @mbercx and @sponce24) and we'll mention this in the meeting in 30 minutes:

1. the input should signify which type of calculation we are doing, not if the final resulting material is magnetic or not (in a similar way, ElectronicType = metal does not mean that the system cannot be an insulator in the end - just that we're going to activate the numerics to deal with metals (smearing etc.)
2. We should indeed make sure the we define things in a common way - it's good that everybody brings their code experience so we see what's common and what is not

The current suggestion (but are still not sure of the names) would be the following (will be added soon to #236):

• Rename SpinType (possibly) to something like MagneticType or MagnetisationType or MagnetisationTreatmentType or .., with values none, collinear and non_collinear (internally it will determine whether to compute with a single wave function, two wave functions, or with spinor wave functions; but from the input, what it will change is if/how you can specify the initial magnetisation: cannot/as a list of 3 floats/as a list of 3 vectors, respectively
• Add a boolean spin_orbit flag

Codes might decide to validate and stop for incompatible options (for the given code) but we don't put a limitation on the common interface.