Add new MP input sets / concurrently update MatPES POTCARs

[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

MatPESStaticSet Users: please note that the recommended POTCARs for MatPES (PBE64 generally) have updated. These updates are consistent with the data generation for MatPES, please use the 12 recommended updated POTCARs

[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

[shyuep]

I don't think this is an issue. A user can always override KPAR with user incar settings.

[Andrew-S-Rosen]

@esoteric-ephemera, @mkhorton: Just a head's up that the VASP team does strongly suggest using NPAR = 1 for LELF = True. I asked about it on the forum recently. Here was their response: https://www.vasp.at/forum/viewtopic.php?t=20020. That said, I did not get the error they are reporting and I am concerned about the computational costs associated with forcing NPAR = 1.

[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

[mkhorton]

Copying a suggestion here:

@esoteric-ephemera a late suggestion, but can we set GGA_COMPAT to False? See here for discussion.

[esoteric-ephemera]

@mkhorton: Sorry I forgot to answer! Yes shouldn't be an issue to add this, makes sense to me. Been running the recompute with this tag added

@shyuep: Should be ready for review

[Andrew-S-Rosen]

Linking this to #4301.