-
Notifications
You must be signed in to change notification settings - Fork 90
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
Add initial exact exchange implementation #942
base: master
Are you sure you want to change the base?
Conversation
Co-authored-by: bkaperick <[email protected]>
@antoine-levitt Thoughts or blockers ? |
""" | ||
function model_HF(lattice::AbstractMatrix, atoms::Vector{<:Element}, | ||
positions::Vector{<:AbstractVector}; extra_terms=[], kwargs...) | ||
@warn "Exact exchange in DFTK is hardly optimised and not yet production-ready." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
put that check in the instantiation of the exchange term?
@@ -0,0 +1,76 @@ | |||
@doc raw""" | |||
Exact exchange term: the Hartree-Exact exchange energy of the orbitals |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
calling it hartree is confusing?
# ABINIT/src/66_wfs/m_getghc.F90 | ||
# ABINIT/src/66_wfs/m_fock_getghc.F90 | ||
# ABINIT/src/66_wfs/m_prep_kgb.F90 | ||
# ABINIT/src/66_wfs/m_bandfft_kpt.F90 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd rather not give explicit references to code (as that might give the impression that we reproduced the implementation instead of a clean-room reimplementation)
# https://journals.aps.org/prb/pdf/10.1103/PhysRevB.73.205119 | ||
# https://journals.aps.org/prb/pdf/10.1103/PhysRevB.77.193110 | ||
# https://docs.abinit.org/topics/documents/hybrids-2017.pdf (Abinit apparently | ||
# uses a short-ranged Coulomb) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that we should meet and think about, also with @ELallinec who is thinking about the Coulomb singularity
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Definitely as a first attempt it's reasonable to have a short-ranged Coulomb.
Have you tested this in any way? I'm reluctant to merge something that might just be flat out wrong, esp. with the Coulomb singularity. Maybe H2? |
Is this even converging at all? There's basically no damping on the Fock exchange by doing it this way. Direct minimization OTOH should work outside the box |
Roadmap after discussion:
|
Hello, I am a doctoral researcher at the university of Ghent. I am considering DFTK as a main software to run my simulations. But I need the coulomb and exchange interaction between orbitals. I see that you were already succesfull in implementing the coulomb interaction for gamma-point calculations. I made a somewhat adapted version for my specific needs (coulomb interactions between Wannier orbitals). For now i got it to work for gamma point calculations as well. But i struggle to get realistic results for simulations with multiple kpoints. I get relatively large imaginary parts and other inconsistancies. I was wondering if there was any other internal progress made, not yet publicly available. I will share my code shortly as well, but for now i just wanted signal that i am working an a similar problem and open for conversation. |
ρnm_fourier = fft(basis, ρnm_real) | ||
|
||
fac_mn = occk[n] * occk[m] / T(2) | ||
E -= fac_mn * real(dot(ρnm_fourier .* term.poisson_green_coeffs, ρnm_fourier)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the justification for taking the real part here? shouldn't it automatically be real? (except for small numerical errors of course)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You have to take real parts at some point to get a real number out. If you take it out at the end you have to declare E = zero(Complex(T)) or your code is unstable.
Hi and thanks for your interest! I haven't worked on this at all, but I'm still interested so let me know if you want help! |
thanks for your interest and intent to use DFTK ! For the moment nobody is actively working on this. Effectively the missing piece is to implement an appropriate regularisation for the coulomb operator following the roadmap mentioned in above reply. If you happen to make any progress in this direction, we would be very happy to integrate it!. We are certainly open for conversation and happy to discuss a PR to DFTK. |
Small overhowl of #717.