# Special Features¶

## Initial Hessian¶

In a Geometry Optimization (or Transition State search) the Hessian matrix - second derivatives of the energy with respect to changes in coordinates - is updated while the program steps around in an attempt to find the (local) energy minimum. The quality of the initial Hessian may have a considerable impact on the required number of steps to reach geometric convergence.

By default the initial Hessian is read from a restart file (see the key RESTART) if a restart file is present. Otherwise it is constructed from a force field [11] that is implemented in the program. When using the new branch, the initial Hessian is calculated by the same method as in QUILD [225]. In case of the old branch of optimization one can modify this with the key HESSDIAG. With the new branch of optimization it is possible to read an Hessian from an input file, see subkey INITHESS of the key GEOMETRY.

## Constrained optimizations, LT (new branch)¶

The key CONSTRAINTS can only be used in case of the New branch for optimization of coordinates. The input for this key is very similar to that of the RESTRAINT keyword. The key CONSTRAINTS can, however, also be used to constrain Cartesian coordinates. Note that the key RESTRAINT and freezing of coordinates with the GEOVAR key can also be used in the New branch for optimization of coordinates. Currently, the New branch for optimization can only be used in geometry optimizations and transition state searches.

The CONSTRAINTS keyword allows geometry optimizations with constraints for the distance between two atoms, an angle defined by three atoms, a dihedral angle defined by four atoms, or to freeze a block of atoms:

```
CONSTRAINTS
ATOM Ia1 {Xa1 Ya1 Za1}
COORD Ia1 Icoord {valcoord}
DIST Ia1 Ia2 Ra
ANGLE Ib1 Ib2 Ib3 Rb
DIHED Ic1 Ic2 Ic3 Ic4 Rc
BLOCK bname
end
```

The ATOM, COORD, DIST, ANGLE, and DIHED constraints do not have to be satisfied at the start of the geometry optimization. The ATOM and COORD constraints can only be used in Cartesian optimizations while all other constraints may only be used with delocalized coordinates.

**Important note about constraints and symmetry**: if the system has some symmetry, which is going to be maintained, that is if a non-NOSYM symmetry is specified on input or if the initial geometry has non-NOSYM symmetry and “Symmetry NOSYM” is not specified, then the constraints specified here must also be symmetric. This means that if, for example, two distances are equivalent due to symmetry then and are going to be constrained then both must be specified in the CONSTRAINTS input block. It is incorrect to specify only one of them and hope that ADF will take care of the other automatically.

`ATOM`

- When
*ATOM*is specified, the Cartesian coordinates of atom Ia1 are constrained to: Xa1 Ya1 Za1. The atom number should be given in*Input order*; the value for the coordinates in Angstrom. Optionally one can give the three Cartesian coordinates a value. This key can only be used in Cartesian optimizations. `COORD`

- When
*COORD*is specified, the Icoord Cartesian coordinate of atom Ia1 is constrained to: valcoord The atom number should be given in*Input order*; the value for the coordinate in Angstrom. Icoord is 1 means the x-coordinate. Icoord is 2 means the y-coordinate. Icoord is 3 means the z-coordinate. Optionally one can give the Cartesian coordinate a value. This key can only be used in Cartesian optimizations. `DIST`

- When
*DIST*is specified, the distance between atoms Ia1 and Ia2 is constrained to the value Ra in Angstrom. `ANGLE`

- When
*ANGLE*is specified, the angle between atoms Ib1, Ib2 and Ib3 (Ib1-Ib2-Ib3) is constrained to the value Rb in degrees. `DIHED`

- When
*DIHED*is specified, the dihedral angle between atoms Ic1, Ic2, Ic3 and Ic4 (Ic1-Ic2-Ic3-Ic4) is restrained to the value Rc in degrees. The dihedral angle Ic1-Ic2-Ic3-Ic4 is defined in the same way as for the Z-matrix in ADF. The dihedral angle is projected onto the [0,2:math:pi] interval, so there should be no difference between specifying -30° or 330°. `BLOCK`

