mirror of
https://github.com/nwchemgit/nwchem.git
synced 2026-07-28 22:25:48 -04:00
minor corrections; fixed several examples; clarified some wording
This commit is contained in:
parent
989be656d9
commit
5f5671dcaa
7 changed files with 137 additions and 172 deletions
|
|
@ -16,15 +16,11 @@ the first derivatives.
|
|||
|
||||
\begin{itemize}
|
||||
\item Self Consistent Field (SCF) or Hartree Fock (RHF, UHF, high-spin
|
||||
ROHF). Code to compute analytic second derivatives is being tested.
|
||||
ROHF).
|
||||
\item Gaussian Density Functional Theory (DFT), using many local and
|
||||
non-local exchange-correlation potentials (RHF and UHF).
|
||||
non-local exchange-correlation potentials (RHF or UHF).
|
||||
\item MP2 semi-direct using frozen core and RHF and UHF reference.
|
||||
|
||||
\item Coupled-cluster single and double excitations (CCSD), with RHF
|
||||
reference\footnote{CCSD analytic gradients were not yet complete at
|
||||
the time of writing}.
|
||||
|
||||
\item Complete active space SCF (CASSCF).
|
||||
|
||||
\end{itemize}
|
||||
|
|
@ -33,11 +29,11 @@ The following methods are available to compute energies only. First
|
|||
and second derivatives are computed by finite difference of the
|
||||
energies.
|
||||
\begin{itemize}
|
||||
\item MP3, MP4, CCSD(T), with RHF reference.
|
||||
\item MP3, MP4, CCSD, CCSD(T), CCSD+T(CCSD), with RHF reference.
|
||||
\item Selected-CI with second-order perturbation correction.
|
||||
\item MP2 fully-direct with RHF reference.
|
||||
\item Resolution of the identity integral approximation MP2 (RI-MP2), with
|
||||
RHF and UHF reference.
|
||||
RHF or UHF reference.
|
||||
\end{itemize}
|
||||
|
||||
For all methods, the following operations may be performed:
|
||||
|
|
|
|||
|
|
@ -593,8 +593,7 @@ The \verb+ZCOORD+ input parameters are defined as follows:
|
|||
the atoms.
|
||||
\end{itemize}
|
||||
|
||||
\section{Freezing internal coordinates or atom coordinates
|
||||
in geometry optimizations}
|
||||
\section{Freezing coordinates in geometry optimizations}
|
||||
\label{sec:activeatoms}
|
||||
|
||||
Internal coordinates may have been specified by means of a user
|
||||
|
|
|
|||
|
|
@ -35,7 +35,7 @@ module-specific directives (i.e., compound directives) can appear in
|
|||
any order, with the exception of the \verb+TASK+ directive (see
|
||||
sections \ref{sec:inputstructure} and \ref{sec:task}) which is used to
|
||||
invoke an NWChem module. All input for a given task must
|
||||
proceed the \verb+TASK+ directive. This input specification rule
|
||||
precede the \verb+TASK+ directive. This input specification rule
|
||||
allows the concatenation of multiple tasks in a single NWChem input
|
||||
file.
|
||||
|
||||
|
|
@ -97,12 +97,14 @@ something like the following;
|
|||
\end{verbatim}
|
||||
|
||||
The default name for the input file is \verb+nwchem.nw+. If an input
|
||||
file name \verb+input_file+ is specified without an extension, the code
|
||||
assumes \verb+.nw+ as a default extension, and the input filename becomes \verb+input_file.nw+. If the code cannot
|
||||
locate a file named either \verb+nwchem.nw+ or \verb+input_file.nw+, an
|
||||
error is reported and execution terminates. The following
|
||||
section presents two input files to illustrate the directive syntax and
|
||||
input file format for NWChem applications.
|
||||
file name \verb+input_file+ is specified without an extension, the
|
||||
code assumes \verb+.nw+ as a default extension, and the input filename
|
||||
becomes \verb+input_file.nw+. If the code cannot locate a file named
|
||||
either \verb+input_file+ or \verb+input_file.nw+ (or \verb+nwchem.nw+
|
||||
if no file name is provided), an error is reported and execution
|
||||
terminates. The following section presents two input files to
|
||||
illustrate the directive syntax and input file format for NWChem
|
||||
applications.
|
||||
|
||||
\section{Simple Input File --- SCF geometry optimization}
|
||||
\label{sec:simplesample}
|
||||
|
|
@ -163,21 +165,21 @@ both standard output and standard error.
|
|||
\label{sec:realsample}
|
||||
|
||||
A more complex sample problem is the optimization of a positively
|
||||
charged water molecule at the MP2 level of theory, followed by a
|
||||
computation of frequencies at the optimized geometry. A preliminary
|
||||
SCF geometry optimization is performed using a computationally
|
||||
inexpensive basis set (STO-3G). This yields a good starting guess for
|
||||
the optimal geometry, and any Hessian information generated will be
|
||||
used in the next optimization step. Then the optimization is finished
|
||||
using second-order M{\o}ller-Plesset perturbation theory and a basis
|
||||
set with polarization functions. The final task is to calculate the
|
||||
vibrational frequencies. The input file to accomplish these three
|
||||
charged water molecule using second-order M{\o}ller-Plesset
|
||||
perturbation theory (MP2), followed by a computation of frequencies at
|
||||
the optimized geometry. A preliminary SCF geometry optimization is
|
||||
performed using a computationally inexpensive basis set (STO-3G).
|
||||
This yields a good starting guess for the optimal geometry, and any
|
||||
Hessian information generated will be used in the next optimization
|
||||
step. Then the optimization is finished using MP2 and a basis set
|
||||
with polarization functions. The final task is to calculate the
|
||||
MP2 vibrational frequencies. The input file to accomplish these three
|
||||
tasks is as follows:
|
||||
|
||||
\begin{verbatim}
|
||||
start h2o_freq
|
||||
|
||||
title; H2O+ frequencies with MP2 and 6-31g**
|
||||
charge 1
|
||||
|
||||
geometry units angstroms
|
||||
O 0.0 0.0 0.0
|
||||
|
|
@ -185,44 +187,35 @@ geometry units angstroms
|
|||
H 0.0 1.0 0.0
|
||||
end
|
||||
|
||||
charge 1
|
||||
|
||||
basis "starting basis"
|
||||
basis
|
||||
H library sto-3g
|
||||
O library sto-3g
|
||||
end
|
||||
|
||||
basis "final basis"
|
||||
scf
|
||||
uhf; doublet
|
||||
print low
|
||||
end
|
||||
|
||||
title; H2O+ : STO-3G UHF geometry optimization
|
||||
|
||||
task scf optimize
|
||||
|
||||
basis
|
||||
H library 6-31g**
|
||||
O library 6-31g**
|
||||
end
|
||||
|
||||
scf
|
||||
uhf
|
||||
doublet
|
||||
print low
|
||||
end
|
||||
|
||||
set "ao basis" "starting basis"
|
||||
|
||||
task scf optimize
|
||||
|
||||
set "ao basis" "final basis"
|
||||
|
||||
scf
|
||||
vectors input atomic
|
||||
print none
|
||||
end
|
||||
title; H2O+ : 6-31g** UMP2 geometry optimization
|
||||
|
||||
task mp2 optimize
|
||||
|
||||
mp2
|
||||
print none
|
||||
end
|
||||
mp2; print none; end
|
||||
scf; print none; end
|
||||
|
||||
title; H2O+ : 6-31g** UMP2 frequencies
|
||||
|
||||
task mp2 freq
|
||||
|
||||
eof
|
||||
\end{verbatim}
|
||||
|
||||
The \verb+START+ directive (Section \ref{sec:start}) tells NWChem that
|
||||
|
|
@ -242,86 +235,47 @@ actually necessary, however.) The {\tt CHARGE} directive defines the
|
|||
total charge of the system. This calculation is to be done on an ion
|
||||
with charge +1.
|
||||
|
||||
The next two directives are the {\tt BASIS} directives. The names for
|
||||
the basis sets are arbitrary, and they may be chosen so that they will
|
||||
serve as a helpful mnemonic for later reference in subsequent input
|
||||
directives.
|
||||
|
||||
The multiple lines of the first {\tt SCF} directive in the {\tt scf
|
||||
\ldots end} block specify details about the SCF calculation to be
|
||||
performed. Unrestricted Hartree-Fock is chosen here (by specifying
|
||||
the keyword {\tt uhf}), rather than the default, restricted open-shell
|
||||
high-spin Hartree-Fock (ROHF). This is necessary for the subsequent
|
||||
MP2 calculation, because only UMP2 is currently available for
|
||||
open-shell systems (see Section \ref{sec:functionality}). For
|
||||
open-shell systems, the spin multiplicity has to be specified (using
|
||||
{\tt doublet} in this case), or it defaults to {\tt singlet}. The
|
||||
print level is set to {\tt low} to reduce the output from the SCF
|
||||
module to a minimum during the geometry optimization (to avoid verbose
|
||||
output for the starting basis calculations).
|
||||
|
||||
The final step in setting up the input for the SCF calculation is to
|
||||
specify that the \verb+"starting basis"+ should be used. This is
|
||||
accomplished by means of the \verb+SET+ directive, which specifies
|
||||
that the \verb+"ao basis"+ is the \verb+"starting basis"+. All
|
||||
molecular orbital (MO) methods look for the \verb+"ao basis"+ in which
|
||||
to expand the MOs. In the previous example with the nitrogen
|
||||
molecule, it was not necessary to use the \verb+SET+ directive in this
|
||||
manner, since the \verb+BASIS+ directive used the default name (which
|
||||
is \verb+"ao basis"+). An alternative approach, which avoids the
|
||||
necessity of assigning the starting basis set name, would be to defer
|
||||
definition of the final basis until after the first SCF calculation is
|
||||
complete.
|
||||
A small basis set (STO-3G) is specified for the intial geometry
|
||||
optimization. Next, the multiple lines of the first {\tt SCF}
|
||||
directive in the {\tt scf \ldots end} block specify details about the
|
||||
SCF calculation to be performed. Unrestricted Hartree-Fock is chosen
|
||||
here (by specifying the keyword {\tt uhf}), rather than the default,
|
||||
restricted open-shell high-spin Hartree-Fock (ROHF). This is
|
||||
necessary for the subsequent MP2 calculation, because only UMP2 is
|
||||
currently available for open-shell systems (see Section
|
||||
\ref{sec:functionality}). For open-shell systems, the spin
|
||||
multiplicity has to be specified (using {\tt doublet} in this case),
|
||||
or it defaults to {\tt singlet}. The print level is set to {\tt low}
|
||||
to avoid verbose output for the starting basis calculations.
|
||||
|
||||
All input up to this point affects only the settings in the runtime
|
||||
database. The program takes its information from this database, so
|
||||
the sequence of directives up to the first \verb+TASK+ directive is
|
||||
irrelevant. An exchange of order of the different blocks or
|
||||
directives would not affect the result. The {\tt TASK} directive,
|
||||
however, must be specified last of all in the list of input directives
|
||||
for a given problem. The {\tt TASK} directive invokes the program and
|
||||
directs the code to perform the specified calculation using the
|
||||
parameters set in the preceding directives. In this case, the first
|
||||
task is an SCF calculation with geometry optimization, specified with
|
||||
the input {\tt scf} and {\tt optimize}. (See Section \ref{sec:task}
|
||||
for a list of available tasks and operations.)
|
||||
however, must be specified after all relevant input for a given
|
||||
problem. The {\tt TASK} directive causes the code to perform the
|
||||
specified calculation using the parameters set in the preceding
|
||||
directives. In this case, the first task is an SCF calculation with
|
||||
geometry optimization, specified with the input {\tt scf} and {\tt
|
||||
optimize}. (See Section \ref{sec:task} for a list of available
|
||||
tasks and operations.)
|
||||
|
||||
After the completion of any task, settings in the database are used
|
||||
in subsequent tasks without change, unless they are overridden by new
|
||||
input directives. In this example, there are several important
|
||||
changes between the first task (\verb+task scf optimize+) and the
|
||||
second task (\verb+task mp2 optimize+). The {\tt "ao basis"} is set
|
||||
to a better basis (i.e., {\tt "final basis"}), using the \verb+SET+
|
||||
directive. The SCF output will be completely discarded (as a result of the
|
||||
{\tt print none} input in the {\tt SCF} directive), which means that
|
||||
no SCF output will be produced unless an error occurs. The SCF starting
|
||||
guess vectors are reset to be the atomic guess, since the STO-3G
|
||||
vectors are no longer appropriate (see Section \ref{sec:vectors} for
|
||||
details on the different possible starting guesses).
|
||||
|
||||
The second {\tt TASK} directive invokes an MP2 optimization, instead
|
||||
of the SCF optimization.
|
||||
After the completion of any task, settings in the database are used in
|
||||
subsequent tasks without change, unless they are overridden by new
|
||||
input directives. In this example, before the second task (\verb+task
|
||||
mp2 optimize+), a better basis set (6-31G**) is defined and the title
|
||||
is changed. The second {\tt TASK} directive invokes an MP2 geometry
|
||||
optimization.
|
||||
|
||||
Once the MP2 optimization is completed, the geometry obtained in the
|
||||
calculation is used to perform a frequency calculation. This task is
|
||||
invoked by the keyword \verb+freq+ in the final \verb+TASK+ directive,
|
||||
\verb+task mp2 freq+. The second derivatives of the energy are
|
||||
calculated as numerical derivatives of analytical gradients. The
|
||||
gradients as such are not of interest in this case, so the amount of
|
||||
output from the {\tt mp2} module is reduced with the \verb+PRINT+
|
||||
directive.
|
||||
|
||||
The {\tt EOF} directive marks the end of the input to be read. It is
|
||||
not necessary to specify the end-of-file as an explicit directive at
|
||||
the actual end of the file. However, using the directive allows
|
||||
additional lines in the file that will not be processed as input. For
|
||||
example, the user might want to add a description of the
|
||||
calculation(s) specified in the input or notes on the purpose of the
|
||||
task(s), or other informational comments. The {\tt eof} directive can
|
||||
also be used to remove a task (or series of tasks) from the
|
||||
calculation without actually removing the relevant input directives
|
||||
from the file. Any lines in the file that occur after the {\tt eof}
|
||||
directive are ignored by the program.
|
||||
intermediate energies and gradients as such are not of interest in
|
||||
this case, so output from the SCF and MP2 modules is disabled with the
|
||||
\verb+PRINT+ directives.
|
||||
|
||||
\section{Input Format and Syntax for Directives}
|
||||
\label{sec:syntax}
|
||||
|
|
|
|||
|
|
@ -1,7 +1,7 @@
|
|||
\label{sec:intro}
|
||||
|
||||
NWChem is a computational chemistry package designed to run on
|
||||
high-performance parallel supercomputers and workstation clusters.
|
||||
high-performance parallel supercomputers.
|
||||
Code capabilities include the calculation of molecular electronic
|
||||
energies and analytic gradients using Hartree-Fock self-consistent field (SCF) theory, Gaussian
|
||||
density function theory (DFT), and second-order perturbation theory.
|
||||
|
|
@ -14,7 +14,7 @@ NWChem is scalable, both in its ability to treat large problems
|
|||
efficiently, and in its utilization of available parallel computing
|
||||
resources. The code uses the parallel programming tools TCGMSG and
|
||||
the Global Array (GA) library developed at PNNL for the High Performance
|
||||
Computing and Communication Initiative (HPCCI) grand-challenge
|
||||
Computing and Communication (HPCC) grand-challenge
|
||||
software program and the Environmental Molecular Sciences Laboratory
|
||||
(EMSL) Project. NWChem has been optimized to perform calculations on
|
||||
large molecules using large parallel computers, and it is unique in
|
||||
|
|
|
|||
|
|
@ -127,8 +127,9 @@ example above, the \verb+SET+ directive is as follows:
|
|||
\end{verbatim}
|
||||
|
||||
NWChem will automatically check for such indirections when loading
|
||||
geometries. The other database object, \verb+"basis set"+, functions
|
||||
in a similar fashion, using the default name \verb+"ao basis"+.
|
||||
geometries. Storage of data associated with basis sets, the other
|
||||
database resident object, functions in a similar fashion, using the
|
||||
default name \verb+"ao basis"+.
|
||||
|
||||
\section{Persistence of data and restart}
|
||||
\label{sec:persist}
|
||||
|
|
|
|||
|
|
@ -9,11 +9,11 @@
|
|||
{\bf\Huge Release \nwchemversion}\\[1.0in]
|
||||
|
||||
{\bf\Large High Performance Computational Chemistry Group\\
|
||||
Environmental Molecular Sciences Laboratory\\
|
||||
W.R.\ Riley Environmental Molecular Sciences Laboratory\\
|
||||
Pacific Northwest National Laboratory\\
|
||||
P.O. Box 999, Richland, WA 99352\\[0.5in]}
|
||||
|
||||
{\bf\Large April 1997}\\[1.0in]
|
||||
{\bf\Large March 1998}\\[1.0in]
|
||||
|
||||
|
||||
%\psfig{figure=zsm.major.ps,height=4in,width=4in}
|
||||
|
|
|
|||
|
|
@ -37,15 +37,22 @@ The \verb+START+ directive indicates that the calculation is one in
|
|||
which a new database is to be created. Any relevant information that
|
||||
already exists in a previous database of the same name is destroyed.
|
||||
The string variable {\tt <file\_prefix>} will be used as the prefix to
|
||||
name any files created in the course of the calculation. If the user
|
||||
does not specify an entry for {\tt <file\_prefix>} on the \verb+START+
|
||||
directive (or omits the \verb+START+ directive altogether), the code
|
||||
uses the base-name of the input file as the file prefix. That is, the
|
||||
variable {\tt <file\_prefix>} is assigned the name of the input file
|
||||
(not its full pathname), but without the last "dot-suffix". For
|
||||
example, the input file name \verb+/home/dave/job.2.nw+ yields
|
||||
\verb+job.2+ as the file prefix, if a name is not assigned explicitly
|
||||
using the \verb+START+ directive.
|
||||
name any files created in the course of the calculation.
|
||||
|
||||
E.g., to start a new calculation on water, one might specify
|
||||
\begin{verbatim}
|
||||
start water
|
||||
end
|
||||
which would result in all files beginning with {\tt "water."}.
|
||||
|
||||
If the user does not specify an entry for {\tt <file\_prefix>} on the
|
||||
\verb+START+ directive (or omits the \verb+START+ directive
|
||||
altogether), the code uses the base-name of the input file as the file
|
||||
prefix. That is, the variable {\tt <file\_prefix>} is assigned the
|
||||
name of the input file (not its full pathname), but without the last
|
||||
"dot-suffix". For example, the input file name
|
||||
\verb+/home/dave/job.2.nw+ yields \verb+job.2+ as the file prefix, if
|
||||
a name is not assigned explicitly using the \verb+START+ directive.
|
||||
|
||||
The user also has the option of
|
||||
specifying a unique name for the database, using the keyword {\tt
|
||||
|
|
@ -200,8 +207,8 @@ other scratch files in \verb+/scratch+:
|
|||
\begin{verbatim}
|
||||
scratch_dir /scratch 0:/piofs/rjh
|
||||
\end{verbatim}
|
||||
\item Put scratch files from Process 1 in directory \verb+scr1+, those from
|
||||
Process 2 in \verb+scr2+, and so forth, in a round-robin fashion, using the
|
||||
\item Put scratch files from Process 0 in directory \verb+scr1+, those from
|
||||
Process 1 in \verb+scr2+, and so forth, in a round-robin fashion, using the
|
||||
given list of directories:
|
||||
\begin{verbatim}
|
||||
scratch_dir /scr1 /scr2 /scr3 /scr4 /scr5
|
||||
|
|
@ -219,11 +226,13 @@ given list of directories:
|
|||
|
||||
This is a start-up directive that allows the user to specify the
|
||||
amount of memory that NWChem can use for the job. If this directive
|
||||
is not specified, memory is allocated according to installation-dependent
|
||||
defaults. These should generally suffice for most
|
||||
calculations, since the defaults usually correspond to the total amount
|
||||
of memory available on the machine. The general form of the directive
|
||||
is as follows:
|
||||
is not specified, memory is allocated according to
|
||||
installation-dependent defaults. {\em These defaults should generally
|
||||
suffice for most calculations, since the defaults usually correspond
|
||||
to the total amount of memory available on the machine. It should
|
||||
usually be unncessary to provide a memory directive.}
|
||||
|
||||
The general form of the directive is as follows:
|
||||
|
||||
\begin{verbatim}
|
||||
MEMORY [[total] <integer total_size>] \
|
||||
|
|
@ -381,10 +390,12 @@ once, by Process 0 when the input file is read.
|
|||
|
||||
\section{{\tt TITLE} --- Specify job title}
|
||||
|
||||
This top-level directive allows the user to identify a job or series of
|
||||
jobs that use a
|
||||
particular database. It is an optional directive, and if omitted, the
|
||||
character string containing the input title will be empty. The format for
|
||||
This top-level directive allows the user to identify a job or series
|
||||
of jobs that use a particular database. It is an optional directive,
|
||||
and if omitted, the character string containing the input title will
|
||||
be empty. Multiple {\tt TITLE} directives may appear in the input
|
||||
file (e.g., the example file in Section {sec:realsample}) in which
|
||||
case a task will use the one most recently specified. The format for
|
||||
the directive is as follows:
|
||||
|
||||
\begin{verbatim}
|
||||
|
|
@ -471,9 +482,12 @@ are:
|
|||
``rtdb'' \> high \> Print names of RTDB entries\\
|
||||
``rtdbvalues'' \> high \> Print name and values of RTDB entries\\
|
||||
``ga summary'' \> medium \> Summarize GA allocations at job end \\
|
||||
``ga stats'' \> high \> Print GA usage statistics at job end \\
|
||||
``ma summary'' \> medium \> Summarize MA allocations at job end \\
|
||||
``ma stats'' \> high \> Print MA usage statistics at job end \\
|
||||
``version'' \> debug \> Print version number of all compiled routines \\
|
||||
``version'' \> debug \> Print version number of all
|
||||
compiled routines \\
|
||||
``tcgmsg'' \> never \> Print TCGMSG debug information \\
|
||||
\end{tabbing}
|
||||
|
||||
|
||||
|
|
@ -506,15 +520,14 @@ The format of the directive is as follows:
|
|||
SET <string name> [<string type default automatic>] <$type$ data>
|
||||
\end{verbatim}
|
||||
|
||||
The entry for variable \verb+<name>+ is the name of some array or
|
||||
object to be entered into the database. This must be specified
|
||||
explicitly; there is no default. The variable \verb+<type>+, which is
|
||||
The entry for variable \verb+<name>+ is the name of
|
||||
data to be entered into the database. This must be specified; there is no default. The variable \verb+<type>+, which is
|
||||
optional, allows the user to define a string specifying the type of
|
||||
data in the array \verb+<name>+. The data type can be explicitly
|
||||
specified as \verb+integer+, \verb+real+, \verb+double+,
|
||||
\verb+logical+, or \verb+string+. If no entry for \verb+<type>+ is
|
||||
specified on the directive, its value is inferred from the data type
|
||||
of the {\em first} data element. In such a case, floating-point data
|
||||
of the {\em first} datum. In such a case, floating-point data
|
||||
entered using this directive must include either an exponent or a
|
||||
decimal point, to ensure that the correct default type will be
|
||||
inferred. The correct default type will be inferred for logical
|
||||
|
|
@ -523,18 +536,21 @@ values if logical-true values are specified as \verb+.true.+,
|
|||
\verb+.false.+, \verb+false+, or \verb+f+. One exeception to the
|
||||
automatic detection of the data type is that the data type {\bf must}
|
||||
be explicitly stated to input integer ranges, unless the first
|
||||
elemenent in the list is an integer that is not a range (c.f.,
|
||||
element in the list is an integer that is not a range (c.f.,
|
||||
\ref{sec:syntax}). For example,
|
||||
\begin{verbatim}
|
||||
set atomid 1 3:7 21
|
||||
set atomid 1 3:7 21
|
||||
\end{verbatim}
|
||||
will interpret the type as integer and the list input will work fine.
|
||||
However,
|
||||
will be interpreted as a list of integers. However,
|
||||
\begin{verbatim}
|
||||
set atomid 3:7 21
|
||||
set atomid 3:7 21
|
||||
\end{verbatim}
|
||||
will not work since the first element will be interpreted as a
|
||||
string and not an integer.
|
||||
string and not an integer. To work around this feature, use instead
|
||||
\begin{verbatim}
|
||||
set atomid integer 3:7 21
|
||||
\end{verbatim}
|
||||
|
||||
|
||||
The \verb+SET+ directive is useful for providing indirection by
|
||||
associating the name of a basis set or geometry with the standard
|
||||
|
|
@ -573,7 +589,7 @@ geometries. The required input lines are as follows:
|
|||
This input tells the code to perform MP2 energy calculations
|
||||
on an argon dimer in the first task, and then
|
||||
on the argon atom in the presence of the ``ghost'' basis of the other
|
||||
atom at the same geometry.
|
||||
atom.
|
||||
|
||||
The \verb+SET+ directive can also be used as an indirect means of
|
||||
supplying input to a part of the code that does not have a separate
|
||||
|
|
@ -594,7 +610,7 @@ database. The general form of the directive is as follows:
|
|||
\end{verbatim}
|
||||
|
||||
This directive cannot be used with complex objects such as geometries
|
||||
and basis sets\footnote{Complex objects are stored using structured
|
||||
and basis sets\footnote{Complex objects are stored using a structured
|
||||
naming convention that is not matched by a simple wild card.}. A
|
||||
wild-card (*) specified at the end of the string \verb+<name>+ will
|
||||
cause {\em all} entries whose name begins with that string to be
|
||||
|
|
@ -634,23 +650,22 @@ the calculation terminates with an error condition.
|
|||
\section{{\tt TASK} --- Perform a task}
|
||||
\label{sec:task}
|
||||
|
||||
The \verb+TASK+ directive is used to tell the code what to do with the
|
||||
input. The input directives are parsed sequentially until a
|
||||
\verb+TASK+ directive is encountered, as described in Section
|
||||
\ref{sec:inputstructure}. At that point, the calculation or operation
|
||||
specified in the \verb+TASK+ directive is performed. When that task
|
||||
is completed, the code looks for additional input to process until the
|
||||
next \verb+TASK+ directive is encountered, which is then executed.
|
||||
This process continues to the end of the input file. NWChem expects
|
||||
the last directive before the end-of-file to be a \verb+TASK+
|
||||
directive. If it is not, a warning message is printed. Since the
|
||||
database is persistent, multiple tasks within one job behave {\em
|
||||
exactly} the same as multiple restart jobs with the same sequence of
|
||||
input.
|
||||
The \verb+TASK+ directive is used to tell the code what to do. The
|
||||
input directives are parsed sequentially until a \verb+TASK+ directive
|
||||
is encountered, as described in Section \ref{sec:inputstructure}. At
|
||||
that point, the calculation or operation specified in the \verb+TASK+
|
||||
directive is performed. When that task is completed, the code looks
|
||||
for additional input to process until the next \verb+TASK+ directive
|
||||
is encountered, which is then executed. This process continues to the
|
||||
end of the input file. NWChem expects the last directive before the
|
||||
end-of-file to be a \verb+TASK+ directive. If it is not, a warning
|
||||
message is printed. Since the database is persistent, multiple tasks
|
||||
within one job behave {\em exactly} the same as multiple restart jobs
|
||||
with the same sequence of input.
|
||||
|
||||
There are four main forms of the the \verb+TASK+ directive. The most
|
||||
common form is used to tell the code at what level of theory to
|
||||
perform electronic structure calculation, and which specific
|
||||
perform an electronic structure calculation, and which specific
|
||||
calculations to perform. The second form is used to specify tasks
|
||||
that do not involve electronic structure calculations or tasks that
|
||||
have not been fully implemented at all theory levels in NWChem, such
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue