[WIP] Add new MP input sets

[esoteric-ephemera]

This PR adds new MP input sets that resulted from a benchmarking effort over the past year. For the benchmarks, refer to:

• 0026 - Updating the MP parameter sets foundation#26
• Reference living document

Critical updates include:

• POTCARs
• KSPACING adjustment by bandgap
• LREAL = False
• LMAXMIX = 6

The updated KSPACING function is slightly different from what was discussed with the MP foundation initially. This is to ensure that calculations with the highest $k$-point density (KSPACING = 0.22) would not be deprecated by this PR. Previously I recommended that the minimum KSPACING = 0.2, but this is effectively the same as 0.22.

Leaving this up as a WIP pending further community discussion and writing tests

[mkhorton]

I believe it restricts to NPAR = 1 not KPAR = 1. I am not sure where this restriction originates.

There is some logic that expensive-to-compute quantities should be saved by default? (e.g., to my knowledge the only way to recover the KE density from a VASP calculation is to store the ELF)

I see the sense in leaving this as False but I wonder what should be stored by default? I imagine there is a trade-off with I/O and post-processing time too, especially for simple calculations.

[esoteric-ephemera]

The manual says NPAR = 1, but the actual error message I get when I run VASP 6.4.2 (just checked) is: ELF: KPAR>1 not implemented, sorry. Either way, restricts the parallelization

You can reconstruct the KED from the orbitals in WAVECAR, since those should just be the plane wave coefficients + wave vectors (think we have tools in PMG to parse this but haven't looked thoroughly)

I'm good with LELF = True for the final static in the MP workflow, since this is usually very cheap (it starts from the WAVECAR of the r2SCAN relaxation)

[mkhorton]

So we hard-code KPAR: 1 for the final static?

Makes sense with the WAVECAR, I am genuinely wondering whether one day we should encourage storage of this by default if storage costs continue to reduce. I am encountering more and more post-processing tools that would really benefit if a large dataset of wave functions were available. I wonder how compressible they are with modern methods too, something I will not have time to investigate unfortunately!

[esoteric-ephemera]

A little hesitant to do that, especially if we want to treat larger systems, but it'll require some testing for me to see if KPAR = 1 is a real practical issue

Saving the vaspwave.h5 file might be better in the long run. There's currently an open PR for this, I also need to finish the vaspout.h5 PR

[matthewkuner]

@esoteric-ephemera is this PR ready for merging?

[esoteric-ephemera]

@matthewkuner debugging some potential issues with the Ba pseudo (updated to the GW one) - hope to have an update soon