Block constraints allow the internal degrees of freedom of a block of atoms to be frozen, so that the block moves as a whole. To apply block constraints, you add block labels to atoms in the Atoms block, and then add the block constraint in the Constraints input block:

ATOMS 1.C -0.004115 -0.000021 0.000023 b=b1 2.C 1.535711 0.000022 0.000008 b=b2 3.H -0.399693 1.027812 -0.000082 b=b1 4.H -0.399745 -0.513934 0.890139 b=b1 5.H -0.399612 -0.513952 -0.890156 b=b1 6.H 1.931188 0.514066 0.890140 b=b2 7.H 1.931432 0.513819 -0.890121 b=b2 8.H 1.931281 -1.027824 0.000244 b=b2 END CONSTRAINTS BLOCK b1 BLOCK b2 END

**Note**: The following restrictions apply to optimization with block constraints:- block constraints may only be used with delocalized coordinates;
- there should be no other constrained coordinates used together with block constraints although this may work in many situation;
- the user should absolutely avoid specifying other constraints that include atoms of a frozen block.

## Constrained optimizations, IRC, NEB, LT (old branch)¶

**GEOVAR**

The block key GeoVar is used

- In case of the old branch of optimizations
- To put restrictions on the number of coordinates that are varied and
- To define Linear Transit or NEB parameters and assign them initial and final (and in case of NEB - also intermediate) values.

geovar can also be used to assign (initial) values to coordinates without other implications, but this feature is accidental.

In the input section of atomic coordinates (key ATOMS) identifiers (names) may be used rather than numerical values wherever coordinate values are expected: x, y, z in case of Cartesian coordinate input; r, q, f in case of internal coordinates. All such identifiers must then be specified under geovar and assigned a value.

```
GEOVAR
Name Data
...
end
```

`Name`

- An identifier that can be used in place of a numerical value for one or more of the atomic coordinate values under atoms.
`Data`

Either of the following three formats:

- A single value simply assigns the value to the corresponding atomic coordinate(s).
- Two or more values (separated by a delimiter) imply that the corresponding atomic coordinate is a Linear Transit or a Nudged Elastic Band parameter. For Linear Transit, only two values are allowed in which case they specify initial and final values of the LT path, respectively. In case of a NEB calculation one can provide more than just initial and final values to get a better initial approximation of the reaction path. It is generally recommended (and in some cases necessary) to use more values. Intermediate images will be obtained by polynomial interpolation of degree N-1, where N is the number of values.
- A single value followed by a letter F assigns the value to the corresponding atomic coordinates
*and*specifies that these coordinates are frozen: they will not be optimized.

As regards the optimization of coordinates other than the frozen ones and the LT or NEB parameters, the meaning and effect of the input under geovar depends on the subkey *optim* in the geometry block:

If selected has been set, optimizations are carried out only for the coordinates that are referred to under geovar (and that are not Linear Transit parameters or Frozen). All coordinates that were input as simple numerical data under atoms are kept frozen then.

Alternatively, if selected has *not* been set (: all, the default) all atomic coordinates are optimized (except the Linear Transit parameters and the explicitly frozen coordinates). In that case, each assignments under geovar other than to freeze the coordinate or to define it as a Linear Transit parameter simply assigns an initial value to the pertaining coordinates. In this respect it is not different from typing the numerical value directly in the atoms block, except for the next aspect. Please note that whereas during a linear transit run the LT parameters are *never* optimized, the NEB parameters specified in the *geovar* section are always optimized.

The same identifier may be used for two or more coordinates in atoms. If they are varied (i.e. if they are not frozen) they will forcibly be kept equal throughout the optimization so that they constitute only one degree of freedom. Don’t use the same geovar variable for coordinates that belong to atoms of different chemical types or to different *types* of coordinates (an angle and a bond length for instance). It is not sensible to do so and it will very probably lead to an error abort or to stupid results.

