About¶
SKPAR is a software tool intended to automate the optimisation of parameters for the Density Functional Tight Binding (DFTB) theory. It allows a flexible and simultaneous use of diverse reference data, e.g. from DFT calculations or experimentally obtained physical quantities.
Conceptual Overview¶
The conceptual diagram of SKPAR is shown in Fig. 1, where the relation between the following entities is suggested:
- Model – a collection of executables outside SKPAR that produce some data; In the context of DFTB parameterisation the model may encompass Slate-Koster table generation (driven by some parameters per chemical element), and a number of DFTB calculations that yield total energy and band-structure for one or more atomic structures. SKPAR features a dynamic model setup via the declaration of a ‘Model Task-List’ in the SKPAR input file; There is no hard-coded application-specific model.
- Objectives – a set of single valued functions that depend on the model parameters; Typical example is a root-mean-squared deviation between some reference data (e.g. band-structure calculated by DFT) and the model data (e.g. the band-structure calculated by DFTB). SKPAR provides a generic facility for declaring objective function by specifying a list of Objectives in the input file; the specification includes instruction on accessing reference data and determines a query into the model and reference databases.
- Reference data – a set of data items that we want the model to be able to reproduce within certain error tolerance; Reference data may come from DFT calculations or be experimentally obtained. SKPAR admits explicit reference data in the input file, or instructions on how to obtain reference data by accessing and interpreting external files; support for database query is under development too.
- Cost function – a scalar function of the individual objectives mentioned above that yields a single number representative of the quality of a given set of parameter values. Currently SKPAR supports only weighted root mean squared deviation of the objectives from zero.
- Optimiser – an algorithm for efficient exploration of the parameter space with the aim of minimising the cost function. SKPAR features particle-swarm-optimisation (PSO) algorithm.
The sole purpose of the Optimiser in Fig. 1 is to generate parameters in a way that does not depend on the specifics of the model being optimised. The Evaluator in Fig. 1 acts as an interface between the embodiment of the Model by one or more external executables, and the Optimiser.
The declaration of objectives and model tasks, as well as the overall functionality of SKPAR is controlled by an input file (in YAML format), where the user must define as a minimum:
- A list of tasks that must be executed in order to obtain model data.
- A list of objectives that must be evaluated in order to assess overall cost.
- The optimisation strategy – algorithm, parameters, etc.
- Aliases to complex commands involving external executables
The optimisation loop realised by SKPAR is shown in Fig. 2.
Implementation Overview¶
SKPAR is implemented in Python and currently uses a Particle Swarm Optimisation (PSO) engine based on the DEAP library for evolutionary algorithms. Its control is done via an input file written in YAML.
Currently SKPAR provides two sub-packages: core
and dftbutils
.
The core
package is of general nature, and its coupling to
dftbutils
is only via a tasks dictionary, through which SKPAR
learns how to acquire data related to a DFTB model.
The dftbutils
package concerns with all that is necessary to obtain
data from a DFTB calculation. Presently, this package is limited in its
support to the executables provided by BCCMS at the University of Bremen,
Germany.
This assumes:
- SKGEN is used for Slater-Koster File (.skf) generation (by
slateratom
,twocnt
, and SKGEN),- DFTB+ is used as the DFTB calculator, and
- dp_bands is used as post-processor of eigenvalue data to produce band-structure data.
However, an easy extension to alternative tool-flow is possible, and current development aims to completely decouple model execution from the core of SKPAR.
See also
Subpackages and modules
Development
Extensions¶
The design of SKPAR features weak coupling between the core engine that deals with a general multi-objective optimisation problem, and the specifics of model execution that yields model data for a given set of parameter values. Therefore, its extension beyond DFTB parameterisation – e.g. to the closely related problems of parameter optimisation for empirical tight-bining (ETB) Hamiltonians or classical interatomic potentials for molecular dynamics, should be straightforward.