Difference between revisions of "Category:Moving atoms"
(Description of strategies) 
(No difference)

Latest revision as of 12:01, 8 August 2014
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 transitionpath 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 pathintegrals.
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 firstprinciples 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 movingatoms 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 movingatoms 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 movingatoms routines to be written without dependencies from the dft side.
Pages in category "Moving atoms"
The following 5 pages are in this category, out of 5 total.