It is allowed to put as atomic coordinate under atoms *minus* a geovar variable name, i.e. the name preceded directly by a minus sign (without a blank in between!). The coordinate will then be kept equal, but with opposite sign, to coordinates that are defined by the same variable without the minus sign. The initial (and final, in case of a LT or NEB run) value for that coordinate is the negative of the geovar value.

**Coordinate types**

Restricted optimizations are performed by freezing certain coordinates, by explicitly referring to one and the same geovar identifier for different coordinates, or by using the selected option. In addition, they are implicit in each Linear Transit or IRC run. All restricted optimizations demand that the *type* of optimization variables (Cartesian or Z-matrix) equal the type of coordinates used in atoms. zcart input under atoms is considered to be *Cartesian* in this respect.

If this is violated in a Linear Transit calculation the program will abort. If you apply the Frozen option under geovar, while not using the same coordinate type for atoms as for optimization, an error will occur. If you refer to the same geovar identifier for distinct coordinates while the atoms and the optimization types of variables do not match, the program will continue and assume that you only have assigned the same *starting* values to the pertaining coordinates. No equality constraints will be in effect then during the optimization.

**Linear combinations of constraint**

It is often desirable to carry out a geometry optimization in internal coordinates where two or more of the coordinates are required to maintain constant values relative to each other. The most simple case, where two internal coordinates a kept equal can be achieved by referencing both coordinates to a single variable in the GEOVAR block. Ensuring a different relationship, such as forcing one bond length in a molecule to be 0.5 Angstrom longer than another is more difficult to achieve. These kind of constraints can often be be managed through the creative use of dummy atoms but this is generally laborious and not always possible at all.

This key can not be used in case of optimization in delocalized coordinates.

The LINEARCONSTRAINTS keyword allows geometry optimizations with constraints defined by arbitrary linear combinations of internal coordinates to be performed quite straightforwardly. The keyword allows the linear combination to be constrained or used as part of a linear transit calculation with the constrained value being stepped as would a variable from the GEOVAR block.

```
LINEARCONSTRAINTS
Name1 Data1
VAR11 Coef11
VAR12 Coef12
...
SUBEND
Name2 Data2
VAR21 Coef21
VAR22 Coef22
...
SUBEND
end
```

`Namex`

- Identifier of the xth linear constraint.
`Datax`

Either of two formats

- A single number, giving the value of the xth constraint
- Two numbers, the first as in 1) and the second the final value in a linear transit calculation. The LINEARTRANSIT keyword must be present in the GEOMETRY block.

`Varxy`

- Name of the yth variable in that is part of the xth constraint. Varxy must be defined in the GEOVAR block.
`Coeffxy`

- Coefficient of Varxy in the linear combination defining the constraint. Thus: Coeff11*Var11 + Coeff12*Var12 ...= Data1 The summation must be consistent with the initial values of the Varxy.

This procedure is only possible when the geometry is defined in terms of internal coordinates. Although the program will not complain, it makes no sense to have linear combinations containing both bonds and angles of course.

The number of linear constraints must be less than or equal to the number of entries in the GEOVAR block. Only internal coordinates involving QM atoms can be included at this stage.

As a geometry optimization is run, the force acting on the linear constraints will be printed immediately after the forces on the internal coordinates. The constraint forces may be useful in the search for a transition state for instance.

**Z-matrix and symmetry**

If the structure of the Z-matrix does not reflect the symmetry of the molecule *and* constraints are applied the program may encounter algorithmic problems to match all demands. As a result some of the *frozen* coordinates may be found to change. Usually these changes are very small. To cure this: build the Z-matrix in a symmetric way.

**Summary of geovar, optim, and atoms**

