Questions about 'update_nscf_num_bands'

[greschd]

Questions about 'update_nscf_num_bands'

[qiaojunfeng]

Hi Dominik,

My understanding (based mostly on what I've been doing so far, could be wrong) is that its purpose is to extend the number of bands to cover all projections used by Wannier90. To make an example:

In the SCDM method the number of projections in Wannier90 is equal to the number of valence orbitals defined in the UPF files. So the purpose of the function update_nscf_num_bands is to set the number of bands in NSCF step equals [(max of number_of_electrons/2 and number_of_valence_orbitals) + some few more bands].

• silicon has configuration 3s2 3p2
• if we were to use only p projections in Wannier90, there would be 2 occupied and 4 unoccupied bands
• if we use this pseudopotential with z_valence=4, we should use nbnd>=8 to cover all the valence states of the pseudo, as well as all the "unoccupied projections" for NSCF. In the SCF, we may get away with nbnd>=4 since unoccupied states don't contribute to density. (for both cases we may add some bands to make the "interesting" bands better converged)

However, the get_nprojs_from_upf function returns 4, where I would expect 8 (2s + 6p).

I assume this is a non-spin calculation, so the bands have degeneracy 2. For a 2-atoms silicon primitive cell, in total 8 electrons, we need nbnd = 4 for valence-only calculation, and nbnd = 8 for valence + conduction calculation.
From the header of this Si.pbe-n-kjpaw_psl.1.0.0.UPF

    Valence configuration:
    nl pn  l   occ       Rcut    Rcut US       E pseu
    3S  1  0  2.00      1.600      1.800    -0.794729
    3P  2  1  2.00      1.600      1.800    -0.299966

So this UPF has 1 + 3 = 4 valence orbitals and this is what get_nprojs_from_upf returns, there are 2 atoms in silicon primitive cell, so the num_wann is 8. If you use only p projections in wannier90, then there are in total 2 (atoms) * 3 = 6 num_wann, different from SCDM.

Even more confusing, for [this In pseudo]https://www.quantum-espresso.org/upf_files/In.rel-pbe-dn-kjpaw_psl.1.0.0.UPF), the result is 17 (I would expect 18). Am I misunderstanding the purpose of update_nscf_num_bands, or is there an edge case here that is not considered? I think this part of the PP_INFO may be relevant:

    Valence configuration:
    nl pn  l   occ       Rcut    Rcut US       E pseu
    5S  1  0  2.00      1.800      2.000    -0.594935
    5P  2  1  1.00      1.900      2.500    -0.194078
    5P  2  1  0.00      1.900      2.500    -0.172410
    4D  3  2  4.00      1.400      1.700    -1.394116
    4D  3  2  6.00      1.400      1.700    -1.330978
    Generation configuration:
    5S  1  0  2.00      1.800      2.000    -0.594932
    5S  1  0  0.00      1.800      2.000     3.000000
    5P  2  1  1.00      1.900      2.500    -0.194079
    5P  2  1  0.00      1.900      2.500    -0.172409
    5P  2  1  0.00      1.900      2.500     6.000000
    5P  2  1  0.00      1.900      2.500     6.000000
    4D  3  2  4.00      1.400      1.700    -1.394112
    4D  3  2  6.00      1.400      1.700    -1.330972
    4D  3  2  0.00      1.400      1.700     5.000000
    4D  3  2  0.00      1.400      1.700     5.000000

But this In.rel-pbe-dn-kjpaw_psl.1.0.0.UPF is a little bit different, this is a relativistic pseudo, the valence info in the header is a bit misleading, we should look at the <PP_SPIN_ORB> block in the UPF, that is

  <PP_SPIN_ORB>
    <PP_RELWFC.1 index="1" els="5S" nn="1" lchi="0" jchi="5.000000000000e-1" oc="2.000000000000e0"/>
    <PP_RELWFC.2 index="2" els="5P" nn="2" lchi="1" jchi="5.000000000000e-1" oc="1.000000000000e0"/>
    <PP_RELWFC.3 index="3" els="5P" nn="2" lchi="1" jchi="1.500000000000e0" oc="0.000000000000e0"/>
    <PP_RELWFC.4 index="4" els="4D" nn="3" lchi="2" jchi="1.500000000000e0" oc="4.000000000000e0"/>
    <PP_RELWFC.5 index="5" els="4D" nn="3" lchi="2" jchi="2.500000000000e0" oc="6.000000000000e0"/>
    <PP_RELBETA.1 index="1" lll="0" jjj="5.000000000000e-1"/>
    <PP_RELBETA.2 index="2" lll="0" jjj="5.000000000000e-1"/>
    <PP_RELBETA.3 index="3" lll="1" jjj="5.000000000000e-1"/>
    <PP_RELBETA.4 index="4" lll="1" jjj="1.500000000000e0"/>
    <PP_RELBETA.5 index="5" lll="1" jjj="5.000000000000e-1"/>
    <PP_RELBETA.6 index="6" lll="1" jjj="1.500000000000e0"/>
    <PP_RELBETA.7 index="7" lll="2" jjj="1.500000000000e0"/>
    <PP_RELBETA.8 index="8" lll="2" jjj="2.500000000000e0"/>
    <PP_RELBETA.9 index="9" lll="2" jjj="1.500000000000e0"/>
    <PP_RELBETA.10 index="10" lll="2" jjj="2.500000000000e0"/>
  </PP_SPIN_ORB>

Specifically the PP_RELWFC. Here we have 5 valence orbitals: 5S: l = 0, j = 1/2, 5P: l = 1, j = 1/2, 5P: l = 1, j = 3/2, 4D: l = 2, j = 3/2, 4D: l = 2, j = 5/2, so in total there are 2 + 2 + 4 + 4 + 6 = 18 orbitals. The current get_nprojs_from_upf in the repo was written without considering spin orbit coupling pseudo, it is correct for non-relativistic pseudo but is wrong for this rel-pbe, so the the result 17 is wrong. Last week I rewrote these UPF parsers so now they works for both non-rel and rel-pseudos, but I haven't pushed commits to this repo. I also tried adding spin-orbit-coupling support to the SCDM workchain, I was stuck at the projwfc.x parser in aiida-quantumespresso, the current parser here does not support spin orbit coupling calculations. Also, I gave it a quick look and it seems the orbital definition in aiida-core here only support n, l, m quantum numbers, but not j, m_j quantum numbers. To add spin orbit coupling support to projwfc parser, we might need to update orbital definitions in aiida-core. So I postponed the work on spin-orb.

As a final question, what is the purpose of update_nscf_num_bands in the context of using the SCDM method? What is the logic behind how many unoccupied bands are needed then?

In summary, for non-spin case, the number of bands is [(max of number_of_electrons/2 and number_of_valence_orbitals) + some few more bands]. And the best approach to verify the number of projections used by quantum espresso is looking at the stdout of projwfc.x, e.g.
for your silicon pseudo, the projwfc outputs

     Atomic states used for projection
     (read from pseudopotential files):

     state #   1: atom   1 (Si ), wfc  1 (l=0 m= 1)
     state #   2: atom   1 (Si ), wfc  2 (l=1 m= 1)
     state #   3: atom   1 (Si ), wfc  2 (l=1 m= 2)
     state #   4: atom   1 (Si ), wfc  2 (l=1 m= 3)
     state #   5: atom   2 (Si ), wfc  1 (l=0 m= 1)
     state #   6: atom   2 (Si ), wfc  2 (l=1 m= 1)
     state #   7: atom   2 (Si ), wfc  2 (l=1 m= 2)
     state #   8: atom   2 (Si ), wfc  2 (l=1 m= 3)

2 atoms, 4 orbitals in UPF so in total 8 orbitals
for the Indium pseudo, projwfc outputs

     Atomic states used for projection
     (read from pseudopotential files):

     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)
     state #  19: atom   2 (In ), wfc  1 (l=0 j=0.5 m_j=-0.5)
     state #  20: atom   2 (In ), wfc  1 (l=0 j=0.5 m_j= 0.5)
     state #  21: atom   2 (In ), wfc  2 (l=1 j=0.5 m_j=-0.5)
     state #  22: atom   2 (In ), wfc  2 (l=1 j=0.5 m_j= 0.5)
     state #  23: atom   2 (In ), wfc  3 (l=1 j=1.5 m_j=-1.5)
     state #  24: atom   2 (In ), wfc  3 (l=1 j=1.5 m_j=-0.5)
     state #  25: atom   2 (In ), wfc  3 (l=1 j=1.5 m_j= 0.5)
     state #  26: atom   2 (In ), wfc  3 (l=1 j=1.5 m_j= 1.5)
     state #  27: atom   2 (In ), wfc  4 (l=2 j=1.5 m_j=-1.5)
     state #  28: atom   2 (In ), wfc  4 (l=2 j=1.5 m_j=-0.5)
     state #  29: atom   2 (In ), wfc  4 (l=2 j=1.5 m_j= 0.5)
     state #  30: atom   2 (In ), wfc  4 (l=2 j=1.5 m_j= 1.5)
     state #  31: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j=-2.5)
     state #  32: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j=-1.5)
     state #  33: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j=-0.5)
     state #  34: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j= 0.5)
     state #  35: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j= 1.5)
     state #  36: atom   2 (In ), wfc  5 (l=2 j=2.5 m_j= 2.5)

2 atoms, 18 orbitals in UPF so in total 36 orbitals.

For extending the SCDM workflow to spin-orbit case, I think the only limit is the projwfc parser.

Hope this helps!
Junfeng

[greschd]

Hi Junfeng,

Thanks for the detailed answer - that certainly helped clear up my confusion :)

I've also encountered the limitation of the projwfc parser (see aiidateam/aiida-quantumespresso#542) - but the part you've linked to appears to be the bigger issue.

I'll open an issue in aiida-core to get the discussion on the Orbital started.