Make functionals isbits types, in preparation for GPU usage#24
Make functionals isbits types, in preparation for GPU usage#24Technici4n wants to merge 3 commits intoJuliaMolSim:masterfrom
Conversation
- Functionals don't store their identifier anymore. The creator of a functional is responsible for remembering its identifier, if applicable. - Functionals directly store their parameters instead of a ComponentArray.
|
|
||
| identifier(pbe::PbeCorrelation) = pbe.identifier | ||
| parameters(pbe::PbeCorrelation) = pbe.parameters | ||
| function change_parameters(pbe::PbeCorrelation, parameters::ComponentArray; |
There was a problem hiding this comment.
Are you sure we don't need this ?
There was a problem hiding this comment.
The point was to have something, that allows to change parameters without knowing which parameters are actually around (e.g. many functionals have β and γ parameters under the same meaning and you may want something like change_parameter(xc, β=1.0) to be able to generically change this parameter without knowing what xc is.
There was a problem hiding this comment.
that allows to change parameters without knowing which parameters are actually around
Indeed, but I am not sure that this operation makes sense in practice. You'd still have to assume that the functional takes exactly β and γ for example, without knowing what they are used for.
The biggest use case is probably unwrapping Duals -- for that I have a @generated trick in DFTK.
There was a problem hiding this comment.
I'm happy to drop it for now if it causes headaches.
But I want to remark that this does indeed give a generic way to perform sensitivity analysis in standard functionals ... an aspect that I think is aspirational for us in the long run, so we should think a little if there is still a way this can be achieved generically, if we drop this.
There was a problem hiding this comment.
Looking towards the future and GPUs, a function like change_parameters can be quite useful.
The GPU compiler needs very explicit types for successful compilation. In my POC branch, I've used it to insure that upon entry of a function to be differentiated, all types are explicitly converted to match (e.g. here).
Generally, I think it can be convenient to get and set functional parameters in a generic way. This could be done by writing a function which returns the parameters as a NamedTuple, and a change_parameters function that takes a NamedTuple/ComponentArray.
|
Updated as discussed. The identifier is now looked up based on the parameters' values. |
3 participants
nothingis returned it means that the identifier is not available, and the functional will be printed using the default print for structs.