For *unconstrained* optimization: don’t use geovar, apply *optim* if *Cartesian* optimization is required while the data in the atoms block was in z-matrix format or when *z**-matrix* optimization is required while the atoms input was in zcart format. Provide the atomic coordinates (atoms) directly as numerical data.

For optimizations where only very few coordinates are frozen: use geovar to set a few coordinates to frozen and/or to enforce equality of optimization coordinates whose values should remain equal. Don’t use *optim*: the type of optimization coordinates - Cartesian or internal - must be identical to what is used in the atoms input part because you’re using constraints now. In the atoms section, use identifiers for the frozen coordinates and for those that should satisfy equality conditions; use numerical input for all other (optimization) coordinates.

For very limited optimization: turn on the selected option with *optim* and assign with geovar initial values to the coordinates that you want to optimize. In the atoms input use identifiers for these coordinates. The numerical input coordinates are kept frozen automatically now.

**Initial Hessian**

By default the initial Hessian is read from a restart file - see the key RESTART - or constructed from a force field [11] that is implemented in the program. In the latter case the user can modify the so-generated initial Hessian in four ways:

- By setting all diagonal elements to some constant.
- By defining
*three*constants, one for distances (or Cartesian displacements, as the case may be), one for bond angles, and one for dihedral angles. All diagonal elements of the Hessian are adapted accordingly. - By supplying a list of diagonal values.
- By giving diagonal-Hessian values for one or more specific coordinates.

For each element *i* for which a diagonal Hessian value Hii is supplied the off-diagonal elements Hij, (all j i \(\neq\) j) are set to zero.

A combination of the above options is possible. The rules of how combinations are interpreted by the program are:

- The program first initializes the Hessian using the force field (or restart data).
- If a single constant (
*1*) or three constants (*2*) are supplied, all diagonal elements are adjusted (and all off diagonal elements are set to zero). - If a list of diagonal values is supplied (
*3*), this overrides the first so many values of the diagonal. Such a list is not required to cover*all*diagonal elements. If the list is shorter than the dimension of the Hessian, i.e. the number of atomic coordinates, only the first so many elements will be adjusted. - If any individual elements are supplied specifically (
*4*), their values are replaced in the diagonal defined thus far.

All input values of the Hessian are in units of Hartree/bohr2 for Cartesian coordinates and bond lengths. Hartree/radian2 for bond angles and dihedral angles.

The first 3 options are controlled by the key HESSDIAG:

```
HESSDIAG {General}
{ List
end }
```

`HESSDIAG`

- A
*general*key: it has either an argument (General), or a data block (List). It is also possible to supply the argument*and*the data block, but this requires that the continuation symbol (&) is given after the argument, separated from the argument by at least one blank. `General`

Must be either a single numerical value, or one or more named specifications of options, in the format optionname=value.

If a single numerical value is given, this value is assigned to all the options that are available. If the named-option format is applied, any named options that are not found get the value 1.0. The options are: rad=radvalue to assign a value to all Hessian diagonal elements that refer to distance coordinates (bond length in case of z-matrix coordinates, Cartesian coordinates otherwise),

ang=angvalue to assign a value to all elements that refer to bond angles, and finally dih=dihvalue for dihedral angles. ang and dih are not significant in Cartesian optimizations.

`List`

- A list of numerical values, which may expand over any number of lines. If
*n*numbers are supplied, they are assigned to the first*n*diagonal elements of the Hessian. The remaining diagonal elements, if any, are not effected. The maximum number of Hessian diagonal elements equals the number of atomic coordinates.

The force field derived initial Hessian can be printed for inspection. Type in input:

```
HESSTEST
```

**Hessian values for selected coordinates**

ADF will construct and print the initial Hessian and then abort.

The diagonal elements for selected free coordinates can be given if these free variables are named in the geovar block.

```
GEOVAR
Varname Data H=HessValue
end
```

`Varname, Data`

- The name of the variable and any data as discussed in the sections above: assignment of initial value, final value (in case of a Linear Transit run), or a Frozen specification.
`HessValue`

