comp-chem/NWChem
1
0
Fork 0
mirror of https://github.com/nwchemgit/nwchem.git synced 2026-07-27 13:45:27 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions 1
NWChem/web/doc/user.4.6/node12.html
Edoardo Apra 13bcf92830 added 4.6 user manual for reference
2006-01-12 21:22:32 +00:00

1870 lines
63 KiB
HTML
Raw Permalink Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<!--Converted with jLaTeX2HTML 2002 (1.62) JA patch-1.4
patched version by: Kenshi Muto, Debian Project.
LaTeX2HTML 2002 (1.62),
original version by: Nikos Drakos, CBLU, University of Leeds
* revised and updated by: Marcus Hennecke, Ross Moore, Herb Swan
* with significant contributions from:
Jens Lippmann, Marek Rouchal, Martin Wilck and others -->
<HTML>
<HEAD>
<TITLE>10. Hartree-Fock or Self-consistent Field</TITLE>
<META NAME="description" CONTENT="10. Hartree-Fock or Self-consistent Field">
<META NAME="keywords" CONTENT="user">
<META NAME="resource-type" CONTENT="document">
<META NAME="distribution" CONTENT="global">
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="jLaTeX2HTML v2002 JA patch-1.4">
<META HTTP-EQUIV="Content-Style-Type" CONTENT="text/css">
<LINK REL="STYLESHEET" HREF="user.css">
<LINK REL="next" HREF="node13.html">
<LINK REL="previous" HREF="node11.html">
<LINK REL="up" HREF="user.html">
<LINK REL="next" HREF="node13.html">
</HEAD>
<BODY BGCOLOR="#FFFFFF">
<!--Navigation Panel-->
<A NAME="tex2html1150"
HREF="node13.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html1146"
HREF="user.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html1140"
HREF="node11.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html1148"
HREF="node2.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html1151"
HREF="node13.html">11. DFT for Molecules</A>
<B> Up:</B> <A NAME="tex2html1147"
HREF="user.html">user</A>
<B> Previous:</B> <A NAME="tex2html1141"
HREF="node11.html">9. Relativistic All-electron Approximations</A>
&nbsp <B> <A NAME="tex2html1149"
HREF="node2.html">Contents</A></B>
<BR>
<BR>
<!--End of Navigation Panel-->
<!--Table of Child-Links-->
<A NAME="CHILD_LINKS"><STRONG>Subsections</STRONG></A>
<UL>
<LI><A NAME="tex2html1152"
HREF="node12.html#SECTION001210000000000000000">10.1 Wavefunction type</A>
<LI><A NAME="tex2html1153"
HREF="node12.html#SECTION001220000000000000000">10.2 <TT>SYM</TT> -- use of symmetry</A>
<LI><A NAME="tex2html1154"
HREF="node12.html#SECTION001230000000000000000">10.3 <TT>ADAPT</TT> - symmetry adaptation of MOs</A>
<LI><A NAME="tex2html1155"
HREF="node12.html#SECTION001240000000000000000">10.4 <TT>TOL2E</TT> -- integral screening threshold</A>
<LI><A NAME="tex2html1156"
HREF="node12.html#SECTION001250000000000000000">10.5 <TT>VECTORS</TT> -- input/output of MO vectors</A>
<UL>
<LI><A NAME="tex2html1157"
HREF="node12.html#SECTION001251000000000000000">10.5.1 Superposition of fragment molecular orbitals</A>
<LI><A NAME="tex2html1158"
HREF="node12.html#SECTION001252000000000000000">10.5.2 Atomic guess orbitals with charged atoms</A>
</UL>
<BR>
<LI><A NAME="tex2html1159"
HREF="node12.html#SECTION001260000000000000000">10.6 Accuracy of initial guess</A>
<LI><A NAME="tex2html1160"
HREF="node12.html#SECTION001270000000000000000">10.7 <TT>THRESH</TT> -- convergence threshold</A>
<LI><A NAME="tex2html1161"
HREF="node12.html#SECTION001280000000000000000">10.8 <TT>MAXITER</TT> -- iteration limit</A>
<LI><A NAME="tex2html1162"
HREF="node12.html#SECTION001290000000000000000">10.9 <TT>PROFILE</TT> -- performance profile</A>
<LI><A NAME="tex2html1163"
HREF="node12.html#SECTION0012100000000000000000">10.10 <TT>DIIS</TT> -- DIIS convergence</A>
<LI><A NAME="tex2html1164"
HREF="node12.html#SECTION0012110000000000000000">10.11 <TT>DIRECT</TT> and <TT>SEMIDIRECT</TT> -- recomputation of integrals</A>
<UL>
<LI><A NAME="tex2html1165"
HREF="node12.html#SECTION0012111000000000000000">10.11.1 Integral File Size and Format for the SCF Module</A>
</UL>
<BR>
<LI><A NAME="tex2html1166"
HREF="node12.html#SECTION0012120000000000000000">10.12 SCF Convergence Control Options</A>
<LI><A NAME="tex2html1167"
HREF="node12.html#SECTION0012130000000000000000">10.13 <TT>NR</TT> -- controlling the Newton-Raphson</A>
<LI><A NAME="tex2html1168"
HREF="node12.html#SECTION0012140000000000000000">10.14 <TT>LEVEL</TT> -- level-shifting the orbital Hessian</A>
<LI><A NAME="tex2html1169"
HREF="node12.html#SECTION0012150000000000000000">10.15 Orbital Localization</A>
<LI><A NAME="tex2html1170"
HREF="node12.html#SECTION0012160000000000000000">10.16 Printing Information from the SCF Module</A>
<LI><A NAME="tex2html1171"
HREF="node12.html#SECTION0012170000000000000000">10.17 Hartree-Fock or SCF, MCSCF and MP2 Gradients</A>
</UL>
<!--End of Table of Child-Links-->
<HR>
<H1><A NAME="SECTION001200000000000000000"></A>
<A NAME="sec:scf"></A>
<BR>
10. Hartree-Fock or Self-consistent Field
</H1>
<P>
The NWChem self-consistent field (SCF) module computes closed-shell
restricted Hartree-Fock (RHF) wavefunctions, restricted high-spin
open-shell Hartree-Fock (ROHF) wavefunctions, and spin-unrestricted
Hartree-Fock (UHF) wavefunctions.
<P>
The <code>SCF</code> directive provides input to the SCF module and is a
compound directive that encloses additional directives specific to the
SCF module:
<PRE>
SCF
...
END
</PRE>
<P>
<H1><A NAME="SECTION001210000000000000000">
10.1 Wavefunction type</A>
</H1>
<P>
A spin-restricted, closed shell RHF calculation is performed by
default. An error results if the number of electrons is inconsistent
with this assumption. The number of electrons is inferred from the
total charge on the system and the sum of the effective nuclear
charges of all centers (atoms and dummy atoms, Section
<A HREF="node8.html#sec:geom">6</A>). The total charge on the system is zero by default,
unless specified at some value by input on the <code>CHARGE</code> directive
(Section <A HREF="node7.html#sec:toplevel">5</A>).
<P>
The options available to define the SCF wavefunction and multiplicity
are as follows:
<P>
<PRE>
SINGLET
DOUBLET
TRIPLET
QUARTET
QUINTET
SEXTET
SEPTET
OCTET
NOPEN &lt;integer nopen default 0&gt;
RHF
ROHF
UHF
</PRE>
<P>
The optional keywords <code>SINGLET</code>, <code>DOUBLET</code>, ...,
<code>OCTET</code> and <code>NOPEN</code> allow the user to specify the number of
singly occupied orbitals for a particular calculation. <code>SINGLET</code>
is the default, and specifies a closed shell; <code>DOUBLET</code> specifies
one singly occupied orbital; <code>TRIPLET</code> specifies two singly
occupied orbitals; and so forth. If there are more than seven singly
occupied orbitals, the keyword <code>NOPEN</code> must be used, with the
integer <code>nopen</code> defining the number of singly occupied
orbitals (sometimes referred to as open shells).
<P>
If the multiplicity is any value other than <code>SINGLET</code>, the
default calculation will be a spin-restricted, high-spin, open-shell
SCF calculation (keyword ROHF). The open-shell orbitals must be the
highest occupied orbitals. If necessary, any starting vectors may be
rearranged through the use of the <code>SWAP</code> keyword on the
<code>VECTORS</code> directive (see Section <A HREF="node12.html#sec:vectors">10.5</A>) to accomplish
this.
<P>
A spin-unrestricted solution can also be performed by specifying the
keyword <code>UHF</code>. In UHF calculations, it is assumed that the
number of singly occupied orbitals corresponds to the difference
between the number of alpha-spin and beta-spin orbitals. For example,
a UHF calculation with 2 more alpha-spin orbitals than beta-spin
orbitals can be obtained by specifying
<P>
<PRE>
scf
triplet ; uhf # (Note: two logical lines of input)
...
end
</PRE>
<P>
The user should be aware that, by default, molecular orbitals are
symmetry adapted in NWChem. This may not be desirable for fully
unrestricted wavefunctions. In such cases, the user has the option of
defeating the defaults by specifying the keywords <code>ADAPT OFF</code>
(see Section <A HREF="node12.html#sec:adapt">10.3</A>) and <code>SYM OFF</code> (see Section
<A HREF="node12.html#sec:sym">10.2</A>).
<P>
The keywords <code>RHF</code> and <code>ROHF</code> are provided in the code for
completeness. It may be necessary to specify these in order to modify
the behavior of a previous calculation (see Section <A HREF="node5.html#sec:persist">3.2</A>
for restart behavior).
<P>
<H1><A NAME="SECTION001220000000000000000"></A>
<A NAME="sec:sym"></A>
<BR>
10.2 <TT>SYM</TT> -- use of symmetry
</H1>
<P>
<PRE>
SYM &lt;string (ON||OFF) default ON&gt;
</PRE>
<P>
This directive enables/disables the use of symmetry to speed up Fock matrix
construction (via the petite-list or skeleton algorithm) in the SCF, if
symmetry was used in the specification of the geometry. Symmetry
adaptation of the molecular orbitals is not affected by this option.
The default is to use symmetry if it is specified in the geometry
directive (Section <A HREF="node8.html#sec:geom">6</A>).
<P>
For example, to disable use of symmetry in Fock matrix construction:
<PRE>
sym off
</PRE>
<P>
<H1><A NAME="SECTION001230000000000000000"></A>
<A NAME="sec:adapt"></A>
<BR>
10.3 <TT>ADAPT</TT> - symmetry adaptation of MOs
</H1>
<P>
<PRE>
ADAPT &lt;string (ON||OFF) default ON&gt;
</PRE>
<P>
The default in the SCF module calculation is to force symmetry
adaption of the molecular orbitals. This does not affect the speed of
the calculation, but without explicit adaption the resulting orbitals
may be symmetry contaminated for some problems. This is especially
likely if the calculation is started using orbitals from a distorted
geometry.
<P>
The underlying assumption in the use of symmetry in Fock matrix
construction is that the density is totally symmetric. If the orbitals
are symmetry contaminated, this assumption may not be valid -- which
could result in incorrect energies and poor convergence of the
calculation. It is thus advisable when specifying <code>ADAPT OFF</code> to
also specify <code>SYM OFF</code> (Section <A HREF="node12.html#sec:sym">10.2</A>).
<P>
<H1><A NAME="SECTION001240000000000000000"></A>
<A NAME="sec:tol2e"></A>
<BR>
10.4 <TT>TOL2E</TT> -- integral screening threshold
</H1>
<P>
<PRE>
TOL2E &lt;real tol2e default min(10e-7 , 0.01*$thresh$)&gt;
</PRE>
<P>
The variable <code>tol2e</code> is used in determining the integral
screening threshold for the evaluation of the energy and related
Fock-like matrices. The Schwarz inequality is used to screen the
product of integrals and density matrices in a manner that results in
an accuracy in the energy and Fock matrices that approximates the
value specified for <code>tol2e</code>.
<P>
It is generally not necessary to set this parameter directly. Specify
instead the required precision in the wavefunction, using the
<code>THRESH</code> directive (Section <A HREF="node12.html#sec:thresh">10.7</A>). The default
threshold is the minimum of <IMG
WIDTH="37" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img90.gif"
ALT="$10^{-7}$"> and 0.01 times the requested
convergence threshold for the SCF calculation (Section
<A HREF="node12.html#sec:thresh">10.7</A>).
<P>
The input to specify the threshold explicitly within the <code>SCF</code>
directive is, for example:
<P>
<PRE>
tol2e 1e-9
</PRE>
<P>
For very diffuse basis sets, or for high-accuracy calculations it
might be necessary to set this parameter. A value of <IMG
WIDTH="44" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img91.gif"
ALT="$10^{-12}$"> is
sufficient for nearly all such purposes.
<P>
<H1><A NAME="SECTION001250000000000000000"></A>
<A NAME="sec:vectors"></A>
<BR>
10.5 <TT>VECTORS</TT> -- input/output of MO vectors
</H1>
<P>
<PRE>
VECTORS [[input] (&lt;string input_movecs default atomic&gt;) || \
(project &lt;string basisname&gt; &lt;string filename&gt;) || \
(fragment &lt;string file1&gt; [&lt;string file2&gt; ...])] \
[swap [alpha||beta] &lt;integer vec1 vec2&gt; ...] \
[reorder &lt;integer atom1 atom2&gt; ...] \
[output &lt;string output_filename default input_movecs&gt;] \
[lock]
[rotate &lt;string input_geometry&gt; &lt;string input_movecs&gt;]
</PRE>
<P>
The <code>VECTORS</code> directive allows the user to specify the source and
destination of the molecular orbital vectors. In a startup
calculation (see Section <A HREF="node7.html#sec:start">5.1</A>), the default source for
guess vectors is a diagonalized Fock matrix constructed from a
superposition of the atomic density matrices for the particular
problem. This is usually a very good guess. For a restarted
calculation, the default is to use the previous MO vectors.
<P>
The optional keyword <code>INPUT</code> allows the user to specify the
source of the input molecular orbital vectors as any of the following:
<UL>
<LI><code>ATOMIC</code> -- eigenvectors of a Fock-like matrix formed from
a superposition of the atomic densities (the default guess). See
Sections <A HREF="node12.html#sec:atomscf">10.5.2</A> and <A HREF="node12.html#sec:tolguess">10.6</A>.
</LI>
<LI><code>HCORE</code> -- eigenvectors of the bare-nucleus Hamiltonian or
the one-electron Hamiltonian.
</LI>
<LI><code>filename</code> -- the name of a file containing the MO vectors
from a previous calculation. Note that unless the path is fully
qualified, or begins with a dot (``.''), then it is assumed to
reside in the directory for permanent files (see Section
<A HREF="node7.html#sec:dirs">5.2</A>).
</LI>
<LI><code>PROJECT basisname filename</code> -- projects the existing MO
vectors in the file <code>filename</code> from the smaller basis with name
<code>basisname</code> into the current basis. The definition of the
basis <code>basisname</code> must be available in the current database,
and the basis must be smaller than the current basis. In addition,
the geometry used for the previous calculations must have the atoms
in the same order and in the same orientation as the current
geometry.
</LI>
<LI><code>FRAGMENT file1 ...</code> -- assembles starting MO vectors from
previously performed calculations on fragments of the system and is
described in more detail in Section <A HREF="node12.html#sec:fragguess">10.5.1</A>. Even
though there are some significant restrictions in the use of the
initial implementation of this method (see Section
<A HREF="node12.html#sec:fragguess">10.5.1</A>), this is the most powerful initial guess option
within the code. It is particularly indispensable for open shell
metallic systems.
</LI>
<LI><code>ROTATE input_geometry input_movecs</code> -- rotates
MO vectors generated at a previous geometry
to the current active geometry.
</LI>
</UL>
<P>
The molecular orbitals are saved every iteration if more than 600
seconds have elapsed, and also at the end of the calculation. At
completion (converged or not), the SCF module always canonically
transforms the molecular orbitals by <EM>separately</EM> diagonalizing
the closed-closed, open-open, and virtual-virtual blocks of the
Fock matrix.
<P>
The name of the file used to store the MO vectors is determined as
follows:
<UL>
<LI>if the <code>OUTPUT</code> keyword was specified on the <code>VECTORS</code>
directive, then the filename that follows this keyword is used, or
</LI>
<LI>if the input vectors were read from a file, this file is reused
for the output vectors (overwriting the input vectors); else,
</LI>
<LI>a default file name is generated in the directory for permanent
files (Section <A HREF="node7.html#sec:dirs">5.2</A>) by prepending <code>".movecs"</code> with
the file prefix, i.e., <code>"&lt;file_prefix&gt;.movecs"</code>.
</LI>
</UL>
The name of this file is stored in the database so that a subsequent
SCF calculation will automatically restart from these MO vectors.
<P>
Applications of this directive are illustrated in the following
examples.
<P>
Example 1:
<PRE>
vectors output h2o.movecs
</PRE>
Assuming a start-up calculation, this directive will result in use of
the default atomic density guess, and will output the vectors to the
file <code>h2o.movecs</code>.
<P>
Example 2:
<PRE>
vectors input initial.movecs output final.movecs
</PRE>
This directive will result in the initial vectors being read from the
file <code>"initial.movecs"</code>. The results will be written to the file
<code>final.movecs</code>. The contents of <code>"initial.movecs"</code> will not
be changed.
<P>
Example 3:
<PRE>
vectors input project "small basis" small.movecs
</PRE>
This directive will cause the calculation to start from vectors in the
file <code>"small.movecs"</code> which are in a basis named <code>"small basis"</code>.
The output vectors will be written to the default file
<code>"&lt;file_prefix.movecs&gt;"</code>.
<P>
Once starting vectors have been obtained using any of the possible
options, they may be reordered through use of the <code>SWAP</code> keyword.
This optional keyword requires a list of orbital pairs that will be
swapped. For UHF calculations, separate <code>SWAP</code> keywords may be
provided for the alpha and beta orbitals, as necessary.
<P>
An example of use of the <code>SWAP</code> directive:
<PRE>
vectors input try1.movecs swap 173 175 174 176 output try2.movecs
</PRE>
This directive will cause the initial orbitals to be read from the
file <code>"try1.movecs"</code>. The vectors for the orbitals within the
pairs 173-175 will be swapped with those within 174-176, so the
resulting order is 175, 176, 173, 174. The final orbitals obtained in
the calculation will be written to the file <code>"try2.movecs"</code>.
<P>
The swapping of orbitals occurs as a sequential process in the order
(left to right) input by the user. Thus, regarding each pair as an
elementary transposition it is possible to construct arbitrary
permutations of the orbitals. For instance, to apply the permutation
<IMG
WIDTH="48" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
SRC="img92.gif"
ALT="$(6 7 8 9)$"><A NAME="tex2html24"
HREF="footnode.html#foot2584"><SUP>10.1</SUP></A> we note that this
permutation is equal to <!-- MATH
$(6 7)(7 8)(8 9)$
-->
<IMG
WIDTH="89" HEIGHT="31" ALIGN="MIDDLE" BORDER="0"
SRC="img93.gif"
ALT="$(6 7)(7 8)(8 9)$">, and thus may be specified
as
<PRE>
vectors swap 8 9 7 8 6 7
</PRE>
<P>
Another example, now illustrating this feature for a UHF calculation,
is the directive
<PRE>
vectors swap beta 4 5 swap alpha 5 6
</PRE>
This input will result in the swapping of the 5-6 alpha orbital pair
and the 4-5 beta orbital pair. (All other items in the input use the
default values.)
<P>
The <code>LOCK</code> keyword allows the user to specify that the ordering
of orbitals will be locked to that of the initial vectors, insofar as
possible. The default is to order by ascending orbital energies within
each orbital space. One application where locking might be desirable
is a calculation where it is necessary to preserve the ordering of a
previous geometry, despite flipping of the orbital energies. For such
a case, the <code>LOCK</code> directive can be used to prevent the SCF
calculation from changing the ordering, even if the orbital energies
change.
<P>
The mapping of the MO's to the nuclei can be changed using the <code>REORDER</code> keyword.
Once starting vectors have been obtained using any of the possible
options, the <code>REORDER</code> keyword moves the MO coefficients between atoms
listed in the integer list. This keyword is particularly useful for calculating localized
electron and hole states.
<P>
This optional keyword requires a list containing the new atom ordering.
It is not necessary to provide separate lists for alpha and
beta orbitals.
<P>
An example of use of the <code>REORDER</code> keyword:
<PRE>
vectors input try1.movecs reorder 2 1 output try2.movecs
</PRE>
This directive will cause the initial orbitals to be read from the
file <code>"try1.movecs"</code>. The MO coefficients for the basis functions
on atom 2
will be swapped with those on atom 1.
The final orbitals obtained in
the calculation will be written to the file <code>"try2.movecs"</code>.
<P>
The following example shows how the <code>ROTATE</code> keyword can be used to rotate
MO vectors calculated at geometry <code>geom1</code> to geometry <code>geom2</code>, which has a
different rotational orientation:
<P>
<PRE>
set geometry geom1
dft
vectors input atomic output geom1.mo
end
task dft
set geometry geom2
dft
vectors input rotate geom1 geom1.mo output geom2.mo
end
task dft
</PRE>
<H2><A NAME="SECTION001251000000000000000"></A>
<A NAME="sec:fragguess"></A>
<BR>
10.5.1 Superposition of fragment molecular orbitals
</H2>
<P>
The fragment initial guess is particularly useful in the following
instances:
<UL>
<LI>The system naturally decomposes into molecules that can be
treated individually, e.g., a cluster.
</LI>
<LI>One or more fragments are particularly hard to converge and
therefore much time can be saved by converging them independently.
</LI>
<LI>A fragment (e.g., a metal atom) must be prepared with a specific
occupation. This can often be readily accomplished with a
calculation on the fragment using dummy charges to model a ligand
field.
</LI>
<LI>The molecular occupation predicted by the atomic initial guess
is often wrong for systems with heavy metals which may have
partially occupied orbitals with lower energy than some doubly
occupied orbitals. The fragment initial guess avoids this problem.
</LI>
</UL>
<P>
<PRE>
VECTORS [input] fragment &lt;string file1&gt; [&lt;string file2&gt; ...]
</PRE>
The molecular orbitals are formed by superimposing the previously
generated orbitals of fragments of the molecule being studied. These
fragment molecular orbitals must be in the same basis as the current
calculation. The input specifies the files containing the fragment
molecular orbitals. For instance, in a calculation on the water
dimer, one might specify
<PRE>
vectors fragment h2o1.movecs h2o2.movecs
</PRE>
where <code>h2o1.movecs</code> contains the orbitals for the first fragment, and
<code>h2o2.movecs</code> contains the orbitals for the second fragment.
<P>
A complete example of the input for a calculation on the water
dimer using the fragment guess is as follows:
<PRE>
start dimer
title "Water dimer SCF using fragment initial guess"
geometry dimer
O -0.595 1.165 -0.048
H 0.110 1.812 -0.170
H -1.452 1.598 -0.154
O 0.724 -1.284 0.034
H 0.175 -2.013 0.348
H 0.177 -0.480 0.010
end
geometry h2o1
O -0.595 1.165 -0.048
H 0.110 1.812 -0.170
H -1.452 1.598 -0.154
end
geometry h2o2
O 0.724 -1.284 0.034
H 0.175 -2.013 0.348
H 0.177 -0.480 0.010
end
basis
o library 3-21g
h library 3-21g
end
set geometry h2o1
scf; vectors input atomic output h2o1.movecs; end
task scf
set geometry h2o2
scf; vectors input atomic output h2o2.movecs; end
task scf
set geometry dimer
scf
vectors input fragment h2o1.movecs h2o2.movecs \
output dimer.movecs
end
task scf
</PRE>
First, the geometry of the dimer and the two monomers are specified
and given names. Then, after the basis specification, calculations
are performed on the fragments by setting the geometry to the
appropriate fragment (Section <A HREF="node7.html#sec:set">5.7</A>) and redirecting the
output molecular orbitals to an appropriately named file. Note also
that use of the atomic initial guess is forced, since the default
initial guess is to use any existing MOs which would not be
appropriate for the second fragment calculation. Finally, the dimer
calculation is performed by specifying the dimer geometry, indicating
use of the fragment guess, and redirecting the output MOs.
<P>
The following points are important in using the fragment initial guess:
<OL>
<LI>The fragment calculations must be in the same basis set as the
full calculation.
</LI>
<LI>The order of atoms in the fragments and the order in which the
fragment files are specified must be such that when the fragment
basis sets are concatenated all the basis functions are in the same
order as in the full system. This is readily accomplished by first
generating the full geometry with atoms for each fragment
contiguous, splitting this into numbered fragments and specifying
the fragment MO files in the correct order on the <code>VECTORS</code>
directive.
</LI>
<LI>The occupation of orbitals is preserved when they are merged
from the fragments to the full molecule and the resulting occupation
must match the requested occupation for the full molecule. E.g., a
triplet ROHF calculation must be comprised of fragments that have
a total of exactly two open-shell orbitals.
</LI>
<LI>Because of these restrictions, it is not possible to introduce
additional atoms (or basis functions) into fragments for the purpose
of cleanly breaking real bonds. However, it is possible, and highly
recommended, to introduce additional point charges to simulate the
presence of other fragments.
</LI>
<LI>MO vectors of partially occupied or strongly polarized systems
are very sensitive to orientation. While it is possible to specify
the same fragment MO vector file multiple times in the
<code>VECTORS</code> directive, it is usually much better to do a separate
calculation for each fragment.
</LI>
<LI>Linear dependencies which were present in a fragment calculation
may be magnified in the full calculation. When this occurs,
some of the fragment's highest virtual orbitals will not be copied to the
full system, and a warning will be printed.
<P>
</LI>
</OL>
<P>
A more involved example is now presented. We wish to model the sextet
state of Fe(III) complexed with water, imidazole and a heme with a net
unit positive charge. The default atomic guess does not give the
correct <IMG
WIDTH="20" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img94.gif"
ALT="$d^5$"> occupation for the metal and also gives an incorrect
state for the double anion of the heme. The following performs
calculations on all of the fragments. Things to note are:
<OL>
<LI>The use
of a dummy <IMG
WIDTH="24" HEIGHT="28" ALIGN="MIDDLE" BORDER="0"
SRC="img95.gif"
ALT="$+2$"> charge in the initial guess on the heme which in part
simulates the presence of the metal ion, and also automatically forces
an additional two electrons to be added to the system (the default net
charge being zero).
</LI>
<LI>The iron fragment calculation (charge +3, <IMG
WIDTH="20" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img94.gif"
ALT="$d^5$">, sextet) will
yield the correct open-shell occupation for the full system. If,
instead, the <I>d</I>-orbitals were partially occupied (e.g., the doublet
state) it would be useful to introduce dummy charges around the iron
to model the ligand field and thereby lift the degeneracy to obtain
the correct occupation.
</LI>
<LI><IMG
WIDTH="22" HEIGHT="29" ALIGN="MIDDLE" BORDER="0"
SRC="img96.gif"
ALT="$C_s$"> symmetry is used for all of the calculations. It is not
necessary that the same symmetry be used in all of the
calculations, provided that the order and orientation of the atoms
is preserved.
</LI>
<LI>The <code>unset scf:*</code> directive is used immediately before
the calculation on the full system so that the default name for the
output MO vector file can be used, rather than having to specify it
explicitly.
</LI>
</OL>
<PRE>
start heme6a1
title "heme-H2O (6A1) from M.Dupuis"
############################################################
# Define the geometry of the full system and the fragments #
############################################################
geometry full-system
symmetry cs
H 0.438 -0.002 4.549
C 0.443 -0.001 3.457
C 0.451 -1.251 2.828
C 0.452 1.250 2.828
H 0.455 2.652 4.586
H 0.461 -2.649 4.586
N1 0.455 -1.461 1.441
N1 0.458 1.458 1.443
C 0.460 2.530 3.505
C 0.462 -2.530 3.506
C 0.478 2.844 1.249
C 0.478 3.510 2.534
C 0.478 -2.848 1.248
C 0.480 -3.513 2.536
C 0.484 3.480 0.000
C 0.485 -3.484 0.000
H 0.489 4.590 2.664
H 0.496 -4.592 2.669
H 0.498 4.573 0.000
H 0.503 -4.577 0.000
H -4.925 1.235 0.000
H -4.729 -1.338 0.000
C -3.987 0.685 0.000
N -3.930 -0.703 0.000
C -2.678 1.111 0.000
C -2.622 -1.076 0.000
H -2.284 2.126 0.000
H -2.277 -2.108 0.000
N -1.838 0.007 0.000
Fe 0.307 0.000 0.000
O 2.673 -0.009 0.000
H 3.238 -0.804 0.000
H 3.254 0.777 0.000
end
geometry ring-only
symmetry cs
H 0.438 -0.002 4.549
C 0.443 -0.001 3.457
C 0.451 -1.251 2.828
C 0.452 1.250 2.828
H 0.455 2.652 4.586
H 0.461 -2.649 4.586
N1 0.455 -1.461 1.441
N1 0.458 1.458 1.443
C 0.460 2.530 3.505
C 0.462 -2.530 3.506
C 0.478 2.844 1.249
C 0.478 3.510 2.534
C 0.478 -2.848 1.248
C 0.480 -3.513 2.536
C 0.484 3.480 0.000
C 0.485 -3.484 0.000
H 0.489 4.590 2.664
H 0.496 -4.592 2.669
Bq 0.307 0.0 0.0 charge 2 # simulate the iron
end
geometry imid-only
symmetry cs
H 0.498 4.573 0.000
H 0.503 -4.577 0.000
H -4.925 1.235 0.000
H -4.729 -1.338 0.000
C -3.987 0.685 0.000
N -3.930 -0.703 0.000
C -2.678 1.111 0.000
C -2.622 -1.076 0.000
H -2.284 2.126 0.000
H -2.277 -2.108 0.000
N -1.838 0.007 0.000
end
geometry fe-only
symmetry cs
Fe .307 0.000 0.000
end
geometry water-only
symmetry cs
O 2.673 -0.009 0.000
H 3.238 -0.804 0.000
H 3.254 0.777 0.000
end
############################
# Basis set for everything #
############################
basis nosegment
O library 6-31g*
N library 6-31g*
C library 6-31g*
H library 6-31g*
Fe library "Ahlrichs pVDZ"
end
##########################################################
# SCF on the fragments for initial guess for full system #
##########################################################
scf; thresh 1e-2; end
set geometry ring-only
scf; vectors atomic swap 80 81 output ring.mo; end
task scf
set geometry water-only
scf; vectors atomic output water.mo; end
task scf
set geometry imid-only
scf; vectors atomic output imid.mo; end
task scf
charge 3
set geometry fe-only
scf; sextet; vectors atomic output fe.mo; end
task scf
##########################
# SCF on the full system #
##########################
unset scf:* # This restores the defaults
charge 1
set geometry full-system
scf
sextet
vectors fragment ring.mo imid.mo fe.mo water.mo
maxiter 50
end
task scf
</PRE>
<P>
<H2><A NAME="SECTION001252000000000000000"></A>
<A NAME="sec:atomscf"></A>
<BR>
10.5.2 Atomic guess orbitals with charged atoms
</H2>
<P>
As noted above, the default guess vectors are based on superimposing
the density matrices of the neutral atoms. If some atoms are
significantly charged, this default guess may be improved upon by
modifying the atomic densities. This is done by setting parameters
that add fractional charges to the occupation of the valence atomic
orbitals. Since the atomic SCF program does not have its own input
block, the <code>SET</code> directive (Section <A HREF="node7.html#sec:set">5.7</A>) must be used
to set these parameters.
<P>
The input specifies a list of tags (i.e., names of atoms in a
geometry, see Section <A HREF="node8.html#sec:geom">6</A>) and the charges to be added to
those centers. Two parameters must be set as follows:
<PRE>
set atomscf:tags_z &lt;string list_of_tags&gt;
set atomscf:z &lt;real list_of_charges&gt;
</PRE>
<P>
<P>
The array of strings <code>atomscf:tags_z</code> should be set to the list
of tags, and the array <code>atomscf:z</code> should be set to the list of
charges which must be real numbers (not integers). All atoms that
have a tag specified in the list of tags will be assigned the
corresponding charge from the list of charges.
<P>
<P>
For example, the following specifies that all oxygen atoms with tag
<code>O</code> be assigned a charge of <code>-1</code> and all iron atoms with tag
<code>Fe</code> be assigned a charge of <code>+2</code>
<PRE>
set atomscf:z -1 2.0
set atomscf:tags_z O Fe
</PRE>
<P>
There are some limitations to this feature. It is not possible to add
electrons to closed shell atoms, nor is it possible to remove all
electrons from a given atom. Attempts to do so will cause the code to
report an error, and it will not report further errors in the input
for modifying the charge even when they are detected.
<P>
Finally, recall that the database is persistent (Section
<A HREF="node5.html#sec:persist">3.2</A>) and that the modified settings will be used in
subsequent atomic guess calculations unless the data is deleted from
the database with the <code>UNSET</code> directive (Section
<A HREF="node7.html#sec:unset">5.8</A>).
<P>
<H1><A NAME="SECTION001260000000000000000"></A>
<A NAME="sec:tolguess"></A>
<BR>
10.6 Accuracy of initial guess
</H1>
<P>
For SCF, the initial Fock-matrix construction from the atomic guess is
now (staring from version 3.3) performed to a default precision of
1e-7. However, other wavefunctions, notably DFT, use a lower
precision. In charged, or diffuse basis sets, this precision may not
be sufficient and could result in incorrect ordering of the initial
orbitals. The accuracy may be increased with the following directive
which should be inserted in the top-level of input (i.e., outside of
the SCF input block) and before the <TT>TASK</TT> directive.
<PRE>
set tolguess 1e-7
</PRE>
<P>
<H1><A NAME="SECTION001270000000000000000"></A>
<A NAME="sec:thresh"></A>
<BR>
10.7 <TT>THRESH</TT> -- convergence threshold
</H1>
<P>
<PRE>
THRESH &lt;real thresh default 1.0e-4&gt;
</PRE>
<P>
This directive specifies the convergence threshold for the
calculation. The convergence threshold is the norm of the orbital
gradient, and has a default value in the code of <IMG
WIDTH="37" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img97.gif"
ALT="$10^{-4}$">.
<P>
The norm of the orbital gradient corresponds roughly to the precision
available in the wavefunction, and the energy should be converged to
approximately the square of this number. It should be noted, however,
that the precision in the energy will not exceed that of the integral
screening tolerance. This tolerance (Section <A HREF="node12.html#sec:tol2e">10.4</A>) is
automatically set from the convergence threshold, so that sufficient
precision is usually available by default.
<P>
The default convergence threshold suffices for most SCF energy and
geometry optimization calculations, providing about 6-8 decimal
places in the energy, and about four significant figures in the
density and energy derivative with respect to nuclear coordinates.
However, greater precision may be required for calculations involving
weakly interacting systems, floppy molecules, finite-difference of
gradients to compute the Hessian, and for post-Hartree-Fock
calculations. A threshold of <IMG
WIDTH="37" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img98.gif"
ALT="$10^{-6}$"> is adequate for most such
purposes, and a threshold of <IMG
WIDTH="37" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img99.gif"
ALT="$10^{-8}$"> might be necessary for very
high accuracy or very weak interactions. A threshold of <IMG
WIDTH="44" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img100.gif"
ALT="$10^{-10}$">
should be regarded as the best that can be attained in most
circumstances.
<P>
<H1><A NAME="SECTION001280000000000000000"></A>
<A NAME="sec:max"></A>
<BR>
10.8 <TT>MAXITER</TT> -- iteration limit
</H1>
<P>
<PRE>
MAXITER &lt;integer maxiter default 8&gt;
</PRE>
<P>
<P>
The maximum number of iterations for the SCF calculation defaults to
20 for both ROHF/RHF and UHF calculations. For most molecules, this
number of iterations is more than sufficient for the quadratically
convergent SCF algorithm to obtain a solution converged to the default
threshold (see Section <A HREF="node12.html#sec:thresh">10.7</A> above). If the SCF program
detects that the quadratically convergent algorithm is not
efficient, then it will resort to a linearly convergent
algorithm and increase the maximum number of iterations by 10.
<P>
<P>
Convergence may not be reached in the maximum number of iterations for
many reasons, including input error (e.g., an incorrect geometry or a
linearly dependent basis), a very low convergence threshold, a poor
initial guess, or the fact that the system is intrinsically hard to
converge due to the presence of many states with similar energies.
<P>
The following sets the maximum number of SCF iterations to 50:
<PRE>
maxiter 50
</PRE>
<P>
<H1><A NAME="SECTION001290000000000000000">
10.9 <TT>PROFILE</TT> -- performance profile</A>
</H1>
<P>
This directive allows the user to obtain timing and parallel
execution information about the SCF module. It is specified by the
simple keyword
<P>
<PRE>
PROFILE
</PRE>
<P>
This option can be helpful in understanding the computational
performance of an SCF calculation. However,
it can introduce a significant overhead
on machines that have expensive timing routines, such as the SUN.
<P>
<H1><A NAME="SECTION0012100000000000000000">
10.10 <TT>DIIS</TT> -- DIIS convergence</A>
</H1>
<P>
This directive allows the user to specify DIIS convergence rather than
second-order convergence for the SCF calculation. The form of the
directive is as follows:
<P>
<PRE>
DIIS
</PRE>
<P>
The implementation of this option is currently fairly rudimentary. It
does not have level-shifting and damping, and does not support open
shells or UHF. It is provided on an ``as is'' basis, and should be
used with caution.
<P>
When the <code>DIIS</code> directive is specified in the input, the user has
the additional option of specifying the size of the subspace for the
DIIS extrapolation. This is accomplished with the <code>DIISBAS</code>
directive, which is of the form:
<PRE>
DIISBAS &lt;integer diisbas default 5&gt;
</PRE>
The default of 5 should be adequate for most applications, but may be
increased if convergence is poor. On large systems, it may be necessary
to specify a lower value for <code>diisbas</code>, to conserve memory.
<P>
<H1><A NAME="SECTION0012110000000000000000"></A>
<A NAME="sec:semidirect"></A>
<BR>
10.11 <TT>DIRECT</TT> and <TT>SEMIDIRECT</TT> -- recomputation of integrals
</H1>
<P>
In the context of SCF calculations direct means that all integrals are
recomputed as required and none are stored. The other extreme are
disk- or memory-resident (sometimes termed conventional) calculations
in which all integrals are computed once and stored. Semi-direct
calculations are between these two extremes with some integrals being
precomputed and stored, and all other integrals being recomputed as
necessary.
<P>
The default behavior of the SCF module is
<UL>
<LI>If enough memory is available, the integrals are computed once
and are cached in memory.
</LI>
<LI>If there is not enough memory to store all the integrals at
once, then 95% of the available disk space in the scratch directory
(see Section <A HREF="node7.html#sec:dirs">5.2</A>) is assumed to be available for this
purpose, and as many integrals as possible are cached on disk (with
no memory being used for caching). Some attempt is made to store
the most expensive integrals in the cache.
</LI>
<LI>If there is not enough room in memory or on disk for all the
integrals, then the ones that are not cached are recomputed in a
semidirect fashion.
</LI>
</UL>
<P>
The integral file is deleted at the end of a calculation, so it is not
possible to restart a semidirect calculation when the integrals are
cached in memory or on disk. Many computer systems (e.g., the EMSL
IBM SP) clear the fast scratch space at the end of each job, adding a
further complication to the problem of restarting a <EM>parallel</EM>
semidirect calculation.
<P>
On the IBM SP or any other computer with fast disks local to each
processor, semidirect calculation offers the best behavior. It can
result in <EM>quadratic speedup</EM> as more processors are added.
<P>
A fully direct calculation (with recomputation of the integrals at
each iteration) is forced by specifying the directive
<P>
<PRE>
DIRECT
</PRE>
<P>
Alternatively, the <code>SEMIDIRECT</code> directive can be used to control
the default semidirect calculation by defining the amount of disk
space and the cache memory size. The form of this directive is as
follows:
<P>
<PRE>
SEMIDIRECT [filesize &lt;integer filesize default disksize&gt;]
[memsize &lt;integer memsize default available&gt;]
[filename &lt;string filename default $file_prefix.aoints$&gt;]
</PRE>
<P>
The keyword <code>FILESIZE</code> allows the user to specify the amount of
disk space to be used per process for storing the integrals in 64-bit
words. Similarly, the keyword <code>MEMSIZE</code> allows the user to
specify the number of 64-bit words to be used per process for caching
integrals in memory. (Note: If the amount of storage space specified
by the entry for <code>memsize</code> is not available, the code cuts the
value in half and checks again for available space. This process is
repeated until the request is satisfied.)
<P>
By default, the integral files are placed into the scratch directory
(see Section <A HREF="node7.html#sec:dirs">5.2</A>). Specifying the keyword <code>FILENAME</code>
overrides this default. The user-specified name entered in the string
<code>filename</code> has the process number appended to it, so that each
process has a distinct file but with a common base-name and directory.
Therefore, it is not possible to use this keyword to specify different
disks for different processes. The <code>SCRATCH_DIR</code> directive (see
Section <A HREF="node7.html#sec:dirs">5.2</A>) can be used for this purpose.
<P>
For example, to force full recomputation of all integrals:
<PRE>
direct
</PRE>
<P>
Exactly the same result could be obtained by entering the directive:
<PRE>
semidirect filesize 0 memsize 0
</PRE>
<P>
To disable the use of memory for caching integrals and limit disk
usage by each process to 100 megawords (MW):
<PRE>
semidirect memsize 0 filesize 100000000
</PRE>
<P>
The integral records are typically 32769 words long and any non-zero
value for <code>filesize</code> or <code>memsize</code> should be enough to hold
at least one record.
<P>
<H2><A NAME="SECTION0012111000000000000000">
10.11.1 Integral File Size and Format for the SCF Module</A>
</H2>
<P>
The file format is rather complex, since it accommodates a variety of
packing and compression options and the distribution of data. This
section presents some information that may help the user understand
the output, and illustrates how to use the output information to
estimate file sizes.
<P>
If integrals are stored with a threshold of greater than <IMG
WIDTH="44" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img100.gif"
ALT="$10^{-10}$">,
then the integrals are stored in a 32-bit fixed-point format (with
appropriate treatment for large values to retain precision). If
integrals are stored with a threshold less than <IMG
WIDTH="44" HEIGHT="17" ALIGN="BOTTOM" BORDER="0"
SRC="img100.gif"
ALT="$10^{-10}$">, however,
the values are stored in 64-bit floating-point format. If a
replicated-data calculation is being run, then 8 bits are used for
each basis function label, unless there are more than 256 functions,
in which case 16 bits are used. If distributed data is being used,
then the labels are always packed to 8 bits (the distributed blocks
always being less than 256; labels are relative to the start of the
block).
<P>
Thus, the number (<IMG
WIDTH="21" HEIGHT="15" ALIGN="BOTTOM" BORDER="0"
SRC="img101.gif"
ALT="$W$">) of 64-bit words required to store <IMG
WIDTH="19" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
SRC="img102.gif"
ALT="$N$">
integrals, may be computed as
<BR><P></P>
<DIV>
<!-- MATH
\begin{displaymath}
W = \left\{ \\
\begin{array}{c}
N \mbox{ , 8-bit labels and 32-bit values} \\
\frac{3}{2}N \mbox{ , 16-bit labels and 32-bit values} \\
\frac{3}{2}N \mbox{ , 8-bit labels and 64-bit values} \\
2N \mbox{ , 16-bit labels and 64-bit values}
\end{array}
\right.
\end{displaymath}
-->
<IMG
WIDTH="310" HEIGHT="123" BORDER="0"
SRC="img103.gif"
ALT="\begin{displaymath}
W = \left\{ \\
\begin{array}{c}
N \mbox{ , 8-bit labels ...
...mbox{ , 16-bit labels and 64-bit values}
\end{array} \right.
\end{displaymath}">
</DIV>
<BR CLEAR="ALL">
<P></P>
<P>
The actual number of words required can
exceed this computed value by up to one percent, due to
bookkeeping overhead, and because the file itself is
organized into fixed-size records.
<P>
With at least the default print level, all semidirect (not direct)
calculations will print out information about the integral file and
the number of integrals computed. The form of this output is as
follows:
<P>
<PRE>
Integral file = ./c6h6.aoints.0
Record size in doubles = 32769 No. of integs per rec = 32768
Max. records in memory = 3 Max. records in file = 5
No. of bits per label = 8 No. of bits per value = 32
#quartets = 2.0D+04 #integrals = 7.9D+05 direct = 63.6% cached = 36.4%
</PRE>
<P>
The file information above relates only to process 0. The line of
information about the number of quartets, integrals, etc., is a sum
over all processes.
<P>
When the integral file is closed, additional information of the following
form is printed:
<P>
<PRE>
------------------------------------------------------------
EAF file 0: "./c6h6.aoints.0" size=262152 bytes
------------------------------------------------------------
write read awrite aread wait
----- ---- ------ ----- ----
calls: 6 12 0 0 0
data(b): 1.57e+06 3.15e+06 0.00e+00 0.00e+00
time(s): 1.09e-01 3.12e-02 0.00e+00
rate(mb/s): 1.44e+01 1.01e+02
------------------------------------------------------------
Parallel integral file used 4 records with 0 large values
</PRE>
Again, the detailed file information relates just to process 0, but
the final line indicates the total number of integral records stored
by all processes.
<P>
This information may be used to optimize subsequent calculations, for
instance by assigning more memory or disk space.
<P>
<H1><A NAME="SECTION0012120000000000000000"></A>
<A NAME="sec:scfconv"></A>
<BR>
10.12 SCF Convergence Control Options
</H1>
<P>
<EM>Note to users:</EM> It is desired that the SCF program converge
reliably with the default options for a wide variety of molecules. In
addition, it should be guaranteed to converge for any system, with
sufficient iterations. Please report significant convergence problems
to <code>nwchem</code>-<code>support@</code><code>emsl.pnl.gov</code>, and include the
input file.
<P>
The SCF program uses a preconditioned conjugate gradient (PCG) method
that is unconditionally convergent. Basically, a search direction is
generated by multiplying the orbital gradient (the derivative of the
energy with respect to the orbital rotations) by an approximation to
the inverse of the level-shifted orbital Hessian. In the initial
iterations (see Section <A HREF="node12.html#sec:nrswitch">10.13</A>), an inexpensive
one-electron approximation to the inverse orbital Hessian is used.
Closer to convergence, the full orbital Hessian is used, which should
provide quadratic convergence. For both the full or one-electron
orbital Hessians, the inverse-Hessian matrix-vector product is formed
iteratively. Subsequently, an approximate line search is performed
along the new search direction. If the exact Hessian is being
employed, then the line search should require a single step (of
unity). Preconditioning with approximate Hessians may require
additional steps, especially in the initial iterations. It is the
(approximate) line search that provides the convergence guarantee.
The iterations required to solve the linear equations are referred to
as micro-iterations. A macro-iteration comprises both the iterative
solution and a line search.
<P>
Level-shifting plays the same role in this algorithm as
it does in the conventional iterative solution of the SCF equations.
The approximate Hessian used for preconditioning should be positive
definite. If this is not the case, then level-shifting by a positive
constant (<IMG
WIDTH="17" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
SRC="img104.gif"
ALT="$\Delta$">) serves to make the preconditioning matrix positive
definite, by adding <IMG
WIDTH="17" HEIGHT="14" ALIGN="BOTTOM" BORDER="0"
SRC="img104.gif"
ALT="$\Delta$"> to all of its eigenvalues. The
level-shifts employed for the RHF orbital Hessian should be
approximately four times (only twice for UHF) the value that one would
employ in a conventional SCF<A NAME="tex2html25"
HREF="footnode.html#foot2590"><SUP>10.2</SUP></A>. Level-shifting is automatically enabled
in the early iterations, and the default options suffice for most test
cases.
<P>
So why do things go wrong and what can be done to fix convergence
problems? Most problems encountered so far arise either poor initial
guesses or from small or negative eigenvalues of the orbital Hessian.
The atomic orbital guess is usually very good. However, in
calculations on charged systems, especially with open shells,
incorrect initial occupations may result. The SCF might then converge
very slowly since very large orbital rotations might be required to
achieve the correct occupation or move charge large distances in the
molecule. Possible actions are
<UL>
<LI>Modify the atomic guess by assigning charges to the atoms
known to carry substantial charges (Section <A HREF="node12.html#sec:atomscf">10.5.2</A>)
</LI>
<LI>Examining an analysis of the initial orbitals (Section
<A HREF="node12.html#sec:scfprint">10.16</A>) and then swapping them to attain the desired
occupation (Section <A HREF="node12.html#sec:vectors">10.5</A>).
</LI>
<LI>Converging the calculation in a minimal basis set, which is
usually easier, and then projecting into a larger basis set (Section
<A HREF="node12.html#sec:vectors">10.5</A>).
</LI>
<LI>Using the fragment orbital initial guess (Section
<A HREF="node12.html#sec:fragguess">10.5.1</A>).
</LI>
</UL>
<P>
Small or negative Hessian eigenvalues can occur even though the
calculation seem to be close to convergence (as measured by the
gradient norm, or the off-diagonal Fock matrix elements). Small
eigenvalues will cause the iterative linear equation solver to
converge slowly, resulting in an excessive number of micro-iterations.
This makes the SCF expensive in terms of computation time, and it is
possible to exceed the maximum number of iterations without achieving
the accuracy required for quadratic convergence -- which causes more
macro-iterations to be performed.
<P>
Two main options are available when a problem will not converge:
Newton-Raphson can be disabled temporarily or permanently (see Section
<A HREF="node12.html#sec:nrswitch">10.13</A>), and level-shifting can be applied to the matrix
(see Section <A HREF="node12.html#sec:level">10.14</A>). In some cases, both options may be
necessary to achieve final convergence.
<P>
If there is reason to suspect a negative eigenvalue, the first course
is to disable the Newton-Raphson iteration until the solution is
closer to convergence. It may be necessary to disable it completely.
At some point close to convergence, the Hessian will be positive
definite, so disabling Newton-Raphson should yield a solution with
approximately the same convergence rate as DIIS.
<P>
If temporarily disabling Newton-Raphson is not sufficient to achieve
convergence, it may be necessary to disable it entirely and apply a
small level-shift to the approximate Hessian. This should improve the
convergence rate of the micro-iterations and stabilize the
macro-iterations. The level-shifting will destroy exact quadratic
convergence, but the optimization process is automatically adjusted to
reflect this by enforcing conjugacy and reducing the accuracy to which
the linear equations are solved. The net result of this is that the
solution will do more macro-iterations, but each one should take less
time than it would with the unshifted Hessian.
<P>
The following sections describe the directives needed to disable the
Newton-Raphson iteration and specify level-shifting.
<P>
<H1><A NAME="SECTION0012130000000000000000"></A>
<A NAME="sec:nrswitch"></A>
<BR>
10.13 <TT>NR</TT> -- controlling the Newton-Raphson
</H1>
<P>
<PRE>
NR &lt;real nr_switch default 0.1&gt;
</PRE>
<P>
The exact orbital Hessian is adopted as the preconditioner when the
maximum element of the orbital gradient is below the value specified
for <code>nr_switch</code>. The default value is 0.1, which means that
Newton-Raphson will be disabled until the maximum value of the orbital
gradient (twice the largest off-diagonal Fock matrix element) is less
than 0.1. To disable the Newton-Raphson entirely, the
value of <code>nr_switch</code> must be set to zero. The directive to accomplish
this is as follows:
<PRE>
nr 0
</PRE>
<P>
<H1><A NAME="SECTION0012140000000000000000"></A>
<A NAME="sec:level"></A>
<BR>
10.14 <TT>LEVEL</TT> -- level-shifting the orbital Hessian
</H1>
<P>
This directive allows the user to specify level-shifting to obtain a
positive-definite preconditioning matrix for the SCF solution
procedure. Separate level shifts can be set for the first-order
convergent one-electron approximation to the Hessian used with the
preconditioned conjugate gradient (PCG) method, and for the full
Hessian used with the Newton-Raphson (NR) approach. It is also
possible to change the level-shift automatically as the solution
attains some specified accuracy. The form of the directive is as
follows:
<PRE>
LEVEL [pcg &lt;real initial default 20.0&gt; \
[&lt;real tol default 0.5&gt; &lt;real final default 0.0&gt;]] \
[nr &lt;real initial default 0.0&gt; \
[&lt;real tol default 0.0&gt; &lt;real final default 0.0&gt;]]
</PRE>
<P>
This directive contains only two keywords: one for the PCG method and
the other for the exact Hessian (Newton Raphson, or NR). Use of PCG
or NR is determined by the input specified for <code>nr_switch</code> on the
<code>NR</code> directive, Section <A HREF="node12.html#sec:nrswitch">10.13</A> above.
<P>
Specifying the keyword <code>pcg</code> on the <code>LEVEL</code> directive allows
the user to define the level shifting for the approximate (i.e., PCG)
method. Specifying the keyword <code>nr</code> allows the user to define
the level shifting for the exact Hessians. In both options, the
initial level shift is defined by the value specified for the variable
<code>initial</code>. Optionally, <code>tol</code> can be specified independently
with each keyword to define the level of accuracy that must be
attained in the solution before the level shifting is changed to the
value specified by input in the real variable <code>final</code>. Level
shifts and gradient thresholds are specified in atomic units.
<P>
For the PCG method (as specified using the keyword <code>pcg</code>), the
defaults for this input are 20.0 for <code>initial</code>, 0.5 for
<code>tol</code>, and 0.0 for <code>final</code>. This means that the
approximate Hessian will be shifted by 20.0 until the maximum element
of the gradient falls below 0.5, at which point the shift will be set
to zero.
<P>
For the exact Hessian (as specified using the keyword <code>nr</code>), the
defaults are all zero. The exact Hessian is usually not shifted since
this destroys quadratic convergence. An example of an input directive
that applies a shift of 0.2 to the exact Hessian is as follows:
<PRE>
level nr 0.2
</PRE>
<P>
To apply this shift to the exact Hessian only until the maximum
element of the gradient falls below 0.005, the required input
directive is as follows:
<PRE>
level nr 0.2 0.005 0
</PRE>
<P>
Note that in both of these examples, the parameters for the PCG method
are at the default values. To obtain values different from the
defaults, the keyword <code>pcg</code> must also be specified. For example,
to specify the level shifting in the above example for the exact
Hessian <EM>and</EM> non-default shifting for the PCG method, the
directive would be something like the following:
<PRE>
level pcg 20 0.3 0.0 nr 0.2 0.005 0.0
</PRE>
<P>
This input will cause the PCG method to be level-shifted by 20.0 until
the maximum element of the gradient falls below 0.3, then the shift
will be zero. For the exact Hessian, the level shifting is initially
0.2, until the maximum element falls below 0.005, after which the
shift is zero.
<P>
The default options correspond to
<PRE>
level pcg 20 0.5 0 nr 0 0 0
</PRE>
<P>
<H1><A NAME="SECTION0012150000000000000000"></A>
<A NAME="orbloc"></A>
<BR>
10.15 Orbital Localization
</H1>
The SCF module includes an <EM>experimental</EM> implementation of
orbital localization, including Foster-Boys and Pipek-Mezey which only
works for closed-shell (RHF) wavefunctions. There is currently no
input in the SCF block to control this so the <code>SET</code> directive
(Section <A HREF="node7.html#sec:set">5.7</A>) must be used.
<P>
The directive
<PRE>
set scf:localize t
</PRE>
will separately localize the core, valence, and virtual orbital spaces
using the Pipek-Mezey algorithm. If the additional directive
<PRE>
set scf:loctype FB
</PRE>
is included, then the Foster-boys algorithm is used. The partitioning
of core-orbitals is performed using the atomic information described
in Section <A HREF="node18.html#mp2:core">16.1</A>.
<P>
In the next release, this functionality will be extended to included all
wavefunctions using molecular orbitals.
<P>
<H1><A NAME="SECTION0012160000000000000000"></A>
<A NAME="sec:scfprint"></A>
<BR>
10.16 Printing Information from the SCF Module
</H1>
<P>
All output from the SCF module is controlled using the <code>PRINT</code>
directive described in Section <A HREF="node7.html#sec:printcontrol">5.6</A>. The following
list describes the items from SCF that are currently under direct
print control, along with the print level for each one.
<P>
<BR><P></P>
<DIV ALIGN="CENTER"><A NAME="2577"></A>
<TABLE>
<CAPTION><STRONG>Table 10.1:</STRONG>
SCF Print Control Specifications</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 ALIGN="CENTER">
<TR><TD ALIGN="LEFT"><B>Name</B></TD>
<TD ALIGN="CENTER"><B>Print Level</B></TD>
<TD ALIGN="CENTER"><B>Description</B></TD>
</TR>
<TR><TD ALIGN="LEFT">``atomic guess density''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">guess density matrix</TD>
</TR>
<TR><TD ALIGN="LEFT">``atomic scf''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">details of atomic SCF</TD>
</TR>
<TR><TD ALIGN="LEFT">``mo guess''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">brief info from mo guess</TD>
</TR>
<TR><TD ALIGN="LEFT">``information''</TD>
<TD ALIGN="CENTER">low</TD>
<TD ALIGN="CENTER">results</TD>
</TR>
<TR><TD ALIGN="LEFT">``initial vectors''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``intermediate vectors''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``final vectors''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``final vectors analysis''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``initial vectors analysis''</TD>
<TD ALIGN="CENTER">never</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``intermediate evals''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``final evals''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``schwarz''</TD>
<TD ALIGN="CENTER">high</TD>
<TD ALIGN="CENTER">integral screening info &amp; stats at completion</TD>
</TR>
<TR><TD ALIGN="LEFT">``screening statistics''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">display stats after every Fock build</TD>
</TR>
<TR><TD ALIGN="LEFT">``geometry''</TD>
<TD ALIGN="CENTER">high</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``symmetry''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">detailed symmetry info</TD>
</TR>
<TR><TD ALIGN="LEFT">``basis''</TD>
<TD ALIGN="CENTER">high</TD>
<TD ALIGN="CENTER">&nbsp;</TD>
</TR>
<TR><TD ALIGN="LEFT">``geombas''</TD>
<TD ALIGN="CENTER">debug</TD>
<TD ALIGN="CENTER">detailed basis map info</TD>
</TR>
<TR><TD ALIGN="LEFT">``vectors i/o''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">report vectors I/O</TD>
</TR>
<TR><TD ALIGN="LEFT">``parameters''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">convergence parameters</TD>
</TR>
<TR><TD ALIGN="LEFT">``convergence''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">info each iteration</TD>
</TR>
<TR><TD ALIGN="LEFT">``mulliken ao''</TD>
<TD ALIGN="CENTER">never</TD>
<TD ALIGN="CENTER">Mulliken population of basis functions</TD>
</TR>
</TABLE>
</DIV>
</TD></TR>
</TABLE>
</DIV><P></P>
<BR>
<P>
<H1><A NAME="SECTION0012170000000000000000">
10.17 Hartree-Fock or SCF, MCSCF and MP2 Gradients</A>
</H1>
<P>
<A NAME="sec:scfgrad"></A>
<P>
The input for this directive allows the user to adjust the print control
for the SCF, UHF, ROHF, MCSCF and MP2 gradients. The
form of the directive is as follows:
<P>
<PRE>
GRADIENTS
[print || noprint] ...
END
</PRE>
<P>
The complementary keyword pair <code>print</code> and <code>noprint</code> allows
the user some additional control on the information that can be
included in the print output from the SCF calculation. Currently,
only a few items can be explicitly invoked via print control. These
are as follows:
<P>
<BR><P></P>
<DIV ALIGN="CENTER"><A NAME="2981"></A>
<TABLE>
<CAPTION><STRONG>Table 10.2:</STRONG>
Gradient Print Control Specifications</CAPTION>
<TR><TD>
<DIV ALIGN="CENTER">
<TABLE CELLPADDING=3 ALIGN="CENTER">
<TR><TD ALIGN="LEFT"><B>Name</B></TD>
<TD ALIGN="CENTER"><B>Print Level</B></TD>
<TD ALIGN="CENTER"><B>Description</B></TD>
</TR>
<TR><TD ALIGN="LEFT">``information''</TD>
<TD ALIGN="CENTER">low</TD>
<TD ALIGN="CENTER">calculation info</TD>
</TR>
<TR><TD ALIGN="LEFT">``geometry''</TD>
<TD ALIGN="CENTER">high</TD>
<TD ALIGN="CENTER">geometry information</TD>
</TR>
<TR><TD ALIGN="LEFT">``basis''</TD>
<TD ALIGN="CENTER">high</TD>
<TD ALIGN="CENTER">basis set(s) used</TD>
</TR>
<TR><TD ALIGN="LEFT">``forces''</TD>
<TD ALIGN="CENTER">low</TD>
<TD ALIGN="CENTER">details of force components</TD>
</TR>
<TR><TD ALIGN="LEFT">``timing''</TD>
<TD ALIGN="CENTER">default</TD>
<TD ALIGN="CENTER">timing for each phase</TD>
</TR>
</TABLE>
</DIV>
</TD></TR>
</TABLE>
</DIV><P></P>
<BR>
<P>
<P>
<HR>
<!--Navigation Panel-->
<A NAME="tex2html1150"
HREF="node13.html">
<IMG WIDTH="37" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="next" SRC="next.png"></A>
<A NAME="tex2html1146"
HREF="user.html">
<IMG WIDTH="26" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="up" SRC="up.png"></A>
<A NAME="tex2html1140"
HREF="node11.html">
<IMG WIDTH="63" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="previous" SRC="prev.png"></A>
<A NAME="tex2html1148"
HREF="node2.html">
<IMG WIDTH="65" HEIGHT="24" ALIGN="BOTTOM" BORDER="0" ALT="contents" SRC="contents.png"></A>
<BR>
<B> Next:</B> <A NAME="tex2html1151"
HREF="node13.html">11. DFT for Molecules</A>
<B> Up:</B> <A NAME="tex2html1147"
HREF="user.html">user</A>
<B> Previous:</B> <A NAME="tex2html1141"
HREF="node11.html">9. Relativistic All-electron Approximations</A>
&nbsp <B> <A NAME="tex2html1149"
HREF="node2.html">Contents</A></B>
<!--End of Navigation Panel-->
<ADDRESS>
Edoardo Apra
2004-05-25
</ADDRESS>
</BODY>
</HTML>
Reference in a new issue View git blame Copy permalink