Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Integrate with PseudoPotentialIO #823

Open
azadoks opened this issue Feb 15, 2023 · 0 comments
Open

Integrate with PseudoPotentialIO #823

azadoks opened this issue Feb 15, 2023 · 0 comments

Comments

@azadoks
Copy link
Contributor

azadoks commented Feb 15, 2023

Now that the new pseudo interface in PseudoPotentialIO has mostly stabilized, I tried out integrating it with DFTK by defining wrapper functions that follow the NormConservingPsp interface.

After fixing a few bugs and loosening function type signatures to un-break AD, most everything seems to work as expected, i.e. the same results as before, performance TBD (preliminarily, it looks a tad slower 😞).

If we want to provide a deprecation path for the old pseudopotential code in DFTK, some small changes will be have to be made, basically defining a functional interface for accessing the fields that are currently required by NormConservingPsp but which PseudoPotentialIO structs don't provide. I'd rather not re-name the fields in PseudoPotentialIO, so even though it's trivial, a handful of functions will be enough to allow the old and new to coexist.

To fully swap over to PseudoPotentialIO, the pseudopotential tests will need a going-over, and load_pseudo will need to be changed to use PseudoPotentialIO / the artifacts system.
Any calls to eval_psp* and the pseudo-related accessors will need to be changed. In theory, this could also be transparent to most users, so I'd advocate for going directly for this.

In an ideal world, we could also do some re-architecting in the form-factor calculations in DFTK: by swapping the order of the loops to go over angular momentum first (basically elevating conditions on angular momentum up a couple of loops), I think we could also gain some not insignificant performance benefits.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant