Twenty five example programs are presented in detail in the book A Practical Introduction to the Simulation of Molecular Systems. In spite of the differences between the versions of the DYNAMO library described there and in these web pages, the majority of the examples remain unchanged. The source code for the examples and the differences, if any, are given below. Note that the source code for the examples and their output files are included in the version of the library that can be downloaded.

In addition to the examples from the book, this page also includes four example programs that show the use of the semi-empirical quantum mechanical and hybrid potential modules in the DYNAMO library. In general, DYNAMO programs that perform calculations with QM, hybrid or MM potentials differ very little, except for a few statements that specify which atoms are to be treated quantum mechanically. Otherwise, the types of calculation and the way that these calculations are performed are the same.

Example 1

Example 1 remains unchanged.

Example 2

Example 2 remains unchanged.

Example 3

Example 3 has changed in two respects:

  1. The function Inertia_Matrix no longer returns a 3 by 3 two-dimensional matrix but an upper triangular packed matrix with six elements. The declaration of the array INERTIA has been changed accordingly.
  2. Instead of printing the matrix INERTIA explicitly, the subroutine Print_Symmetric_Matrix is employed.

Example 4

Example 4 remains unchanged.

Example 5

Example 5 has changed in one respect:

  1. The name of the variable TOTAL_PE in the module Potential_Energy has changed to ETOTAL.

Example 6

Example 6 has changed in one respect:

  1. The name of the variable TOTAL_PE in the module Potential_Energy has changed to ETOTAL.

Example 7

Example 7 has changed in one respect:

  1. The name of the variable TOTAL_PE in the module Potential_Energy has changed to ETOTAL.

Example 8

Example 8 remains unchanged.

Example 9

Example 9 remains unchanged.

Example 10

Example 10 remains unchanged.

Example 11

Example 11 has changed in one respect:

  1. The name of the variable TOTAL_PE in the module Potential_Energy has changed to ETOTAL.

Example 12

Example 12 has changed due to the rearrangement of the dynamics modules. The alterations are due to the splitting up of the argument list that was processed by the old subroutine DYNAMICS into three parts - a part concerned with velocity assignment that is handled by the subroutine Velocity_Assign, a part concerned with options common to all of DYNAMO's dynamics algorithms that is handled by the subroutine Dynamics_Options, and a part specific to the implementation of the dynamics algorithm that is handled by the subroutine that does the dynamics calculation, in this case the subroutine Velocity_Verlet_Dynamics.

In detail the changes to Example 12 are:

  1. The first lines of the Example, up to the start of the dynamics portion of the program, remain the same.
  2. At the very start of the dynamics, velocities must be given to the atoms. In the old version of the example this was done by the subroutine DYNAMICS directly. Now this must be done explicitly by a call to Velocity_Assign.
  3. The heating phase of the dynamics is achieved by a call to the subroutine Dynamics_Options which sets the timestep, the length and the print frequency options for the dynamics and a call to the subroutine Velocity_Verlet_Dynamics which actually does the simulation. Velocity_Verlet_Dynamics also processes the algorithm or implementation specific arguments that are concerned with temperature control. The heating is done in exactly the same way as in the old example.
  4. The equilibration phase of the dynamics is done in the same way as in the old example and uses the same syntax as for the heating phase described above. Thus, calls to the subroutines Dynamics_Options and Velocity_Verlet_Dynamics replace the call to the subroutine DYNAMICS. The only functional difference to the old example is that the same velocities are used and are not reassigned. To use new velocities (not of great importance) requires a second call to the subroutine Velocity_Assign.
  5. The data collection phase is performed in the same way as before but using the syntax described above.

Example 13

Example 13 remains unchanged.

Example 14

Example 14 has changed in two respects:

  1. The name of the variable TOTAL_PE in the module Potential_Energy has changed to ETOTAL.
  2. The two calls to the subroutine DYNAMICS have been replaced by the new sequence of calls to Velocity_Assign, Dynamics_Options and Velocity_Verlet_Dynamics. See Example 12 for a full discussion.

A further change that could be made to this subroutine and that would enhance the transparency of the example is the use of the module Constraint to define the harmonic distance constraints between the atoms. This change will be made in the future.

Example 15

Example 15 remains unchanged.

Example 16

Example 16 has changes similar to those made for Example 12 and concern how the subroutines from the dynamics modules are called. Please refer to Example 12 for a fuller discussion.

Example 17

Example 17 has changed in two respects:

  1. The name of the procedure TRAJECTORY_DSELF has changed to DCD_Dself and there is an extra optional argument that specifies the timestep for the trajectory.
  2. The name of the procedure TRAJECTORY_RDF has changed to DCD_RDF_Self.

Example 18

Example 18 has changes similar to those made for Example 12 and concern how the subroutines from the dynamics modules are called. Please refer to Example 12 for a fuller discussion. In constrast to Example 12, however, Example 18 uses a leapfrog Verlet algorithm, implemented in the subroutine Leapfrog_Verlet_Dynamics, to do the dynamics simulation with the Berendsen method of pressure and temperature control.

