|
Allink
v0.1
|
The potential energy functions used by MOLMCD cannot be chosen at run time, but can be easily modified at compile time, by redefining typedefs and recompiling. The potential energy classes used by MolMcD are referred to throughout the class library by a set of typedefs. Thus, for example, the class that represents a pair potential is referred to throughout the implementation of MdSystem and McSystem by a typedef "PairPotential". In the default configuration of MolMcD, "PairPotential" is defined to be an alias for the "LJPotential" class.
In order to replace the Lennard-Jones potential by some other functional form for the pair potential, one must modify the typedef "PairPotential" to refer to another pair potential class with the same interface, and then recompile the class library. The relevant typedefs for pair and bond potentials are defined in the header files src/base/PairPotential.h and src/base/BondPotential.h, respectively. Each of these typedef definition files also includes a header files for the actual pair and bond potential classes (e.g., LJPair and HarmonicBond), so that only class that includes the typedef also includes the header for the class to which it refers. See the documentation for these typedefs for a more detailed explanation of how to change potential classes by changing a few lines in the appropriate header.
We have chosen to use typedefs rather than polymorphic classes and virtual functions for the potential classes for reasons of efficiency. The force and energy evaluation methods are called repeatedly in the inner loops of MD and MC simulations, respectively. For efficiency, we would like to be able to inline these methods. The use of polymorphic classes with virtual force and energy evaluation methods would be more flexible, and would allow the user to choose potential energies at run time, without recompiling. It would also prevent inlining, however, and so would incur the full overhead associated with virtual function calls in the inner loop of either type of simulation.
The other candidate for similar treatment is the Boundary class. Boundary provides inline methods to evaluate separations and distances that are called within the inlined force and energy evaluation methods. At the moment, there is no need for a typedef because we have implemented only one version of the Boundary class, which represents a periodic orthorhombic unit cell. If and when we need the flexibility to define (for example) a more general triclinic unit cell, Boundary may be converted to a typedef in order to allow the user to select between orthorthombic and triclinic unit cells at compile time, while still allowing these functions to be inlined.
1.7.6.1