Example: Geometry Optimization: H2O¶
Summary:
- geometry optimization in delocalized coordinates
- geometry optimization in internal coordinates
- start-up Hessian defined in the input file
- geometry optimization in Cartesian coordinates
Geometry optimization of the water molecule, using the (default) local density functional approximation (LDA)
Fair quality basis set: triple zeta with polarization. Four equivalent computations are carried out. The first optimization is done in delocalized coordinates, which requires that atomic coordinates in the input are Cartesian. In the three other optimizations the atomic coordinates are input in Z-matrix format. The optimization is carried out by optimization of the internal coordinates in the second and third calculations, and by optimizing the Cartesian coordinates in the fourth one. In calculation #3 the start-up Hessian is defined in the input file; in #1,2, and 4 the default start-up Hessian (from a force-field approximation) is applied.
As expected all final results are the same, within the range that might be expected from the convergence thresholds (here: the default values).
The ‘-n’ flag, with value one (1) in the commands $ADFBIN/adf is used to control parallelization. ‘adf’ and other program names that you may find in $ADFBIN are not the executables themselves but (UNIX) scripts to control running the corresponding programs. If a parallel version has been installed and the machine configuration is right, you can carry calculations out in parallel by supplying a suitable value to the -n flag. Omitting the -n flag invokes the default value, which is given by the environment variable $NSCM. Finally, depending on the type of parallel platform, a file $ADFBIN/nodeinfo may define an upper bound on the parallel execution. See the Installation manual for details on the parallel installation.
In all subsequent examples, the set-shell and remove-file commands will be omitted, as well as any -n flags. Also any inputs for create runs will not be shown in other examples except when a special feature is involved or when it may help to clarify the example at hand.
Optimization in delocalized coordinates
$ADFBIN/adf <<eor
Title WATER Geometry Optimization with Delocalized Coordinates
Atoms
O 0.000000 0.000000 0.000000
H 0.000000 -0.689440 -0.578509
H 0.000000 0.689440 -0.578509
End
Basis
Type TZP
Core Small
End
Geometry
Optim Deloc
End
End Input
eor
A title is supplied. This title is printed in the output header. It is also written to any result files from the calculation and will be printed out when such a file is attached to another calculation, for instance as a fragment file. In addition, adf constructs a ‘jobidentification’ string that contains the adf release number and the date and time. The jobidentification is also printed in the output header and dumped on any result files.
The atomic positions are given with the key atoms. The Cartesian atomic coordinates are in Angstrom. The structure used here does not necessary imply that the two HO bonds must remain equal in the optimization. The symmetry will keep them equal.
The key geometry must be supplied to let the program do an optimization: otherwise a single point calculation would be carried out. The geometry data block is empty here, meaning that no default values are reset for the options that are controlled with this key.
No symmetry is specified by a Schönfliess type symbol (key symmetry). The program will use the true symmetry of the nuclear frame (accounting for any fields, if present). In this case that is C(2v). If such symmetry would not be acceptable for adf (not all point groups are supported!) or when you want to run in a lower symmetry, the symmetry to be used must be specified.
The fragment files are defined implicitly with the Basis keyword. In this case (as well as in most other samples) the fragment files reside in the local directory since they were created there in the same job. If they would have been located elsewhere you could specify a full path for each of the files, or alternatively (if all fragmentfiles are in one single directory) write the directory after the keyword fragments (on the same line).
The precision of numerical integration, to evaluate Hamiltonian matrix elements etc., is not specified and attains therefore the default value (4.0 in an optimization run).
Z-matrix Optimization
$ADFBIN/adf <<eor
Title WATER Geometry Optimization with Internal Coordinates
Atoms Z-Matrix
1. O 0 0 0
2. H 1 0 0 rOH
3. H 1 2 0 rOH theta
End
Basis
Type TZP
Core Small
End
GeoVar
rOH=0.9
theta=100
End
Geometry
End
End Input
eor
The atomic positions are given with the key atoms. Bond lengths are in Angstrom and angles in degrees. The key geometry assigns numerical starting values to the two variables. We could also have written numerical values directly in the atoms block. The structure used here implies that the two HO bonds are equal and must remain equal: they are associated with the same variable; this constraint would not have applied if numerical data had been put in the atoms section, although the symmetry would have kept them equal anyway.
Definition of (diagonal) start-up Hessian
$ADFBIN/adf <<eor
Title WATER optimization with (partial) specification of Hessian
Atoms Z-Matrix
1. O 0 0 0
2. H 1 0 0 rOH
3. H 1 2 0 rOH theta
End
GeoVar
rOH=0.9
theta=100
End
HessDiag rad=1.0 ang=0.1
Fragments
H t21.H
O t21.O
End
Geometry
End
End Input
eor
All input is identical to the previous case, except for the key HessDiag. This defines here the start-up Hessian to be diagonal with values 1.0 and 0.1 for the entries related to bondlengths and angles respectively.
Optimization in Cartesian coordinates
$ADFBIN/adf <<eor
Title WATER Geometry Optimization in Cartesians
Geometry
Optim Cartesian
End
Define
rOH=0.9
theta=100
End
Atoms Z-Matrix
1. O 0 0 0
2. H 1 0 0 rOH
3. H 1 2 0 rOH theta
End
Fragments
H t21.H
O t21.O
End
End Input
eor
In the last calculation the atomic coordinates are input in the same way as before, but the geometry block now specifies, with the subkey optim, that the cartesian coordinates are to be varied and monitored for convergence.
If different coordinates are specified in the optim instruction than were used for the input in the atoms block, no constraints can be used. The variable ‘rOH’ cannot be placed in the geovar block therefore, since that would imply a constraint: keep the two OH distances equal.
The placement of rOH (and theta) in the define block has a completely different meaning. define merely associates a numerical value with an identifier. Wherever the identifier occurs in input (not only in the gatoms block) it will be replaced by the numerical value. This means that there are now nine (9) variables: the x,y,z coordinates of the three atoms.
Pure translations and rotations will be filtered out by the program and the symmetry (explicitly specified or internally computed), C(2v) here, will be enforced on all developments so that the situation is equivalent to the previous calculation as regards the degrees of freedom of the system.
Remark: the define block must occur in input before the variables defined in it are used. This is one of the few cases where the relative position of keys in the input stream is relevant. The same does not hold for the geovar key used in the earlier example: geovar may be placed anywhere in the input, irrespective of the locations of atoms.