Example 19

Example 19 has changed in three respects:

  1. The procedure Encode_Integer has changed from a function to a subroutine which has necessitated the declaration of an intermediate character variable ISTRING to hold the encoded integer.
  2. The constraint definitions are handled using subroutines from the new module Constraint instead of the old module ENERGY_EXTRA. In the loop, calls to Constraint_Point_Define, Constraint_Initialize and Constraint_Define remove all previous constraints and define the new constraint whereas calls to Constraint_Writing_Start and Constraint_Writing_Stop control the writing of the constraint data.
  3. Changes have been made to the calls to the dynamics subroutines to account for the modifications to the dynamics modules. In addition, the subroutine Langevin_Verlet_Dynamics is used instead of Velocity_Verlet_Dynamics to perform the simulation. This subroutine should provide a better temperature control (and sampling from the NVT ensemble) than the Berendsen algorithm.

Example 20

Example 20 has changed in two respects:

  1. The procedure Encode_Integer has changed from a function to a subroutine. See Example 19 for a full discussion.
  2. The name of the procedure UMBRELLA_WHAM has changed to WHAM_Analyse.

Example 21

Example 21 remains unchanged.

Example 22

Example 22 remains unchanged except for the renaming of the type variable and the subroutines associated with reading trajectories. The new items all start with the characters DCD_ and are from the module DCD_IO whereas the names of the old items started with the characters TRAJECTORY_ and were from the module TRAJECTORY_IO. Although the names of these items have changed their calling sequences and usage remain the same.

Example 23

Example 23 remains unchanged.

Example 24

Example 24 remains unchanged.

Example 25

Example 25 remains unchanged.

QM Example 1

QM Example 1 performs a geometry optimization of the bALA molecule using the AM1 semi-empirical QM potential. The geometry optimization is carried out in the same way as in Example 6 but with two differences:

  1. The subroutine Coordinate_Define is used to define the atoms in the system. When the entire system is treated quantum mechanically it is unnecessary to pass by the more cumbersome procedure of defining the system's sequence and force field terms using sequence and MM files.
  2. The subroutine Mopac_Setup is used to define which semi-empirical method is to be employed - either AM1, MNDO or PM3 - and to determine which atoms are to be treated quantum mechanically. In this case, the AM1 method is chosen and all the atoms are treated quantum mechanically.

QM Example 2

QM Example 2 performs a path-integral molecular dynamics simulation of the molecule CH5+ in which all the atoms are treated quantum mechanically and all the atoms are treated as path-integral atoms with 32 copies of each. When doing path-integral calculations, each copy of a path-integral atom is considered to be independent and so each copy must be specified explicitly in the system definition. Thus, in this example, the coordinate file (in this case in XYZ format) that is used to define the atoms in the system contains 32 sets of coordinates for the CH5+ molecule. After the system has been defined, the subroutine Mopac_Setup is called to indicate which atoms in the system are to be treated as QM atoms and which atoms are to path-integral atoms. In this example, all the atoms are QM atoms and all are path-integral atoms. The identity of the path-integral atoms is specified through the array argument, PIFLAG, which contains a list of the atoms in each of the path-integral `necklaces' or beads.

Hybrid Potential Example 1

Hybrid Potential Example 1 performs a geometry optimization of a water dimer in which one of the molecules of water is treated with the AM1 semi-empirical QM potential and the second molecule with the OPLS-AA force field. The procedure for performing the optimization is similar to that of Example 6 except that the subroutine Mopac_Setup is called to specify which atoms are to treated quantum mechanically. The specification is made using the SELECTION argument and, in this case, is for the atoms of the second water molecule. It should be noted that Mopac_Setup must be called after the MM data for the system has been constructed or read in from an external file.

Hybrid Potential Example 2

Hybrid Potential Example 2 performs a geometry optimization of the bALA molecule in which the methyl side-chain is treated quantum mechanically and the rest of the molecule molecular mechanically. DYNAMO uses a link-atom approximation to deal with molecules that have been partitioned between QM and MM regions but, as these are added automatically by the subroutine Mopac_Setup for each bond that exists between QM and MM atoms, the program is the same as that of HP Example 1.

AMBER Example 1

AMBER Example 1 illustrates how data about a system can be written out in AMBER format. Coordinate data is written to AMBER coordinate files whereas information about a system's composition and its MM terms are written to AMBER topology files. This example was included primarily because the use of AMBER-format files is currently one of the easiest ways to transfer information between the older Fortran version of the DYNAMO library and its more recent cousins.

NEB Example 1

NEB Example 1 determines a reaction path for the transition between the chair and boat forms of cyclohexane using the NEB method. This is essentially the same as Example 9 but with the SAW commands replaced by their NEB versions.



Back to the DYNAMO Home-Page.