Specifying the Energy/Gradient Evaluator
Introduction
Driver routines that require evaluation of energies and gradients
will require an argument (usually theory=) to specify
the type of calculation to be performed. The options available
will depend on which interfaces have been built.
In most cases it will be necessary to pass arguments to the energy/gradient
function, and this is achieved using the
: notation
Examples
the following examples illustrates the use of
the opt geometry optimiser with two different
energy codes:
#
opt zmatrix=z result=z_mndo theory=mopac
#
opt zmatrix=z result=z_b3lyp theory=gamess : { hamiltonian=b3lyp basis=dzp }
Implementation Details
It is valuable to be able to develop general purpose computational
chemistry routines without direct reference to the methods of
computing the energy and gradient that will be used. This is achieved
in ChemShell by a general purpose interface between the
``driver'' codes and the energy and gradient codes they invoke.
Central to this interface is a naming convention for the Tcl
procedures that do the work. A root name is defined for each type of
computation and the specific routines are generated by adding
suffixes, for example the group of routines used to implement the
Hartree-Fock SCF energy and gradient (via the GAMESS-UK code) all have
the root name gamess to which the suffixes (see the Table
below) are added. The routine to compute the energy is thus called
gamess.energy. Usually, the argument theory= is used
to specify the root name of the computational procedure required. For
example, the optimisation opt, if passed the
theory=gamess argument, will then invoke routines
gamess.energy and gamess.gradient as required during the
optimisation.
The following table lists the suffixes used to generate the name
of the specific routines, and the arguments that will generally be
passed. Further arguments, specific to a given routine, may be passed
to any of these functions.
It should be stressed that at the moment this interface is not
fully defined, and that there are some subtle differences in the way
the codes operate, for example whether control information passed to
the .init function is provided again for the
.energy function. This will be defined more precisely in a
future release.
| Routine suffix |
Arguments |
Function |
| .init |
|
Set up procedure |
| .energy |
|
Compute energy |
| .gradient |
|
Compute gradient, on the assumption
that a previous call has evaluated the energy |
| .eandg |
|
Compute both energy and gradient together |
| .kill |
|
Kill off any processes, free memory etc. |
| .update |
|
Pairlist update, null routine for QM codes etc. |
|
