DFTK.jl icon indicating copy to clipboard operation
DFTK.jl copied to clipboard

PAW

Open antoine-levitt opened this issue 1 year ago • 15 comments

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.

antoine-levitt avatar Jul 09 '24 16:07 antoine-levitt

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

simonganne01 avatar Feb 07 '25 14:02 simonganne01

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.

mfherbst avatar Feb 07 '25 16:02 mfherbst

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)

antoine-levitt avatar Feb 07 '25 16:02 antoine-levitt

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

simonganne01 avatar Feb 07 '25 17:02 simonganne01

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.

mfherbst avatar Feb 07 '25 17:02 mfherbst

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?

simonganne01 avatar Feb 07 '25 17:02 simonganne01

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.

mfherbst avatar Feb 07 '25 17:02 mfherbst

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

antoine-levitt avatar Feb 07 '25 17:02 antoine-levitt

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?

simonganne01 avatar Feb 08 '25 11:02 simonganne01

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

antoine-levitt avatar Feb 08 '25 11:02 antoine-levitt

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 avatar Feb 08 '25 12:02 simonganne01

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?

simonganne01 avatar Feb 13 '25 12:02 simonganne01

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.

antoine-levitt avatar Feb 13 '25 15:02 antoine-levitt

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

mfherbst avatar Feb 13 '25 19:02 mfherbst

Related topic, ultrasoft: #1092.

Technici4n avatar May 14 '25 12:05 Technici4n