- The value for the diagonal element of the Hessian associated with that variable. All atomic coordinates that are defined by this variable will get the HessValue as diagonal element in the initial force field. Specification of a HessValue for a frozen coordinate or a Linear Transit parameter is meaningless.

## Restrained optimizations¶

With the old branch of optimizations, the only way to constrain distances, angles or dihedral angles within a geometry optimization is by using a Z-matrix, and freezing that particular coordinate. With the key RESTRAINT it is possible to select **any** coordinate (distance, angle, dihedral), irrespective of the coordinates used, and restrain this coordinate.

Note the difference between *constrained* and *restrained* coordinates. At every step in the geometry optimization, the value of a *constrained* coordinate should match exactly a predefined fixed value. On the other hand, with *restraints*, a potential is added to the potential energy in order to satisfy the *restraint*, which means that the *restraint* does not have to be satisfied exactly. For example, one can start with a geometry in a geometry optimization run in which the restraint is not satisfied.

The RESTRAINT keyword allows geometry optimizations with restraints for the distance between two atoms, an angle defined by three atoms, a dihedral angle defined by four atoms, and (or) a distance difference defined by four atoms:

```
RESTRAINT
DIST Ia1 Ia2 Ra {[Aa] [Ba]}
ANGLE Ib1 Ib2 Ib3 Rb {[Ab] [Bb]}
DIHED Ic1 Ic2 Ic3 Ic4 Rc {[Ac] [Bc]}
DD Id1 Id2 Id3 Id4 R0 [{Ad} {Bd}]
end
```

`DIST`

- When
*DIST*is specified, the distance between atoms Ia1 and Ia2 is restrained to the value Ra. The atom numbers should be given in*Input order*; the value for the distance in Angstrom. The Aa and Ba values are mere technical values, that don’t have to be specified (in fact, recommended not to change these values); the default values of 2.0 resp. 0.1 have been chosen on sensible grounds. `ANGLE`

- When
*ANGLE*is specified, the angle between atoms Ib1, Ib2 and Ib3 (Ib1-Ib2-Ib3) is restrained to the value Rb. The atom numbers should be given in*Input order*; the value for the angle in degrees. The Aa and Ba values are mere technical values, that don’t have to be specified (in fact, recommended not to change these values); the default values of 1.0 resp. 0.1 have been chosen on sensible grounds. `DIHED`

- When
*DIHED*is specified, the dihedral angle between atoms Ic1, Ic2, Ic3 and Ic4 (Ic1-Ic2-Ic3-Ic4) is restrained to the value Rc. The atom numbers should be given in*Input order*; the value for the angle in degrees. The Aa and Ba values are mere technical values, that don’t have to be specified (in fact, recommended not to change these values); the default values of 0.5 resp. 0.1 have been chosen on sensible grounds. The dihedral angle Ic1-Ic2-Ic3-Ic4 is defined in the same way as for the Z-matrix in ADF. The dihedral angle is projected onto the [0,2:math:pi] interval, so there should be no difference between specifying -30° or 330°. `DD`

- When
*DD*is specified, it is possible to restrain a difference between two distances: R0 = (r1 - r2) - (r3 - r4), where r1..r4 are positions of four atoms Id1..Id4 and R0 is the final restrained property. The functional form and meaning of Ad and Bd is the same as with plain distance restraints. Atoms Id1..Id4 need not all to be different.

## Symmetry versus constraints¶

The symmetry of the atomic system defined by the input Schönfliess symbol is preserved during optimization. If the input information (which coordinates are kept frozen and which are optimized) conflicts with the symmetry, the result is unpredictable. For example, if two distances are equivalent due to symmetry then and are going to be constrained then both must be specified in the CONSTRAINTS input block. It is incorrect to specify only one of them and hope that ADF will take care of the other automatically.

Input specifications that are in conflict with the point group symmetry may lead to an error or a non-converging optimization.