qiaojunfeng
commented
4 years ago 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 usenbnd>=8to cover all the valence states of the pseudo, as well as all the "unoccupied projections" for NSCF. In the SCF, we may get away withnbnd>=4since 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_upffunction returns4, where I would expect8(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.299966So 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 expect18). Am I misunderstanding the purpose ofupdate_nscf_num_bands, or is there an edge case here that is not considered? I think this part of thePP_INFOmay 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.000000But this
In.rel-pbe-dn-kjpaw_psl.1.0.0.UPFis 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 are2 + 2 + 4 + 4 + 6 = 18orbitals. The currentget_nprojs_from_upfin the repo was written without considering spin orbit coupling pseudo, it is correct for non-relativistic pseudo but is wrong for thisrel-pbe, so the the result17is 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 theprojwfc.xparser inaiida-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 inaiida-corehere only supportn, l, mquantum numbers, but notj, m_jquantum numbers. To add spin orbit coupling support to projwfc parser, we might need to update orbital definitions inaiida-core. So I postponed the work on spin-orb.As a final question, what is the purpose of
update_nscf_num_bandsin 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 all! I'm trying to understand the details of the
update_nscf_num_bandsfunction here.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:
z_valence=4, we should usenbnd>=8to cover all the valence states of the pseudo, as well as all the "unoccupied projections" for NSCF. In the SCF, we may get away withnbnd>=4since 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_upffunction returns4, where I would expect8(2s + 6p).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 expect18). Am I misunderstanding the purpose ofupdate_nscf_num_bands, or is there an edge case here that is not considered? I think this part of thePP_INFOmay be relevant:As a final question, what is the purpose of
update_nscf_num_bandsin the context of using the SCDM method? What is the logic behind how many unoccupied bands are needed then?