Add pslibrary ultrasoft and PAW families (scalar- and fully-relativistic, PBE)

[skilledwolf]

Adds four families packaged from Quantum ESPRESSO's pslibrary 1.0.0 (PBE): ultrasoft (rrkjus) and PAW (kjpaw), each in a scalar-relativistic and a fully-relativistic flavour. These are the first ultrasoft and PAW families in the collection.

• pslibrary.us.sr.pbe.v1_0_0.default.upf — Fe, Si
• pslibrary.us.fr.pbe.v1_0_0.default.upf — Bi, Fe, Pt, Si
• pslibrary.paw.sr.pbe.v1_0_0.default.upf — Fe, Si
• pslibrary.paw.fr.pbe.v1_0_0.default.upf — Bi, Fe, Pt, Si

One thing worth settling before the rest: that's a handful of elements, not a periodic table, and every family already here carries 64 or more. I put these together for ultrasoft/PAW work in DFTK (DFTK#1092), where a few elements spanning US/PAW × SR/FR is what you need to develop and test against, and pslibrary is the natural source in the QE ecosystem. Extending later is cheap — see the script below. But if you'd rather the collection only carried complete families, say so and I'll close this — better to hear it now than to have it sit.

Everything follows the pattern of the other collections: scripts/add_pslibrary.jl generates the whole tree. Its curated input is a per-element variant table (Fe is the spn semicore variant, Si the n one — the variant recommended per element on the pslibrary page, which is what the default tag refers to; pslibrary has no accuracy tiers) plus pinned md5 checksums. It downloads exactly those files, unmodified, from pseudopotentials.quantum-espresso.org, verifies them, and derives Ecut/supersampling from the wfc_cutoff/rho_cutoff fields of the UPF headers — so the recommendations transmitted here are pslibrary's own, like the other collections' are theirs. To add an element, extend the tables and re-run. The tree in this PR is exactly the script's output; scripts/check_pseudo_folders.jl passes.

Two smaller choices I'd like a ruling on. I added license and source keys to meta.toml — GPL-2.0-or-later, matching pslibrary's own "version 2, or at your option any later version" grant. No existing family records either key, and it seemed worth having for redistributed data, but it's your schema. And I left LIBRARY_VERSION alone, since I gather bumping it belongs to your release commit.

A companion PR registering these in PseudoPotentialData follows once there's a release to point at. PseudoPotentialIO#33 adds the accessor for reading the augmentation data out of files like these.

[mfherbst]

Thanks for the PR and sorry for the slow response, I hope to take a more detailled look later this week.

In general partial families are fine, but if all it takes is to add more elements in the script, why not do it ?

[mfherbst]

Some more comments after having had a closer look:

• Generally looks good. I am not sure why you call the variant default. If it's related to the selected core configuration, why not call it semicode, fullcore or similar like we did for the Goedecker pseudos (see add_cp2k.jl) ?
• I wonder to what extend pinning the variants using a dict (i.e. VARIANTS = Dict("Bi" => "dn", "Fe" => "spn", "Pt" => "n", "Si" => "n")) is a good idea. Again, in Goedecker we took the decision to rather implement some general mapping rules how to map from an element to a configuration.

I'm unsure what is a good strategy here, but we should make sure that we settle on something that is reasonably future-proof (e.g. changing the meaning of default or semicore in the future would be very bad). What's the approach the psplibrary is suggesting concretely regarding to the selection of the core ? Could you point to some docs or a paper. I could not find something on a quick read on the website.

Regarding the added keys:

• I think both are reasonable. But maybe source to me suggest the actual tarball to download (which you cannot do in general at the family level). Maybe website or upstream_website is better ?
• licence: Yes, I agree this should be in there as we are re-distributing. What to do for families that bundle different pseudos which may have different licences (I'm thinking of SSSP). How does SSSP deal with this ?