`DOPED` doesn't set `NBANDS` (?) about doped

[joebesity]

I haven't noticed this issue on any calcs I've set up since this initial post. Sounds like a rare occurrence and that trying to "fix" it in DOPED would be more over-engineering that is probably worth it, for what you say is likely only a 5-10% speedup... Happy to leave it as it is, but will let you know if I ever spot it again!

I think it must have been a fringe case, where adding one electron triggered VASP into bumping up another whole multiple of NBANDS (64 iirc). So yeah, not sure of the total impact of a fix for this issue is worth it.

[zhubonan]

BTW NBANDS needs to be a multiple of NPAR which is NCPUS / KPAR / NCORE.

I think VASP's round up will always result in the minimum possible NBAND to accomodate NPAR (number of band groups) that is larger than the originally supplied. Bad case arises when one is a bit over-parallelising (e.g. puting a handful of bands per band group)

I don't think DOPED should set it as VASP does it already, but just give out a warning would be useful. The estimated default NBANDS in VASP can be calculated from the POTCAR used. This also needs the user to input the number of MPI tasks, KPAR and NCORE (or the NPAR value itself).

[joebesity]

Rough idea on how to implement a fix to this... thanks @maudeinhorn for the suggestion

Some sort of automatic checker that will add up the number of electrons in the system and then choose a smart number of NBANDS because of this. This would require you to indicate which machine you're planning on running the calculations on (for internal SMTG use, perhaps for external use then just a simple metric of the cluster architecture?) when setting up input files, then it could just round up NBANDS to the most sensible multiple of cores above the VBM?

Interested to hear other approaches

[joebesity]

I also guess this is a massive pain on archer where there are 64 cores per node... 😅

[zhubonan]

This would be a useful function I think. Also by estimating which much "round up", we also know how much increase (roughly) in the computational cost it will be.

[kavanase]

HI @joebesity @zhubonan, thanks for the suggestions!
Reopening the discussion on this here. So the default in VASP is to set NBANDS equal to the maximum of either NELECT/2 + NIONS/2 or NELECT*0.6. Given the typical size of POTCARs (and thus NELECT), usually NELECT*0.6 will be the larger of these (empirically matches from a quick check through 8 different materials I've run defects/supercells in), while NELECT/2 + NIONS/2 often comes to somewhere in the region of ~0.55*NELECT.

Of course the number of occupied bands is equal to NELECT*0.5, and some amount of additional bands above this is required for:

1. Efficient electronic convergence, particularly depending on the choice of ALGO (see https://www.vasp.at/wiki/index.php/NBANDS), for which they recommend NELECT/2 + NIONS/2 as a good choice for this
2. To have a reasonable picture of the CBM DOS and position of defect states relative to this when analysing the calculation result.
3. Additional bands are also included as necessary when MAGMOM is used – which I guess is mostly relevant to your use cases @joebesity, though I guess still shouldn't cause a significant difference between different defect calcs in the same supercell?

So VASP currently already automatically rounds NBANDS up to the minimum value above this threshold of NELECT*0.6, based on the NCORE and KPAR settings and number of CPUs available, so I don't really see how inputting the parallelisation settings to doped would set NBANDS any differently than how VASP already automatically handles it, unless we were to set NBANDS to some value between 0.55 and 0.6*NELECT; but that seems like minimal benefit (max 5% speedup?) for the sake of potentially hurting convergence / DOS output and making the input generation more effort for the user and more system-dependent. I might be missing something so please point out if so!

[kavanase]

I get the benefit of having a pre-calculation estimate of how much round up in NBANDS there will be based on the default minimum NBANDS and NCORE & KPAR settings... Which I guess could be done fairly handy if the user sets NCORE and KPAR in the input incar_settings dictionary. How would this info be most useful to the user?

I guess could adjust NBANDS if there was a value in the region of 0.55 - 0.6*NELECT that would fit nicely, vs a larger roundup.

And possibly if it's a bad round-up (like >10% unnecessary bands) can suggest adjusting parallelisation settings to avoid this – though I would guess it'd be a rare case where this would be possible, as NCORE is usually fixed for a given HPC, and you typically only go lower (which makes roundup worse) rather than higher than your default, and then KPAR is often memory-limited for hybrid DFT supercells, but could possibly be bumped up in some cases

[kavanase]

Thanks for the input! Yeah I agree with all the above. Also posting @alexsquires's comment in the doped Slack channel for posterity

I tend to agree, internal settings for the group would be easier, and I did implement this is a branch of the group make-vasp-go-easier code.
For the general user, the DictSet.estimate_nbands() functionality in pymatgen could be helpful

Particularly the step of getting the user to specify how many cores they're gonna use, as well as having to have input NCORE and KPAR, would make it less user friendly. I think consensus there is that by default we shouldn't try to over-engineer this, as the VASP default in most cases is quite sensible

[kavanase]

Thanks all, will close this now