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

PAW #987

Open
antoine-levitt opened this issue Jul 9, 2024 · 14 comments
Open

PAW #987

antoine-levitt opened this issue Jul 9, 2024 · 14 comments

Comments

@antoine-levitt
Copy link
Member

I don't want to bother implementing PAW, but I found the very nice
http://staff.ustc.edu.cn/~zqj/posts/VASP-All-Electron-WFC/ so I'm just putting this link up here for reference if somebody is interested.

@simonganne01
Copy link

I assume nobody is implementing this yet, because it would be very nice since this really is state-of-the-art. I looked at the documentation of gpaw as well, and the things needed to implement this are certainly compatible with DFTK but a lot of work to implement. I want to adopt DFTK as main simulation software but PAW would be a requirement in order to really adopt it

@mfherbst
Copy link
Member

mfherbst commented Feb 7, 2025

Indeed @simonganne01 nobody is actively working on PAW. As you mention it would be considerable work (but also very interesting) and we would be open and support any help in this direction.

@antoine-levitt
Copy link
Member Author

I don't think it's that much work especially now that we've got numerical pseudos, all the tools are there, it's just a matter of plugging the formulas correctly. The more annoying part is getting that to work with the rest of the stuff (forces, phonons, etc)

@simonganne01
Copy link

yes, i was reading into the subject and it seemed like it is doable. only constructing the projectors seems a lot of work. But it would be nice to have this implemented in a more human readable way. My alternative is using gpaw since it is open source as well, but i am dissappointed in the readability of gpaw. they use to many classes and subclasses etc. I would like to work on it but i am afraid that it will turn out to take much longer than expected

@mfherbst
Copy link
Member

mfherbst commented Feb 7, 2025

I don't think it's that much work especially now that we've got numerical pseudos

well we don't have ultrasofts. That would be the first step, getting all this augmentation charge business in place and get that working reliably within an SCF (and mixing ...). The step up from there to PAW is not that large though, I agree.

@simonganne01
Copy link

So what you are saying is that we first need ultrasoft pseudopotentials and from there we can calculate the necessary parameters for paw. or am i missing something?

@mfherbst
Copy link
Member

mfherbst commented Feb 7, 2025

Not quite, it's more of a programming question. The next step to expand DFTK towards PAW on the SCF-side and the diagonalisation would be to implement ultrasoft pseudos. This gets much of the plumbing in place you need for PAW.

@antoine-levitt
Copy link
Member Author

Looking at https://www.tcm.phy.cam.ac.uk/castep/documentation/WebHelp/content/modules/castep/thcastepultrapseudo.htm it really doesn't seem that hard : it's just a bunch of extra things in H and S that are low rank operators built from functions given on a radial grid, so very similar to numerical norm conserving pseudos

@simonganne01
Copy link

I see that DFTK is not using the latest version of PseudoPotentialIO, and that the latest version of pseudopotential IO has already defined several classes for ultrasoft etc. outside of DFTK. Is it intended that this be updated to a newer version of pseudopotentialIO and that the pseudopotential classes from there be used?

@antoine-levitt
Copy link
Member Author

Pspio will get us the atomic data we need, but we still have to make use of it in dftk

@simonganne01
Copy link

yes but we want to use the classes of PseudopotentialIO to store the data and then add different terms to the overlap and hamiltonian depending on the pseudopotential through multiple dispatch right?

@simonganne01
Copy link

Is it intended that the classes inside the PseudoPotentialIO package will replace the current pseudopotential classes in DFTK? I think this will e a cleaner implementation. Furthermore, is there a reason that PseudoPotentialIO is not included in the JuliaMolSim repositories?

@antoine-levitt
Copy link
Member Author

I'm not very familiar with the pseudopotentials code but those are API questions. To work on this the priority would be to actually code up the equations (using whatever hack is needed to get the info from the psps to DFTK) and to test them. Then the API stuff is relatively minor and can be worked out more constructively once it's clear what functionality is actually needed.

@mfherbst
Copy link
Member

I agree and yes the idea was to longterm have the pseudo stuff live in pspio.

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

3 participants