\page input_spec_summary Input Spec Summary

This file is derived automatically from dakota.xml, which is used in
the generation of parser system files that are compiled into the
%Dakota executable. Therefore, these files are the definitive source
for input syntax, capability options, and associated data
inputs. Refer to the Developers Manual information on how to modify
the input specification and propagate the changes through the parsing
system.

Key features of the input specification and the associated user
input files include:

\li In the input specification, required individual specifications
simply appear, optional individual and group specifications are
enclosed in \c [], required group specifications are enclosed in \c
(), and either-or relationships are denoted by the \c | symbol. These
symbols only appear in dakota.input.summary; they must not appear in
actual user input files.

\li Keyword specifications (i.e., \c environment, \c method, \c model, \c
variables, \c interface, and \c responses) begin with the keyword
possibly preceded by white space (blanks, tabs, and newlines)
both in the input specifications and in user input
files. For readability, keyword specifications may be spread across
several lines. Earlier versions of %Dakota (prior to 4.1) required
a backslash character (\\) at the ends of intermediate lines of
a keyword. While such backslashes are still accepted, they are
no longer required.

\li Some of the keyword components within the input specification
indicate that the user must supply <tt>INTEGER</tt>, <tt>REAL</tt>,
<tt>STRING</tt>, <tt>INTEGERLIST</tt>, <tt>REALLIST</tt>, or
<tt>STRINGLIST</tt> data as part of the specification. In a user input
file, the \c "=" is optional, data in a <tt>LIST</tt> can be separated
by commas or whitespace, and the <tt>STRING</tt> data are enclosed in
single or double quotes (e.g., \c 'text_book' or "text_book").

\li In user input files, input is largely order-independent (except for
entries in lists of data), case insensitive, and white-space
insensitive. Although the order of input shown in the 
\ref input_file_examples generally follows the order of options in the input
specification, this is not required.

\li In user input files, specifications may be abbreviated so long as
the abbreviation is unique. For example, the \c npsol_sqp
specification within the method keyword could be abbreviated as \c
npsol, but \c dot_sqp should not be abbreviated as \c dot since this
would be ambiguous with other DOT method specifications.

\li In both the input specification and user input files, comments are
preceded by \c #.

\li ALIAS refers to synonymous keywords, which often exist for backwards
compatability. Users are encouraged to use the most current keyword.

<b>dakota.input.summary:</b>