PSML

[azadoks]

PSML is an XML-based format that supports norm-conserving potentials, including kinetic energy densities for meta-GGAs, and can be generated by ONCV/METAPSP and the ATOM code maintained by SIESTA.
Currently, SIESTA and ABINIT support the use of PSML.

In this PR, I used Serde.jl for (de)serialization directly from/to a set of custom types defined to respect the PSML schema.

Because PseudoLibrary doesn't have any PSML families, I include the set of examples from the libPSML repo for testing. I additionally generated the same example Ba potential provided in the METAPSP test suite in PSML so that consistency could in future be checked against the UPF parser. Unfortunately, ONCV/METAPSP use different grids for PSML (sampled from the log grid) and UPF (interpolated onto a linear grid), so the consistency check is nontrivial.

[mfherbst]

Looks like an accidential commit.

[azadoks]

For some reason InteractiveUtils is the module that provides the subtypes method 🤷🏼‍♂️, which I use to write a bunch of macros to convert the PSML XML tag convention with - as a separator (e.g. core-corrections) to/from _ so that they can map to valid Julia variable names (e.g. core_corrections).

[mfherbst]

I see. I'm not a big expert in Julia metaprogramming, but I bet there are less heavy dependencies one could use to help with this. My point is that PseudoPotentialIO is essentially a dependency of the entire Julia materials modelling stack, so thinking about staying lightweight in the dependencies is something to keep in mind. I've seen InteractiveUtils to lead to problems in some HPC execution scenarios, so not exactly something I'd like to see unavoidably in our stack.

[mfherbst]

On the same note Serde is also not exactly lightweight, but there I see the benefits outweigh the cost. Could still be worth at least a quick discussion whether going down the road of optional dependencies is worthwhile considering. Or do you think supporting PSML is so important that it only makes sense to have it around all the time ?

[azadoks]

I see. I'm not a big expert in Julia metaprogramming, but I bet there are less heavy dependencies one could use to help with this. ...

Makes a lot of sense. I'll hardcode the result of subtypes and remove the dependency.

On the same note Serde is also not exactly lightweight, but there I see the benefits outweigh the cost.
...
Or do you think supporting PSML is so important that it only makes sense to have it around all the time ?

I think an optional dependency could make sense here.
From the looks of it, PSML is a much saner and more well-defined format than UPF is at the moment, and it's implementation in ONCV/METAPSP is more consistent than either PSP8 or UPF.
I think it's nice to have around and could be beneficial in certain circumstances.
Given that there's no real consumer of it at the moment, it could easily be optional though.

Another approach would be to set up a JLL for libPSML and just use that. It would be lightweight and we're also guaranteed compliance by definition.
libPSML uses a bunch of non-C-compatible derived types, so I don't think it's possible to use it from Julia.

[mfherbst]

For DFTK's own interest. Is it worth / possible to convert PSML -> UPF ?

[azadoks]

It should be possible; just a few open questions:

• PSML has the concept of multiple "sets" of nonlocal projectors (imagine a fully-relativistic pseudo where you might choose to write for convenience both the full "lj" projectors for downstream FR calculations and an "average" scalar-relativistic representation for NR calculations).
  • To convert in full generality, you'd need to select one set if there are multiple. There should usually be a good way to pick one automatically.
• In ONCV/METAPSP, the developers chose to write a subset of the log grid to the PSML files. libPSML provides a copy of the interpolation subroutine from ONCVPSP so that this irregular grid can be interpolated onto, e.g., a linear grid.
  • For consistency and compatibility with DFTK, we'd probably want to implement that interpolator here and use it for the conversion.

[Technici4n]

For me the main point of PSML would be to be able to use the log grid with DFTK, rather than the equispaced grid that e.g. the UPF output of ONCVPSP uses. But that could also be changed at the level of the UPF generator. Otherwise, PSML doesn't seem to buy much, and unlike UPF it is also limited to NC pseudos. My 2 cents.