You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add some more developer information to the docs. In particular add that CI is run automatically only when on:
master
a branch with a name ending in gpu (e.g. lobpcg-gpu)
when manually triggered
on the DFTK.jl main repo (i.e. no forks)
Find out what is happening with the drop! function and speed up the mapreduce part
Speed up the view when doing an FFT. Removing the bounds check doesn't seem to do much, so maybe there is no "trick" to make it go faster. Instead, we could work on the mapping. For example, Antoine pointed out that if basis.variational is false, the mapping is the identity, so we could do:
if basis.variational
f_fourier .= view(f_real, kpt.mapping)
else
f_fourier .= f_real
Medium/long term
Xc term: I think a good way to start with this is by working on the DftFunctionals package
Compatibility with automatic differentiation
Get stresses to work
Miscellaneous
Support for an other architecture: in theory, one only has to define the corresponding DFTK.Architecture. However, it is highly likely that there will be a few bugs or missing features (for example linear algebra functions) from the corresponding GPU package.
Add support for more solvers (NLsolve, CROP). There have been discussions of removing the dependency in NLsolve from DFTK: the replacement solvers should keep in mind GPU programming and try to be compatible.
Investigate on the gmres! function from IterativeSolvers: it doesn't seem to be CUDA-compatible for now. Making it CUDA compatible would allow us to use the χ0Mixing.
The text was updated successfully, but these errors were encountered:
Following @antoine-levitt's advice, here is a short TODO list of additional features worth implementing for GPUs.
Short term (see also #794)
drop!
function and speed up themapreduce
partview
when doing an FFT. Removing the bounds check doesn't seem to do much, so maybe there is no "trick" to make it go faster. Instead, we could work on the mapping. For example, Antoine pointed out that ifbasis.variational
isfalse
, the mapping is the identity, so we could do:Medium/long term
Miscellaneous
DFTK.Architecture
. However, it is highly likely that there will be a few bugs or missing features (for example linear algebra functions) from the corresponding GPU package.gmres!
function from IterativeSolvers: it doesn't seem to be CUDA-compatible for now. Making it CUDA compatible would allow us to use theχ0Mixing
.The text was updated successfully, but these errors were encountered: