workchain for spin-orbit-coupling

[qiaojunfeng]

Now the Wannier90BandsWorkChain in the opengrid branch supports spin-orbit-coupling (SOC) calculations.

Some prerequisites for using the workchain:

1. The aiida-quantumespresso should contain at least commit aiidateam/aiida-quantumespresso@031b92b
2. I couldn't find any "standard" pseudo for SOC case (let me know if you know better pseudos), so I am just using pslibrary, as specified in this json. This json is generated by this function, essentially it downloads UPF from QE website, then you can import those UPF by verdi data upf uploadfamily. If you want to use other pseudos, just modify the json file.

How to submit the workchain:
just add one line like this

aiida-wannier90-workflows/examples/workflows/run_automated_wannier.py

Line 187 in 1decab3

'spin_orbit_coupling': orm.Bool(True)

Let me know if you have comments, suggestions!

[qiaojunfeng]

Reports from Giovanni: changing the call parameters of seekpath_structure_analysis

-from aiida_quantumespresso.workflows.functions.seekpath_structure_analysis import seekpath_structure_analysis
+from aiida_quantumespresso.calculations.functions.seekpath_structure_analysis import seekpath_structure_analysis
-            self.inputs.structure, seekpath_parameters
+            structure=self.inputs.structure, **seekpath_parameters.get_dict()

This has been done in c00dd54 and 655c0f9, for master branch.

[qiaojunfeng]

Reports from Giovanni: moving the import inside the if statement:

       if self.inputs.use_opengrid:
+            from aiida_wannier90_workflows.workflows.opengrid import Wannier90OpengridWorkChain

Done in 30bd0f7, for opengrid branch.

[qiaojunfeng]

Currently, the workchain uses pslibrary SOC pseudos, consider using the (norm-conserving) full-relativistic pseudos from the pseudo-dojo (FR v0.4, PBE, stringent)?

TODO: need cutoff table

[qiaojunfeng]

problems with the function parse_number_of_pswfc_soc:

1. with the pseudos of the pseudo-dojo, it crashes because there is no 'oc' field in the XML rows - i temporarily fixed by just removing the three lines

   oc = float(child.get('oc'))
   if oc < 0:
   continue

but this might be wrong in general

Seems there are some slight differences between pseudos generated by different codes. I think we can skip these lines if there is no oc attribute in the PP_RELWFC tag. For all the pslibrary pseudos, all the oc are >= 0 so this if conditional has no effect.
I skip the check of oc in this commit 78b65e5

2. I'm not sure I follow the logic
   num_projections += 2 * lchi
   if abs(jchi - lchi - 0.5) < 1e-6:
   num_projections += 2

For a given quantum number l, there are 2 cases:

1. j = l - 1/2 then there are 2*j + 1 = 2l states
2. j = l + 1/2 then there are 2*j + 1 = 2l + 2 states so we have to add another 2

E.g. for In pseudo

     state #   1: atom   1 (In ), wfc  1 (l=0 j=0.5 m_j=-0.5)
     state #   2: atom   1 (In ), wfc  1 (l=0 j=0.5 m_j= 0.5)
     state #   3: atom   1 (In ), wfc  2 (l=1 j=0.5 m_j=-0.5)
     state #   4: atom   1 (In ), wfc  2 (l=1 j=0.5 m_j= 0.5)
     state #   5: atom   1 (In ), wfc  3 (l=1 j=1.5 m_j=-1.5)
     state #   6: atom   1 (In ), wfc  3 (l=1 j=1.5 m_j=-0.5)
     state #   7: atom   1 (In ), wfc  3 (l=1 j=1.5 m_j= 0.5)
     state #   8: atom   1 (In ), wfc  3 (l=1 j=1.5 m_j= 1.5)
     state #   9: atom   1 (In ), wfc  4 (l=2 j=1.5 m_j=-1.5)
     state #  10: atom   1 (In ), wfc  4 (l=2 j=1.5 m_j=-0.5)
     state #  11: atom   1 (In ), wfc  4 (l=2 j=1.5 m_j= 0.5)
     state #  12: atom   1 (In ), wfc  4 (l=2 j=1.5 m_j= 1.5)
     state #  13: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j=-2.5)
     state #  14: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j=-1.5)
     state #  15: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j=-0.5)
     state #  16: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j= 0.5)
     state #  17: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j= 1.5)
     state #  18: atom   1 (In ), wfc  5 (l=2 j=2.5 m_j= 2.5)

In fact this python function is a translation of the QE Fortran code uspp.f90:n_atom_wfc:

https://github.com/QEF/q-e/blob/7d5cebcf1250114756b88c6064ebe82e6f8fd835/Modules/uspp.f90#L69-L75

[giovannipizzi]

Thanks for the last clarification! It might be good to add this as a comment in the code so it's easier to understand.

[qiaojunfeng]

Thanks for the last clarification! It might be good to add this as a comment in the code so it's easier to understand.

Thanks, done in a41bd77