Here you find all routines and tools that relate with moving atoms in general, meaning mostly molecular dynamics and geometry relaxation, with the many algorithms and flavours to both. But this theme also includes other functionalities and methods, such as transition-path searching (with or without previous knowledge of destination basin, as in the nudged elastic band for the former, and the dimer method for the latter), or path-integrals.
Within the context of electronic structure, a key characteristic of this theme is that the by far most computationally demanding part is the computation of the ab initio forces for the given positions. Which means that the computational effort associated to the algorithms and software within this theme is absolutely negligible considering the total cost of the simulation. This implies that the computational strategies for moving atoms in a first-principles setting can be quite different from the ones of the molecular dynamics codes for large systems using empirical potentials.
There are three main strategies reflected in ESL for the moment:
- Using a whole standalone DFT code as a force evaluator, and calling it from scripts that encode the moving-atoms algorithms, communicating via parsing input and output files. This is what the Atomic Simulation Environment (ASE) does. It is extremely flexible and versatile. On the downside, the parsing can be fragile, the initialisation from scratch of a DFT code every time is somewhat wasteful, and it can conflict with usage policies of HPC centers. The flexibility makes up for these limtations, however.
- Using standalone DFT codes as force evaluators, as before, but communicate with them with sockets or pipes, so avoiding the parsing and the restarting problems. The socket interface and an implementation are described here and here. It requires patching the DFT codes so that they can communicate the right data with the controlling scripts or programs.
- Everything within a compiled program, which introduces more rigidity and dependences, but solves the problems mentioned above. For a sequential job like relaxation or MD, for instance, using a scheme like:
program main call initialise_dynamics % defining algorithm, flavour etc call initialise_dftforces do for all moving steps call dftforces(in:positions,cell; out:forces,stress) call dynamics(in:forces,stress; out:positions,cell) enddo call post_dft % for analysis of electronics call post_dynamics % for analysis of trajectory end program main
it defines a scheme that can allow the incorporation of many different moving-atoms routines. The "dynamics" routine representing just a main routine that calls the particular ones used. Information particular for electrons and for moving atoms would be in well separated modules, allowing for the moving-atoms routines to be written without dependencies from the dft side.