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
This issue is to discus how to enable users to have control on DFT specific inputs through the common interface. With DFT specific inputs we mean the choice of the functional, to enable various level of corrections (vdW, +U, ...) and so on.
Regarding the functionals PBE must be the default (for bw-compatibility) and compulsory to have. Then we should agree on the others to support (LDA, PBEsol, maybe SCAN as strongly suggested) and define unique names (use libXC?).
Regarding the actual implementation, a proposal from @giovannipizzi is to create CommonRelaxWorkChain subclass (say CommonRelaxDFTWorkChain) same as parent class, but with additional Dict input (we should decide schema), for DFT-specific (but common) inputs.
This approach basically just add an independent input to manage the DFT specifics. Questions rise on the interplay of this input with the protocol input. Is it feasible for each code to decouple the choice of the level of accuracy (protocol) from the DFT inputs? To make a practical example: a set of parameters (kpoints, PWcutoff, basis, ..) that is considered "precise" for PBE, can be considered "precise" also switching to LDA?
In any case it would be important to provide methods that allow to explore the available options for each implementation AND also say whether a functional (PBE, LDA, PBEsol, ...) or feature (vdW, +U,...) is just available or available and tested with one or more protocols.
The text was updated successfully, but these errors were encountered:
This issue is to discus how to enable users to have control on DFT specific inputs through the common interface. With DFT specific inputs we mean the choice of the functional, to enable various level of corrections (vdW, +U, ...) and so on.
Regarding the functionals PBE must be the default (for bw-compatibility) and compulsory to have. Then we should agree on the others to support (LDA, PBEsol, maybe SCAN as strongly suggested) and define unique names (use libXC?).
Regarding the actual implementation, a proposal from @giovannipizzi is to create CommonRelaxWorkChain subclass (say CommonRelaxDFTWorkChain) same as parent class, but with additional Dict input (we should decide schema), for DFT-specific (but common) inputs.
This approach basically just add an independent input to manage the DFT specifics. Questions rise on the interplay of this input with the
protocol
input. Is it feasible for each code to decouple the choice of the level of accuracy (protocol
) from the DFT inputs? To make a practical example: a set of parameters (kpoints, PWcutoff, basis, ..) that is considered "precise" for PBE, can be considered "precise" also switching to LDA?In any case it would be important to provide methods that allow to explore the available options for each implementation AND also say whether a functional (PBE, LDA, PBEsol, ...) or feature (vdW, +U,...) is just available or available and tested with one or more protocols.
The text was updated successfully, but these errors were encountered: