Make DftFunctionals.jl types GPU compatible #23
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR is part of an effort to port DFTK's stress and response calculations to the GPU. The main issue with the current implementation is that various types are not
isbits
. Any data passed to a GPU kernel must beisbits
.Changes:
ComponentArray
toNamedTuple
. Usage remains the same, while the new type isisbits
.to_isbits()
function that returns aisbits
version of a functional. Issue is that theidentifier
field was restricted to be aSymbol
, which is notisbits
. The parametrization of theidentifier
is extended to acceptVal
, and theto_isbits()
function returns a copy of the input functional with the identifier set toVal{identifier}()
With these changes (and a few more, for a later PR), it is possible to run DFTK stress calculations on the GPU.
Possible points of contention/discussion:
runtests.jl
andchange_parameters
dispatching in individual functional implementations)NamedTuple
, vs formerlyComponentArray{<:Number}
. So the type of the individual parameters is not enforced. I am not 100% sure whether that is an issue.