namespace Dakota {

/** \page MethodCommands Method Commands

\htmlonly
<b>Method Commands Table of Contents</b>
<ul>
<li> <a href="MethodCommands.html#MethodDescr">Method Description</a>
<li> <a href="MethodCommands.html#MethodSpec">Method Specification</a>
<li> <a href="MethodCommands.html#MethodIndControl">
     Method Independent Controls</a>
<li> <a href="MethodCommands.html#MethodMeta">Component-Based Iterator Commands</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodMetaHybrid">Hybrid Minimization</a>
  <li> <a href="MethodCommands.html#MethodMetaMultiStart">Multistart Iteration</a>
  <li> <a href="MethodCommands.html#MethodMetaParetoSet">Pareto Set Minimization</a>
  <li> <a href="MethodCommands.html#MethodSBL">Surrogate-Based Local Minimization</a>
  <li> <a href="MethodCommands.html#MethodSBG">Surrogate-Based Global Minimization</a>
  </ul>
<li> <a href="MethodCommands.html#MethodStd">Standard Iterator Commands</a>
<li> <a href="MethodCommands.html#MethodMin">Minimizer Commands</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodEG">Efficient Global Minimization</a>
  </ul>
<li> <a href="MethodCommands.html#MethodOpt">Optimization Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodDOT">DOT Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodDOTIC">
         DOT method independent controls</a>
    <li> <a href="MethodCommands.html#MethodDOTDC">
         DOT method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodNPSOL">NPSOL Method</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodNPSOLIC">
         NPSOL method independent controls</a>
    <li> <a href="MethodCommands.html#MethodNPSOLDC">
         NPSOL method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodNLPQL">NLPQL Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodNLPQLIC">
         NLPQL method independent controls</a>
    <li> <a href="MethodCommands.html#MethodNLPQLDC">
         NLPQL method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodCONMIN">CONMIN Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodCONMINIC">
         CONMIN method independent controls</a>
    <li> <a href="MethodCommands.html#MethodCONMINDC">
         CONMIN method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodOPTPP">OPT++ Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodOPTPPIC">
         OPT++ method independent controls</a>
    <li> <a href="MethodCommands.html#MethodOPTPPDC">
         OPT++ method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodAPPS">Asynchronous Parallel
       Pattern Search (APPS)</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodAPPSIC">
         APPS method independent controls</a>
    <li> <a href="MethodCommands.html#MethodAPPSDC">
         APPS method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodSCOLIB">SCOLIB Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodSCOLIBIC">
         SCOLIB method independent controls</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBDC">
         SCOLIB method dependent controls</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBCOB">
         Constrained Optimization BY Linear Approximations (COBYLA)</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBDIR">
         DIviding RECTangles (DIRECT)</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBEA">Evolutionary Algorithms</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBPS">Pattern Search</a>
    <li> <a href="MethodCommands.html#MethodSCOLIBSW">Solis-Wets</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodNOMAD">Mesh Adaptive Search (NOMAD)</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodNOMADIC">
          NOMADmethod independent controls</a>
    <li> <a href="MethodCommands.html#MethodNOMADDC">
         NOMAD method dependent controls</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodJEGA">JEGA Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodJEGAIC">
         JEGA method independent controls</a>
    <li> <a href="MethodCommands.html#MethodJEGADC">
         JEGA method dependent controls</a>
    <li> <a href="MethodCommands.html#MethodJEGAMOGA">Multi-Objective Evolutionary Algorithms</a> 
    <li> <a href="MethodCommands.html#MethodJEGASOGA">Single-Objective Evolutionary Algorithms</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodNCSU">NCSU Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodNCSUIC">
         NCSU method independent controls</a>
    <li> <a href="MethodCommands.html#MethodNCSUDC">
         NCSU method dependent controls</a>
    </ul>
  </ul>
<li> <a href="MethodCommands.html#MethodLS">Least Squares Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodLSNL2SOL">NL2SOL Method</a>
  <li> <a href="MethodCommands.html#MethodLSNLSSOL">NLSSOL Method</a>
  <li> <a href="MethodCommands.html#MethodLSGN">Gauss-Newton Method</a>
  </ul>
<li> <a href="MethodCommands.html#MethodNonD">Uncertainty Quantification Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodNonDAleat">Aleatory Uncertainty Quantification Methods</a>
    <ul>
    <li> <a href="MethodCommands.html#MethodNonDMC">Sampling methods</a>
    <li> <a href="MethodCommands.html#MethodNonDLocalRel">Local reliability
	  methods</a>
    <li> <a href="MethodCommands.html#MethodNonDGlobalRel">Global reliability
	  methods</a>
    <li> <a href="MethodCommands.html#MethodNonDImportance">Importance sampling
	  methods</a>
    <li> <a href="MethodCommands.html#MethodNonDAdaptive">Adaptive sampling
	  methods</a>
    <li> <a href="MethodCommands.html#MethodNonDPOFDarts">POF Darts
	  method</a>
    <li> <a href="MethodCommands.html#MethodNonDPCE">
         Polynomial chaos expansion method</a>
    <li> <a href="MethodCommands.html#MethodNonDSC">
         Stochastic collocation method</a>
    </ul>
  <li> <a href="MethodCommands.html#MethodNonDEpist">Epistemic Uncertainty Quantification Methods</a>
    <ul> 
    <li> <a href="MethodCommands.html#MethodNonDLocalIntervalEst">Local Interval Estimation</a>
    <li> <a href="MethodCommands.html#MethodNonDGlobalIntervalEst">Global Interval Estimation</a>
    <li> <a href="MethodCommands.html#MethodNonDLocalEvid">Local Evidence theory (Dempster-Shafer) methods</a>
    <li> <a href="MethodCommands.html#MethodNonDGlobalEvid">Global Evidence theory (Dempster-Shafer) methods</a>
    </ul>
  </ul>
<li> <a href="MethodCommands.html#MethodNonDCalib">Nondeterministic Calibration Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodNonDBayesCalib">Bayesian Calibration Methods</a>
  </ul>
<li> <a href="MethodCommands.html#MethodSoln">Solution Verification Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodSolnRichardson">Richardson Extrapolation</a>
  </ul>
<li> <a href="MethodCommands.html#MethodDACE">Design of Computer Experiments Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodDDACE">DDACE</a>
  <li> <a href="MethodCommands.html#MethodFSUDACE">FSUDace</a>
  <li> <a href="MethodCommands.html#MethodPSUADE">PSUADE</a>
  </ul>
<li> <a href="MethodCommands.html#MethodPS">Parameter Study Methods</a>
  <ul>
  <li> <a href="MethodCommands.html#MethodPSVPS">Vector parameter study</a>
  <li> <a href="MethodCommands.html#MethodPSLPS">List parameter study</a>
  <li> <a href="MethodCommands.html#MethodPSCPS">Centered parameter study</a>
  <li> <a href="MethodCommands.html#MethodPSMPS">
       Multidimensional parameter study</a>
  </ul>
</ul>
\endhtmlonly


\section MethodDescr Method Description


The method section in a %Dakota input file specifies the name and
controls of an iterator. The terms "method" and "iterator" can be used
interchangeably, although method often refers to an input
specification whereas iterator usually refers to an object within the
Iterator hierarchy. A method specification, then, is used to select an
iterator from the iterator hierarchy, which includes standard
iterators for optimization, uncertainty quantification, least squares,
design of experiments, solution verification, and parameter study
methods, as well as advanced multi-component iterators such as hybrid
and multi-start methods, surrogate-based methods, and branch and bound
methods (refer to the Users Manual [\ref UsersMan "Adams et al., 2010"] 
for more information on these iterator branches).

Several examples follow. The first example shows a minimal specification 
for an optimization method, the sequential quadratic programming (SQP) 
algorithm from the DOT library.
\verbatim
method,
	dot_sqp
\endverbatim
This example uses all of the defaults for this method, including binding
to a default model specification.  

A more advanced specification would be
\verbatim
method,
	id_method = 'NLP1'
	model_pointer = 'M1'
	dot_sqp
	  max_iterations = 50
	  convergence_tolerance = 1e-4
	  output verbose
\endverbatim
This example demonstrates the use of identifiers and pointers (see
\ref MethodIndControl) as well as some method independent controls for
\c max_iterations, \c convergence_tolerance, and \c output settings.
These controls are method independent in that they are defined outside
of the method selection blocks within the method specification (see
\ref MethodDOTIC for DOT usage of these controls).

The next example shows a specification for a least squares method.
\verbatim
method,
	optpp_g_newton
	  max_iterations = 10
	  convergence_tolerance = 1.e-8
	  search_method trust_region
	  gradient_tolerance = 1.e-6
\endverbatim
Some of the same method independent controls are present along with
several method dependent controls (\c search_method and \c
gradient_tolerance) which are only meaningful for OPT++ methods (see
\ref MethodOPTPPDC).

The next example shows a specification for a nondeterministic method
with several method dependent controls (refer to \ref MethodNonDMC).
\verbatim
method,
	sampling
	  samples = 100	seed = 12345
	  sample_type lhs
	  response_levels = 1000. 500.
\endverbatim

The next example shows a specification for a parameter study method
where, again, each of the controls are method dependent (refer to \ref
MethodPSVPS).
\verbatim
method,
	vector_parameter_study
	  step_vector = 1. 1. 1.
	  num_steps = 10
\endverbatim

The final three examples show specifications for advanced multi-component 
iterators.  First, a \c hybrid example identifies the sequence of 
sub-methods in a list of pointers to separate method specifications:
\verbatim
method,
	hybrid sequential
	  method_pointer_list = 'GA', 'PS', 'NLP'
\endverbatim

Next, a \c multi_start example specification identifies a single 
sub-method that will be executed ten times from random starting points:
\verbatim
method,
	multi_start
	  method_pointer = 'NLP1'
	  random_starts = 10
\endverbatim

And, finally, a \c surrogate_based_local example specifies trust region
controls and identifies a solver (by \c method_pointer) for the approximate 
subproblems defined by the surrogate model (identified by \c model_pointer):
\verbatim
method,
	id_method = 'SBLO'
	surrogate_based_local
	method_pointer = 'NLP'
	model_pointer  = 'SURROGATE'
	trust_region
	  initial_size = 0.10
	  minimum_size = 1.0e-6
\endverbatim


\section MethodSpec Method Specification


As alluded to in the examples above, the method specification 
has the following structure:
\verbatim
method,
	<method independent controls>
	<method selection>
	  <method dependent controls>
\endverbatim

<!-- TO DO: communicate new method groupings from input spec? -->

where <tt>\<method selection\></tt> is one of the following: \c
hybrid, \c multi_start, \c pareto_set, \c surrogate_based_local, \c
surrogate_based_global, \c dot_frcg, \c dot_mmfd, \c dot_bfgs, \c
dot_slp, \c dot_sqp, \c conmin_frcg, \c conmin_mfd, \c npsol_sqp, \c
nlssol_sqp, \c nlpql_sqp, \c nl2sol, \c nonlinear_cg, \c optpp_cg, \c
optpp_q_newton, \c optpp_fd_newton, \c optpp_g_newton, \c
optpp_newton, \c optpp_pds, \c asynch_pattern_search, \c
coliny_cobyla, \c coliny_direct, \c coliny_pattern_search, \c
coliny_solis_wets, \c coliny_ea, \c moga, \c soga, \c ncsu_direct, \c
efficient_global, \c dl_solver, \c polynomial_chaos, \c
stoch_collocation, \c sampling, \c importance_sampling, \c
adaptive_sampling, \c local_reliability, \c global_reliability, \c
local_evidence, \c global_evidence, \c local_interval_est, \c
global_interval_est, \c bayes_calibration, \c dace, \c fsu_quasi_mc,
\c fsu_cvt, \c psuade_moat, \c vector_parameter_study, \c
list_parameter_study, \c centered_parameter_study, or \c
multidim_parameter_study.

The <tt>\<method independent controls\></tt> are those controls which
are valid for a variety of methods. In some cases, these controls are
abstractions which may have slightly different implementations from
one method to the next. The <tt>\<method dependent controls\></tt> are
those controls which are only meaningful for a specific method or
library. Referring to dakota.input.summary, the method independent
controls are those controls defined externally from and prior to the
method selection blocks. They are all optional. The method selection
blocks are all required group specifications separated by logical
OR's. The method dependent controls are those controls defined within
individual method selection blocks, or within specification groupings
that apply to a set of methods. Defaults for method independent and
method dependent controls are generally defined in DataMethod.cpp,
although some controls employ a non-informative default in DataMethod
that is specialized within the Iterator hierarchy.

Starting with Dakota v6.0, the methods are grouped into two types:
standard methods and multi-component methods.  The former group is
stand-alone and self-contained in the sense that it only requires
access to a model to perform a study.  While methods such as \c
polynomial_chaos and \c efficient_global internally utilize multiple
iterator and surrogate model components, these components are
generally hidden from user control due to restrictions on modularity;
thus, these methods are stand-alone.  The latter multi-component group
of methods provides a higher level "meta-algorithm" that points to
other methods and models that support sub-iteration within the larger
context.  For example, in a sequential hybrid method, the \c hybrid
method specification must identify a list of subordinate methods, and
the "meta-algorithm" executes these methods in sequence and transfers
information between them.  Surrogate-based minimizers provide another
example in that they point both to other methods (e.g. what
optimization method is used to solve the approximate subproblem) as
well as to models (e.g. what type of surrogate model is employed).
Multi-component methods generally provide some level of "plug and
play" modularity, through their flexible support of a variety of
method and model selections.

The following sections provide additional detail on the method
independent controls followed by the method selections and their
corresponding method dependent controls.  Method dependent controls
that are defined for groups of methods are called out in the
documentation, prior to the group of methods to which they apply.


\section MethodIndControl Method Independent Controls


The method independent controls include a method identifier string, a
speculative gradient selection, an output verbosity control, maximum
iteration and function evaluation limits, constraint and convergence
tolerance specifications, a scaling selection, and a number of final
solutions. While each of these controls is not valid for every method,
the controls are valid for enough methods that it was reasonable to
pull them out of the method dependent blocks and consolidate the
specifications.

The method identifier string is supplied with \c id_method and is used
to provide a unique identifier string for use with environment or
meta-iterator specifications (refer to \ref EnvDescr). It is
appropriate to omit a method identifier string if only one method is
included in the input file, since the single method to use is
unambiguous in this case.

When performing gradient-based optimization in parallel, \c
speculative gradients can be selected to address the load imbalance
that can occur between gradient evaluation and line search phases. In
a typical gradient-based optimization, the line search phase consists
primarily of evaluating the objective function and any constraints at
a trial point, and then testing the trial point for a sufficient
decrease in the objective function value and/or constraint
violation. If a sufficient decrease is not observed, then one or more
additional trial points may be attempted sequentially. However, if the
trial point is accepted then the line search phase is complete and the
gradient evaluation phase begins. By speculating that the gradient
information associated with a given line search trial point will be
used later, additional coarse grained parallelism can be introduced by
computing the gradient information (either by finite difference or
analytically) in parallel, at the same time as the line search phase
trial-point function values. This balances the total amount of
computation to be performed at each design point and allows for
efficient utilization of multiple processors. While the total amount
of work performed will generally increase (since some speculative
gradients will not be used when a trial point is rejected in the line
search phase), the run time will usually decrease (since gradient
evaluations needed at the start of each new optimization cycle were
already performed in parallel during the line search phase). Refer to
[\ref Byrd1988 "Byrd et al., 1998"] for additional details. The
speculative specification is implemented for the gradient-based
optimizers in the DOT, CONMIN, and OPT++ libraries, and it can be used
with dakota numerical or analytic gradient selections in the responses
specification (refer to \ref RespGrad for information on these
specifications). It should not be selected with vendor numerical
gradients since vendor internal finite difference algorithms have not
been modified for this purpose. In full-Newton approaches, the Hessian
is also computed speculatively.  NPSOL and NLSSOL do not support
speculative gradients, as their gradient-based line search in
user-supplied gradient mode (dakota numerical or analytic gradients)
is a superior approach for load-balanced parallel execution.

Output verbosity control is specified with \c output followed by \c
silent, \c quiet, \c verbose or \c debug.  If there is no user
specification for output verbosity, then the default setting is \c
normal.  This gives a total of five output levels to manage the volume
of data that is returned to the user during the course of a study,
ranging from full run annotation plus internal debug diagnostics (\c
debug) to the bare minimum of output containing little more than the
total number of simulations performed and the final solution (\c
silent). Output verbosity is observed within the Iterator (algorithm
verbosity), Model (synchronize/fd_gradients verbosity), Interface
(map/synch verbosity), Approximation (global data fit coefficient
reporting),and AnalysisCode (file operation reporting) class
hierarchies; however, not all of these software components observe the
full granularity of verbosity settings.  Specific mappings are as
follows:

\li \c output \c silent (i.e., really quiet):
    silent iterators, silent model, silent interface, quiet approximation,
    quiet file operations
\li \c output \c quiet:
    quiet iterators, quiet model, quiet interface, quiet approximation,
    quiet file operations
\li \c output \c normal:
    normal iterators, normal model, normal interface, quiet approximation,
    quiet file operations
\li \c output \c verbose:
    verbose iterators, normal model, verbose interface, verbose approximation,
    verbose file operations
\li \c output \c debug (i.e., really verbose):
    debug iterators, normal model, debug interface, verbose approximation,
    verbose file operations

Note that iterators and interfaces utilize the full granularity in
verbosity, whereas models, approximations, and file operations do not.
With respect to iterator verbosity, different iterators implement this
control in slightly different ways (as described below in the method
independent controls descriptions for each iterator), however the
meaning is consistent.  For models, interfaces, approximations, and
file operations, \c quiet suppresses parameter and response set
reporting and \c silent further suppresses function evaluation headers
and scheduling output.  Similarly, \c verbose adds file management,
approximation evaluation, and global approximation coefficient
details, and \c debug further adds diagnostics from nonblocking
schedulers.

The \c constraint_tolerance specification determines the maximum
allowable value of infeasibility that any constraint in an
optimization problem may possess and still be considered to be
satisfied. It is specified as a positive real value. If a constraint
function is greater than this value then it is considered to be
violated by the optimization algorithm. This specification gives some
control over how tightly the constraints will be satisfied at
convergence of the algorithm. However, if the value is set too small
the algorithm may terminate with one or more constraints being
violated. This specification is currently meaningful for the NPSOL,
NLSSOL, DOT and CONMIN constrained optimizers (refer to 
\ref MethodDOTIC and \ref MethodNPSOLIC).

The \c convergence_tolerance specification provides a real value for
controlling the termination of iteration. In most cases, it is a
relative convergence tolerance for the objective function; i.e., if
the change in the objective function between successive iterations
divided by the previous objective function is less than the amount
specified by convergence_tolerance, then this convergence criterion is
satisfied on the current iteration. Since no progress may be made on
one iteration followed by significant progress on a subsequent
iteration, some libraries require that the convergence tolerance be
satisfied on two or more consecutive iterations prior to termination
of iteration. This control is used with optimization and least squares
iterators (DOT, CONMIN, NPSOL, NLSSOL, OPT++, and SCOLIB) and is not
used within the uncertainty quantification, design of experiments, or
parameter study iterator branches. Refer to \ref MethodDOTIC, 
\ref MethodNPSOLIC, \ref MethodOPTPPIC, and \ref MethodSCOLIBIC for 
specific interpretations of the \c convergence_tolerance specification.

The \c max_iterations and \c max_function_evaluations controls provide
integer limits for the maximum number of iterations and maximum number
of function evaluations, respectively. The difference between an
iteration and a function evaluation is that a function evaluation
involves a single parameter to response mapping through an interface,
whereas an iteration involves a complete cycle of computation within
the iterator. Thus, an iteration generally involves multiple function
evaluations (e.g., an iteration contains descent direction and line
search computations in gradient-based optimization, population and
multiple offset evaluations in nongradient-based optimization,
etc.). The \c max_function_evaluations control is not currently used
within the uncertainty quantification, design of experiments, and
parameter study iterator branches, and in the case of gradient-based
methods, does not currently capture function evaluations that occur as
part of the \c method_source \c dakota finite difference routine
(since these additional evaluations are intentionally isolated from
the iterators).

The \c final_solutions controls the number of final solutions returned
by the iterator as the best solutions.  For most optimizers, this is
one, but some optimizers can produce multiple solutions (e.g. genetic
algorithms).  In the case of analyzers such as sampling methods, if
one specifies 100 samples (for example) but also specifies \c
final_solutions = 5, the five best solutions (in order of lowest
response function value) are returned.  When using a \c hybrid
meta-iterator, the number of final solutions dictates how many
solutions are passed from one method to another.

Continuous design variable, function, and constraint scaling can be
turned on for optimizers and least squares minimizers by providing the
\c scaling keyword.  Discrete variable scaling is not supported.  When
scaling is enabled, variables, functions, gradients, Hessians, etc.,
are transformed such that the optimizer iterates in scaled variable
space, whereas evaluations of the computational model as specified in
the interface are performed on the original problem scale.  Therefore
using scaling does not require rewriting the interface to the
simulation code. The user may specify no, one, or a vector of scaling
type strings through each of the \c scale_types (see \ref
VarCommands); \c objective_function_scale_types, \c
calibration_term_scale_types, \c nonlinear_inequality_scale_types,
\c nonlinear_equality_scale_types (see \ref RespFn); \c
linear_inequality_scale_types, and \c linear_equality_scale_types (see
\ref MethodIndControl below) specifications.  Valid options for types
include
 <tt>'none'</tt> (default), <tt>'value'</tt>, <tt>'auto'</tt>, or
<tt>'log'</tt>, for no, characteristic value, automatic, or
logarithmic scaling, respectively, although not all types are valid
for scaling all entities (see the references for details).  If a
single string is specified using any of these keywords it will apply
to each component of the relevant vector, e.g., <tt>scale_types =
'value'</tt> will enable characteristic value scaling for each
continuous design variable. The user may specify no, one, or a vector
of nonzero characteristic scale values through each of the \c
scales (see \ref VarCommands); \c objective_function_scales, \c
calibration_term_scales, \c nonlinear_inequality_scales, \c
nonlinear_equality_scales (see \ref RespFn); \c
linear_inequality_scales, and \c linear_equality_scales (see \ref
MethodIndControl below) specifications.  These values are ignored for
scaling type <tt>'none'</tt>, required for <tt>'value'</tt>, and
optional for <tt>'auto'</tt> and <tt>'log'</tt>.  If a single value is
specified using any of these keywords it will apply to each component
of the relevant vector, e.g., <tt>scales = 3.0</tt> will apply a
characteristic scaling value of <tt>3.0</tt> to each continuous design
variable.  When the \c scaling keyword is omitted, all \c
*_scale_types and \c *_scales specifications are ignored in the
method, variables, and responses sections.

When scaling is enabled, the following procedures determine the
transformations used to scale each component of a variables or
response vector.  A warning is issued if scaling would result in
division by a value smaller in magnitude than <tt>1.0e10*DBL_MIN</tt>.
User-provided values violating this lower bound are accepted
unaltered, whereas for automatically calculated scaling, the lower
bound is enforced.

<ul> 
<li> None (<tt>'none'</tt>): no scaling performed (\c *_scales ignored)
on this component

<li> Characteristic value (<tt>'value'</tt>): the corresponding
quantity is scaled by the (required) characteristic value provided in
the \c *_scales specification.  If the scale value is negative, the
sense of inequalities are changed accordingly.

<li> Automatic (<tt>'auto'</tt>): First, any characteristic values
from the optional \c *_scales specification are applied.  Then,
automatic scaling will be attempted according to the following scheme:

  <ul> 
  <li> two-sided bounds scaled into the interval [0,1]; 
  <li> one-sided bound or targets are scaled by the characteristic
value, moving the bound or target to 1 and changing the sense of
inequalities where necessary;
  <li> no bounds or targets: no automatic scaling possible, therefore no 
       scaling for this component 
  </ul> 

Automatic scaling is not available for objective functions nor calibration 
terms since they lack bound constraints.  Futher, when automatically
scaled, linear constraints are scaled by characteristic values only, not
affinely scaled into [0,1].  

<li> Logarithmic (<tt>'log'</tt>): First, any characteristic values from the
optional \c *_scales specification are applied.  Then, logarithm base
10 scaling is applied.  Logarithmic scaling is not available for
linear constraints.  Further, when continuous design variables are log
scaled, linear constraints are not allowed.
</ul>

\ref T5d1 "Table 5.1" provides the specification detail for the method
independent controls involving identifiers, pointers, output
verbosity, speculative gradients, and scaling, and \ref T5d2 "Table 5.2" 
provides the specification detail for the method independent controls 
involving convergence tolerances and iteration limits.

\anchor T5d1
<table>
<caption align = "top">
\htmlonly
Table 5.1
\endhtmlonly
Specification detail for the method independent controls: identifiers, 
pointers, output verbosity, speculative gradients, and scaling
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Method set identifier
<td>\c id_method
<td>string
<td>Optional
<td>environment/meta-iterators employ last method parsed
<tr>
<td>Speculative gradients and Hessians
<td>\c speculative
<td>none
<td>Optional
<td>no speculation
<tr>
<td>Output verbosity
<td>\c output
<td>\c silent | \c quiet | \c normal | \c verbose | \c debug
<td>Optional
<td>\c normal
<tr>
<td>Final solutions
<td>\c final_solutions
<td>integer
<td>Optional
<td>1
<tr>
<td>Scaling flag
<td>\c scaling
<td>none
<td>Optional
<td>no scaling
</table>

\anchor T5d2
<table>
<caption align = "top">
\htmlonly
Table 5.2
\endhtmlonly
Specification detail for the method independent controls: convergence 
tolerances and iteration limits
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Maximum iterations
<td>\c max_iterations
<td>integer
<td>Optional
<td>100 (exceptions: \c fsu_cvt, \c local_reliability: 25;
\c global_{reliability, \c interval_est, \c evidence} / \c efficient_global: 25*n)
<tr>
<td>Maximum function evaluations
<td>\c max_function_evaluations
<td>integer
<td>Optional
<td>1000
<tr>
<td>Constraint tolerance
<td>\c constraint_tolerance
<td>real
<td>Optional
<td>Library default
<tr>
<td>Convergence tolerance
<td>\c convergence_tolerance
<td>real
<td>Optional
<td>1.e-4
</table>


\section MethodMeta Component-Based Iterator Commands


Component-based iterator specifications include hybrid, multi-start,
pareto set, surrogate-based local, surrogate-based global, and branch
and bound methods.  Whereas a standard iterator specification only
needs an optional model pointer string (specified with \c
model_pointer), component-based iterator specifications can include
method pointer, method name, and model pointer specifications in order
to define the components employed in the "meta-iteration."  In
particular, these specifications identify one or more methods (by
pointer or by name) to specify the subordinate iterators that will be
used in the top-level algorithm.  Identifying a sub-iterator by name
instead of by pointer is a lightweight option that relaxes the need
for a separate method specification for the sub-iterator; however, a
model pointer may be required in this case to provide the
specification connectivity normally supported by the method pointer.
Refer to these individual method descriptions for specific
requirements for these advanced methods.

<!-- Hybrid meta-iterators identify sub-iterators and sub-models using
either (a) lists of method pointers or lists of method names with
optional model pointers (sequential and collaborative hybrids), or (b)
global and local method pointers or global and local method names with
optional model pointers (embedded hybrid).  Multi-start and pareto-set
meta-iterators identify a single sub-method either by pointer or name,
with the latter name case supporting an optional model pointer.  The
branch and bound, surrogate-based local, and surrogate-based global
methods support a similar specification in identifying a sub-method by
either pointer or by name and either a required (surrogate-based) or
optional (branch and bound) model pointer.  Each of the method
specifications identified by pointer has the responsibility for
identifying corresponding model specifications (using \c model_pointer
from \ref MethodIndControl), whereas methods identified by name cannot
delegate the need to identify a model by pointer.  -->

\ref T5d3 "Table 5.3" provides general guidance with respect to
identifying methods by pointer or by name and identifying models by
pointer.  Method and model pointers are strings that identify
particular method and model specifications based on their \c id_method
and \c id_model identifier strings, respectively (see \ref
MethodIndControl and \ref ModelIndControl).  These pointer string
identifiers (e.g., 'NLP1' or 'LO_FI_MODEL') are defined by the user
and should \e not be confused with method and model selections (e.g.,
\c dot_mmfd or \c nested).  On the other hand, when identifying a
method name, the string provided should exactly match the method
selection (e.g., 'dot_mmfd'), and an error will result if the method
name provided fails to identify a method that supports lightweight
iterator construction.
\anchor T5d3
<table>
<caption align = "top">
\htmlonly
Table 5.3
\endhtmlonly
Specification detail for meta-iteration and model pointers
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Identification of a sub-method by pointer to a separate specification block
<td>\c method_pointer
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Identification of a sub-method by name (no separate specification block)
<td>\c method_name
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>%Model pointer
<td>\c model_pointer
<td>string
<td>Optional (typical)
<td>method use of last model parsed (or use of default model if none parsed)
</table>

If either a method or model pointer string is specified and no
corresponding id is available, %Dakota will exit with an error
message.  Method identifications by pointer or by name are generally
required specifications without need to define default behaviors.
However, model pointers are often optional.  When a model pointer is
provided, it is responsible for identifying the variables, interface,
and responses specifications (using \c variables_pointer, \c
interface_pointer, and \c responses_pointer from \ref ModelCommands)
that are used to build the model.  If optional model, variables,
interface, or responses pointers are not provided, then these
components will be constructed using the last specification parsed.
If no model pointer string is specified and no model specification is
provided by the user, then a default model specification is used
(similar to the default environment specification, see \ref EnvDescr).
This default model specification is of type \c single with no \c
variables_pointer, \c interface_pointer, or \c responses_pointer (see
\ref ModelSingle).  It is appropriate to omit a model specification
whenever the relationships are unambiguous due to the presence of
single variables, interface, and responses specifications.

An important feature for component-based iterators is that execution
of sub-iterator runs may be performed concurrently.  The \c
iterator_servers, \c processors_per_iterator, and \c
iterator_scheduling specifications provide manual overrides for the
number of concurrent iterator partitions, the size of iterator
partitions, and the scheduling configuration (\c master or \c peer),
respectively, for concurrent iterator jobs.  These settings are
normally determined automatically in the parallel configuration
routines (see ParallelLibrary) but can be overridden with user inputs
if desired.  Currently, \c hybrid, \c multi_start, and \c pareto_set
component-based iterators support concurrency in their sub-iterators.

\anchor T5d4
<table>
<caption align = "top">
\htmlonly
Table 5.4
\endhtmlonly
Specification detail for iterator scheduling controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Number of iterator servers
<td>\c iterator_servers
<td>integer
<td>Optional
<td>no override of auto configure
<tr>
<td>Number of processors per iterator server
<td>\c processors_per_iterator
<td>integer
<td>Optional
<td>no override of auto configure
<tr>
<td>Message passing configuration for scheduling of iterator jobs
<td>\c iterator_scheduling
<td>\c master | \c peer
<td>Optional
<td>no override of auto configure
</table>


\subsection MethodMetaHybrid Hybrid Minimization


In a hybrid minimization approach (\c hybrid), a set of methods
synergistically seek an optimal design.  The relationships among the
methods are categorized as collaborative, embedded, or sequential.
The goal in each case is to exploit the strengths of different
optimization and nonlinear least squares algorithms through different
stages of the minimization process. Global/local hybrids (e.g.,
genetic algorithms combined with nonlinear programming) are a common
example in which the desire for identification of a global optimum is
balanced with the need for efficient navigation to a local optimum.
Hybrid algorithms are implemented within the MetaIterator branch of
the Iterator hierarchy in the CollabHybridMetaIterator,
EmbedHybridMetaIterator, and SeqHybridMetaIterator classes.
Additional information on hybrid algorithm logic is available in the
Users Manual [\ref UsersMan "Adams et al., 2010"].

The hybrid minimization specification has \c sequential,\c embedded, 
and \c collaborative options (see the Users
Manual [\ref UsersMan "Adams et al., 2010"] for more information on
the algorithms employed).  In the sequential approach, the best
solutions are transferred from one method to the next through a
specified sequence.  In the embedded approach, a tightly-coupled
hybrid is employed in which a subordinate local method provides
periodic refinements to a top-level global method.  And in the
collaborative approach, multiple methods work together and share
solutions while executing concurrently.

In the \c sequential approach, a list of method strings supplied with
either the \c method_name_list or the \c method_pointer_list
specification specifies the identity and sequence of iterators to be
used. Any number of iterators may be specified. In the former case of
a list of method names, a \c model_pointer_list may be optionally
supplied.  Method switching is managed through the separate
convergence controls of each method (an adaptive variant has also been
prototyped, but is not active).  The number of solutions
transferred between methods is specified by the particular method
through its \c final_solutions method control.  For example, if one
sets up a two-method approach with a first method that generates
multiple solutions such as a genetic algorithm, followed by a second
method that is initialized only at a single point such as a
gradient-based algorithm, it is possible to take the multiple
solutions generated by the first method and create several instances
of the second method, each one with a different initial starting
point. The logic governing the transfer of multiple solutions between
methods is as follows: if one solution is returned from method A, then
one solution is transferred to method B.  If multiple solutions are
returned from method A, and method B can accept multiple solutions as
input (for example, as a genetic algorithm population), then one
instance of method B is initialized with multiple solutions.  If
multiple solutions are returned from method A but method B only can
accept one initial starting point, then method B is run several times,
each one with a separate starting point from the results of method
A. \ref T5d5 "Table 5.5" summarizes the sequential hybrid
meta-iterator inputs.

\anchor T5d5
<table>
<caption align = "top">
\htmlonly
Table 5.5
\endhtmlonly
Specification detail for sequential hybrid meta-iterators
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Hybrid meta-iterator
<td>\c hybrid
<td>none
<td>Required group (1 of 4 selections)
<td>N/A
<tr>
<td>Sequential hybrid
<td>\c sequential
<td>none
<td>Required group (1 of 3 selections)
<td>N/A
<tr>
<td>%List of method pointers
<td>\c method_pointer_list
<td>list of strings
<td>Required (one of two options)
<td>N/A
<tr>
<td>%List of method names
<td>\c method_name_list
<td>list of strings
<td>Required (one of two options)
<td>N/A
<tr>
<td>%List of model pointers
<td>\c model_pointer_list
<td>list of strings
<td>Optional
<td>methods identified by name reuse last model parsed (or default model if none parsed)
</table>

In the \c embedded approach, global and local method strings supplied
with the \c global_method_pointer and \c local_method_pointer
specifications identify the two methods to be used. As for other
meta-iterators, method pointers can be replaced by method names and
optional model pointers.  The \c local_search_probability setting is
an optional specification for supplying the probability (between 0.0
and 1.0) of employing local search to improve estimates within the
global search. \ref T5d6 "Table 5.6" summarizes the embedded hybrid inputs.

\anchor T5d6
<table>
<caption align = "top">
\htmlonly
Table 5.6
\endhtmlonly
Specification detail for embedded hybrid meta-iterators
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Hybrid meta-iterator
<td>\c hybrid
<td>none
<td>Required group (1 of 4 selections)
<td>N/A
<tr>
<td>Embedded hybrid
<td>\c embedded
<td>none
<td>Required group (1 of 3 selections)
<td>N/A
<tr>
<td>Pointer to the global method specification
<td>\c global_method_pointer
<td>string
<td>Required (one of two options)
<td>N/A
<tr>
<td>Name of the global method
<td>\c global_method_name
<td>string
<td>Required (one of two options)
<td>N/A
<tr>
<td>Pointer to the global model specification
<td>\c global_model_pointer
<td>string
<td>Optional
<td>global method identified by name reuses last model parsed (or default model if none parsed)
<tr>
<td>Pointer to the local method specification
<td>\c local_method_pointer
<td>string
<td>Required
<td>N/A
<tr>
<td>Name of the local method
<td>\c local_method_name
<td>string
<td>Required (one of two options)
<td>N/A
<tr>
<td>Pointer to the local model specification
<td>\c local_model_pointer
<td>string
<td>Optional
<td>local method identified by name reuses last model parsed (or default model if none parsed)
<tr>
<td>Probability of executing local searches
<td>\c local_search_probability
<td>real
<td>Optional
<td>0.1
</table>

In the \c collaborative approach, the specification for \c
method_pointer_list, \c method_name_list, and \c model_pointer_list
are identical to that of the sequential hybrid. The method
collaboration logic follows that of either the Agent-Based
Optimization or HOPSPACK codes and is currently under development.
\ref T5d7 "Table 5.7" summarizes the collaborative hybrid inputs.

\anchor T5d7
<table>
<caption align = "top">
\htmlonly
Table 5.7
\endhtmlonly
Specification detail for collaborative hybrid meta-iterators
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Hybrid meta-iterator
<td>\c hybrid
<td>none
<td>Required group (1 of 4 selections)
<td>N/A
<tr>
<td>Collaborative hybrid
<td>\c collaborative
<td>none
<td>Required group (1 of 3 selections)
<td>N/A
<tr>
<td>%List of method pointers
<td>\c method_pointer_list
<td>list of strings
<td>Required (one of two options)
<td>N/A
<tr>
<td>%List of method names
<td>\c method_name_list
<td>list of strings
<td>Required (one of two options)
<td>N/A
<tr>
<td>%List of model pointers
<td>\c model_pointer_list
<td>list of strings
<td>Optional
<td>methods identified by name reuse last model parsed (or default model if none parsed)
</table>


\subsection MethodMetaMultiStart Multistart Iteration


In the multi-start iteration method (\c multi_start), a series of
iterator runs are performed for different values of parameters in the
model.  A common use is for multi-start optimization (i.e., different
local optimization runs from different starting points for the design
variables), but the concept and the code are more general.
Multi-start iteration is implemented within the MetaIterator branch of
the Iterator hierarchy within the ConcurrentMetaIterator class.
Additional information on the multi-start algorithm is available in
the Users Manual [\ref UsersMan "Adams et al., 2010"].

The \c multi_start meta-iterator must specify a sub-iterator using
either a \c method_pointer or a \c method_name plus optional \c
model_pointer.  This iterator is responsible for completing a series
of iterative analyses from a set of different starting points.  These
starting points can be specified as follows: (1) using \c
random_starts, for which the specified number of starting points are
selected randomly within the variable bounds, (2) using \c
starting_points, in which the starting values are provided in a list,
or (3) using both \c random_starts and \c starting_points, for which
the combined set of points will be used.  In aggregate, at least one
starting point must be specified.  The most common example of a
multi-start algorithm is multi-start optimization, in which a series of
optimizations are performed from different starting values for the
design variables.  This can be an effective approach for problems with
multiple minima.  \ref T5d8 "Table 5.8" summarizes the multi-start inputs.

\anchor T5d8
<table>
<caption align = "top">
\htmlonly
Table 5.8
\endhtmlonly
Specification detail for multi-start meta-iterators
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Multi-start meta-iterator
<td>\c multi_start
<td>none
<td>Required group (1 of 4 selections)
<td>N/A
<tr>
<td>Identification of sub-iterator by pointer
<td>\c method_pointer
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Identification of sub-iterator by name
<td>\c method_name
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Identification of model by pointer
<td>\c model_pointer
<td>string
<td>Optional
<td>method identified by name uses last model parsed (or default model if none parsed)
<tr>
<td>Number of random starting points
<td>\c random_starts
<td>integer
<td>Optional group
<td>no random starting points
<tr>
<td>Seed for random starting points
<td>\c seed
<td>integer
<td>Optional
<td>system-generated seed
<tr>
<td>%List of user-specified starting points
<td>\c starting_points
<td>list of reals
<td>Optional
<td>no user-specified starting points
</table>


\subsection MethodMetaParetoSet Pareto Set Minimization


In the pareto set minimization method (\c pareto_set), a series of
optimization or least squares calibration runs are performed for
different weightings applied to multiple objective functions.  This
set of optimal solutions defines a "Pareto set," which is useful for
investigating design trade-offs between competing objectives.  The
code is similar enough to the \c multi_start technique that both
algorithms are implemented in the same ConcurrentMetaIterator class.

The \c pareto_set specification must identify an optimization or least
squares calibration method using either a \c method_pointer or a \c
method_name plus optional \c model_pointer.  This minimizer is
responsible for computing a set of optimal solutions from a set of
response weightings (multi-objective weights or least squares term
weights).  These weightings can be specified as follows: (1) using \c
random_weight_sets, in which case weightings are selected randomly
within [0,1] bounds, (2) using \c weight_sets, in which the weighting
sets are specified in a list, or (3) using both \c random_weight_sets
and \c weight_sets, for which the combined set of weights will be
used.  In aggregate, at least one set of weights must be specified.
The set of optimal solutions is called the "pareto set," which can
provide valuable design trade-off information when there are competing
objectives.  \ref T5d9 "Table 5.9" summarizes the pareto set inputs.

\anchor T5d9
<table>
<caption align = "top">
\htmlonly
Table 5.9
\endhtmlonly
Specification detail for pareto set meta-iterators
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Pareto set minimization
<td>\c pareto_set
<td>none
<td>Required group (1 of 4 selections)
<td>N/A
<tr>
<td>Identification of minimizer by pointer
<td>\c method_pointer
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Identification of minimizer by name
<td>\c method_name
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Identification of model by pointer
<td>\c model_pointer
<td>string
<td>Optional
<td>minimizer identified by name uses last model parsed (or default model if none parsed)
<tr>
<td>Number of random weighting sets
<td>\c random_weight_sets
<td>integer
<td>Optional
<td>no random weighting sets
<tr>
<td>Seed for random weighting sets
<td>\c seed
<td>integer
<td>Optional
<td>system-generated seed
<tr>
<td>%List of user-specified weighting sets
<td>\c weight_sets
<td>list of reals
<td>Optional
<td>no user-specified weighting sets
</table>


\subsection MethodSBL Surrogate-Based Local Minimization
<!-- dakota subcat surrogate_based_local -->

In surrogate-based optimization (SBO) and surrogate-based nonlinear
least squares (SBNLS), minimization occurs using a set of one or more
approximations, defined from a surrogate model, that are built and
periodically updated using data from a "truth" model. The surrogate
model can be a global data fit (e.g., regression or interpolation of
data generated from a design of computer experiments), a multipoint
approximation, a local Taylor Series expansion, or a model hierarchy
approximation (e.g., a low-fidelity simulation model), whereas the
truth model involves a high-fidelity simulation model.  The goals of
surrogate-based methods are to reduce the total number of truth model
simulations and, in the case of global data fit surrogates, to smooth
noisy data with an easily navigated analytic function.

In the surrogate-based local (SBL) method, a trust region approach is
used to manage the minimization process to maintain acceptable
accuracy between the surrogate model and the truth model (by limiting
the range over which the surrogate model is trusted). The process
involves a sequence of minimizations performed on the surrogate model
and bounded by the trust region. At the end of each approximate
minimization, the candidate optimum point is validated using the truth
model. If sufficient decrease has been obtained in the truth model,
the trust region is re-centered around the candidate optimum point and
the trust region will either shrink, expand, or remain the same size
depending on the accuracy with which the surrogate model predicted the
truth model decrease. If sufficient decrease has not been attained,
the trust region center is not updated and the entire trust region
shrinks by a user-specified factor. The cycle then repeats with the
construction of a new surrogate model, a minimization, and another
test for sufficient decrease in the truth model. This cycle continues
until convergence is attained.

The \c surrogate_based_local method must specify an optimization or
least squares sub-method either by pointer using \c method_pointer
(e.g., 'NLP1') or by name using \c method_name (e.g., 'npsol_sqp'),
where the former identifies a full sub-method specification for the
sub-problem minimizer (allowing non-default minimizer settings) and
the latter supports a streamlined specification (employs default
minimizer settings).  For both cases, a \c model_pointer (see 
\ref MethodIndControl) must also be provided in order to select a 
\c surrogate model (see \ref ModelSurrogate).  Any \c model_pointer
identified within a sub-method specification is ignored.

In addition to the method independent controls for \c max_iterations
and \c convergence_tolerance described in Table \ref T5d1 "5.1", SBL
algorithm controls include \c soft_convergence_limit (a soft
convergence control for the SBL iterations which limits the number of
consecutive iterations with improvement less than the convergence
tolerance) and \c truth_surrogate_bypass (a flag for bypassing all
lower level surrogates when performing truth verifications on a top
level surrogate).  Table \ref T5d10 "5.10" summarizes these SBL
inputs.

\anchor T5d10
<table>
<caption align = "top">
\htmlonly
Table 5.10
\endhtmlonly
Specification detail for surrogate-based local minimization method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Surrogate-based local method
<td>\c surrogate_based_local
<td>none
<td>Required group
<td>N/A
<tr>
<td>Approximate sub-problem minimization method pointer
<td>\c method_pointer
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Approximate sub-problem minimization method name
<td>\c method_name
<td>string
<td>Required (one of two selections)
<td>N/A
<tr>
<td>Surrogate model pointer
<td>\c model_pointer
<td>string
<td>Required
<td>N/A
<tr>
<td>Soft convergence limit for SBL iterations
<td>\c soft_convergence_limit
<td>integer
<td>Optional
<td>5
<tr>
<td>Flag for bypassing lower level surrogates in truth verifications
<td>\c truth_surrogate_bypass
<td>none
<td>Optional
<td>no bypass
</table>

The \c trust_region optional group specification can be used to
specify the initial size of the trust region (using \c initial_size)
relative to the total variable bounds, the minimum size of the trust
region (using \c minimum_size), the contraction factor for the trust
region size (using \c contraction_factor) used when the surrogate
model is performing poorly, and the expansion factor for the trust
region size (using \c expansion_factor) used when the the surrogate
model is performing well. Two additional commands are the trust region
size contraction threshold (using \c contract_threshold) and the trust
region size expansion threshold (using \c expand_threshold).  These
two commands are related to what is called the trust region ratio,
which is the actual decrease in the truth model divided by the
predicted decrease in the truth model in the current trust region. The
command \c contract_threshold sets the minimum acceptable value for
the trust region ratio, i.e., values below this threshold cause the
trust region to shrink for the next SBL iteration. The command \c
expand_threshold determines the trust region value above which the
trust region will expand for the next SBL iteration. Table 
\ref T5d11 "5.11" summarizes these trust region inputs.

\anchor T5d11
<table>
<caption align = "top">
\htmlonly
Table 5.11
\endhtmlonly
Specification detail for trust region controls in surrogate-based 
local methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Trust region group specification
<td>\c trust_region
<td>none
<td>Optional group
<td>N/A
<tr>
<td>Trust region initial size (relative to bounds)
<td>\c initial_size
<td>real
<td>Optional
<td>0.4
<tr>
<td>Trust region minimum size
<td>\c minimum_size
<td>real
<td>Optional
<td>1.e-6
<tr>
<td>Shrink trust region if trust region ratio is below this value
<td>\c contract_threshold
<td>real
<td>Optional
<td>0.25
<tr>
<td>Expand trust region if trust region ratio is above this value
<td>\c expand_threshold
<td>real
<td>Optional
<td>0.75
<tr>
<td>Trust region contraction factor
<td>\c contraction_factor
<td>real
<td>Optional
<td>0.25
<tr>
<td>Trust region expansion factor
<td>\c expansion_factor
<td>real
<td>Optional
<td>2.0
</table>

For SBL problems with nonlinear constraints, a number of algorithm
formulations exist as described in 
[\ref Eldred2006a "Eldred and Dunlavy, 2006"] and as summarized in the
Advanced Examples section of the Models chapter of the Users Manual 
[\ref UsersMan "Adams et al., 2010"].
First, the "primary" functions (that is, the objective functions or
calibration terms) in the approximate subproblem can be selected to
be surrogates of the original primary functions (\c original_primary),
a single objective function (\c single_objective) formed from the
primary function surrogates, or either an augmented Lagrangian merit
function (\c augmented_lagrangian_objective) or a Lagrangian merit
function (\c lagrangian_objective) formed from the primary and
secondary function surrogates.  The former option may imply the use of
a nonlinear least squares method, a multiobjective optimization
method, or a single objective optimization method to solve the
approximate subproblem, depending on the definition of the primary
functions.  The latter three options all imply the use of a single
objective optimization method regardless of primary function
definition.  Second, the surrogate constraints in the approximate
subproblem can be selected to be surrogates of the original
constraints (\c original_constraints) or linearized approximations to
the surrogate constraints (\c linearized_constraints), or constraints
can be omitted from the subproblem (\c no_constraints). Following
optimization of the approximate subproblem, the candidate iterate is
evaluated using a merit function, which can be selected to be a simple
penalty function with penalty ramped by SBL iteration number (\c
penalty_merit), an adaptive penalty function where the penalty ramping
may be accelerated in order to avoid rejecting good iterates which
decrease the constraint violation (\c adaptive_penalty_merit), a
Lagrangian merit function which employs first-order Lagrange
multiplier updates (\c lagrangian_merit), or an augmented Lagrangian
merit function which employs both a penalty parameter and zeroth-order
Lagrange multiplier updates (\c augmented_lagrangian_merit).  When an
augmented Lagrangian is selected for either the subproblem objective
or the merit function (or both), updating of penalties and multipliers
follows the approach described in [\ref Conn2000 "Conn et al., 2000"].
Following calculation of the merit function for the new iterate, the
iterate is accepted or rejected and the trust region size is adjusted
for the next SBL iteration.  Iterate acceptance is governed either by
a trust region ratio (\c tr_ratio) formed from the merit function
values or by a filter method (\c filter); however, trust region
resizing logic is currently based only on the trust region ratio.  For
infeasible iterates, constraint relaxation can be used for balancing
constraint satisfaction and progress made toward an optimum. The
command \c constraint_relax followed by a method name specifies the
type of relaxation to be used. Currently, \c homotopy [\ref Perez2004
"Perez et al., 2004"] is the only available method for constraint
relaxation, and this method is dependent on the presence of the NPSOL
library within the %Dakota executable. Table \ref T5d12 "5.12"
summarizes these constraint management inputs.

\anchor T5d12
<table>
<caption align = "top">
\htmlonly
Table 5.12
\endhtmlonly
Specification detail for constraint management in surrogate-based local methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Approximate subproblem formulation
<td>\c approx_subproblem
<td>\c original_primary | \c single_objective |
\c augmented_lagrangian_objective | \c lagrangian_objective \n
\c original_constraints | \c linearized_constraints | \c no_constraints
<td>Optional group
<td>\c original_primary \n \c original_constraints
<tr>
<td>SBL merit function
<td>\c merit_function
<td>\c penalty_merit | \c adaptive_penalty_merit | \c lagrangian_merit | 
\c augmented_lagrangian_merit
<td>Optional group
<td>\c augmented_lagrangian_merit
<tr>
<td>SBL iterate acceptance logic
<td>\c acceptance_logic
<td>\c tr_ratio | \c filter
<td>Optional group
<td>\c filter
<tr>
<td>SBL constraint relaxation method for infeasible iterates
<td>\c constraint_relax
<td>\c homotopy
<td>Optional group
<td>no relaxation
</table>


\subsection MethodSBG Surrogate-Based Global Minimization
<!-- dakota subcat surrogate_based_global -->

The \c surrogate_based_global method differs from the \c
surrogate_based_local method in a few ways.  First, \c
surrogate_based_global is not a trust region method.  Rather, \c
surrogate_based_global works in an iterative scheme where optimization
is performed on a global surrogate using the same bounds during each
iteration.  In one iteration, the optimal solutions of the surrogate
model are found, and then a selected set of these optimal surrogate
solutions are passed to the next iteration. At the next iteration,
these surrogate points are evaluated with the "truth" model, and then
these points are added back to the set of points upon which the next
surrogate is constructed.  In this way, the optimization acts on a
more accurate surrogate during each iteration, presumably driving to
optimality quickly.  This approach has no guarantee of convergence.
It was originally designed for MOGA (a multi-objective genetic
algorithm).  Since genetic algorithms often need thousands or tens of
thousands of points to produce optimal or near-optimal solutions, the
use of surrogates can be helpful for reducing the truth model
evaluations.  Instead of creating one set of surrogates for the
individual objectives and running the optimization algorithm on the
surrogate once, the idea is to select points along the (surrogate)
Pareto frontier, which can be used to supplement the existing points.
In this way, one does not need to use many points initially to get a
very accurate surrogate.  The surrogate becomes more accurate as the
iterations progress. Note that the user has the option of appending 
the optimal points from the surrogate model to the current set of 
truth points or using the optimal points from the surrogate model 
to replace the optimal set of points from the previous iteration. 
Although appending to the set is the default behavior, at this time 
we strongly recommend using the option \c replace_points because it 
appears to be more accurate and robust.  Finally, the number 
of best solutions that will be passed from one iteration 
to another is governed by the iterator control 
\c final_solutions.  If this is not specified, the 
surrogate-based global method will take all of the 
solutions available (e.g. all of the solutions 
in the Pareto front). 

As for the \c surrogate_based_local method, the \c surrogate_based_global 
specification must identify a sub-method using either \c
method_pointer or \c method_name and must identify a
surrogate model (see \ref ModelSurrogate) using \c model_pointer
(see \ref MethodIndControl).  The only other algorithm control at this
time is the method independent control for \c max_iterations described
in Table \ref T5d1 "5.1".  Table \ref T5d13 "5.13" summarizes the
method dependent surrogate based global inputs.

\anchor T5d13
<table>
<caption align = "top">
\htmlonly
Table 5.13
\endhtmlonly
Specification detail for the surrogate-based global method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Surrogate-based global method
<td>\c surrogate_based_global 
<td>none
<td>Required group
<td>N/A
<tr>
<td>Approximate sub-problem minimization method pointer
<td>\c approx_method_pointer
<td>string
<td>Required (1 of 2 selections)
<td>N/A
<tr>
<td>Approximate sub-problem minimization method name
<td>\c approx_method_name
<td>string
<td>Required (1 of 2 selections)
<td>N/A
<tr>
<td>Replace points used in surrogate construction with best points from previous iteration
<td>\c replace_points 
<td>none
<td>Optional
<td>Points appended, not replaced
</table>

We have two cautionary notes before using the surrogate-based 
global method:

\li One might first try a single minimization method coupled with a
surrogate model prior to using the surrogate-based global method.
This is essentially equivalent to setting \c max_iterations to 1 and
will allow one to get a sense of what surrogate types are the most
accurate to use for the problem.  (Also note that one can specify that
surrogates be built for all primary functions and constraints or for
only a subset of these functions and constraints.  This allows one to
use a "truth" model directly for some of the response functions,
perhaps due to them being much less expensive than other functions.
This is outlined in \ref ModelSurrogate.)

\li We initially recommend a small number of maximum iterations, such
as 3-5, to get a sense of how the optimization is evolving as the
surrogate gets updated.  If it appears to be changing significantly,
then a larger number (used in combination with restart) may be needed.


\section MethodStd Standard Iterator Commands


Standard iterators are stand-alone and self-contained.  As such, they
do not bind with other iterator specifications.  Rather, they contain
a single pointer specification for binding to the model that will be
employed within the iteration.  This pointer is the \c model_pointer
specification from \ref T5d1 "Table 5.1", and it is optional.  Default
behavior when a model pointer is not provided is as described
previously in \ref MethodMeta.


\section MethodMin Minimizer Commands


Optimization and Least Squares methods both fall under the category of
Minimizers (and are inherited from the Minimizer branch of the
Iterator class hierarchy).  This section describes specifications that
are common among Minimizers.

Many of the %Dakota minimization methods can handle constraints.
Nonlinear constraints are specified in the responses section, are
provided by the user's analysis driver, and are documented in \ref
RespFn.  Linear constraints are specified within the method
specification, since they are managed internally by the minimizers
(i.e., the user does not need to supply their values on each driver
execution).

Linear inequality constraints can be supplied with the \c
linear_inequality_constraint_matrix, \c
linear_inequality_lower_bounds, and \c linear_inequality_upper_bounds
specifications, and linear equality constraints can be supplied with
the \c linear_equality_constraint_matrix and \c
linear_equality_targets specifications.  In the inequality case, the
constraint matrix provides coefficients for the variables and the
lower and upper bounds provide constraint limits for the following 
two-sided formulation:
\f[a_l \leq Ax \leq a_u\f]
As with nonlinear inequality constraints (see \ref RespFnOpt), the 
default linear inequality constraint bounds are selected so that 
one-sided inequalities of the form
\f[Ax \leq 0.0\f]
result when there are no user bounds specifications (this provides
backwards compatibility with previous %Dakota versions). In a user
bounds specification, any upper bound values greater than \c
+bigRealBoundSize (1.e+30, as defined in Minimizer) are treated as
+infinity and any lower bound values less than \c -bigRealBoundSize
are treated as -infinity.  This feature is commonly used to drop one
of the bounds in order to specify a 1-sided constraint (just as the
default lower bounds drop out since \c -DBL_MAX < \c
-bigRealBoundSize).  In the equality case, the constraint matrix again
provides coefficients for the variables and the targets provide the
equality constraint right hand sides:
\f[Ax = a_t\f]
and the defaults for the equality constraint targets enforce a value 
of \c 0. for each constraint
\f[Ax = 0.0\f]

Currently, APPS, CONMIN, DOT, JEGA, NLSSOL, NLPQL, NPSOL, OPT++, and 
SCOLIB all support specialized handling of linear constraints (either
directly through the algorithm itself or indirectly through the %Dakota
wrapper).  Linear constraints need not be computed by the user's
interface on every function evaluation; rather the coefficients,
bounds, and targets of the linear constraints can be provided at start
up, allowing the optimizers to track the linear constraints
internally. It is important to recognize that linear constraints are
those constraints that are linear in the \e design variables, e.g.:
\f[0.0 \leq 3x_1 - 4x_2 + 2x_3 \leq 15.0\f]
\f[x_1 + x_2 + x_3 \geq 2.0\f]
\f[x_1 + x_2 - x_3 = 1.0\f]
which is not to be confused with something like 
\f[s(X) - s_{fail} \leq 0.0\f]
where the constraint is linear in a response quantity, but may be a
nonlinear implicit function of the design variables. For the three linear
constraints above, the specification would appear as:
\verbatim
linear_inequality_constraint_matrix =  3.0 -4.0  2.0
                                       1.0  1.0  1.0
linear_inequality_lower_bounds =       0.0  2.0
linear_inequality_upper_bounds =      15.0  1.e+50
linear_equality_constraint_matrix =    1.0  1.0 -1.0
linear_equality_targets =              1.0
\endverbatim
where the <tt>1.e+50</tt> is a dummy upper bound value which defines a
1-sided inequality since it is greater than \c bigRealBoundSize.  The
constraint matrix specifications list the coefficients of the first
constraint followed by the coefficients of the second constraint, and
so on.  They are divided into individual constraints based on the
number of design variables, and can be broken onto multiple lines for
readability as shown above.

The \c linear_inequality_scale_types and \c
linear_equality_scale_types specifications provide strings specifying
the scaling type for each linear inequality or equality constraint,
respectively, in methods that support scaling, when scaling is enabled
(see \ref MethodIndControl for details). Each entry in \c
linear_*_scale_types may be selected from <tt>'none'</tt>,
<tt>'value'</tt>, or <tt>'auto'</tt> to select no, characteristic
value, or automatic scaling, respectively.  If a single string is
specified it will apply to each constraint component. Each entry in \c
linear_inequality_scales or \c linear_equality_scales may be a
user-specified nonzero characteristic value to be used in scaling each
constraint.  These values are ignored for scaling type
<tt>'none'</tt>, required for <tt>'value'</tt>, and optional for
<tt>'auto'</tt>.  If a single real value is specified it will apply to
all components of the constraint.  Scaling for linear constraints is
applied \e after any continuous variable scaling.  For example, for
variable scaling on continuous design variables x: \f[ \tilde{x}^j =
\frac{x^j - x^j_O}{x^j_M} \f] we have the following system for linear
inequality constraints \f[ a_L \leq A_i x \leq a_U \f] \f[ a_L \leq
A_i \left( \mathrm{diag}(x_M) \tilde{x} + x_O \right) \leq a_U \f] \f[
a_L - A_i x_O \leq A_i \mathrm{diag}(x_M) \tilde{x} \leq a_U - A_i x_O
\f] \f[ \tilde{a}_L \leq \tilde{A}_i \tilde{x} \leq \tilde{a}_U \f]
and user-specified or automatically computed scaling multipliers are
appplied to this final transformed system, which accounts for
continuous design variable scaling.  When automatic scaling is in use
for linear constraints they are linearly scaled by a computed
characteristic value, but not affinely to [0,1].

\ref T5d14 "Table 5.14" provides the specification detail for the
method independent controls involving linear constraints.

\anchor T5d14
<table>
<caption align = "top">
\htmlonly
Table 5.14
\endhtmlonly
Specification detail for the method independent controls: linear 
inequality and equality constraints
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Linear inequality coefficient matrix
<td>\c linear_inequality_constraint_matrix
<td>list of reals
<td>Optional
<td>no linear inequality constraints
<tr>
<td>Linear inequality lower bounds
<td>\c linear_inequality_lower_bounds
<td>list of reals
<td>Optional
<td>vector values = \c -DBL_MAX
<tr>
<td>Linear inequality upper bounds
<td>\c linear_inequality_upper_bounds
<td>list of reals
<td>Optional
<td>vector values = \c 0.
<tr>
<td>Linear inequality scaling types
<td>\c linear_inequality_scale_types
<td>list of strings
<td>Optional
<td>vector values = <tt>'none'</tt>
<tr>
<td>Linear inequality scales
<td>\c linear_inequality_scales
<td>list of reals
<td>Optional
<td>vector values = \c 1. (no scaling)
<tr>
<td>Linear equality coefficient matrix
<td>\c linear_equality_constraint_matrix
<td>list of reals
<td>Optional
<td>no linear equality constraints
<tr>
<td>Linear equality targets
<td>\c linear_equality_targets
<td>list of reals
<td>Optional
<td>vector values = \c 0.
<tr>
<td>Linear equality scaling types
<td>\c linear_equality_scale_types
<td>list of strings
<td>Optional
<td>vector values = <tt>'none'</tt>
<tr>
<td>Linear equality scales
<td>\c linear_equality_scales
<td>list of reals
<td>Optional
<td>vector values = \c 1. (no scaling)
</table>

Some methods are natively Minimizers, with support for both
optimization and least squares.  These methods are described in the
following sub-sections.


\subsection MethodEG Efficient Global Minimization
<!-- dakota subcat efficient_global -->

The Efficient Global Optimization (EGO) method was first developed by
Jones, Schonlau, and Welch [\ref Jones1998 "Jones et al., 1998"].  In
EGO, a stochastic response surface approximation for the objective
function is developed based on some sample points from the "true"
simulation.  The particular response surface used is a Gaussian
process (GP).  The GP allows one to calculate the prediction at a new
input location as well as the uncertainty associated with that
prediction.  The key idea in EGO is to maximize the Expected
Improvement Function (EIF).  The EIF is used to select the location at
which a new training point should be added to the Gaussian process
model by maximizing the amount of improvement in the objective
function that can be expected by adding that point. A point could be
expected to produce an improvement in the objective function if its
predicted value is better than the current best solution, or if the
uncertainty in its prediction is such that the probability of it
producing a better solution is high.  Because the uncertainty is
higher in regions of the design space with few observations, this
provides a balance between exploiting areas of the design space that
predict good solutions, and exploring areas where more information is
needed. EGO trades off this "exploitation vs. exploration."  The
general procedure for these EGO-type methods is:

\li Build an initial Gaussian process model of the objective function

\li Find the point that maximizes the EIF.  If the EIF value at this
point is sufficiently small, stop.

\li Evaluate the objective function at the point where the EIF is
maximized.  Update the Gaussian process model using this new point.
Return to the previous step.
 
Note that several major differences exist between our implementation
and that of [\ref Jones1998 "Jones et al., 1998"].  First, rather than
using a branch and bound method to find the point which maximizes the
EIF, we use the DIRECT global optimization method (see \ref
MethodSCOLIBDIR and \ref MethodNCSU).  Second, we support both global
optimization and global nonlinear least squares as well as general
nonlinear constraints through abstraction and subproblem recasting
within the SurrBasedMinimizer and EffGlobalMinimizer classes.

The efficient global minimization algorithm is specified by the
keyword \c efficient_global along with an optional \c seed
specification, as shown in in Table \ref T5d15 "5.15" below.  By
default, EGO uses the Surfpack GP (Kriging) model, but the %Dakota
implementation may be selected instead.  If \c use_derivatives is
specified the GP model will be built using available derivative data
(Surfpack GP only).  The \c import_points_file and \c
export_points_file specifications are as described in \ref ModelSurrG,
(the use of an embedded global surrogate model necessitates repeating
selected surrogate model specifications within the method specification).

\anchor T5d15
<table>
<caption align = "top">
\htmlonly
Table 5.15
\endhtmlonly
Specification detail for the efficient global method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Efficient global method 
<td>\c efficient_global
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>Time based seed: nonrepeatable
<tr>
<td>GP selection
<td>\c gaussian_process
<td>\c surfpack | \c dakota
<td>Optional
<td>Surfpack Gaussian process
<tr>
<td>Derivative usage
<td>\c use_derivatives
<td>none
<td>Optional
<td>Use function values only
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>


\section MethodOpt Optimization Methods


The %Dakota project started as an toolbox for optimization methods,
and has accumulated a broad variety of gradient-based and
nongradient-based optimizers from the DOT, NPSOL, NLPQL, CONMIN,
OPT++, APPS, SCOLIB, NCSU, and JEGA packages.  These capabilities are
described in the following sub-sections.

Since least squares minimization is a special case of general
optimization, all of these optimization methods also support solution
of least squares problems, via an internal recasting performed at the
Optimizer base class that is activated when an optimizer is presented
with \c calibration_terms (see \ref RespFnLS).  Since information is
lost in this transformation, it is not possible to go the other
direction (i.e., to support general optimization within nonlinear
least squares solvers).


\subsection MethodDOT DOT Methods

The DOT library 
[\ref Vrand1995 "Vanderplaats Research and Development, 1995"] 
contains nonlinear programming optimizers, specifically the
Broyden-Fletcher-Goldfarb-Shanno (%Dakota's \c dot_bfgs method) and
Fletcher-Reeves conjugate gradient (%Dakota's \c dot_frcg method)
methods for unconstrained optimization, and the modified method of
feasible directions (%Dakota's \c dot_mmfd method), sequential linear
programming (%Dakota's \c dot_slp method), and sequential quadratic
programming (%Dakota's \c dot_sqp method) methods for constrained
optimization. %Dakota provides access to the DOT library through the
DOTOptimizer class.

We here provide a caution regarding \c dot_frcg.  In DOT
Version 4.20, we have noticed inconsistent behavior of this algorithm
across different versions of Linux.  Our best assessment is that it is
due to different treatments of uninitialized variables.  As we do not
know the intention of the code authors and maintaining DOT source code
is outside of the %Dakota project scope, we have not made nor are we
recommending any code changes to address this.  However, all users who
use \c dot_frcg in DOT Version 4.20 should be aware that
results may not be reliable.

\subsubsection MethodDOTIC DOT method independent controls

The method independent controls for \c max_iterations and \c
max_function_evaluations limit the number of major iterations and the
number of function evaluations that can be performed during a DOT
optimization. The \c convergence_tolerance control defines the
threshold value on relative change in the objective function that
indicates convergence. This convergence criterion must be satisfied
for two consecutive iterations before DOT will terminate. The \c
constraint_tolerance specification defines how tightly constraint
functions are to be satisfied at convergence. The default value for
DOT constrained optimizers is 0.003. Extremely small values for
constraint_tolerance may not be attainable. The output verbosity
specification controls the amount of information generated by DOT: the
\c silent and \c quiet settings result in header information, final
results, and objective function, constraint, and parameter information
on each iteration; whereas the \c verbose and \c debug settings add
additional information on gradients, search direction, one-dimensional
search results, and parameter scaling factors. DOT contains no
parallel algorithms which can directly take advantage of concurrent
evaluations. However, if \c numerical_gradients with \c method_source
\c dakota is specified, then the finite difference function
evaluations can be performed concurrently (using any of the parallel
modes described in the Users Manual [\ref UsersMan "Adams et al., 2010"]). 
In addition, if \c speculative
is specified, then gradients (\c dakota \c numerical or \c analytic
gradients) will be computed on each line search evaluation in order to
balance the load and lower the total run time in parallel optimization
studies. Lastly, specialized handling of linear constraints is
supported with DOT; linear constraint coefficients, bounds, and
targets can be provided to DOT at start-up and tracked
internally. Specification detail for these method independent controls
is provided in Tables \ref T5d1 "5.1" through \ref T5d14 "5.14".


\subsubsection MethodDOTDC DOT method dependent controls

DOT does not currently support any method dependent controls. 


\subsection MethodNPSOL NPSOL Method


The NPSOL library [\ref Gill1986 "Gill et al., 1986"] contains a
sequential quadratic programming (SQP) implementation (the \c
npsol_sqp method). SQP is a nonlinear programming optimizer for
constrained minimization. %Dakota provides access to the NPSOL library
through the NPSOLOptimizer class.


\subsubsection MethodNPSOLIC NPSOL method independent controls

The method independent controls for \c max_iterations and \c
max_function_evaluations limit the number of major SQP iterations and
the number of function evaluations that can be performed during an
NPSOL optimization. The \c convergence_tolerance control defines
NPSOL's internal optimality tolerance which is used in evaluating if
an iterate satisfies the first-order Kuhn-Tucker conditions for a
minimum. The magnitude of \c convergence_tolerance approximately
specifies the number of significant digits of accuracy desired in the
final objective function (e.g., \c convergence_tolerance = \c 1.e-6
will result in approximately six digits of accuracy in the final
objective function). The \c constraint_tolerance control defines how
tightly the constraint functions are satisfied at convergence. The
default value is dependent upon the machine precision of the platform
in use, but is typically on the order of \c 1.e-8 for double precision
computations. Extremely small values for \c constraint_tolerance may
not be attainable. The \c output verbosity setting controls the amount
of information generated at each major SQP iteration: the \c silent
and \c quiet settings result in only one line of diagnostic output for
each major iteration and print the final optimization solution,
whereas the \c verbose and \c debug settings add additional
information on the objective function, constraints, and variables at
each major iteration.

NPSOL is not a parallel algorithm and cannot directly take advantage
of concurrent evaluations. However, if \c numerical_gradients with \c
method_source \c dakota is specified, then the finite difference
function evaluations can be performed concurrently (using any of the
parallel modes described in the Users Manual 
[\ref UsersMan "Adams et al., 2010"]). An important related
observation is the fact that NPSOL uses two different line searches
depending on how gradients are computed. For either \c
analytic_gradients or \c numerical_gradients with \c method_source \c
dakota, NPSOL is placed in user-supplied gradient mode (NPSOL's
"Derivative Level" is set to 3) and it uses a gradient-based line
search (the assumption is that user-supplied gradients are
inexpensive). On the other hand, if \c numerical_gradients are
selected with \c method_source \c vendor, then NPSOL is computing
finite differences internally and it will use a value-based line
search (the assumption is that finite differencing on each line search
evaluation is too expensive). The ramifications of this are: (1)
performance will vary between \c method_source \c dakota and \c
method_source \c vendor for \c numerical_gradients, and (2) gradient
speculation is unnecessary when performing optimization in parallel
since the gradient-based line search in user-supplied gradient mode is
already load balanced for parallel execution. Therefore, a \c
speculative specification will be ignored by NPSOL, and optimization
with numerical gradients should select \c method_source \c dakota for
load balanced parallel operation and \c method_source \c vendor for
efficient serial operation.

Lastly, NPSOL supports specialized handling of linear inequality and
equality constraints. By specifying the coefficients and bounds of the
linear inequality constraints and the coefficients and targets of the
linear equality constraints, this information can be provided to NPSOL
at initialization and tracked internally, removing the need for the
user to provide the values of the linear constraints on every function
evaluation. Refer to \ref MethodIndControl for additional information
and to Tables \ref T5d1 "5.1" through \ref T5d14 "5.14" for method
independent control specification detail.


\subsubsection MethodNPSOLDC NPSOL method dependent controls

NPSOL's method dependent controls are \c verify_level, \c
function_precision, and \c linesearch_tolerance. The \c verify_level
control instructs NPSOL to perform finite difference verifications on
user-supplied gradient components. The \c function_precision control
provides NPSOL an estimate of the accuracy to which the problem
functions can be computed. This is used to prevent NPSOL from trying
to distinguish between function values that differ by less than the
inherent error in the calculation. And the \c linesearch_tolerance
setting controls the accuracy of the line search. The smaller the
value (between 0 and 1), the more accurately NPSOL will attempt to
compute a precise minimum along the search direction. 
\ref T5d16 "Table 5.16" provides the specification detail for the NPSOL 
SQP method and its method dependent controls.

\anchor T5d16
<table>
<caption align = "top">
\htmlonly
Table 5.16
\endhtmlonly
Specification detail for the NPSOL SQP method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Gradient verification level
<td>\c verify_level
<td>integer
<td>Optional
<td>-1 (no gradient verification)
<tr>
<td>Function precision
<td>\c function_precision
<td>real
<td>Optional
<td>1.e-10
<tr>
<td>Line search tolerance
<td>\c linesearch_tolerance
<td>real
<td>Optional
<td>0.9 (inaccurate line search)
</table>


\subsection MethodNLPQL NLPQL Methods


The NLPQL library includes a sequential quadratic programming (SQP)
optimizer, specified as %Dakota's \c nlpql_sqp method, for constrained
optimization. The particular implementation used is NLPQLP [\ref
Schitt2004 "Schittkowski, 2004"], a variant with distributed and
non-monotone line search.  %Dakota provides access to the NLPQL
library through the NLPQLPOptimizer class.


\subsubsection MethodNLPQLIC NLPQL method independent controls

The method independent controls for maximum iterations and output
verbosity are mapped to NLPQL controls MAXIT and IPRINT, respectively.
The maximum number of function evaluations is enforced within the
NLPQLPOptimizer class.


\subsubsection MethodNLPQLDC NLPQL method dependent controls

NLPQL does not currently support any method dependent controls. 


\subsection MethodCONMIN CONMIN Methods


The CONMIN library [\ref Van1973 "Vanderplaats, 1973"] is a public
domain library of nonlinear programming optimizers, specifically the
Fletcher-Reeves conjugate gradient (%Dakota's \c conmin_frcg method)
method for unconstrained optimization, and the method of feasible
directions (%Dakota's \c conmin_mfd method) for constrained
optimization. As CONMIN was a predecessor to the DOT commercial
library, the algorithm controls are very similar.  %Dakota provides
access to the CONMIN library through the CONMINOptimizer class.


\subsubsection MethodCONMINIC CONMIN method independent controls

The interpretations of the method independent controls for CONMIN are
essentially identical to those for DOT.  Therefore, the discussion in
\ref MethodDOTIC is relevant for CONMIN. 


\subsubsection MethodCONMINDC CONMIN method dependent controls

CONMIN does not currently support any method dependent controls. 


\subsection MethodOPTPP OPT++ Methods
<!-- dakota subcat optpp -->

The OPT++ library [\ref MeOlHoWi07 "Meza et al., 2007"] contains primarily
gradient-based nonlinear programming optimizers for unconstrained,
bound-constrained, and nonlinearly constrained minimization:
Polak-Ribiere conjugate gradient (%Dakota's \c optpp_cg method),
quasi-Newton (%Dakota's \c optpp_q_newton method), finite difference
Newton (%Dakota's \c optpp_fd_newton method), and full Newton (%Dakota's
\c optpp_newton method).  The conjugate gradient method is strictly
unconstrained, and each of the Newton-based methods are automatically
bound to the appropriate OPT++ algorithm based on the user constraint
specification (unconstrained, bound-constrained, or
generally-constrained).  In the generally-constrained case, the Newton
methods use a nonlinear interior-point approach to manage the
constraints.  The library also contains a direct search algorithm, PDS
(parallel direct search, %Dakota's \c optpp_pds method), which supports
bound constraints. %Dakota provides access to the OPT++ library through
the SNLLOptimizer class, where "SNLL" denotes Sandia National
Laboratories - Livermore.


\subsubsection MethodOPTPPIC OPT++ method independent controls
<!-- dakota subcat optpp_ic -->

The method independent controls for \c max_iterations and \c
max_function_evaluations limit the number of major iterations and the
number of function evaluations that can be performed during an OPT++
optimization. The \c convergence_tolerance control defines the
threshold value on relative change in the objective function that
indicates convergence. The \c output verbosity specification controls
the amount of information generated from OPT++ executions: the \c debug
setting turns on OPT++'s internal debug mode and also generates
additional debugging information from %Dakota's SNLLOptimizer wrapper
class. OPT++'s gradient-based methods are not parallel algorithms and
cannot directly take advantage of concurrent function
evaluations. However, if \c numerical_gradients with \c method_source
\c dakota is specified, a parallel %Dakota configuration can utilize
concurrent evaluations for the finite difference gradient
computations. OPT++'s nongradient-based PDS method can directly
exploit asynchronous evaluations; however, this capability has not yet
been implemented in the SNLLOptimizer class.

The \c speculative specification enables speculative computation of
gradient and/or Hessian information, where applicable, for parallel
optimization studies.  By speculating that the derivative information
at the current point will be used later, the complete data set (all
available gradient/Hessian information) can be computed on every
function evaluation.  While some of these computations will be wasted,
the positive effects are a consistent parallel load balance and
usually shorter wall clock time.  The \c speculative specification is
applicable only when parallelism in the gradient calculations can be
exploited by %Dakota (it will be ignored for \c vendor \c numerical
gradients).

Lastly, linear constraint specifications are supported by each of the
Newton methods (\c optpp_newton, \c optpp_q_newton, \c optpp_fd_newton,
and \c optpp_g_newton); whereas \c optpp_cg must be unconstrained and
\c optpp_pds can be, at most, bound-constrained. Specification detail 
for the method independent controls is provided in Tables 
\ref T5d1 "5.1" through \ref T5d14 "5.14".


\subsubsection MethodOPTPPDC OPT++ method dependent controls
<!-- dakota subcat optpp_dc -->

OPT++'s method dependent controls are \c max_step, \c
gradient_tolerance, \c search_method, \c merit_function, \c
steplength_to_boundary, \c centering_parameter, and \c
search_scheme_size. The \c max_step control specifies the maximum step
that can be taken when computing a change in the current design point
(e.g., limiting the Newton step computed from current gradient and
Hessian information). It is equivalent to a move limit or a maximum
trust region size. The \c gradient_tolerance control defines the
threshold value on the L2 norm of the objective function gradient that
indicates convergence to an unconstrained minimum (no active
constraints). The \c gradient_tolerance control is defined for all
gradient-based optimizers.

\c max_step and \c gradient_tolerance are the only method dependent
controls for the OPT++ conjugate gradient method.  \ref T5d17 "Table 5.17" 
covers this specification.

\anchor T5d17
<table>
<caption align = "top">
\htmlonly
Table 5.17
\endhtmlonly
Specification detail for the OPT++ conjugate gradient method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>OPT++ conjugate gradient method
<td>\c optpp_cg
<td>none
<td>Required
<td>N/A
<tr>
<td>Maximum step size
<td>\c max_step
<td>real
<td>Optional
<td>1000.
<tr>
<td>Gradient tolerance
<td>\c gradient_tolerance
<td>real
<td>Optional
<td>1.e-4
</table>

The \c search_method control is defined for all Newton-based
optimizers and is used to select between \c trust_region, \c
gradient_based_line_search, and \c value_based_line_search methods.
The \c gradient_based_line_search option uses the line search method
proposed by [\ref More1994 "More and Thuente, 1994"].  This option
satisfies sufficient decrease and curvature conditions; whereas, \c
value_base_line_search only satisfies the sufficient decrease
condition.  At each line search iteration, the \c
gradient_based_line_search method computes the function and gradient
at the trial point.  Consequently, given expensive function
evaluations, the \c value_based_line_search method is preferred to the
\c gradient_based_line_search method. Each of these Newton methods
additionally supports the \c tr_pds selection for unconstrained
problems.  This option performs a robust trust region search using
pattern search techniques.  Use of a line search is the default for
bound-constrained and generally-constrained problems, and use of a \c
trust_region search method is the default for unconstrained problems.

The \c merit_function, \c steplength_to_boundary, and \c
centering_parameter selections are additional specifications that are
defined for the solution of generally-constrained problems with
nonlinear interior-point algorithms.  A \c merit_function is a
function in constrained optimization that attempts to provide joint
progress toward reducing the objective function and satisfying the
constraints.  Valid options are \c el_bakry, \c argaez_tapia, or \c
van_shanno, where user input is not case sensitive in this case.
Details for these selections are as follows:

\li The "el_bakry" merit function is the L2-norm of the first order
optimality conditions for the nonlinear programming problem.  The cost
per linesearch iteration is n+1 function evaluations.  For more
information, see [\ref ElBak1996 "El-Bakry et al., 1996"].
  
\li The "argaez_tapia" merit function can be classified as a modified
augmented Lagrangian function.  The augmented Lagrangian is modified
by adding to its penalty term a potential reduction function to handle
the perturbed complementarity condition.  The cost per linesearch
iteration is one function evaluation.  For more information, see
[\ref Tapia1 "Tapia and Argaez"].

\li The "van_shanno" merit function can be classified as a penalty
function for the logarithmic barrier formulation of the nonlinear
programming problem.  The cost per linesearch iteration is one
function evaluation. For more information see 
[\ref VanShanno1999 "Vanderbei and Shanno, 1999"].

If the function evaluation is expensive or noisy, set the \c
merit_function to "argaez_tapia" or "van_shanno".

<!-- MSE/PDH: option retired on 12/14/2012 as OPT++ hardwires this
     	      internally to match merit_function.
The \c central_path specification represents a measure of proximity to
the central path and specifies an update strategy for the perturbation
parameter mu.  Refer to [\ref Argaez2002 "Argaez et al., 2002"] for a
detailed discussion on proximity measures to the central region. Valid
options are, again, \c el_bakry, \c argaez_tapia, or \c van_shanno.
The default value for \c central_path is the value of \c
merit_function (either user-selected or default). -->

The \c steplength_to_boundary specification is a parameter (between 0
and 1) that controls how close to the boundary of the feasible region
the algorithm is allowed to move.  A value of 1 means that the
algorithm is allowed to take steps that may reach the boundary of the
feasible region.  If the user wishes to maintain strict feasibility of
the design parameters this value should be less than 1.  Default
values are .8, .99995, and .95 for the \c el_bakry, \c argaez_tapia,
and \c van_shanno merit functions, respectively.  The \c
centering_parameter specification is a parameter (between 0 and 1)
that controls how closely the algorithm should follow the 
"central path". See [\ref Wright1 "Wright"] for the definition of central 
path. The larger the value, the more closely the algorithm follows the
central path, which results in small steps. A value of 0 indicates
that the algorithm will take a pure Newton step. Default values are
.2, .2, and .1 for the \c el_bakry, \c argaez_tapia, and \c van_shanno
merit functions, respectively.

\ref T5d18 "Table 5.18" provides the details for the Newton-based methods.

\anchor T5d18
<table>
<caption align = "top">
\htmlonly
Table 5.18
\endhtmlonly
Specification detail for OPT++ Newton-based optimization methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>OPT++ Newton-based methods
<td>\c optpp_q_newton | \c optpp_fd_newton | \c optpp_newton
<td>none
<td>Required group
<td>N/A
<tr>
<td>Search method
<td>\c value_based_line_search | \c gradient_based_line_search | 
\c trust_region | \c tr_pds
<td>none
<td>Optional group
<td>\c trust_region (unconstrained), \c value_based_line_search 
(bound/general constraints)
<tr>
<td>Maximum step size
<td>\c max_step
<td>real
<td>Optional
<td>1000.
<tr>
<td>Gradient tolerance
<td>\c gradient_tolerance
<td>real
<td>Optional
<td>1.e-4
<tr>
<td>Merit function
<td>\c merit_function
<td>\c argaez_tapia, \c el_bakry, or \c van_shanno
<td>Optional
<td>\c argaez_tapia
<tr>
<td>Steplength to boundary
<td>\c steplength_to_boundary
<td>real
<td>Optional
<td>Merit function dependent: 0.8 (el_bakry), 0.99995 (argaez_tapia),
0.95 (van_shanno)
<tr>
<td>Centering parameter
<td>\c centering_parameter
<td>real
<td>Optional
<td>Merit function dependent: 0.2 (el_bakry), 0.2 (argaez_tapia),
0.1 (van_shanno)
</table>

The \c search_scheme_size is defined for the PDS method to specify the
number of points to be used in the direct search template.  PDS does
not support parallelism at this time due to current limitations in the
OPT++ interface.  \ref T5d19 "Table 5.19" provides the detail for the
parallel direct search method.

\anchor T5d19
<table>
<caption align = "top">
\htmlonly
Table 5.19
\endhtmlonly
Specification detail for the OPT++ PDS method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>OPT++ parallel direct search method
<td>\c optpp_pds
<td>none
<td>Required group
<td>N/A
<tr>
<td>Search scheme size
<td>\c search_scheme_size
<td>integer
<td>Optional
<td>32
</table>


\subsection MethodAPPS Asynchronous Parallel Pattern Search (APPS)
<!-- dakota subcat asynch_pattern_search -->

The asynchronous parallel pattern search (APPS) algorithm [\ref GrKo06
"Gray and Kolda, 2006"] is a fully asynchronous pattern search
technique in that the search along each offset direction continues
without waiting for searches along other directions to finish.  It is
now made available in %Dakota through the HOPSPACK software [\ref
Plantenga2009 "Plantenga, 2009"].  It can handle unconstrained
problems as well as those with bound constraints, linear constraints,
and general nonlinear constraints.  HOPSPACK is available to the
public under the GNU LGPL and the source code is included with %Dakota.
HOPSPACK-specific software documentation is available from
https://software.sandia.gov/trac/hopspack.

\subsubsection MethodAPPSIC APPS method independent controls

The only method independent controls that are currently mapped to APPS
are \c max_function_evaluations, \c constraint_tolerance, and the \c
output verbosity control.  We note that while APPS treats the
constraint tolerance separately for linear and nonlinear constraints,
we apply the same value to both if the user specifies \c
constraint_tolerance.  The APPS internal "display" level is mapped to
the %Dakota \c debug, \c verbose, \c normal, \c quiet, and \c silent
settings as follows:

\li %Dakota "debug":   display final solution, all input parameters,
variable and constraint info, trial points, search directions, and
execution details
\li %Dakota "verbose": display final solution, all input parameters,
variable and constraint info, and trial points
\li %Dakota "normal":  display final solution, all input parameters,
variable and constraint summaries, and new best points
\li %Dakota "quiet":   display final solution and all input parameters
\li %Dakota "silent": display final solution

APPS exploits parallelism through the use of %Dakota's concurrent
function evaluations.  The variant of the algorithm that is currently
exposed, however, limits the amount of concurrency that can be
exploited.  In particular, APPS can leverage an evaluation concurrency
level of at most twice the number of variables.  More options that
allow for greater evaluation concurrency may be exposed in future
releases.

\subsubsection MethodAPPSDC APPS method dependent controls

The APPS method is invoked using a \c asynch_pattern_search group
specification.  Some of the method dependent controls are similar to
the SCOLIB controls for \c coliny_pattern_search described in \ref
MethodSCOLIBPS.  In particular, APPS supports the following step
length control parameters:

\li \c initial_delta: the initial step length, must be positive
\li \c threshold_delta: step length used to determine convergence,
must be greater than or equal to 4.4e-16
\li \c contraction_factor: amount by which step length is rescaled
after unsuccesful iterates, must be strictly between 0 and 1

If \c initial_delta is supplied by the user, it will be applied in an
absolute sense in all coordinate directions.  APPS documentation
advocates choosing \c initial_delta to be the approximate distance
from the initial point to the solution.  If this is unknown, it is
advisable to err on the side of choosing an \c initial_delta that is
too large or to not specify it.  In the latter case, APPS will take a
full step to the boundary in each direction.  Relative application of
\c initial_delta is not available unless the user scales the problem
accordingly.

When the solution to the optimization problem is known, the user may
specify a value for \c solution_target as a termination criteria.
APPS will terminate when the function value falls below \c
solution_target.

Currently, APPS only supports coordinate bases with a total of \e 2n
function evaluations in the pattern, and these patterns may only
contract.  The \c synchronization specification can be used to specify
the use of either \c blocking or \c nonblocking schedulers for APPS.
The \c blocking option causes APPS to behave as a synchronous
algorithm.  The \c nonblocking option is not available when %Dakota is
used in message-passing mode.

APPS solves nonlinearly constrained problems by solving a sequence of
linearly constrained merit function-base subproblems.  There are
several exact and smoothed exact penalty functions that can be
specified with the \c merit_function control.  The options are as
follows:

\li \c merit_max: based on \f$ \ell_\infty\f$ norm
\li \c merit_max_smooth: based on smoothed \f$ \ell_\infty\f$ norm
\li \c merit1: based on \f$ \ell_1\f$ norm
\li \c merit1_smooth: based on smoothed \f$ \ell_1\f$ norm
\li \c merit2: based on \f$ \ell_2\f$ norm
\li \c merit2_smooth: based on smoothed \f$ \ell_2\f$ norm
\li \c merit2_squared: based on \f$ \ell_2^2\f$ norm

The user can also specify the following:

\li \c constraint_penalty: the initial multiplier for the penalty
function, must be nonnegative
\li \c smoothing_parameter: initial smoothing value for smoothed
penalty functions, must be between 0 and 1 (inclusive)

\ref T5d20 "Table 5.20" summarizes the APPS specification.

\anchor T5d20
<table>
<caption align = "top">
\htmlonly
Table 5.20
\endhtmlonly
Specification detail for the APPS method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>APPS method
<td>\c asynch_pattern_search
<td>none
<td>Required group
<td>N/A
<tr>
<td>Initial offset value
<td>\c initial_delta
<td>real
<td>Optional
<td>1.0
<tr>
<td>Threshold for offset values
<td>\c threshold_delta
<td>real
<td>Optional
<td>0.01
<tr>
<td>Pattern contraction factor
<td>\c contraction_factor
<td>real
<td>Optional
<td>0.5
<tr>
<td>Solution target
<td>\c solution_target
<td>real
<td>Optional
<td>not used
<tr>
<td>Evaluation synchronization
<td>\c synchronization
<td>\c blocking | \c nonblocking
<td>Optional
<td>\c nonblocking
<tr>
<td>Merit function
<td>\c merit_function
<td>\c merit_max | \c merit_max_smooth | \c merit1 | \c merit1_smooth | 
\c merit2 | \c merit2_smooth | \c merit2_squared
<td>Optional
<td>\c merit2_squared
<tr>
<td>Constraint penalty
<td>\c constraint_penalty
<td>real
<td>Optional
<td>1.0
<tr>
<td>Smoothing factor
<td>\c smoothing_factor
<td>real
<td>Optional
<td>0.0
</table>


\subsection MethodSCOLIB SCOLIB Methods

SCOLIB (formerly known as COLINY) is a collection of nongradient-based
optimizers that support the Common Optimization Library INterface
(COLIN).  SCOLIB optimizers currently include \c coliny_cobyla, \c
coliny_direct, \c coliny_ea, \c coliny_pattern_search and \c
coliny_solis_wets.  (Yes, the input spec still has "coliny" prepended
to the method name.)  Additional SCOLIB information is available from
https://software.sandia.gov/trac/acro.

SCOLIB solvers now support bound constraints and general nonlinear
constraints.  Supported nonlinear constraints include both equality
and two-sided inequality constraints.  SCOLIB solvers do not yet
support linear constraints.  Most SCOLIB optimizers treat constraints
with a simple penalty scheme that adds \c constraint_penalty times the
sum of squares of the constraint violations to the objective function.
Specific exceptions to this method for handling constraint violations
are noted below.  (The default value of \c constraint_penalty is
1000.0, except for methods that dynamically adapt their constraint
penalty, for which the default value is 1.0.)


\subsubsection MethodSCOLIBIC SCOLIB method independent controls

The method independent controls for \c max_iterations and \c
max_function_evaluations limit the number of major iterations and the
number of function evaluations that can be performed during a SCOLIB
optimization, respectively. The \c convergence_tolerance control
defines the threshold value on relative change in the objective
function that indicates convergence. The \c output verbosity
specification controls the amount of information generated by SCOLIB:
the \c silent, \c quiet, and \c normal settings correspond to minimal
reporting from SCOLIB, whereas the \c verbose setting corresponds to a
higher level of information, and \c debug outputs method
initialization and a variety of internal SCOLIB diagnostics.  The
majority of SCOLIB's methods perform independent function evaluations
that can directly take advantage of %Dakota's parallel
capabilities. Only \c coliny_solis_wets, \c coliny_cobyla, and certain
configurations of \c coliny_pattern_search are inherently serial (see
\ref MethodSCOLIBPS). The parallel methods automatically utilize
parallel logic when the %Dakota configuration supports
parallelism. Lastly, neither \c speculative gradients nor linear
constraints are currently supported with SCOLIB.  Specification detail
for method independent controls is provided in Tables \ref T5d1 "5.1"
through \ref T5d14 "5.14".

Some SCOLIB methods exploit parallelism through the use of %Dakota's
concurrent function evaluations.  The nature of the algorithms,
however, limits the amount of concurrency that can be exploited.  The
maximum amount of evaluation concurrency that can be leveraged by the
various methods is as follows:

\li COBYLA: one
\li DIRECT: twice the number of variables
\li Evolutionary Algorithms: size of the population
\li Pattern Search: size of the search pattern
\li Solis-Wets: one

\subsubsection MethodSCOLIBDC SCOLIB method dependent controls

All SCOLIB methods support the \c show_misc_options optional
specification which results in a dump of all the allowable method
inputs.  Note that the information provided by this command refers to
optimizer parameters that are internal to SCOLIB, and which may differ
from corresponding parameters used by the %Dakota interface.  The \c
misc_options optional specification provides a means for inputing
additional settings supported by the SCOLIB methods but which are not
currently mapped through the %Dakota input specification. Care must be
taken in using this specification; they should only be employed by
users familiar with the full range of parameter specifications
available directly from SCOLIB and understand any differences that
exist between those specifications and the ones available through
%Dakota.

Each of the SCOLIB methods supports the \c solution_target control,
which defines a convergence criterion in which the optimizer will
terminate if it finds an objective function value lower than the
specified target.  Specification detail for method dependent
controls for all SCOLIB methods is provided in Table \ref T5d21 "5.21".

\anchor T5d21
<table>
<caption align = "top">
\htmlonly
Table 5.21
\endhtmlonly
Specification detail for SCOLIB method dependent controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Show miscellaneous options
<td>\c show_misc_options
<td>none
<td>Optional
<td>no dump of specification options
<tr>
<td>Specify miscellaneous options
<td>\c misc_options
<td>list of strings
<td>Optional
<td>no miscellaneous options specified
<tr>
<td>Desired solution target
<td>\c solution_target
<td>real
<td>Optional
<td>\c -DBL_MAX
</table>

Each SCOLIB method supplements the settings of \ref T5d21 "Table 5.21"
with controls which are specific to its particular class of method.


\subsubsection MethodSCOLIBCOB COBYLA
<!-- dakota subcat coliny_cobyla -->

The Constrained Optimization BY Linear Approximations (COBYLA)
algorithm is an extension to the Nelder-Mead simplex algorithm for
handling general linear/nonlinear constraints and is invoked using the
\c coliny_cobyla group specification.  The COBYLA algorithm employs
linear approximations to the objective and constraint functions, the
approximations being formed by linear interpolation at N+1 points in
the space of the variables.  We regard these interpolation points as
vertices of a simplex. The step length parameter controls the size of
the simplex and it is reduced automatically from \c initial_delta to
\c threshold_delta.  One advantage that COBYLA has over many of its
competitors is that it treats each constraint individually when
calculating a change to the variables, instead of lumping the
constraints together into a single penalty function.

COBYLA currently only supports termination based on the \c
max_function_evaluations and \c solution_target specifications.  The
search performed by COBYLA is currently not parallelized.

\ref T5d22 "Table 5.22" summarizes the COBYLA specification.

\anchor T5d22
<table>
<caption align = "top">
\htmlonly
Table 5.22
\endhtmlonly
Specification detail for the COBYLA method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>COBYLA method
<td>\c coliny_cobyla
<td>none
<td>Required group
<td>N/A
<tr>
<td>Initial offset value
<td>\c initial_delta
<td>real
<td>Optional
<td>1.0
<tr>
<td>Threshold for offset values
<td>\c threshold_delta
<td>real
<td>Optional
<td>0.0001
</table>


\subsubsection MethodSCOLIBDIR DIRECT
<!-- dakota subcat coliny_direct -->

The DIviding RECTangles (DIRECT) optimization algorithm is a
derivative free global optimization method that balances local search
in promising regions of the design space with global search in
unexplored regions.  As shown in Figure 5.1, DIRECT adaptively
subdivides the space of feasible design points so as to guarantee that
iterates are generated in the neighborhood of a global minimum in
finitely many iterations.

\image html  direct1.jpg "Figure 5.1 Design space partitioning with DIRECT"
\image latex direct1.eps "Design space partitioning with DIRECT" width=10cm

In practice, DIRECT has proven an effective heuristic for engineering
design applications, for which it is able to quickly identify
candidate solutions that can be further refined with fast local
optimizers.

DIRECT uses the \c solution_target, \c constraint_penalty and
\c show_misc_options specifications that are described in
\ref MethodSCOLIBDC.  Note, however, that DIRECT uses a fixed
penalty value for constraint violations (i.e. it is not dynamically
adapted as is done in \c coliny_pattern_search).

The \c division specification determines how DIRECT subdivides 
each subregion of the search space.  If \c division is set to 
\c major_dimension, then the dimension representing the longest edge
of the subregion is subdivided (this is the default).  If \c division
is set to \c all_dimensions, then all dimensions are simultaneously 
subdivided.

Each subregion considered by DIRECT has a \b size, which corresponds to
the longest diagonal of the subregion.  The \c global_balance_parameter
controls how much global search is performed by only allowing a
subregion to be subdivided if the size of the subregion divided by the
size of the largest subregion is at least \c global_balance_parameter.
Intuitively, this forces large subregions to be subdivided before the
smallest subregions are refined.  The \c local_balance_parameter provides
a tolerance for estimating whether the smallest subregion can provide
a sufficient decrease to be worth subdividing;  the default value is a
small value that is suitable for most applications.

DIRECT can be terminated with the standard \c max_function_evaluations
and \c solution_target specifications.  Additionally, the \c
max_boxsize_limit specification terminates DIRECT if the size of the
largest subregion falls below this threshold, and the \c min_boxsize_limit
specification terminates DIRECT if the size of the smallest subregion
falls below this threshold.  In practice, this latter specification is
likely to be more effective at limiting DIRECT's search.

\ref T5d23 "Table 5.23" summarizes the DIRECT specification.

\anchor T5d23
<table>
<caption align = "top">
\htmlonly
Table 5.23
\endhtmlonly
Specification detail for the DIRECT method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>DIRECT method
<td>\c coliny_direct
<td>none
<td>Required group
<td>N/A
<tr>
<td>Box subdivision approach
<td>\c division
<td>\c major_dimension | \c all_dimensions
<td>Optional group
<td>\c major_dimension
<tr>
<td>Global search balancing parameter
<td>\c global_balance_parameter
<td>real
<td>Optional
<td>0.0
<tr>
<td>Local search balancing parameter
<td>\c local_balance_parameter
<td>real
<td>Optional
<td>1.e-8
<tr>
<td>Maximum boxsize limit
<td>\c max_boxsize_limit
<td>real
<td>Optional
<td>0.0
<tr>
<td>Minimum boxsize limit
<td>\c min_boxsize_limit
<td>real
<td>Optional
<td>0.0001
<tr>
<td>Constraint penalty
<td>\c constraint_penalty
<td>real
<td>Optional
<td>1000.0
</table>


\subsubsection MethodSCOLIBEA Evolutionary Algorithms
<!-- dakota subcat coliny_ea -->

%Dakota currently provides several variants of evolutionary algorithms,
invoked through the \c coliny_ea group specification.

The basic steps of an evolutionary algorithm are depicted in Figure
5.2.

\image html  ga.jpg "Figure 5.2 Depiction of evolutionary algorithm"
\image latex ga.eps "Depiction of evolutionary algorithm" width=10cm

They can be enumerated as follows:
<ol>
<li> Select an initial population randomly and perform function 
evaluations on these individuals
<li> Perform selection for parents based on relative fitness
<li> Apply crossover and mutation to generate \c 
new_solutions_generated new individuals from the selected parents
     <ul>
     <li> Apply crossover with a fixed probability from two 
     selected parents
     <li> If crossover is applied, apply mutation to the newly 
     generated individual with a fixed probability
     <li> If crossover is not applied, apply mutation with a fixed
     probability to a single selected parent
     </ul>
<li> Perform function evaluations on the new individuals
<li> Perform replacement to determine the new population
<li> Return to step 2 and continue the algorithm until convergence
criteria are satisfied or iteration limits are exceeded
</ol>

\ref T5d24 "Table 5.24" provides the specification detail for the
controls for seeding the method, initializing a population, and for
selecting and replacing population members.

\anchor T5d24
<table>
<caption align = "top">
\htmlonly
Table 5.24
\endhtmlonly
Specification detail for the SCOLIB EA method dependent controls: 
seed, initialization, selection, and replacement
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>EA selection
<td>\c coliny_ea
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Number of population members
<td>\c population_size
<td>integer
<td>Optional
<td>50
<tr>
<td>Initialization type
<td>\c initialization_type
<td>\c simple_random | \c unique_random | \c flat_file
<td>Required 
<td>\c unique_random
<tr>
<td>Fitness type
<td>\c fitness_type
<td>\c linear_rank | \c merit_function
<td>Optional
<td>\c linear_rank
<tr>
<td>Replacement type
<td>\c replacement_type
<td>\c random | \c chc | \c elitist
<td>Optional group
<td>\c elitist = \c 1
<tr>
<td>Random replacement type
<td>\c random
<td>integer
<td>Required
<td>N/A
<tr>
<td>CHC replacement type
<td>\c chc
<td>integer
<td>Required
<td>N/A
<tr>
<td>Elitist replacement type
<td>\c elitist
<td>integer
<td>Required
<td>N/A
<tr>
<td>New solutions generated
<td>\c new_solutions_generated
<td>integer
<td>Optional
<td>\c population_size - \c replacement_size
</table>

The random \c seed control provides a mechanism for making a
stochastic optimization repeatable. That is, the use of the same
random seed in identical studies will generate identical results. The
\c population_size control specifies how many individuals will
comprise the EA's population. 

The \c initialization_type defines the type of initialization for the
population of the EA.  There are three types: \c simple_random, \c
unique_random, and \c flat_file.  \c simple_random creates initial
solutions with random variable values according to a uniform random
number distribution. It gives no consideration to any previously
generated designs.  The number of designs is specified by the \c
population_size. \c unique_random is the same as \c simple_random,
except that when a new solution is generated, it is checked against
the rest of the solutions.  If it duplicates any of them, it is
rejected.  \c flat_file allows the initial population to be read from
a flat file.  If \c flat_file is specified, a file name must be given.

The \c fitness_type controls how strongly differences in "fitness"
(i.e., the objective function) are weighted in the process of
selecting "parents" for crossover:

\li the \c linear_rank setting uses a linear scaling of probability of
selection based on the rank order of each individual's objective
function within the population

\li the \c merit_function setting uses a proportional scaling of
probability of selection based on the relative value of each
individual's objective function within the population

The \c replacement_type controls how current populations and newly
generated individuals are combined to create a new population.  Each
of the \c replacement_type selections accepts an integer value, which
is referred to below and in \ref T5d24 "Table 5.24" as the \c
replacement_size:

\li The \c random setting creates a new population using
(a) \c replacement_size randomly selected individuals from the current
population, and (b) \c population_size - \c replacement_size
individuals randomly selected from among the newly generated
individuals (the number of which is optionally specified using \c
new_solutions_generated) that are created for each generation (using
the selection, crossover, and mutation procedures).

\li The \c chc setting creates a new population using (a) the \c
replacement_size best individuals from the \e combination of the
current population and the newly generated individuals, and (b) \c
population_size - \c replacement_size individuals randomly selected
from among the remaining individuals in this combined pool.  The \c
chc setting is the preferred selection for many engineering problems.

\li The \c elitist (default) setting creates a new population using
(a) the \c replacement_size best individuals from the current
population, (b) and \c population_size - \c replacement_size
individuals randomly selected from the newly generated individuals.
It is possible in this case to lose a good solution from the newly
generated individuals if it is not randomly selected for replacement;
however, the default \c new_solutions_generated value is set such that
the entire set of newly generated individuals will be selected for
replacement.

Note that \c new_solutions_generated is not recognized by %Dakota as a
valid keyword unless \c replacement_type has been specified.

\ref T5d25 "Table 5.25" show the controls in the EA method associated
with crossover and mutation.

\anchor T5d25
<table>
<caption align = "top">
\htmlonly
Table 5.25
\endhtmlonly
Specification detail for the SCOLIB EA method: crossover and mutation
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Crossover type
<td>\c crossover_type
<td>\c two_point | \c blend | \c uniform
<td>Optional group
<td>\c two_point
<tr>
<td>Crossover rate
<td>\c crossover_rate
<td>real
<td>Optional
<td>0.8
<tr>
<td>Mutation type
<td>\c mutation_type
<td>\c replace_uniform | \c offset_normal | \c offset_cauchy | \c offset_uniform
<td>Optional group
<td>\c offset_normal
<tr>
<td>Mutation scale
<td>\c mutation_scale
<td>real
<td>Optional
<td>0.1
<tr>
<td>Mutation range
<td>\c mutation_range
<td>integer
<td>Optional
<td>1
<tr>
<td>Mutation dimension ratio
<td>\c dimension_ratio
<td>real
<td>Optional
<td>1.0
<tr>
<td>Mutation rate
<td>\c mutation_rate
<td>real
<td>Optional
<td>1.0
<tr>
<td>Non-adaptive mutation flag
<td>\c non_adaptive
<td>none
<td>Optional
<td>Adaptive mutation
</table>

The \c crossover_type controls what approach is employed for combining
parent genetic information to create offspring, and the \c
crossover_rate specifies the probability of a crossover operation
being performed to generate a new offspring.  The SCOLIB EA method
supports three forms of crossover, \c two_point, \c blend, and \c
uniform, which generate a new individual through combinations of two
parent individuals.  Two-point crossover divides each parent into
three regions, where offspring are created from the combination of the
middle region from one parent and the end regions from the other
parent.  Since the SCOLIB EA does not utilize bit representations of
variable values, the crossover points only occur on coordinate
boundaries, never within the bits of a particular coordinate.  Uniform
crossover creates offspring through random combination of coordinates
from the two parents.  Blend crossover generates a new individual
randomly along the multidimensional vector connecting the two parents.

The \c mutation_type controls what approach is employed in randomly
modifying continuous design variables within the EA population.  Each
of the mutation methods generates coordinate-wise changes to
individuals, usually by adding a random variable to a given coordinate
value (an "offset" mutation), but also by replacing a given coordinate
value with a random variable (a "replace" mutation).  Discrete design
variables are always mutated using the \c offset_uniform method. The
\c mutation_rate controls the probability of mutation being performed
on an individual, both for new individuals generated by crossover (if
crossover occurs) and for individuals from the existing population.
It is the fraction of trial points that are mutated in a given
iteration and therefore must be specified to be between 0 and 1.  When
mutation is performed, all dimensions of each individual are mutated.
The \c mutation_scale specifies a scale factor which scales continuous
mutation offsets; this is a fraction of the total range of each
dimension, so \c mutation_scale is a relative value between 0 and 1.
The \c mutation_range is used to control \c offset_uniform mutation
used for discrete parameters.  The replacement discrete value is the
original value plus or minus an integer value up to \c mutation_range.
The \c offset_normal, \c offset_cauchy, and \c offset_uniform mutation
types are "offset" mutations in that they add a 0-mean random variable
with a normal, cauchy, or uniform distribution, respectively, to the
existing coordinate value.  These offsets are limited in magnitude by
\c mutation_scale.  The \c replace_uniform mutation type is not
limited by \c mutation_scale; rather it generates a replacement value
for a coordinate using a uniformly distributed value over the total
range for that coordinate.

Note that \c mutation_scale and \c mutation_range are not recognized
by %Dakota as valid keywords unless \c mutation_type has been
specified and the type is an "offset" mutations.

The SCOLIB EA method uses self-adaptive mutation, which modifies the mutation
scale dynamically.  This mechanism is borrowed from EAs like 
evolution strategies.  The \c non_adaptive flag can be used to deactivate
the self-adaptation, which may facilitate a more global search.  

Note that \c non_adaptive is not recognized by %Dakota as a valid
keyword unless \c mutation_type has been specified.


\subsubsection MethodSCOLIBPS Pattern Search
<!-- dakota subcat coliny_pattern_search -->

Pattern search techniques are nongradient-based optimization methods
which use a set of offsets from the current iterate to locate improved
points in the design space.  The SCOLIB pattern search technique is
invoked using a \c coliny_pattern_search group specification, which
includes a variety of specification components.

Traditional pattern search methods search with a fixed pattern of
search directions to try to find improvements to the current iterate.
The SCOLIB pattern search methods generalize this simple algorithmic
strategy to enable control of how the search pattern is adapted, as
well as how each search pattern is evaluated.  The \c stochastic and
\c synchronization specifications denote how the the trial points are
evaluated.  The \c stochastic specification indicates that the trial
points are considered in a random order.  For parallel pattern search,
\c synchronization dictates whether the evaluations are scheduled
using a \c blocking scheduler or a \c nonblocking scheduler (i.e.,
\ref Model::synchronize "Model::synchronize()" or \ref
Model::synchronize_nowait "Model::synchronize_nowait()",
respectively).  In the \c blocking case, all points in the pattern are
evaluated (in parallel), and if the best of these trial points is an
improving point, then it becomes the next iterate.  These runs are
reproducible, assuming use of the same seed in the \c stochastic case.
In the \c nonblocking case, all points in the pattern may not be
evaluated, since the first improving point found becomes the next
iterate.  Since the algorithm steps will be subject to parallel timing
variabilities, these runs will not generally be repeatable.  The \c
synchronization specification has similar connotations for sequential
pattern search.  If \c blocking is specified, then each sequential
iteration terminates after all trial points have been considered, and
if \c nonblocking is specified, then each sequential iteration
terminates after the first improving trial point is evaluated.  In
this release, both \c blocking and \c nonblocking specifications
result in blocking behavior (except in the case where \c
exporatory_moves below is set to \c adaptive_pattern).  Nonblocking
behavior will be re-enabled after some underlying technical issues
have been resolved.

The particular form of the search pattern is controlled by the \c
pattern_basis specification.  If \c pattern_basis is \c coordinate
basis, then the pattern search uses a plus and minus offset in each
coordinate direction, for a total of \e 2n function evaluations in the
pattern.  This case is depicted in Figure 5.3 for three coordinate
dimensions.

\image html  pattern_search.jpg "Figure 5.3 Depiction of coordinate pattern search algorithm"
\image latex pattern_search.eps "Depiction of coordinate pattern search algorithm" width=10cm

If \c pattern_basis is \c simplex, then pattern search uses
a minimal positive basis simplex for the parameter space, for a total
of \e n+1 function evaluations in the pattern.  Note that the \c
simplex pattern basis can be used for unbounded problems only.  The \c
total_pattern_size specification can be used to augment the basic \c
coordinate and \c simplex patterns with additional function
evaluations, and is particularly useful for parallel load balancing.
For example, if some function evaluations in the pattern are dropped
due to duplication or bound constraint interaction, then the \c
total_pattern_size specification instructs the algorithm to generate
new offsets to bring the total number of evaluations up to this
consistent total.

The \c exploratory_moves specification controls how the 
search pattern is adapted. (The search pattern can be adapted after 
an improving trial point is found, or after all trial points in 
a search pattern have been found to be unimproving points.) 
The following exploratory moves selections are supported
by SCOLIB:

\li The \c basic_pattern case is the simple pattern search 
approach, which uses the same pattern in each iteration.

\li The \c multi_step case examines each trial step in the pattern in
turn.  If a successful step is found, the pattern search continues
examining trial steps about this new point.  In this manner, the
effects of multiple successful steps are cumulative within a single
iteration.  This option
does not support any parallelism and will result in a serial pattern
search.

\li The \c adaptive_pattern case invokes a pattern search technique
that adaptively rescales the different search directions to maximize
the number of redundant function evaluations.  See 
[\ref Hart2001c "Hart et al., 2001"] for details of this method.  
In preliminary experiments, this method had more robust performance
than the standard \c basic_pattern case in serial tests.  
This option supports a limited degree of parallelism.  After successful
iterations (where the step length is not contracted),
a parallel search will be performed.  After unsuccessful
iterations (where the step length is contracted), only a single
evaluation is performed.

The \c initial_delta and \c threshold_delta specifications provide the
initial offset size and the threshold size at which to terminate the
algorithm.  For any dimension that has both upper and lower bounds,
this step length will be internally rescaled to provide search steps
of length \c initial_delta * range * 0.1.  This rescaling does not
occur for other dimensions, so search steps in those directions have
length \c initial_delta.  Note that the factor of 0.1 in the rescaling
could result in an undesirably small initial step.  This can be offset
by providing a large \c initial_delta.

In general, pattern search methods can expand and contract their step
lengths.  SCOLIB pattern search methods contract the step length by the
value \c contraction_factor, and they expand the step length by the value
(1/contraction_factor).  The \c expand_after_success control specifies
how many successful objective function improvements must occur with a
specific step length prior to expansion of the step length, whereas the
\c no_expansion flag instructs the algorithm to forgo pattern expansion
altogether.

Finally, constraint infeasibility can be managed in a somewhat more
sophisticated manner than the simple weighted penalty function.  If
the \c constant_penalty specification is used, then the simple
weighted penalty scheme described above is used.  Otherwise, the
constraint penalty is adapted to the value \c constraint_penalty/L,
where L is the the smallest step length used so far.

\ref T5d26 "Table 5.26" and \ref T5d27 "Table 5.27" provide the 
specification detail for the SCOLIB pattern search method and its 
method dependent controls.

\anchor T5d26
<table>
<caption align = "top">
\htmlonly
Table 5.26
\endhtmlonly
Specification detail for the SCOLIB pattern search method: randomization,
delta, and constraint controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>SCOLIB pattern search method
<td>\c coliny_pattern_search
<td>none
<td>Required group
<td>N/A
<tr>
<td>Stochastic pattern search
<td>\c stochastic
<td>none
<td>Optional group
<td>N/A
<tr>
<td>Random seed for stochastic pattern search
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Initial offset value
<td>\c initial_delta
<td>real
<td>Optional
<td>0.1*range
<tr>
<td>Threshold for offset values
<td>\c threshold_delta
<td>real
<td>Optional
<td>0.00001
<tr>
<td>Constraint penalty
<td>\c constraint_penalty
<td>real
<td>Optional
<td>1.0
<tr>
<td>Control of dynamic penalty
<td>\c constant_penalty
<td>none
<td>Optional
<td>algorithm dynamically adapts the constraint penalty
</table>

\anchor T5d27
<table>
<caption align = "top">
\htmlonly
Table 5.27
\endhtmlonly
Specification detail for the SCOLIB pattern search method: pattern controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Pattern basis selection
<td>\c pattern_basis
<td>coordinate | simplex
<td>Optional
<td>\c coordinate
<tr>
<td>Total number of points in pattern
<td>\c total_pattern_size
<td>integer
<td>Optional
<td>no augmentation of basic pattern
<tr>
<td>No expansion flag
<td>\c no_expansion
<td>none
<td>Optional
<td>algorithm may expand pattern size
<tr>
<td>Number of consecutive improvements before expansion
<td>\c expand_after_success
<td>integer
<td>Optional
<td>5
<tr>
<td>Pattern contraction factor
<td>\c contraction_factor
<td>real
<td>Optional
<td>0.5
<tr>
<td>Evaluation synchronization
<td>\c synchronization
<td>\c blocking | \c nonblocking
<td>Optional
<td>\c nonblocking
<tr>
<td>Exploratory moves selection
<td>\c exploratory_moves
<td>\c basic_pattern | \c multi_step | \c adaptive_pattern
<td>Optional
<td>\c basic_pattern 
</table>


\subsubsection MethodSCOLIBSW Solis-Wets

%Dakota's implementation of SCOLIB also contains the Solis-Wets
algorithm. The Solis-Wets method is a simple greedy local search
heuristic for continuous parameter spaces.  Solis-Wets generates trial
points using a multivariate normal distribution, and unsuccessful
trial points are reflected about the current point to find a descent
direction.  This algorithm is inherently serial and will not utilize
any parallelism.  \ref T5d28 "Table 5.28" provides the specification  
detail for this method and its method dependent controls.

\anchor T5d28
<table>
<caption align = "top">
\htmlonly
Table 5.28
\endhtmlonly
Specification detail for the SCOLIB Solis-Wets method
<!-- dakota subcat coliny_solis_wets -->
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>SCOLIB Solis-Wets method
<td>\c coliny_solis_wets
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed for stochastic pattern search
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Initial offset value
<td>\c initial_delta
<td>real
<td>Optional
<td>0.1*range
<tr>
<td>Threshold for offset values
<td>\c threshold_delta
<td>real
<td>Optional
<td>0.000001
<tr>
<td>No expansion flag
<td>\c no_expansion
<td>none
<td>Optional
<td>algorithm may expand pattern size
<tr>
<td>Number of consecutive improvements before expansion
<td>\c expand_after_success
<td>integer
<td>Optional
<td>5
<tr>
<td>Number of consecutive failures before contraction
<td>\c contract_after_failure
<td>integer
<td>Optional
<td>4*number of variables
<tr>
<td>Pattern contraction factor
<td>\c contraction_factor
<td>real
<td>Optional
<td>0.5
<tr>
<td>Constraint penalty
<td>\c constraint_penalty
<td>real
<td>Optional
<td>1.0
<tr>
<td>Control of dynamic penalty
<td>\c constant_penalty
<td>none
<td>Optional
<td>algorithm dynamically adapts the constraint penalty
</table>

These specifications have the same meaning as corresponding
specifications for \c coliny_pattern_search.  In particular, \c
coliny_solis_wets supports dynamic rescaling of the step length, and
dynamic rescaling of the constraint penalty.  The only new
specification is \c contract_after_failure, which specifies the number
of unsuccessful cycles which must occur with a specific delta prior to
contraction of the delta.

\subsection MethodNCSU NCSU Methods

North Carolina State University (NCSU) has an implementation of the
DIRECT algorithm (DIviding RECTangles algorithm that is outlined in
the SCOLIB method section above).  This version is documented in [\ref
Gablonsky2001 "Gablonsky, 2001".]  We have found that the NCSU DIRECT
implementation works better and is more robust for some problems than
\c coliny_direct.  Currently, we maintain both versions of DIRECT in
%Dakota; in the future, we may deprecate one.  The NCSU DIRECT method
is selected with \c ncsu_direct.  We have tried to maintain
consistency between the keywords in SCOLIB and NCSU implementation of
DIRECT, but the algorithms have different parameters, so the keywords
sometimes have slightly different meaning.

\subsubsection MethodNCSUIC NCSU method independent controls

The method independent controls for \c max_iterations and \c
max_function_evaluations limit the number of iterations and the number
of function evaluations that can be performed during an NCSU DIRECT
optimization.  This methods will always strictly respect the number of
iterations, but may slightly exceed the number of function
evaluations, as it will always explore all sub-rectangles at the
current level.

\subsubsection MethodNCSUDC NCSU method dependent controls

There are four specification controls affecting NCSU DIRECT: \c
solution_target, \c convergence_tolerance, \c min_boxsize_limit, and
\c volume_boxsize_limit.  The solution target specifies a goal toward
which the optimizer should track.  When \c solution_target is
specified, \c convergence_tolerance specifies a percent error on the
optimization.  This is used for test problems, when the true global
minimum is known (call it \c solution_target := fglobal).  Then, the
optimization terminates when 100(f_min-fglobal)/max(1,abs(fglobal) <
convergence_tolerance.  The default for fglobal is -1.0e100 and the
default for convergence tolerance is as given above.

\c min_boxsize_limit is a setting that terminates the optimization
when the measure of a hyperrectangle S with f(c(S)) = fmin is less
than min_boxsize_limit.  \c volume_boxsize_limit is a setting that
terminates the optimization when the volume of a hyperrectangle S with
f(c(S)) = fmin is less than volume_boxsize_limit percent of the
original hyperrectangle.  Basically, volume_boxsize_limit stops the
optimization when the volume of the particular rectangle which has
fmin is less than a certain percentage of the whole volume.  \c
min_boxsize_limit uses an arbitrary measure to stop the optimization.
The keywords for NCSU DIRECT are described in Table \ref T5d29 "5.29"
below.

\anchor T5d29
<table>
<caption align = "top">
\htmlonly
Table 5.29 
\endhtmlonly
Specification detail for the NCSU DIRECT method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Solution Target 
<td>\c solution_target
<td>real
<td>Optional
<td>0
<tr>
<td>Min boxsize limit
<td>\c min_boxsize_limit 
<td>real in [0,1]
<td>Optional
<td>1.0e-4
<tr>
<td>Volume boxsize limit
<td>\c volume_boxsize_limit 
<td>real in [0,1]
<td>Optional
<td>1.0e-6
</table>


\subsection MethodNOMAD Mesh Adaptive Direct Search Algorithm
<!-- dakota subcat mesh_adaptive_search -->

The mesh adaptive direct search algorithm [\ref AuLeTr09a "Audet, Le
Digabel, and Tribes, 2009"] is a generalized pattern search in which
the set of points evaluated becomes increasingly dense, leading to
good convergence properties.  It is now made available in %Dakota
through the NOMAD software [\ref Nomad "Abramson, Audet, Couture,
Dennis, Le Digabel, and Tribes"].  It can handle unconstrained
problems as well as those with bound constraints and general nonlinear
constraints.  Of particular note, it can handle both continuous and
discrete parameters.  NOMAD is available to the public under the GNU
LGPL and the source code is included with %Dakota.  NOMAD-specific
software documentation is available from http://www.gerad.ca/nomad.

\subsubsection MethodNOMADIC NOMAD method independent controls

The only method independent controls that are currently mapped to APPS
are \c max_function_evaluations and \c max_iterations.

\subsubsection MethodNOMADDC NOMAD method dependent controls

The method implemented in NOMAD method is invoked using the \c
mesh_adaptive_search group specification.  %Dakota 5.3.1 is the first
release that includes NOMAD, so we currently limit the algorithmic
parameters exposed and the number of features available.  We will
continue to expand over time.

The few parameters exposed are the following:

\li \c seed: NOMAD uses a random seed in the generation of search
directions.

\li \c display_all_evaluations: If this is set, then NOMAD will print
out its own record of evaluations completed.

\li \c history_file: This is the name of a file where NOMAD will write
its own output.

\li \c function_precision: This tells NOMAD the amount of precision it
can expect from function evaluations so it can make decisions about
progress and convergence accordingly.

\li \c vns: This parameter guides a variable neighborhood.  It roughly
correspons to how aggressive NOMAD is in trying to move away from
local minima.

\ref T5d20 "Table 5.30" summarizes the NOMAD specification.

\anchor T5d30
<table>
<caption align = "top">
\htmlonly
Table 5.30
\endhtmlonly
Specification detail for the mesh adaptive search  method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>NOMAD method
<td>\c mesh_adaptive_search
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random Seed
<td>\c seed
<td>int
<td>Optional
<td>0
<tr>
<td>Display NOMAD evaluations
<td>\c display_all_evaluations
<td>bool
<td>Optional
<td>false
<tr>
<td>NOMAD History File
<td>\c history_file
<td>string
<td>Optional
<td>mads_history
<tr>
<td>Function Evaluation Precision
<td>\c function_precision
<td>real
<td>Optional
<td>1.e-10
<tr>
<td>Variable Neighborhood Search
<td>\c vns
<td>real
<td>Optional
<td>0.0
</table>

\subsection MethodJEGA JEGA Methods

The JEGA library [\ref JEddy2001 "Eddy and Lewis, 2001"] contains two global
optimization methods.  The first is a Multi-objective Genetic Algorithm (MOGA)
which performs Pareto optimization.  The second is a Single-objective
Genetic Algorithm (SOGA) which performs optimization on a single
objective function.  Both methods support general constraints and a
mixture of real and discrete variables.  The JEGA library was written 
by John Eddy, currently a member of the technical staff in the
System Readiness and Sustainment Technologies department at Sandia National
Laboratories in Albuquerque.  These algorithms are accessed as \c moga and
\c soga within %Dakota.  %Dakota provides access to the JEGA library through the 
JEGAOptimizer class.


\subsubsection MethodJEGAIC JEGA method independent controls

JEGA utilizes the \c max_iterations and \c max_function_evaluations
method independent controls to provide integer limits for the maximum
number of generations and function evaluations, respectively.  Note that 
currently, the %Dakota default for \c max_iterations is 100 and for 
\c max_function_evaluations is 1000.  These are the default settings 
that will be used to "stop" the JEGA algorithms, unless some specific
convergence criteria are set (see Tables \ref T5d32 "5.32" and
\ref T5d33 "5.33" below).

Beginning with v2.0, JEGA also utilizes the \c output method independent control
to vary the amount of information presented to the user during execution.

\subsubsection MethodJEGADC JEGA method dependent controls

The JEGA library currently provides two types of genetic algorithms
(GAs): a multi-objective genetic algorithm (\c moga), and a single-
objective genetic algorithm (\c soga).  Both of these GAs can take
real-valued inputs, integer-valued inputs, or a mixture of real and
integer-valued inputs.  "Real-valued" and "integer-valued" refer to
the use of continuous or discrete variable domains, respectively (the
response data are real-valued in all cases).

The basic steps of the genetic algorithm are as follows: 
<ol> 

<li> Initialize the population (by randomly generating population members
with or without duplicates allowed, or by flat-file initialization)

<li> Evaluate the initial population members (calculate the values 
of the objective function(s) and constraints for each population member)

<li> Perform crossover (several crossover types are available) 

<li> Perform mutation (several mutation types are available)

<li> Evaluate the new population members.

<li> Assess the fitness of each member in the population.  There are a number
of ways to evaluate the fitness of the members of the population.  Choice
of fitness assessor operators is strongly related to the type of replacement 
algorithm being used and can have a profound effect on the
solutions selected for the next generation. For
example, if using \c MOGA, the available assessors are the \c layer_rank
and \c domination_count fitness assessors.  If using either of these, it is
strongly recommended that you use the \c replacement_type called the
\c below_limit selector as well (although
the roulette wheel selectors can also be used).  The functionality of the
domination_count selector of JEGA v1.0 can now be achieved using the
\c domination_count fitness assessor and \c below_limit replacement 
selector together.  If using \c SOGA, there are a number of possible
combinations of fitness assessors and selectors.

<li> Replace the population with members selected to continue 
in the next generation.  The pool of potential members is the current
population and the current set of offspring.  The \c replacement_type of
\c roulette_wheel or \c unique_roulette_wheel may be used either with MOGA or
SOGA problems however they are not recommended for use with MOGA.  Given that
the only two fitness assessors for MOGA are the \c layer_rank and
\c domination_count, the recommended selector is the \c below_limit selector.
The \c below_limit replacement will only keep designs that are 
dominated by fewer than a limiting number of other designs.
The \c replacement_type of \c favor_feasible is specific to a SOGA.
This replacement operator will always prefer a more feasible design to a less
feasible one.  Beyond that, it favors solutions based on an assigned
fitness value which must have been installed by the weighted sum only fitness
assessor (see the discussion below).

<li> Apply niche pressure to the population.  This step is specific to
the MOGA and is new as of JEGA v2.0.  Technically, the step is carried out
during runs of the SOGA but only the \c null_niching operator is available
for use with SOGA.  In MOGA, the \c radial or \c distance operators 
can be used.
The purpose of niching is to encourage differentiation along the Pareto
frontier and thus a more even and uniform sampling.  The radial nicher
takes information input from the user to compute a minimum allowable distance
between designs in the performance space and acts as a secondary selection
operator whereby it enforces this minimum distance. The distance nicher 
requires that solutions must be separated from other solutions by a 
minimum distance in each dimension (vs. Euclidean distance for the 
radial niching).  After niching is complete, all designs in the population will
be at least the minimum distance from one another in all directions.

<li> Test for convergence.  There are two aspects to convergence that must be
considered.  The first is stopping criteria.  A stopping criteria dictates some
sort of limit on the algorithm that is independent of its performance.  Examples
of stopping criteria available for use with JEGA are the \c max_iterations and
\c max_function_evaluations inputs.  All JEGA convergers respect these stopping
criteria in addition to anything else that they do.

The second aspect to convergence involves repeated assessment of the algorithms
progress in solving the problem.  In JEGA v1.0, the SOGA  fitness tracker
convergers (\c best_fitness_tracker and \c average_fitness_tracker) performed
this function by asserting that the fitness values (either best or average) of
the population continue to improve.  There was no such operator for the MOGA. 
As of JEGA v2.0, the same fitness tracker convergers exist for use with SOGA and
there is now a converger available for use with the MOGA.  The MOGA converger
(\c metric_tracker) operates by tracking various changes in the non-dominated
frontier from generation to generation.  When the changes occurring over a user
specified number of generations fall below a user specified threshold, the
algorithm stops.

<li> Perform post processing.  This step is new as of JEGA v2.1.
The purpose of this operation is to perform any needed data manipulations on the
final solution deemed necessary.  Currently the \c distance_postprocessor
is the only one other than the \c null_postprocessor.  The
\c distance_postprocessor is specifically for use with the MOGA and reduces the
final solution set size such that a minimum distance in each direction exists
between any two designs.

</ol>

There are many controls which can be used for both MOGA and SOGA
methods.  These include among others the random seed, initialization types,
crossover and mutation types, and some replacement types.
These are described in Tables \ref T5d30 "5.30" and \ref T5d31 "5.31" below.

The \c seed control defines the starting seed for the random number
generator.  The algorithm uses random numbers heavily but a specification
of a random seed will cause the algorithm to run identically from one trial
to the next so long as all other input specifications remain the same.  New as
of JEGA v2.0 is the introduction of the \c log_file specification.  JEGA now
uses a logging library to output messages and status to the user.  JEGA can be
configured at build time to log to both the console window and a text file, one
or the other, or neither.  The \c log_file input is a string name of a file
into which to log.  If the build was configured without file logging in JEGA,
this input is ignored.  If file logging is enabled and no \c log_file is
specified, the default file name of JEGAGlobal.log is used.  Also new to JEGA
v2.0 is the introduction of the \c print_each_pop specification.  It serves as
a flag and if supplied, the population at each generation will be printed to
a file named "population<GEN#>.dat" where <GEN#> is the number of the current
generation.

The \c initialization_type defines the type of initialization
for the GA.  There are three types: \c simple_random, \c unique_random, and
\c flat_file.  \c simple_random creates initial solutions with random variable
values according to a uniform random number distribution. It gives no
consideration to any previously generated designs.  The number of
designs is specified by the \c population_size. \c unique_random is
the same as \c simple_random, except that when a new solution is generated,
it is checked against the rest of the solutions.  If it duplicates any
of them, it is rejected.  \c flat_file allows the initial population
to be read from a flat file.  If \c flat_file is specified, a file
name must be given.  %Variables can be delimited in the flat file in any
way you see fit with a few exceptions.  The delimiter must be the same on
any given line of input with the exception of leading and trailing whitespace.
So a line could look like: 1.1, 2.2  ,3.3 for example but could not look like:
1.1, 2.2  3.3.  The delimiter can vary from line to line within the file which
can be useful if data from multiple sources is pasted into the same input file.
The delimiter can be any string that does not contain any of the characters
.+-dDeE or any of the digits 0-9.  The input will be read until the end of the
file.  The algorithm will discard any configurations for which it was unable to
retrieve at least the number of design variables.  The objective and constraint
entries are not required but if ALL are present, they will be recorded and the
design will be tagged as evaluated so that evaluators may choose not to
re-evaluate them.  Setting the size for this initializer has the effect of
requiring a minimum number of designs to create.  If this minimum number has
not been created once the files are all read, the rest are created using
the \c unique_random initializer and then the \c simple_random initializer if
necessary.

Note that the \c population_size only sets the size of the initial population.
The population size may vary in the JEGA methods according to the type of
operators chosen for a particular optimization run.

There are many crossover types available.  \c multi_point_binary
crossover requires an integer number, N, of crossover points.  This
crossover type performs a bit switching crossover at N crossover
points in the binary encoded genome of two designs.  Thus, crossover
may occur at any point along a solution chromosome (in the middle of a
gene representing a design variable, for example).  \c
multi_point_parameterized_binary crossover is similar in that it
performs a bit switching crossover routine at N crossover points.
However, this crossover type performs crossover on each design variable 
individually. So the individual chromosomes are crossed at N locations.
\c multi_point_real crossover performs a variable switching crossover routing at
N crossover points in the real real valued genome of two designs. In this
scheme, crossover only occurs between design variables (chromosomes).  Note that
the standard solution chromosome representation in the JEGA algorithm is real
encoded and can handle integer or real design variables.  For any crossover
types that use a binary representation, real variables are converted to long
integers by multiplying the real number by 10^6 and then truncating. Note that
this assumes a precision of only six decimal places. Discrete variables are
represented as integers (indices within a list of possible values) within the
algorithm and thus require no special treatment by the binary operators.

The final crossover type is \c shuffle_random.  This crossover type
performs crossover by choosing design variables at random from a
specified number of parents enough times that the requested number of
children are produced.  For example, consider the case of 3 parents
producing 2 children.  This operator would go through and for each
design variable, select one of the parents as the donor for the child.
So it creates a random shuffle of the parent design variable values.
The relative numbers of children and parents are controllable to allow
for as much mixing as desired.  The more parents involved, the less
likely that the children will wind up exact duplicates of the parents.

All crossover types take a \c crossover_rate.  The crossover rate is
used to calculate the number of crossover operations that take place.
The number of crossovers is equal to the rate * population_size.

There are five mutation types allowed.  \c replace_uniform introduces
random variation by first randomly choosing a design variable of a
randomly selected design and reassigning it to a random valid value
for that variable.  No consideration of the current value is given
when determining the new value.  All mutation types have a \c
mutation_rate.  The number of mutations for the replace_uniform
mutator is the product of the mutation_rate and the population_size.

The \c bit_random mutator introduces random variation by first converting
a randomly chosen variable of a randomly chosen design into a binary
string.  It then flips a randomly chosen bit in the string from a 1 to
a 0 or visa versa. In this mutation scheme, the resulting value has more
probability of being similar to the original value.  The number of mutations
performed is the product of the mutation_rate, the number of design variables,
and the population size.

The offset mutators all act by adding an "offset" random amount to a
variable value.  The random amount has a mean of zero in all cases.  The \c
offset_normal mutator introduces random variation by adding a Gaussian
random amount to a variable value.  The random amount has a standard
deviation dependent on the \c mutation_scale.  The \c mutation_scale
is a fraction in the range [0, 1] and is
meant to help control the amount of variation that takes place when a
variable is mutated.  \c mutation_scale is multiplied by the range of
the variable being mutated to serve as standard deviation. \c
offset_cauchy is similar to \c offset_normal, except that a Cauchy
random variable is added to the variable being mutated.  The
\c mutation_scale also defines the standard deviation for this mutator.
Finally, \c offset_uniform adds a uniform random amount to the
variable value.  For the \c offset_uniform mutator, the \c mutation_scale
is interpreted as a fraction of the total range of the variable.  The
range of possible deviation amounts is +/- 1/2 * (\c mutation_scale * variable
range).  The number of mutations for all offset mutators is defined
as the product of \c mutation_rate and \c population_size.

As of JEGA v2.0, all replacement types are common to both MOGA and SOGA.
They include the \c roulette_wheel, \c unique_roulette_wheel, \c elitist, and
\c below_limit selectors. In roulette_wheel replacement, each design is
conceptually allotted a portion of a wheel proportional to its fitness
relative to the fitnesses of the other Designs.  Then,
portions of the wheel are chosen at random and the design occupying
those portions are duplicated into the next population.  Those Designs
allotted larger portions of the wheel are more likely to be selected
(potentially many times). \c unique_roulette_wheel replacement is the
same as \c roulette_wheel replacement, with the exception that a design
may only be selected once.  The \c below_limit selector attempts to keep
all designs for which the negated fitness is below a certain limit.  The
values are negated to keep with the convention that higher fitness is better.
The inputs to the \c below_limit selector are the limit as a real value, and
a \c shrinkage_percentage as a real value.  The \c shrinkage_percentage 
defines the minimum amount of selections that will take place if
enough designs are available.  It is interpreted as a percentage of
the population size that must go on to the subsequent generation.  To
enforce this, \c below_limit makes all the selections it would
make anyway and if that is not enough, it takes the remaining that it needs
from the best of what is left (effectively raising its limit as far as it must
to get the minimum number of selections).  It continues until it has made
enough selections.  The \c shrinkage_percentage is designed to prevent extreme
decreases in the population size at any given generation, and thus 
prevent a big loss of genetic diversity in a very short time.  Without 
a shrinkage limit, a small group of "super" designs may appear and 
quickly cull the population down to a size on the order of
the limiting value.  In this case, all the diversity of the population 
is lost and it is expensive to re-diversify and spread the population.  The
\c elitist selector simply chooses the required number of designs taking the
most fit.  For example, if 100 selections are requested, then the top 100
designs as ranked by fitness will be selected and the remaining will be
discarded.

\anchor T5d31
<table>
<caption align = "top">
\htmlonly
Table 5.31
\endhtmlonly
Specification detail for JEGA method dependent controls: seed,
output, initialization, mutation, and replacement
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>GA Method
<td>\c moga | \c soga
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>Time based seed
<tr>
<td>Log file
<td>\c log_file
<td>string
<td>Optional
<td>JEGAGlobal.log
<tr>
<td>Number of population members
<td>\c population_size
<td>integer
<td>Optional
<td>50
<tr>
<td>Population output
<td>\c print_each_pop
<td>none
<td>Optional
<td>No printing
<tr>
<td>Output verbosity
<td>\c output
<td>\c silent | \c quiet | \c verbose | \c debug
<td>Optional
<td>\c normal
<tr>
<td>Initialization type
<td>\c initialization_type
<td>\c simple_random | \c unique_random | \c flat_file
<td>Optimal 
<td>unique_random
<tr>
<td>Mutation type
<td>\c mutation_type
<td>\c replace_uniform | \c bit_random | \c offset_cauchy | \c offset_uniform | \c offset_normal
<td>Optional group
<td>replace_uniform
<tr>
<td>Mutation scale
<td>\c mutation_scale
<td>real
<td>Optional
<td>0.15
<tr>
<td>Mutation rate
<td>\c mutation_rate
<td>real
<td>Optional
<td>0.08
<tr>
<td>Below limit selection
<td>\c below_limit
<td>real
<td>Optional
<td>6
<tr>
<td>Shrinkage percentage in below limit selection
<td>\c shrinkage_percentage
<td>real
<td>Optional<BR>
<td>0.9
</table>

\anchor T5d32
<table>
<caption align = "top">
\htmlonly
Table 5.32
\endhtmlonly
Specification detail for JEGA method dependent controls: crossover
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Crossover type
<td>\c crossover_type
<td>\c multi_point_binary | \c multi_point_parameterized_binary |
    \c multi_point_real | \c shuffle_random
<td>Optional group
<td>\c shuffle_random
<tr>
<td>Multi point binary crossover
<td>\c multi_point_binary
<td>integer
<td>Required 
<td>N/A
<tr>
<td>Multi point parameterized binary crossover
<td>\c multi_point_parameterized_binary
<td>integer
<td>Required 
<td>N/A
<tr>
<td>Multi point real crossover
<td>\c multi_point_real
<td>integer
<td>Required 
<td>N/A
<tr>
<td>Random shuffle crossover
<td>\c shuffle_random
<td>\c num_parents, \c num_offspring
<td>Required 
<td>N/A
<tr>
<td>Number of parents in random shuffle crossover
<td>\c num_parents
<td>integer
<td>optional
<td>2
<tr>
<td>Number of offspring in random shuffle crossover
<td>\c num_offspring
<td>integer
<td>optional
<td>2
<tr>
<td>Crossover rate
<td>\c crossover_rate
<td>real
<td>optional (applies to all crossover types)
<td>0.8
</table>

\subsubsection MethodJEGAMOGA Multi-objective Evolutionary Algorithms
<!-- dakota subcat moga -->
The specification for controls specific to Multi-objective
Evolutionary algorithms are described here.  These controls will be
appropriate to use if the user has specified \c moga as the method.

The initialization, crossover, and mutation controls were all
described in the preceding section.  There are no MOGA specific
aspects to these controls.  The \c fitness_type for a MOGA may be
\c domination_count or \c layer_rank.  Both have been specifically designed
to avoid problems with aggregating and scaling objective function values
and transforming them into a single objective.  Instead,
the \c domination_count fitness assessor works by ordering population
members by the negative of the number of designs that dominate them.  The
values are negated in keeping with the convention that higher fitness is
better.  The \c layer_rank fitness assessor works by assigning all
non-dominated designs a layer of 0, then from what remains, assigning all
the non-dominated a layer of 1, and so on until all designs have been
assigned a layer.  Again, the values are negated for the higher-is-better
fitness convention.  Use of the \c below_limit selector with the
\c domination_count fitness assessor has the effect of keeping all designs
that are dominated by fewer then a limiting number of other designs subject
to the shrinkage limit.  Using it with the \c layer_rank fitness assessor
has the effect of keeping all those designs whose layer is below a certain
threshold again subject to the shrinkage limit.

New as of JEGA v2.0 is the introduction of niche pressure operators.  These
operators are meant primarily for use with the moga.  The job of a niche
pressure operator is to encourage diversity along the Pareto frontier as the
algorithm runs.  This is typically accomplished by discouraging clustering
of design points in the performance space.  In JEGA, the application of niche
pressure occurs as a secondary selection operation.  The nicher is given a
chance to perform a pre-selection operation prior to the operation of the
selection (replacement) operator, and is then called to perform niching on the
set of designs that were selected by the selection operator.

Currently, the only niche pressure operators available are the \c
radial nicher, the \c distance nicher, and the \c max_designs nicher.
The \c radial niche pressure applicator works by enforcing a minimum
Euclidean distance between designs in the performance space at each
generation.  The algorithm proceeds by starting at the (or one of the)
extreme designs along objective dimension 0 and marching through the
population removing all designs that are too close to the current
design.  One exception to the rule is that the algorithm will never
remove an extreme design which is defined as a design that is maximal
or minimal in all but 1 objective dimension (for a classical 2
objective problem, the extreme designs are those at the tips of the
non-dominated frontier).  The \c distance nicher enforces a minimimum
distance in each dimension.

The designs that are removed by the nicher are not discarded.  They are
buffered and re-inserted into the population during the next pre-selection
operation.  This way, the selector is still the only operator that discards
designs and the algorithm will not waste time "re-filling" gaps created by the
nicher.

The \c radial nicher requires as input a vector of fractions with
length equal to the number of objectives.  The elements of the vector
are interpreted as percentages of the non-dominated range for each
objective defining a minimum distance to all other designs.  All
values should be in the range (0, 1).  The minimum allowable distance
between any two designs in the performance space is the Euclidian
(simple square-root-sum-of-squares calculation) distance defined by
these percentages.  The \c distance nicher has a similar input vector
requirement, only the distance is the minimum distance in each
dimension.

The \c max_designs niche pressure applicator is designed to choose a
limited number of solutions to remain in the population.  That number
is specified by \c num_designs.  It does so in order to balance the
tendency for populations to grow very large and thus consuming too
many computer resources.  It operates by ranking designs according to
their fitness standing and a computed count of how many other designs
are too close to them.  Too close is a function of the supplied
niche_vector, which specifies the minimum distance between any two
points in the performance space along each dimension individually.
Once the designs are all ranked, the top c\ num_designs designs are
kept in the population and the remaining ones are bufferred or
discarded.  Note that like other niching operators, this one will not
discard an extreme design.

Also new as of JEGA v2.0 is the introduction of the MOGA specific
\c metric_tracker converger.  This converger is conceptually similar to the
best and average fitness tracker convergers in that it tracks the progress of
the population over a certain number of generations and stops when the progress
falls below a certain threshold.  The implementation is quite different
however.  The \c metric_tracker converger tracks 3 metrics specific to the
non-dominated frontier from generation to generation.  All 3 of these metrics
are computed as percent changes between the generations.  In order to compute
these metrics, the converger stores a duplicate of the non-dominated frontier
at each generation for comparison to the non-dominated frontier of the next
generation.

The first metric is one that indicates how the expanse of the frontier is
changing.  The expanse along a given objective is defined by the range of
values existing within the non-dominated set.  The expansion metric is
computed by tracking the extremes of the non-dominated frontier from one
generation to the next.  Any movement of the extreme values is noticed and
the maximum percentage movement is computed as:
\verbatim
    Em = max over j of abs((range(j, i) - range(j, i-1)) / range(j, i-1))  j=1,nof
\endverbatim
where Em is the max expansion metric, j is the objective function index,
i is the current generation number, and nof is the total number of
objectives.  The range is the difference between the largest value along
an objective and the smallest when considering only non-dominated designs.

The second metric monitors changes in the density of the non-dominated
set.  The density metric is computed as the number of non-dominated points
divided by the hypervolume of the non-dominated region of space.  Therefore,
changes in the density can be caused by changes in the number of
non-dominated points or by changes in size of the non-dominated space or
both.  The size of the non-dominated space is computed as:
\verbatim
    Vps(i) = product over j of range(j, i)   j=1,nof
\endverbatim
where Vps(i) is the hypervolume of the non-dominated space at generation i
and all other terms have the same meanings as above.

The density of the a given non-dominated space is then:
\verbatim
    Dps(i) = Pct(i) / Vps(i)
\endverbatim
where Pct(i) is the number of points on the non-dominated frontier at
generation i.

The percentage increase in density of the frontier is then calculated as
\verbatim
    Cd = abs((Dps(i) - Dps(i-1)) / Dps(i-1))
\endverbatim
where Cd is the change in density metric.

The final metric is one that monitors the "goodness" of the non-dominated
frontier.  This metric is computed by considering each design in the previous
population and determining if it is dominated by any designs in the
current population.  All that are determined to be dominated are counted.
The metric is the ratio of the number that are dominated to the total number
that exist in the previous population.

As mentioned above, each of these metrics is a percentage.  The tracker
records the largest of these three at each generation.  Once the recorded
percentage is below the supplied percent change for the supplied number of
generations consecutively, the algorithm is converged.

The specification for convergence in a moga can either be \c metric_tracker
or can be omitted all together.  If omitted, no convergence algorithm will be
used and the algorithm will rely on stopping criteria only.  If
\c metric_tracker is specified, then a \c percent_change and \c num_generations
must be supplied as with the other metric tracker convergers (average and best
fitness trackers).  The \c percent_change is the threshold beneath which
convergence is attained whereby it is compared to the metric value computed
as described above.  The \c num_generations is the number of generations
over which the metric value should be tracked.  Convergence will be attained if
the recorded metric is below \c percent_change for \c num_generations
consecutive generations.

The MOGA specific controls are described in \ref T5d33 "Table 5.33"
below.  Note that MOGA and SOGA create additional output files during
execution.  "finaldata.dat" is a file that holds the final set of Pareto optimal
solutions after any post-processing is complete.  "discards.dat" holds
solutions that were discarded from the population during the course of
evolution.  It can often be useful to plot objective function values
from these files to visually see the Pareto front and ensure that
finaldata.dat solutions dominate discards.dat solutions.  The
solutions are written to these output files in the format
"Input1...InputN..Output1...OutputM".  If MOGA is used in a hybrid
optimization meta-iteration (which requires one optimal solution from each
individual optimization method to be passed to the subsequent
optimization method as its starting point), the solution in the Pareto
set closest to the "utopia" point is given as the best solution. This
solution is also reported in the %Dakota output.  This "best" solution
in the Pareto set has minimum distance from the utopia point.  The
utopia point is defined as the point of extreme (best) values for each
objective function.  For example, if the Pareto front is bounded by
(1,100) and (90,2), then (1,2) is the utopia point.  There will be a
point in the Pareto set that has minimum L2-norm distance to this
point, for example (10,10) may be such a point.  In SOGA, the solution
that minimizes the single objective function is returned as the best
solution.  If moga is used in meta-iteration which may require passing
multiple solutions to the next level (such as the \c
surrogate_based_global or \c hybrid methods), the \c
orthogonal_distance postprocessor type may be used to specify the
distances between each solution value to winnow down the solutions in
the full Pareto front to a subset which will be passed to the next
iteration.
   
\anchor T5d33
<table>
<caption align = "top">
\htmlonly
Table 5.33
\endhtmlonly
Specification detail for MOGA method controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Fitness type
<td>\c fitness_type
<td>\c layer_rank | \c domination_count
<td>Required group
<td> domination_count
<tr>
<td>Niche pressure type
<td>\c niching_type
<td>\c radial | \c distance | \c max_designs
<td>Optional group
<td> No niche pressure
<tr>
<td>Niching distance
<td>\c radial | \c distance | \c max_designs
<td>list of real
<td>Optional
<td> 0.01 for all objectives
<tr>
<td>Number designs to keep for \c max_designs nicher
<td>\c num_designs
<td>integer
<td>Optional
<td> 100
<tr>
<td>Replacement type
<td>\c replacement_type
<td>\c below_limit | \c roulette_wheel | \c unique_roulette_wheel | \c elitist
<td>Required group
<td>below_limit
<tr>
<td>Convergence type
<td>\c metric_tracker
<td>none
<td>Optional group
<td>metric_tracker
<tr>
<td>Percent change limit for metric_tracker converger
<td>\c percent_change
<td>real
<td>Optional
<td>0.1
<tr>
<td>Number generations for metric_tracker converger
<td>\c num_generations
<td>integer
<td>Optional
<td>10
<tr>
<td>Post_processor type
<td>\c postprocessor_type
<td>\c orthogonal_distance
<td>Optional
<td>No post-processing of solutions
<tr>
<td>Post_processor distance
<td>\c orthogonal_distance
<td>\c list of real
<td>Optional
<td>0.01 for all objectives
</table>


\subsubsection MethodJEGASOGA Single-objective Evolutionary Algorithms
<!-- dakota subcat soga -->

The specification for controls specific to Single-objective
Evolutionary algorithms are described here.  These controls will be
appropriate to use if the user has specified \c soga as the method.

The initialization, crossover, and mutation controls were all
described above.  There are no SOGA specific aspects to these
controls.  The \c replacement_type for a SOGA may be \c roulette_wheel,
\c unique_roulette_wheel, \c elitist, or \c favor_feasible.  The
\c favor_feasible replacement type first considers feasibility as a selection
criteria.  If that does not produce a "winner" then it moves on to considering
fitness value.  Because of this, any fitness assessor used with the
\c favor_feasible selector must only account objectives in the creation of
fitness.  Therefore, there is such a fitness assessor and it's use is enforced
when the \ favor_feasible selector is chosen.  In that case, and if the output
level is set high enough, a message will be presented indicating that the
\c weighted_sum_only fitness assessor will be used.  As of JEGA v2.0 and beyond,
the fitness assessment operator must be specified with SOGA
although the \c merit_function is currently the only one (note that the
\c weighted_sum_only assessor exists but cannot be selected).  The roulette
wheel selectors no longer assume a fitness function.  The \c merit_function
fitness assessor uses an exterior penalty function formulation to penalize
infeasible designs.  The specification allows the input of a
\c constraint_penalty which is the multiplier to use on the
constraint violations.

The SOGA controls allow two additional convergence types.  The \c
convergence_type called \c average_fitness_tracker keeps track of the
average fitness in a population.  If this average fitness does not
change more than \c percent_change over some number of generations, \c
num_generations, then the solution is reported as converged and the
algorithm terminates. The \c best_fitness_tracker works in a similar
manner, only it tracks the best fitness in the population. Convergence
occurs after \c num_generations has passed and there has been less
than \c percent_change in the best fitness value.  The percent change can
be as low as 0% in which case there must be no change at all over the number
of generations.  Both also respect the stopping criteria.
 
The SOGA specific controls are described in \ref T5d34 "Table 5.34" below.

\anchor T5d34
<table>
<caption align = "top">
\htmlonly
Table 5.34
\endhtmlonly
Specification detail for SOGA method controls
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Fitness type
<td>\c fitness_type
<td>\c merit_function
<td>Optional group
<td> merit_function
<tr>
<td>Constraint penalty in merit function
<td>\c constraint_penalty
<td>\c real
<td>Optional
<td>1.0
<tr>
<td>Replacement type
<td>\c replacement_type
<td>\c favor_feasible | \c unique_roulette_wheel | \c roulette_wheel | \c elitist
<td>Required group
<td>elitist
<tr>
<td>Convergence type
<td>\c convergence_type
<td>\c best_fitness_tracker | \c average_fitness_tracker
<td>Optional
<td>average_fitness_tracker
<tr>
<td>Number of generations (for convergence test) 
<td>\c num_generations
<td>integer
<td>Optional
<td>10
<tr>
<td>Percent change in fitness
<td>\c percent_change
<td>real
<td>Optional
<td>0.1
</table>


\section MethodLS Least Squares Methods


%Dakota's least squares branch currently contains three methods for
solving nonlinear least squares problems: NL2SOL, a trust-region
method that adaptively chooses between two Hessian approximations
(Gauss-Newton and Gauss-Newton plus a quasi-Newton approximation to
the rest of the Hessian), NLSSOL, a sequential quadratic programming
(SQP) approach that is from the same algorithm family as NPSOL, and
Gauss-Newton, which supplies the Gauss-Newton Hessian approximation to
the full-Newton optimizers from OPT++.

The important difference of these algorithms from general-purpose
optimization methods is that the response set is defined by calibration 
terms (e.g. separate terms for each residual), 
rather than an objective function.  Thus, a finer
granularity of data is used by least squares solvers as compared to
that used by optimizers.  This allows the exploitation of the special
structure provided by a sum of squares objective function. Refer to
\ref RespFnLS for additional information on the least squares response
data set.


\subsection MethodLSNL2SOL NL2SOL Method

NL2SOL is available as \c nl2sol and addresses unconstrained and
bound-constrained problems.  It uses a trust-region method (and thus
can be viewed as a generalization of the Levenberg-Marquardt
algorithm) and adaptively chooses between two Hessian approximations,
the Gauss-Newton approximation alone and the Gauss-Newton
approximation plus a quasi-Newton approximation to the rest of the
Hessian.  Even on small-residual problems, the latter Hessian
approximation can be useful when the starting guess is far from the
solution.  On problems that are not over-parameterized (i.e., that do
not involve more optimization variables than the data support), NL2SOL
usually exhibits fast convergence.

NL2SOL has a variety of internal controls as described in AT&T Bell
Labs CS TR 153 (http://cm.bell-labs.com/cm/cs/cstr/153.ps.gz).  A
number of existing %Dakota controls (method independent controls and
responses controls) are mapped into these NL2SOL internal controls.
In particular, %Dakota's \c convergence_tolerance, \c max_iterations,
\c max_function_evaluations, and \c fd_gradient_step_size are mapped
directly into NL2SOL's \c rfctol, \c mxiter, \c mxfcal, and \c dltfdj
controls, respectively.  In addition, %Dakota's \c fd_hessian_step_size
is mapped into both \c delta0 and \c dltfdc, and %Dakota's \c output
verbosity is mapped into NL2SOL's \c auxprt and \c outlev (for \c
normal/\c verbose/\c debug \c output, NL2SOL prints initial guess,
final solution, solution statistics, nondefault values, and changes to
the active bound constraint set on every iteration; for \c quiet \c
output, NL2SOL prints only the initial guess and final solution; and
for \c silent \c output, NL2SOL output is suppressed).

Several NL2SOL convergence tolerances are adjusted in response to \c
function_precision, which gives the relative precision to which
responses are computed.  These tolerances may also be specified
explicitly: \c convergence_tolerance (NL2SOL's \c rfctol, as mentioned
previously) is the relative-function convergence tolerance (on the
accuracy desired in the sum-of-squares function); \c x_conv_tol
(NL2SOL's \c xctol) is the X-convergence tolerance (scaled relative
accuracy of the solution variables); \c absolute_conv_tol (NL2SOL's \c
afctol) is the absolute function convergence tolerance (stop when half
the sum of squares is less than \c absolute_conv_tol, which is mainly
of interest on zero-residual test problems); \c singular_conv_tol
(NL2SOL's \c sctol) is the singular convergence tolerance, which works
in conjunction with \c singular_radius (NL2SOL's \c lmaxs) to test for
underdetermined least-squares problems (stop when the relative
reduction yet possible in the sum of squares appears less then \c
singular_conv_tol for steps of scaled length at most \c
singular_radius); \c false_conv_tol (NL2SOL's \c xftol) is the
false-convergence tolerance (stop with a suspicion of discontinuity
when a more favorable stopping test is not satisfied and a step of
scaled length at most \c false_conv_tol is not accepted).  Finally,
the \c initial_trust_radius specification (NL2SOL's \c lmax0)
specifies the initial trust region radius for the algorithm.

The internal NL2SOL defaults can be obtained for many of these
controls by specifying the value -1.  For both the \c
singular_radius and the \c initial_trust_radius, this results
in the internal use of steps of length 1.  For other controls,
the internal defaults are often functions of machine epsilon 
(as limited by \c function_precision).  Refer to CS TR 153 for 
additional details on these formulations.

Whether and how NL2SOL computes and prints a final covariance matrix and
regression diagnostics is affected by several keywords.  \c covariance
(NL2SOL's \c covreq) specifies the desired covariance approximation:
\li 0 = default = none
\li 1 or -1 ==> \f$\sigma^2 H^{-1} J^T J H^{-1}\f$
\li 2 or -2 ==> \f$\sigma^2 H^{-1}\f$
\li 3 or -3 ==> \f$\sigma^2 (J^T J)^{-1}\f$
\li Negative values ==> estimate the final Hessian H by finite 
differences of function values only (using \c fd_hessian_step_size)
\li Positive values ==> differences of gradients (using 
\c fd_hessian_step_size)

When \c regression_diagnostics (NL2SOL's \c rdreq) is specified and a
positive-definite final Hessian approximation H is computed, NL2SOL
computes and prints a regression diagnostic vector RD such that if
omitting the i-th observation would cause alpha times the change in
the solution that omitting the j-th observation would cause, then
RD[i] = |alpha| RD[j].  The finite-difference step-size tolerance
affecting H is \c fd_hessian_step_size (NL2SOL's \c delta0 and \c
dltfdc, as mentioned previously).

Table \ref T5d35 "5.35" provides the specification detail for the
NL2SOL method dependent controls.

\anchor T5d35
<table>
<caption align = "top">
\htmlonly
Table 5.35
\endhtmlonly
Specification detail for NL2SOL method dependent controls.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Relative precision in least squares terms
<td>\c function_precision
<td>real
<td>Optional
<td>1e-10
<tr>
<td>Absolute function convergence tolerance
<td>\c absolute_conv_tol
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default)
<tr>
<td>Convergence tolerance for change in parameter vector
<td>\c x_conv_tol
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default)
<tr>
<td>Singular convergence tolerance
<td>\c singular_conv_tol
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default)
<tr>
<td>Step limit for \c sctol
<td>\c singular_radius
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default of 1)
<tr>
<td>False convergence tolerance
<td>\c false_conv_tol
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default)
<tr>
<td>Initial trust region radius
<td>\c initial_trust_radius
<td>real
<td>Optional
<td>-1. (use NL2SOL internal default of 1)
<tr>
<td>Covariance post-processing
<td>\c covariance
<td>integer
<td>Optional
<td>0 (no covariance)
<tr>
<td>Regression diagnostics post-processing
<td>\c regression_diagnostics
<td>none
<td>Optional
<td>no regression diagnostics
</table>


\subsection MethodLSNLSSOL NLSSOL Method

NLSSOL is available as \c nlssol_sqp and supports unconstrained,
bound-constrained, and generally-constrained problems.  It exploits
the structure of a least squares objective function through the
periodic use of Gauss-Newton Hessian approximations to accelerate the
SQP algorithm.  %Dakota provides access to the NLSSOL library through
the NLSSOLLeastSq class.  The method independent and method dependent
controls are identical to those of NPSOL as described in \ref
MethodNPSOLIC and \ref MethodNPSOLDC.


\subsection MethodLSGN Gauss-Newton Method

The Gauss-Newton algorithm is available as \c optpp_g_newton and
supports unconstrained, bound-constrained, and generally-constrained
problems.  The code for the Gauss-Newton approximation (objective
function value, gradient, and approximate Hessian defined from residual 
function values and gradients) is provided outside of OPT++ within 
\ref SNLLLeastSq::nlf2_evaluator_gn "SNLLLeastSq::nlf2_evaluator_gn()".  
When interfaced with the unconstrained, bound-constrained, and
nonlinear interior point full-Newton optimizers from the OPT++
library, it provides a Gauss-Newton least squares capability which --
on zero-residual test problems -- can exhibit quadratic convergence
rates near the solution.  (Real problems almost never have zero
residuals, i.e., perfect fits.)

Mappings for the method independent and dependent controls are the
same as for the OPT++ optimization methods and are as described in
\ref MethodOPTPPIC and \ref MethodOPTPPDC.  In particular, since OPT++
full-Newton optimizers provide the foundation for Gauss-Newton, the
specifications from \ref T5d18 "Table 5.18" are also applicable for 
\c optpp_g_newton.


\section MethodNonD Uncertainty Quantification Methods


%Dakota provides a variety of methods for propagating uncertainty.
Aleatory uncertainty refers to inherent variability, irreducible
uncertainty, or randomness, and is addressed with the probabilistic
methods described in \ref MethodNonDAleat.  Epistemic uncertainty
refers to subjective uncertainty, reducible uncertainty, model form
uncertainty, or uncertainty due to lack of knowledge, and is addressed
using the non-probabilistic approaches described in \ref
MethodNonDEpist.  In general, we refer to both classes of uncertainty
quantification methods in %Dakota as nondeterministic methods.  In the
descriptions below, we described the issues and specification controls
that are common to both aleatory and epistemic uncertainty
quantification.

%Dakota's nondeterministic methods make use of a few method independent
controls.  \c max_iterations and \c convergence_tolerance are used by
iterated local and global reliability, stochastic expansions undergoing
automated refinement, and optimization-based epistemic methods.  \c
output level controls are also employed by several methods:
<ul>
<li> optional output of probability density functions (PDFs), for 
settings of \c normal or higher (sampling methods, including numerical
statistics for stochastic expansion methods)</li>
<li> optional output of sample evaluations performed on approximations,
for settings of \c verbose or higher (stochastic expansion methods)</li>
<li> optional tabular output of numerical integration points and weights,
for settings of \c verbose or higher (stochastic expansion methods)</li>
<li> optional output of local sensitivities computed from global 
approximations, for settings of \c normal or higher (stochastic 
expansion methods)</li>
<li> optional output of statistical quantities of interest (QOI) for 
iterations prior to convergence of an automated refinement process 
(stochastic expansion methods with a \c debug setting)</li>
</ul>
<!-- Only the \c x_taylor_mpp, \c u_taylor_mpp, \c x_two_point, and \c
u_two_point methods within \c local_reliability use method independent
convergence controls (see \ref MethodNonDLocalRel).  As such, the
nondeterministic branch documentation which follows is primarily
limited to the method dependent controls for the sampling,
reliability, stochastic expansion, and epistemic methods. -->

Each of the uncertainty quantification techniques is standardized on
support for \c response_levels, \c probability_levels, \c
reliability_levels, and \c gen_reliability_levels specifications along
with their optional \c num_response_levels, \c num_probability_levels,
\c num_reliability_levels and \c num_gen_reliability_levels keys,
except for a few exceptions where certain level mappings cannot be
supported: \c global_reliability, \c importance, \c local_evidence,
and \c global_evidence do not support mappings involving \c
reliability_levels, and \c local_interval_est and \c
global_interval_est do not support any level mappings.  The keys
define the distribution of the levels among the different response
functions.  For example, the following specification
\verbatim
	num_response_levels = 2 4 3
	response_levels = 1. 2. .1 .2 .3 .4 10. 20. 30.
\endverbatim
would assign the first two response levels (1., 2.) to response
function 1, the next four response levels (.1, .2, .3, .4) to response
function 2, and the final three response levels (10., 20., 30.) to
response function 3.  If the \c num_response_levels key were omitted
from this example, then the response levels would be evenly distributed 
among the response functions (three levels each in this case).

The \c response_levels specification provides the target response
values for generating probabilities, reliabilities, or generalized
reliabilities (forward mapping).  The selection among these possible
results for the forward mapping is performed with the \c compute
keyword followed by either \c probabilities, \c reliabilities, or \c
gen_reliabilities.  For example, specifying a \c response_level of
52.3 followed with \c compute \c probabilities will result in the
calculation that the (uncertain) output value is less than or equal to
52.3, given the uncertain distributions on the inputs.  Conversely,
the \c probability_levels, \c reliability_levels, and \c
gen_reliability_levels specifications provide target levels for which
response values will be computed (inverse mapping).  For example,
specifying a \c probability_level of 0.95 will result in the
calculation of a response value which corresponds to the 95th
percentile of the output distribution.  Specifications of \c
response_levels, \c probability_levels, \c reliability_levels, and \c
gen_reliability_levels may be combined within the calculations for
each response function.  The mapping results (probabilities,
reliabilities, or generalized reliabilities for the forward mapping
and response values for the inverse mapping) define the final
statistics of the nondeterministic analysis that can be accessed for
use at a higher level (via the primary and secondary mapping matrices
for nested models; see \ref ModelNested).

Sets of response-probability pairs computed with the forward/inverse
mappings define either a cumulative distribution function (CDF) or a
complementary cumulative distribution function (CCDF) for each
response function.  In the case of evidence-based epistemic methods,
this is generalized to define either cumulative belief and
plausibility functions (CBF and CPF) or complementary cumulative
belief and plausibility functions (CCBF and CCPF) for each response
function, where a forward mapping involves computing the belief and
plausibility probability level for a specified response level and an
inverse mapping involves computing the belief and plausibility
response level for either a specified probability level or a specified
generalized reliability level (two results for each level mapping in
the evidence-based epistemic case, instead of the one result for each
level mapping in the aleatory case).  The selection of a CDF/CBF/CPF
or CCDF/CCBF/CCPF can be performed with the \c distribution keyword
followed by either \c cumulative for the CDF/CBF/CPF option or \c
complementary for the CCDF/CCBF/CCPF option.  This selection also
defines the sign of the reliability or generalized reliability
indices.  \ref T5d36 "Table 5.36" provides the specification detail
for the forward/inverse mappings used by each of the nondeterministic
analysis methods.

\anchor T5d36
<table>
<caption align = "top">
\htmlonly
Table 5.36
\endhtmlonly
Specification detail for forward/inverse level mappings
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Distribution type
<td>\c distribution
<td>\c cumulative | \c complementary
<td>Optional group
<td>\c cumulative (CDF)
<tr>
<td>%Response levels
<td>\c response_levels
<td>list of reals
<td>Optional group
<td>No CDF/CCDF probabilities/reliabilities to compute
<tr>
<td>Number of response levels
<td>\c num_response_levels
<td>list of integers
<td>Optional
<td>\c response_levels evenly distributed among response functions
<tr>
<td>Target statistics for response levels
<td>\c compute
<td>\c probabilities | \c reliabilities | \c gen_reliabilities
<td>Optional
<td>\c probabilities
<tr>
<td>Probability levels
<td>\c probability_levels
<td>list of reals
<td>Optional group
<td>No CDF/CCDF response levels to compute
<tr>
<td>Number of probability levels
<td>\c num_probability_levels
<td>list of integers
<td>Optional
<td>\c probability_levels evenly distributed among response functions
<tr>
<td>Reliability levels
<td>\c reliability_levels
<td>list of reals
<td>Optional group
<td>No CDF/CCDF response levels to compute
<tr>
<td>Number of reliability levels
<td>\c num_reliability_levels
<td>list of integers
<td>Optional
<td>\c reliability_levels evenly distributed among response functions
<tr>
<td>Generalized reliability levels
<td>\c gen_reliability_levels
<td>list of reals
<td>Optional group
<td>No CDF/CCDF response levels to compute
<tr>
<td>Number of generalized reliability levels
<td>\c num_gen_reliability_levels
<td>list of integers
<td>Optional
<td>\c gen_reliability_levels evenly distributed among response functions
</table>

Different nondeterministic methods have differing support for
uncertain variable distributions. Tables \ref T5d37 "5.37", \ref 
T5d38 "5.38", and \ref T5d39 "5.39" summarize the uncertain variables
that are available for use by the different methods, where a "-"
indicates that the distribution is not supported by the method, a "U"
means the uncertain input variables of this type must be uncorrelated,
a "C" denotes that correlations are supported involving uncertain
input variables of this type, and an "A" means the appropriate 
variables must be specified as active in the variables 
specification block.  For example, if one wants to support 
sampling or a stochastic expansion method over both 
continuous uncertain and continuous state variables, the 
specification \c active \c all must be listed in the variables 
specification block. 
Additional notes include:
- we have four variants for stochastic expansions (SE), listed as
  Wiener, Askey, Extended, and Piecewise which draw from different sets 
  of basis polynomials.  The term stochastic expansion indicates polynomial 
  chaos and stochastic collocation collectively, although the Piecewise 
  option is only currently supported for stochastic collocation.  Refer to 
  \ref MethodNonDPCE and \ref MethodNonDSC for additional information on 
  these three options.  
- methods supporting the epistemic interval distributions have differing
  approaches: \c sampling and the \c lhs option of \c 
  global_interval_est model the interval basic probability
  assignments (BPAs) as continuous histogram bin distributions for
  purposes of generating samples; \c local_interval_est and the 
  \c ego option of \c global_interval_est ignore the BPA details 
  and models these variables as simple bounded regions defined by the 
  cell extremes; and \c local_evidence and \c global_evidence
  model the interval specifications as true BPAs.

<!-- could go into more detail on sub-options of local/global evidence, 
     but I think that's probably overkill. -->
<!-- and a "C#" denotes that correlations are only supported between 
variables of this type and other variables in the same numbered set. -->

\anchor T5d37
<table>
<caption align = "top">
\htmlonly
Table 5.37
\endhtmlonly
Summary of Distribution Types supported by Nondeterministic Methods, Part I (Continuous Aleatory Types)
</caption>
<tr>
<td><b>Distribution Type</b>
<td><b>Sampling</b>
<td><b>Local Reliability</b>
<td><b>Global Reliability</b>
<td><b>Wiener SE</b>
<td><b>Askey SE</b>
<td><b>Extended SE</b>
<td><b>Piecewise SE</b>
<td><b>Local Interval</b>
<td><b>Global Interval</b>
<td><b>Local Evidence</b>
<td><b>Global Evidence</b>
<tr>
<td>Normal
<td>C
<td>C
<td>C
<td>C
<td>C
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Bounded Normal
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Lognormal
<td>C
<td>C
<td>C
<td>C
<td>C
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Bounded Lognormal
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Uniform
<td>C
<td>C
<td>C
<td>C
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Loguniform
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Triangular
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Exponential
<td>C
<td>C
<td>C
<td>C
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Beta
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Gamma
<td>C
<td>C
<td>C
<td>C
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Gumbel
<td>C
<td>C
<td>C
<td>C
<td>C
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Frechet
<td>C
<td>C
<td>C
<td>C
<td>C
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Weibull
<td>C
<td>C
<td>C
<td>C
<td>C
<td>U
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Continuous Histogram Bin
<td>C
<td>U
<td>U
<td>U
<td>U
<td>U
<td>U
<td>-
<td>-
<td>-
<td>-
</table>  

\anchor T5d38
<table>
<caption align = "top">
\htmlonly
Table 5.38
\endhtmlonly
Summary of Distribution Types supported by Nondeterministic Methods, Part II (Discrete Aleatory Types)
</caption>
<tr>
<td><b>Distribution Type</b>
<td><b>Sampling</b>
<td><b>Local Reliability</b>
<td><b>Global Reliability</b>
<td><b>Wiener SE</b>
<td><b>Askey SE</b>
<td><b>Extended SE</b>
<td><b>Piecewise SE</b>
<td><b>Local Interval</b>
<td><b>Global Interval</b>
<td><b>Local Evidence</b>
<td><b>Global Evidence</b>
<tr>
<td>Poisson
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Binomial
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Negative Binomial
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Geometric
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Hypergeometric
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Discrete Histogram Point
<td>C
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
</table>

\anchor T5d39
<table>
<caption align = "top">
\htmlonly
Table 5.39
\endhtmlonly
Summary of Distribution Types supported by Nondeterministic Methods, Part III (Epistemic, Design, and State Types)
</caption>
<tr>
<td><b>Distribution Type</b>
<td><b>Sampling</b>
<td><b>Local Reliability</b>
<td><b>Global Reliability</b>
<td><b>Wiener SE</b>
<td><b>Askey SE</b>
<td><b>Extended SE</b>
<td><b>Piecewise SE</b>
<td><b>Local Interval</b>
<td><b>Global Interval</b>
<td><b>Local Evidence</b>
<td><b>Global Evidence</b>
<tr>
<td>Interval
<td>U
<td>-
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>U
<td>U
<td>U
<td>U
<tr>
<td>Continuous Design
<td>U,A
<td>-
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Discrete Design Range, Int Set, Real Set
<td>U,A
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Continuous State
<td>U,A
<td>-
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>U,A
<td>-
<td>-
<td>-
<td>-
<tr>
<td>Discrete State Range, Int Set, Real Set
<td>U,A
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
<td>-
</table>  

\subsection MethodNonDAleat Aleatory Uncertainty Quantification Methods

Aleatory uncertainty is also known as inherent variability,
irreducible uncertainty, or randomness.  An example of aleatory
uncertainty is the distribution of height in a population, as it is
characterized by the availability of sufficient data to accurately
model the form of the variation.  For this reason, aleatory
uncertainty is typically modeled using probabilistic approaches
through the specification of probability distributions to represent
the uncertain input variables and the propagation of this uncertainty
using probability theory.  The probabilistic approaches supported in
%Dakota include sampling, local and global reliability, polynomial
chaos, and stochastic collocation, which may be used to propagate
random variables described by \ref VarCAUV_Normal, \ref VarCAUV_Lognormal,
\ref VarCAUV_Uniform, \ref VarCAUV_Loguniform, \ref VarCAUV_Triangular, \ref
VarCAUV_Exponential, \ref VarCAUV_Beta, \ref VarCAUV_Gamma, \ref
VarCAUV_Gumbel, \ref VarCAUV_Frechet, \ref VarCAUV_Weibull, \ref
VarCAUV_Bin_Histogram, \ref VarDAUV_Poisson, \ref VarDAUV_Binomial, \ref
VarDAUV_Negative_Binomial, \ref VarDAUV_Geometric, \ref
VarDAUV_Hypergeometric, and/or \ref VarDAUV_Point_Histogram.


\subsubsection MethodNonDMC Nondeterministic sampling method

The nondeterministic sampling method is selected using the \c
sampling specification. This method draws samples from the
specified uncertain variable probability distributions and propagates
them through the model to obtain statistics on the output response
functions of interest.  %Dakota provides access to nondeterministic
sampling methods through the combination of the NonDSampling base
class and the NonDLHSSampling derived class.

CDF/CCDF probabilities are calculated for specified response levels
using a simple binning approach.  %Response levels are calculated for
specified CDF/CCDF probabilities and generalized reliabilities by
indexing into a sorted samples array (the response levels computed are
not interpolated and will correspond to one of the sampled values).
CDF/CCDF reliabilities are calculated for specified response levels by
computing the number of sample standard deviations separating the
sample mean from the response level.  %Response levels are calculated
for specified CDF/CCDF reliabilities by projecting out the prescribed
number of sample standard deviations from the sample mean.

The \c seed integer specification specifies the seed for the random
number generator which is used to make sampling studies repeatable,
and \c rng specifies which random number generator is used.  The \c
fixed_seed flag is relevant if multiple sampling sets will be
generated during the course of a higher level study (e.g., surrogate-based
optimization, optimization under uncertainty).  Specifying this flag
results in the reuse of the same seed value for each of these multiple
sampling sets, which can be important for reducing variability in the
sampling results.  However, this behavior is not the default as the
repetition of the same sampling pattern can result in a modeling
weakness that an optimizer could potentially exploit (resulting in
actual reliabilities that are lower than the estimated reliabilities).
In either case (\c fixed_seed or not), the study is repeatable if the
user specifies a \c seed and the study is random is the user omits a
\c seed specification.

The number of samples to be evaluated is selected with the
\c samples integer specification. The algorithm used to generate the
samples can be specified using \c sample_type followed by either \c
random, for pure random Monte Carlo sampling, or \c lhs, for Latin
Hypercube sampling.

If the user wants to increment a particular set of samples with more
samples to get better estimates of mean, variance, and percentiles,
one can select \c incremental_random or \c incremental_lhs as the \c
sample_type.  Note that a preliminary sample of size N must have
already been performed, and a \c dakota.rst restart file must be
available from this original sample. For example, say a user performs
an initial study using \c lhs as the \c sample_type, and generates 50
samples.  If the user creates a new input file where \c samples is now
specified to be 100, the \c sample_type is defined to be \c
incremental_lhs or \c incremental_random, and \c previous_samples is
specified to be 50, the user will get 50 new LHS samples which
maintain both the correlation and stratification of the original LHS
sample.  The N new samples will be combined with the N original
samples to generate a combined sample of size 2N.  The syntax for
running the second sample set is: \c dakota \c -i \c input2.in \c -r
\c dakota.rst, where \c input2.in is the file which specifies
incremental sampling.  Note that the number of samples in the second
set MUST currently be 2 times the number of previous samples, although
incremental sampling based on any power of two may be supported in
future releases.

The nondeterministic sampling method also supports sampling 
over different types of variables, depending on what is 
specified as \c active in the variables block of the input 
specification.  
Normally, \c sampling generates samples only for the 
uncertain variables, and
treats any design or state variables as constants.  
However, if \c active \c all is specified in the variables block, 
sampling will be performed over all variables, including 
uncertain, design, and state.  
In this case, the sampling 
algorithm will treat any continuous design or continuous state variables
as parameters with uniform probability distributions between their
upper and lower bounds.  Samples are then generated over all of the
continuous variables (design, uncertain, and state) in the variables
specification.  This is similar to the behavior of the design of
experiments methods described in \ref MethodDACE, since they will also
generate samples over all continuous design, uncertain, and state
variables in the variables specification.  However, the design of
experiments methods will treat all variables as being uniformly
distributed between their upper and lower bounds, whereas the \c
sampling method will sample the uncertain variables within
their specified probability distributions.  If further 
granularity of sampling is necessary for uncertain variables, 
one can specify \c active \c epistemic or \c active \c aleatory 
to specify sampling over only epistemic uncertain or 
only aleatory uncertain variables, respectively.   
In the case where one wants to generate samples only over 
state variables, one would specify \c active \c state in the 
variables specification block. 

Finally, the nondeterministic sampling method supports two types of
sensitivity analysis.  In this context of sampling, we take
sensitivity analysis to be global, not local as when calculating
derivatives of output variables with respect to input variables.  Our
definition is similar to that of [\ref Saltelli2004 "Saltelli et al., 2004"]: 
"The study of how uncertainty in the output of a model can be 
apportioned to different sources of uncertainty in the model input."
As a default, %Dakota provides correlation analyses when running LHS.
Correlation tables are printed with the simple, partial, and rank
correlations between inputs and outputs.  These can be useful to get a
quick sense of how correlated the inputs are to each other, and how
correlated various outputs are to inputs.  In addition, we have the
capability to calculate sensitivity indices through variance based
decomposition using the keyword \c variance_based_decomp.  Variance 
based decomposition is a way of using sets of samples to understand
how the variance of the output behaves, with respect to each input
variable. A larger value of the sensitivity index, \f$S_i\f$, means 
that the uncertainty in the input variable i has a larger effect on 
the variance of the output.  More details on the calculations and
interpretation of the sensitivity indices can be found in [\ref
Saltelli2004 "Saltelli et al., 2004"] and 
[\ref Weirs2010 "Weirs et al., 2010"].  Note that \c
variance_based_decomp is extremely computationally intensive since
replicated sets of sample values are evaluated. If the user specified
a number of samples, N, and a number of nondeterministic variables, M,
variance-based decomposition requires the evaluation of N*(M+2)
samples.  To obtain sensitivity indices that are reasonably accurate,
we recommend that N, the number of samples, be at least one hundred
and preferably several hundred or thousands. Because of the
computational cost, \c variance_based_decomp is turned off as a
default. \ref T5d40 "Table 5.40" provides details of the
nondeterministic sampling specifications beyond those of \ref T5d36
"Table 5.36".

\anchor T5d40
<table>
<caption align = "top">
\htmlonly
Table 5.40
\endhtmlonly
Specification detail for nondeterministic sampling method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Nondeterministic sampling method
<td>\c sampling
<td>none
<td>Required group
<td>N/A
<tr>
<td>Sampling type
<td>\c sample_type
<td>\c random | \c lhs | \c incremental_random |\c incremental_lhs
<td>Optional group
<td>\c lhs
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td>minimum required
<tr>
<td>Previous samples for incremental approaches
<td>\c previous_samples
<td>integer
<td>Optional
<td>0 (no previous_samples)
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Fixed seed flag
<td>\c fixed_seed
<td>none
<td>Optional
<td>seed not fixed: sampling patterns are variable among multiple runs
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Variance based decomposition (VBD)
<td>\c variance_based_decomp
<td>none
<td>Optional
<td>No VBD analysis
<tr>
<td>VBD tolerance for omitting small indices
<td>\c drop_tolerance
<td>none
<td>Optional
<td>All VBD indices displayed
</table>


\subsubsection MethodNonDLocalRel Local reliability methods

Local reliability methods are selected using the \c
local_reliability specification and are implemented within the
NonDLocalReliability class. These methods compute approximate response
function distribution statistics based on specified uncertain variable
probability distributions.  Each of the local reliability methods can
compute forward and inverse mappings involving response, probability,
reliability, and generalized reliability levels.

The Mean Value method (MV, also known as MVFOSM in 
[\ref Haldar2000 "Haldar and Mahadevan, 2000"]) is the simplest,
least-expensive method in that it estimates the response means,
response standard deviations, and all CDF/CCDF forward/inverse
mappings from a single evaluation of response functions and gradients
at the uncertain variable means.  This approximation can have
acceptable accuracy when the response functions are nearly linear and
their distributions are approximately Gaussian, but can have poor
accuracy in other situations.

All other reliability methods perform an internal nonlinear
optimization to compute a most probable point (MPP) of failure.  A
sign convention and the distance of the MPP from the origin in the
transformed standard normal space ("u-space") define the reliability
index, as explained in the section on Reliability Methods in the
Uncertainty Quantification chapter of the Users Manual 
[\ref UsersMan "Adams et al., 2010"].  The reliability can
then be converted to a probability using either first- or second-order
integration, may then be refined using importance sampling, and
finally may be converted to a generalized reliability index.  The
forward reliability analysis algorithm of computing
reliabilities/probabilities for specified response levels is called
the Reliability Index Approach (RIA), and the inverse reliability
analysis algorithm of computing response levels for specified
probability levels is called the Performance Measure Approach (PMA).
The different RIA/PMA algorithm options are specified using the \c
mpp_search specification which selects among different limit state
approximations that can be used to reduce computational expense during
the MPP searches.  The \c x_taylor_mean MPP search option performs a
single Taylor series approximation in the space of the original
uncertain variables ("x-space") centered at the uncertain variable
means, searches for the MPP for each response/probability level using
this approximation, and performs a validation response evaluation at
each predicted MPP.  This option is commonly known as the Advanced
Mean Value (AMV) method.  The \c u_taylor_mean option is identical to
the \c x_taylor_mean option, except that the approximation is
performed in u-space.  The \c x_taylor_mpp approach starts with an
x-space Taylor series at the uncertain variable means, but iteratively
updates the Taylor series approximation at each MPP prediction until
the MPP converges.  This option is commonly known as the AMV+ method.
The \c u_taylor_mpp option is identical to the \c x_taylor_mpp option,
except that all approximations are performed in u-space.  The order of
the Taylor-series approximation is determined by the corresponding \c
responses specification and may be first or second-order.  If
second-order (methods named \f$AMV^2\f$ and \f$AMV^2+\f$ in
[\ref Eldred2006b "Eldred and Bichon, 2006"]), the series may employ 
analytic, finite difference, or quasi Hessians (BFGS or SR1).
The \c x_two_point MPP search option uses an x-space Taylor series 
approximation at the uncertain variable means for the initial MPP 
prediction, then utilizes the Two-point Adaptive Nonlinear 
%Approximation (TANA) outlined in [\ref Xu1998 "Xu and Grandhi, 1998"] 
for all subsequent MPP predictions.  The \c u_two_point approach is 
identical to \c x_two_point, but all the approximations are performed 
in u-space. The \c x_taylor_mpp and \c u_taylor_mpp, \c x_two_point 
and \c u_two_point approaches utilize the \c max_iterations and 
\c convergence_tolerance method independent controls to control the
convergence of the MPP iterations (the maximum number of MPP 
iterations per level is limited by \c max_iterations, and the MPP
iterations are considered converged when 
\f$\parallel {\bf u}^{(k+1)} - {\bf u}^{(k)} \parallel_2\f$ < 
\c convergence_tolerance).  And, finally, the \c no_approx option 
performs the MPP search on the original response functions without 
the use of any approximations.  The optimization algorithm used to 
perform these MPP searches can be selected to be either sequential 
quadratic programming (uses the \c npsol_sqp optimizer) or nonlinear 
interior point (uses the \c optpp_q_newton optimizer) algorithms 
using the \c sqp or \c nip keywords.

In addition to the MPP search specifications, one may select among
different integration approaches for computing probabilities at the
MPP by using the \c integration keyword followed by either \c
first_order or \c second_order.  Second-order integration employs the
formulation of [\ref HohenRack "Hohenbichler and Rackwitz, 1988"] 
(the approach of [\ref Breit1984 "Breitung, 1984"] and the correction 
of [\ref Hong "Hong 1999"] are also implemented, but are not active).  
Combining the \c no_approx option of the MPP search with first- and 
second-order integrations results in the traditional first- and 
second-order reliability methods (FORM and SORM).  These integration 
approximations may be subsequently refined using importance sampling.
The \c refinement specification allows the seletion of basic
importance sampling (\c import), adaptive importance sampling (\c
adapt_import), or multimodal adaptive importance sampling (\c
mm_adapt_import), along with the specification of number of samples
(\c samples) and random seed (\c seed).  Additional details 
on these methods are available in [\ref Eldred2004b "Eldred et al., 2004b"] 
and [\ref Eldred2006b "Eldred and Bichon, 2006"] and in the Uncertainty 
Quantification Capabilities chapter of the Users Manual 
[\ref UsersMan "Adams et al., 2010"].

\ref T5d41 "Table 5.41" provides details of the local reliability method
specifications beyond those of \ref T5d41 "Table 5.41".

\anchor T5d41
<table>
<caption align = "top">
\htmlonly
Table 5.41
\endhtmlonly
Specification detail for local reliability methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Reliability method
<td>\c local_reliability
<td>none
<td>Required group
<td>N/A
<tr>
<td>MPP search type
<td>\c mpp_search
<td>\c x_taylor_mean | \c u_taylor_mean | \c x_taylor_mpp | \c u_taylor_mpp | 
\c x_two_point | \c u_two_point | \c no_approx
<td>Optional group
<td>No MPP search (MV method)
<tr>
<td>MPP search algorithm
<td>\c sqp, \c nip
<td>none
<td>Optional
<td>NPSOL's SQP algorithm
<tr>
<td>Integration method
<td>\c integration
<td>\c first_order | \c second_order
<td>Optional group
<td>First-order integration
<tr>
<td>Importance sampling refinement
<td>\c probability_refinement
<td>\c import | \c adapt_import | \c mm_adapt_import
<td>Optional group
<td>No refinement
<tr>
<td>Refinement samples
<td>\c refinement_samples
<td>integer
<td>Optional
<td>1000 (per iteration, if adaptive)
<tr>
<td>Refinement seed
<td>\c seed
<td>integer
<td>Optional group
<td>randomly generated seed
</table>


\subsubsection MethodNonDGlobalRel Global reliability methods
<!-- dakota subcat global_reliability -->

Global reliability methods are selected using the \c
global_reliability specification and are implemented within the
NonDGlobalReliability class.  These methods do not support
forward/inverse mappings involving \c reliability_levels, since they
never form a reliability index based on distance in u-space.  Rather
they use a Gaussian process model to form an approximation to the
limit state (based either in x-space via the \c x_gaussian_process
specification or in u-space via the \c u_gaussian_process
specification), followed by probability estimation based on multimodal
adaptive importance sampling (see 
[\ref Bichon2007 "Bichon et al., 2007"]) and 
[\ref Bichon2008 "Bichon et al., 2008"]).  These
probability estimates may then be transformed into generalized
reliability levels if desired.  At this time, inverse reliability
analysis (mapping probability or generalized reliability levels into
response levels) is not implemented.  The Gaussian process model
approximation to the limit state is formed over the aleatory uncertain
variables by default, but may be extended to also capture the effect
of design, epistemic uncertain, and state variables.  If this is
desired, one must use the appropriate controls to specify the active
variables in the variables specification block. By default, the
Surfpack GP (Kriging) model is used, but the %Dakota implementation may
be selected instead. If \c use_derivatives is specified the GP model
will be built using available derivative data (Surfpack GP only).  
The \c import_points_file and \c export_points_file specifications are
as described in \ref ModelSurrG (the use of an embedded global
surrogate model necessitates repeating selected surrogate model
specifications within the method specification).

\ref T5d42 "Table 5.42" provides details of the global reliability method
specifications beyond those of \ref T5d36 "Table 5.36".

\anchor T5d42
<table>
<caption align = "top">
\htmlonly
Table 5.42
\endhtmlonly
Specification detail for global reliability methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Global reliability method
<td>\c global_reliability
<td>none
<td>Required group
<td>N/A
<tr>
<td>%Approximation type
<td>\c x_gaussian_process | \c u_gaussian_process
<td>none
<td>Required
<td>N/A
<tr>
<td>GP selection
<td>\c gaussian_process
<td>\c surfpack | \c dakota
<td>Optional
<td>Surfpack Gaussian process
<tr>
<td>Derivative usage
<td>\c use_derivatives
<td>none
<td>Optional
<td>Use function values only
<tr>
<td>Random seed for initial GP construction
<td>\c seed
<td>integer
<td>Optional
<td>Time based seed: nonrepeatable
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>


\subsubsection MethodNonDImportance Importance sampling methods
<!-- dakota subcat importance_sampling -->

Importance sampling is a method that allows one to estimate statistical 
quantities such as failure probabilities (e.g. the probability that 
a response quantity will exceed a threshold or fall below a threshold value)
in a way that is more efficient than Monte Carlo sampling.  The core idea 
in importance sampling is that one generates samples that preferentially 
samples important regions in the space (e.g. in or near the failure region 
or user-defined region of interest), and then appropriately weights 
the samples to obtain an unbiased estimate of the failure probability
[\ref Srinivasan "Srinivasan, 2002"]. 
In importance sampling, the samples are generated from a density which is 
called the importance density:  it is not the original probability density 
of the input distributions.  The importance density should be centered near the 
failure region of interest.  For black-box simulations such as those commonly 
interfaced with %Dakota, it is difficult to specify the importance density a priori: 
the user often does not know where the failure region lies, especially in a high-dimensional 
space.[\ref Swiler2010 "Swiler and West, 2010"].  
We have developed two importance sampling approaches which do not 
rely on the user explicitly specifying an importance density. 

The first method is based on ideas in reliability modeling \ref MethodNonDLocalRel.
An initial Latin Hypercube sampling is performed to generate an initial set of samples.
These initial samples are augmented with samples from an importance density as follows:   
The variables are transformed to standard normal space. In the transformed space, 
the importance density is a set of normal densities centered around points which 
are in the failure region.  Note that this is similar in spirit to the reliability 
methods, in which importance sampling is centered around a Most Probable Point (MPP). 
In the case of the LHS samples, the importance sampling density will simply by 
a mixture of normal distributions centered around points in the failure region. 
The options for importance sampling are as follows:  \c import centers a sampling 
density at one of the initial LHS samples identified in the failure region.  
It then generates the importance samples, weights them by their probability of occurence 
given the original density, and calculates the required probability (CDF or CCDF level). 
\c adapt_import is the same as \c import but is performed iteratively until the 
failure probability estimate converges. 
\c mm_adapt_import starts with all of the samples located in the failure region  
to build a multimodal sampling density. First, it uses a small number of samples around 
each of the initial samples in the failure region.  Note that these samples 
are allocated to the different points based on their relative probabilities of occurrence:
more probable points get more samples. This early part of the approach is done 
to search for "representative" points. Once these are located, the multimodal sampling 
density is set and then \c mm_adapt_import proceeds similarly to \c adapt_import (sample 
until convergence).  

\ref T5d43 "Table 5.43" provides details of the \c importance_sampling method.

\anchor T5d43
<table>
<caption align = "top">
\htmlonly
Table 5.43
\endhtmlonly
Specification detail for the LHS-based importance sampling method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Importance sampling method
<td>\c importance_sampling
<td>none
<td>Required group
<td>N/A
<tr>
<td>Type of importance sampling performed
<td>\c import | \c adapt_import | \c mm_adapt_import
<td>none
<td>Required
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
</table>

The second importance sampling method in %Dakota, \c gpais, is the one we recommend, 
at least for problems that have a relatively small number of input variables (e.g. 
less than 10-20).  This method, Gaussian Process Adaptive Importance Sampling, 
is outlined in the paper [\ref Dalbey2014 "Dalbey and Swiler, 2014"].  
This method  starts with an initial set of LHS samples and adds samples one at a time, 
with the goal of adaptively improving the estimate of the ideal importance density 
during the process.  The approach uses a mixture of component densities.  An   
itterative process is used
to construct the sequence of improving component densities. At each
iteration, a Gaussian process (GP) surrogate is used to help identify areas
in the space where failure is likely to occur.  The GPs are not used to
directly calculate the failure probability; they are only used to approximate
the importance density. Thus, the Gaussian process adaptive importance
sampling algorithm overcomes limitations involving using a potentially
inaccurate surrogate model directly in importance sampling calculations.  

The \c import_points_file and \c export_points_file specifications are
as described in \ref ModelSurrG, (the use of an embedded GP model
necessitates repeating selected surrogate model specifications within
the method specification).

\ref T5d44 "Table 5.44" provides details of the \c gpais method
for Gaussian process adaptive importance sampling. 

\anchor T5d44
<table>
<caption align = "top">
\htmlonly
Table 5.44
\endhtmlonly
Specification detail for Gaussian process adaptive importance sampling method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Gaussian process adaptive importance sampling method
<td>\c gpais
<td>none
<td>Required group
<td>N/A
<tr>
<td>Number of initial LHS samples
<td>\c samples
<td>integer
<td>Required
<td>N/A
<tr>
<td>Number of samples on the emulator to generate a new true sample each iteration
<td>\c emulator_samples
<td>integer
<td>Optional
<td>10,000
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>

\subsubsection MethodNonDAdaptive Adaptive sampling methods
<!-- dakota subcat adaptive_sampling -->

The goal in performing adaptive sampling is to construct a surrogate model that
can be used as an accurate predictor to some expensive simulation, thus it is
to one's advantage to build a surrogate that minimizes the error over the entire
domain of interest using as little data as possible from the expensive
simulation.  The adaptive part alludes to the fact that the surrogate will be
refined by focusing samples of the expensive simulation on particular areas of
interest rather than rely on random selection or standard space-filling
techniques.
 
At a high-level, the adaptive sampling pipeline is a four-step process:
<ol>
<li> Evaluate the expensive simulation (referred to as the true model) at
initial sample point
<li> Fit/refit a surrogate model
<li> Create a candidate set and score based on information from surrogate
<li> Select a candidate point to evaluate the true model and Repeat 2-4
</ol>
 
In terms of the %Dakota implementation, the adaptive sampling method
currently uses Latin Hypercube sampling (LHS) to generate the initial
points in Step 1 above.  For Step 2, we use a Gaussian process model.
The user can specify the \c fitness_metric used to select the
next point (or points) to evaluate and add to the set. 
The fitness metrics used for scoring candidate points include: 
\c predicted_variance, \c distance, and \c gradient.  
The predicted variance metric uses the predicted
variance of the Gaussian process surrogate as the score of a candidate
point. Thus, the adaptively chosen points will be in areas of highest
uncertainty according to the Gaussian process model.
The distance metric calculates the Euclidean distance in domain space between the
candidate and its nearest neighbor in the set of points already evaluated on the
true model. Therefore, the most undersampled area of the domain will always be
selected. Note that this is a space-filling metric.  
The gradient metric calculates the score as the absolute value of the difference 
in range space (the outputs) of the two points.  The output values used are 
predicted from the surrogate model. 
This method attempts to evenly fill the range space of the surrogate.

At each iteration (e.g. each loop of Steps 2-4 above),  a Latin Hypercube 
sample is generated (a new one, different from the initial sample) and 
the surrogate model is evaluated at this points.  
These are the candidate points that are then evaluated
according to the fitness metric.  The number of candidates used
in practice should be high enough to fill most
of the input domain: we recommend at least hundreds of points 
for a low-dimensional problem.
All of the candidates (samples on the emulator) are
given a score and then the highest-scoring candidate is selected to be evaluated
on the true model.
 
The adaptive sampling method also can generate batches of points
to add at a time. With batch or  multi-point
selection, the true model can be evaluated in parallel and thus
increase throughput before refitting our surrogate model. This proposes a new
challenge as the problem of choosing a single point and choosing multiple points
off a surrogate are fundamentally different. Selecting the \c n best scoring
candidates is more than likely to generate a set of points clustered in one
area which will not be conducive to adapting the surrogate.

We have implemented several strategies for batch selection of points.  
These are described in the User's manual and are the subject of 
active research.  The number of points to add in each batch is specified 
with \c batch_size.  Briefly, the \c batch_selection strategies include: 
<ol>
<li> \c naive: 
This strategy will select the \c n highest scoring candidates regardless of their
position. This tends to group an entire round of points in the same area.
<li> \c distance_penalty
In this strategy, the highest scoring candidate is selected and then all 
remaining candidates are re-scored with a distance penalization factor 
added in to the score. 
<li> \c topology
In this strategy we look at the topology of the scoring function and select the
\c n highest maxima in the topology. To determine local maxima, we construct the
approximate Morse-Smale complex. This strategy does require the user to have the 
Morse-Smale package.
<li> \c constant_liar
The strategy first selects
the highest scoring candidate, and then refits the surrogate using a ''lie'' value
at the point selected and repeats until \c n points have been selected
whereupon the lie values are removed from the surrogate and the selected points
are evaluated on the true model and the surrogate is refit with these values.
</ol>

The \c import_points_file and \c export_points_file specifications are
as described in \ref ModelSurrG, (the use of an embedded global
surrogate model necessitates repeating selected surrogate model
specifications within the method specification).

\ref T5d45 "Table 5.45" provides details of the \c adaptive_sampling method
for adaptive sampling. 

\anchor T5d45
<table>
<caption align = "top">
\htmlonly
Table 5.45
\endhtmlonly
Specification detail for adaptive sampling method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>adaptive sampling method
<td>\c adaptive_sampling
<td>none
<td>Required group
<td>N/A
<tr>
<td>Number of initial LHS samples
<td>\c samples
<td>integer
<td>Required
<td>N/A
<tr>
<td>Number of samples on the emulator to generate a new true sample each iteration
<td>\c emulator_samples
<td>integer
<td>Optional
<td>400
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>Randomly generated seed
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Fitness metric
<td>\c fitness_metric
<td>\c predicted_variance | \c distance | \c gradient
<td>Optional
<td>\c predicted_variance
<tr>
<td>Batch selection strategy
<td>\c batch_selection
<td>\c naive | \c distance_penalty | \c topology | \c constant_liar
<td>Optional
<td>\c naive
<tr>
<td>Batch size (number of points added each iteration)
<td>\c batch_size
<td>integer
<td>Optional
<td>1
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>

\subsubsection MethodNonDPOFDarts POF Darts method
<!-- dakota subcat pof_darts -->
\c pof_darts is a novel method for estimating the probability of failure based 
on sphere-packing. Random spheres are sampled from the domain with the 
constraint that each new sphere center has to be outside prior disks. 
The radius of each sphere is chosen such that the entire sphere lies either 
in the failure or the non-failure region. This radius depends on the function 
evaluation at the disk center, the failure threshold, and an estimate of the 
function gradient at the disk center. Estimating each radius in the current 
version requires 2d + 1 function evaluations, where d is the number 
of uncertain input variables. In the coming version, we intend 
to utilize a surrogate for evaluating the gradient and hence only one function 
evaluation would be required for each sphere. The number of spheres per failure 
threshold is specified by \c samples.  After exhausting the sampling 
budget specified by \c samples, the domain is decomposed into two regions, 
failure and non-failure, each represented by the union of the spheres of 
each type. The volume of the union of failure spheres gives a lower bound 
on the required estimate of the probability of failure, while the volume 
of the union of the non-failure spheres subtracted from the volume of the 
domain gives an upper estimate. We currently report the average of both estimates. 

\c pof_darts handles multiple response functions and allows each to have 
multiple failure thresholds. For each failure threshold, \c pof_darts will 
insert a number of spheres specified by the user-input parameter \c samples. 
However, estimating the probability of failure for each failure threshold 
would utilize the total number of disks sampled for all failure thresholds. 
For each failure threshold, the sphere radii change to generate the right spatial 
decomposition.

In summary, the total number of samples generated will be the 
total number of response levels (over all response functions) 
times (2d+1)*\c samples, where d is the number of uncertain variables. 

\ref T5d46 "Table 5.46" provides details of the \c pof_darts  method
for estimating probability of failure. 

\anchor T5d46
<table>
<caption align = "top">
\htmlonly
Table 5.46
\endhtmlonly
Specification detail for the pof darts method
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>pof darts method
<td>\c pof_darts
<td>none
<td>Required group
<td>N/A
<tr>
<td>Number of samples used for each response level 
<td>\c samples
<td>integer
<td>Required
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>Randomly generated seed
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
</table>

\subsubsection MethodNonDPCE Polynomial chaos expansion method
<!-- dakota subcat polynomial_chaos -->

The polynomial chaos expansion (PCE) is a general framework for
the approximate representation of random response functions in terms
of finite-dimensional series expansions in standardized random variables

\f[R = \sum_{i=0}^P \alpha_i \Psi_i(\xi) \f]

where \f$\alpha_i\f$ is a deterministic coefficient, \f$\Psi_i\f$ is a
multidimensional orthogonal polynomial and \f$\xi\f$ is a vector of
standardized random variables.  An important distinguishing feature of
the methodology is that the functional relationship between random
inputs and outputs is captured, not merely the output statistics as in
the case of many nondeterministic methodologies. %Dakota provides
access to PCE methods through the NonDPolynomialChaos class.  Refer to
the Uncertainty Quantification Capabilities chapter of the Users
Manual [\ref UsersMan "Adams et al., 2010"] for additional information
on the PCE algorithm.

To select the basis \f$\Psi_i\f$ of the expansion, three approaches
may be employed, as previously shown in Tables \ref T5d37 "5.37", 
\ref T5d38 "5.38", and \ref T5d39 "5.39":
Wiener, Askey, and Extended.  The Wiener option uses a Hermite
orthogonal polynomial basis for all random variables and employs the
same nonlinear variable transformation as the local and global
reliability methods (and therefore has the same variable support).
The Askey option, however, employs an extended basis of Hermite,
Legendre, Laguerre, Jacobi, and generalized Laguerre orthogonal
polynomials.  The Extended option avoids the use of any nonlinear
variable transformations by augmenting the Askey approach with
numerically-generated orthogonal polynomials for non-Askey probability
density functions.  The selection of Wiener versus Askey versus
Extended is partially automated and partially under the user's
control.  The Extended option is the default and supports only
Gaussian correlations (see Tables \ref T5d37 "5.37", 
\ref T5d38 "5.38", and \ref T5d39 "5.39").  This default can
be overridden by the user by supplying the keyword \c askey to request
restriction to the use of Askey bases only or by supplying the keyword
\c wiener to request restriction to the use of exclusively Hermite
bases.  If needed to support prescribed correlations (not under user
control), the Extended and Askey options will fall back to the Wiener
option <EM>on a per variable basis</EM>.  If the prescribed
correlations are also unsupported by Wiener expansions, then %Dakota
will exit with an error.  Additional details include:
- Askey polynomial selections include Hermite for normal (optimal) as 
  well as bounded normal, lognormal, bounded lognormal, gumbel, frechet, 
  and weibull (sub-optimal); Legendre for uniform (optimal) as well as
  loguniform, triangular, and bin-based histogram (sub-optimal);
  Laguerre for exponential (optimal); Jacobi for beta (optimal); and
  generalized Laguerre for gamma (optimal).
- Extended polynomial selections replace each of the sub-optimal Askey 
  basis selections with numerically-generated polynomials that are 
  orthogonal to the prescribed probability density functions (for bounded 
  normal, lognormal, bounded lognormal, loguniform, triangular, gumbel, 
  frechet, weibull, and bin-based histogram).

The \c p_refinement keyword specifies the usage of automated
polynomial order refinement, which can be either \c uniform or \c
dimension_adaptive.  The \c dimension_adaptive option is supported for
the tensor-product quadrature and Smolyak sparse grid options (see
\ref T5d47 "Table 5.47" below), and \c uniform is supported for tensor
and sparse grids as well as regression approaches (\c collocation_points 
or \c collocation_ratio, see \ref T5d48 "Table 5.48" below).  Each of
these refinement cases makes use of the \c max_iterations and \c
convergence_tolerance method independent controls (see \ref T5d1
"Table 5.1"); the former control limits the number of refinement 
iterations, and the latter control terminates refinement when the
two-norm of the change in the response covariance matrix (or, in
goal-oriented approaches, the two-norm of change in the statistical
quantities of interest (QOI)) falls below the tolerance.  The \c
dimension_adaptive case can be further specified to utilize \c sobol,
\c decay, or \c generalized refinement controls.  The former two cases
employ anisotropic tensor/sparse grids in which the anisotropic
dimension preference (leading to anisotropic integrations/expansions
with differing refinement levels for different random dimensions) is
determined using either total Sobol' indices from variance-based
decomposition (\c sobol case: high indices result in high dimension
preference) or using spectral coefficient decay rates from a rate
estimation technique similar to Richardson extrapolation (\c decay
case: low decay rates result in high dimension preference).  In these
two cases as well as the \c uniform refinement case, the \c
quadrature_order or \c sparse_grid_level are ramped by one on each
refinement iteration until either of the two convergence controls is
satisfied.  For the \c uniform refinement case with regression 
approaches, the \c expansion_order is ramped by one on each iteration 
while the oversampling ratio (either defined by \c collocation_ratio
or inferred from \c collocation_points based on the initial expansion) 
is held fixed.  Finally, the \c generalized \c dimension_adaptive case 
is the default adaptive approach; it refers to the generalized sparse
grid algorithm, a greedy approach in which candidate index sets are 
evaluated for their impact on the statistical QOI, the most
influential sets are selected and used to generate additional
candidates, and the index set frontier of a sparse grid is evolved in
an unstructured and goal-oriented manner (refer to User's Manual PCE
descriptions for additional specifics).

The \c variance_based_decomp and \c drop_tolerance are also the same
as those described in \ref MethodNonDMC, but since the default VBD
outputs for PCE include main and total effects and all interactions
present within the terms of the expansion, the \c interaction_order
option has been added to allow suppression of higher-order
interactions, since the output volume (and memory and compute
consumption) of these results could be extensive for high dimensional
problems (note: the previous \c univariate_effects specification is
equivalent to \c interaction_order = 1 in the current specification).
Similar to suppression of interactions is the covariance control,
which can be selected to be \c diagonal_covariance or \c
full_covariance, with the former supporting suppression of the
off-diagonal covariance terms (to again save compute and memory
resources and reduce output volume).  The \c normalized specification
requests output of PCE coefficients that correspond to normalized
orthogonal basis polynomials.  This has no effect on the expansion or
statistics generated from it (each multidimensional basis polynomial
is divided by its norm, such that the corresponding coefficient is
multiplied by this norm to result in the same expansion); rather, it
is primarily useful for analysis of decay rates within the coefficient
spectrum.  The \c import_points_file and \c export_points_file
specifications are as described in \ref ModelSurrG, (the use of an
embedded global surrogate model necessitates repeating selected
surrogate model specifications within the method specification). A PCE
can be read in or exported to a file using \c import_expansion_file and 
\c export_expansion_file respectively.

As for \ref MethodNonDMC and \ref MethodNonDGlobalRel, 
The default behavior is to form expansions over aleatory 
uncertain continuous variables.  To form expansions 
over a broader set of variables, one needs to specify 
\c active followed by \c state, \c epistemic, \c design, or \c all 
in the variables specification block. 
For continuous design, continuous state, and continuous
epistemic uncertain variables included in the expansion,
Legendre chaos bases are used to model the bounded intervals for these
variables.  However, these variables are not assumed to have any
particular probability distribution, only that they are independent
variables.  Moreover, when probability integrals are evaluated, only
the aleatory random variable domain is integrated, leaving behind a
polynomial relationship between the statistics and the remaining
design/state/epistemic variables.

\ref T5d47 "Table 5.47" shows these general PCE controls and it, along
with Tables \ref T5d48 "5.48", \ref T5d49 "5.49", and \ref T5d51 "5.51" 
to follow, provide the details of the polynomial chaos expansion 
specifications beyond those of \ref T5d36 "Table 5.36".

\anchor T5d47
<table>
<caption align = "top">
\htmlonly
Table 5.47
\endhtmlonly
Specification detail for polynomial chaos expansion method: general controls.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Polynomial chaos expansion method
<td>\c polynomial_chaos
<td>none
<td>Required group
<td>N/A
<tr>
<td>Alternate basis of orthogonal polynomials
<td>\c askey | \c wiener
<td>none
<td>Optional
<td>Extended basis of orthogonal polynomials (Askey + numerically generated)
<tr>
<td>Automated polynomial order refinement
<td>\c p_refinement
<td>\c uniform | \c dimension_adaptive
<td>Optional group
<td>No p-refinement
<tr>
<td>Dimension-adaptive refinement control
<td>\c sobol | \c decay | \c generalized
<td>none
<td>Optional group
<td>\c generalized
<tr>
<td>Variance-based decomposition (VBD)
<td>\c variance_based_decomp
<td>none
<td>Optional group
<td>VBD indices not computed/printed
<tr>
<td>Restriction of order of VBD interations
<td>\c interaction_order
<td>integer > 0
<td>Optional
<td>Unrestricted (VBD includes all interaction orders present in the expansion)
<tr>
<td>VBD tolerance for omitting small indices
<td>\c drop_tolerance
<td>real
<td>Optional
<td>All VBD indices displayed
<tr>
<td>Covariance control
<td>\c diagonal_covariance | \c full_covariance
<td>none
<td>Optional
<td>\c diagonal_covariance for response vector > 10; else \c full_covariance
<tr>
<td>Output PCE coefficients corresponding to normalized basis
<td>\c normalized
<td>none
<td>Optional
<td>PCE coefficients correspond to unnormalized basis polynomials
<tr>
<td>File name for points to be imported for forming a PCE (unstructured grid assumed)
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the PCE
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for importing expansion values and multi index to build a PCE
<td>\c import_expansion_file
<td>string
<td>Optional
<td>annotated
<tr>
<td>File name for exporting the coefficients and multi-index of a PCE 
<td>\c export_expansion_file
<td>string
<td>Optional
<td>no expansion import from a file
<tr>
</table>

To obtain the coefficients \f$\alpha_i\f$ of the expansion, six
options are provided and the specification details for these options
are provided in Tables \ref T5d48 "5.48" and \ref T5d49 "5.49":

<ol>
<li> multidimensional integration by a tensor-product of Gaussian
     quadrature rules (specified with \c quadrature_order, and, 
     optionally, \c dimension_preference).  The default rule
     selection is to employ \c non_nested Gauss rules including
     Gauss-Hermite (for normals or transformed normals),
     Gauss-Legendre (for uniforms or transformed uniforms),
     Gauss-Jacobi (for betas), Gauss-Laguerre (for exponentials),
     generalized Gauss-Laguerre (for gammas), and
     numerically-generated Gauss rules (for other distributions when
     using an Extended basis).  For the case of \c p_refinement or the
     case of an explicit \c nested override, Gauss-Hermite rules are
     replaced with Genz-Keister nested rules and Gauss-Legendre rules
     are replaced with Gauss-Patterson nested rules, both of which
     exchange lower integrand precision for greater point reuse.  
     By specifying a \c dimension_preference, where higher preference
     leads to higher order polynomial resolution, the tensor grid may
     be rendered anisotropic.  The dimension specified to have 
     highest preference will be set to the specified \c quadrature_order
     and all other dimensions will be reduced in proportion to their
     reduced preference; any non-integral portion is truncated.
     To synchronize with tensor-product integration, a tensor-product
     expansion is used, where the order \f$p_i\f$ of the expansion in
     each dimension is selected to be half of the integrand precision
     available from the rule in use, rounded down.  In the case of
     non-nested Gauss rules with integrand precision \f$2m_i-1\f$,
     \f$p_i\f$ is one less than the quadrature order \f$m_i\f$ in each
     dimension (a one-dimensional expansion contains the same number 
     of terms, \f$p+1\f$, as the number of Gauss points).  The 
     total number of terms, \e N, in a tensor-product expansion 
     involving \e n uncertain input variables is 
     \f[N ~=~ 1 + P ~=~ \prod_{i=1}^{n} (p_i + 1)\f]
     In some advanced use cases (e.g., multifidelity UQ), multiple
     grid resolutions can be employed; for this reason, the \c 
     quadrature_order specification supports an array input.  In the
     case of an output level of verbose or higher, the quadrature
     points and weights are exported in tabular form to the file \c 
     dakota_quadrature_tabular.dat.
<li> multidimensional integration by the Smolyak sparse grid method
     (specified with \c sparse_grid_level and, optionally, \c
     dimension_preference).  The underlying one-dimensional
     integration rules are the same as for the tensor-product
     quadrature case; however, the default rule selection is \c nested
     for sparse grids (Genz-Keister for normals/transformed normals
     and Gauss-Patterson for uniforms/transformed uniforms).  This
     default can be overridden with an explicit \c non_nested
     specification (resulting in Gauss-Hermite for normals/transformed
     normals and Gauss-Legendre for uniforms/transformed uniforms).
     As for tensor quadrature, the \c dimension_preference
     specification enables the use of anisotropic sparse grids (refer
     to the PCE description in the User's Manual for the anisotropic
     index set constraint definition).  Similar to anisotropic tensor
     grids, the dimension with greatest preference will have
     resolution at the full \c sparse_grid_level and all other
     dimension resolutions will be reduced in proportion to their
     reduced preference.  For PCE with either isotropic or anisotropic
     sparse grids, a summation of tensor-product expansions is used,
     where each anisotropic tensor-product quadrature rule underlying
     the sparse grid construction results in its own anisotropic
     tensor-product expansion as described in case 1.  These
     anisotropic tensor-product expansions are summed into a sparse
     PCE using the standard Smolyak summation (again, refer to the
     User's Manual for additional details).  As for \c quadrature_order,
     the \c sparse_grid_level specification admits an array input for
     enabling specification of multiple grid resolutions used by certain
     advanced solution methodologies, and in the
     case of an output level of verbose or higher, the sparse grid
     points and weights are exported in tabular form to the file \c 
     dakota_sparse_tabular.dat.
<li> multidimensional integration by Stroud cubature rules [\ref
     Stroud1971 "Stroud, 1971"] and extensions 
     [\ref Xiu2008 "Xiu, 2008"], as specified with \c cubature_integrand.  
     A total-order
     expansion is used, where the isotropic order \e p of the
     expansion is half of the integrand order, rounded down.  The
     total number of terms \e N for an isotropic total-order expansion
     of order \e p over \e n variables is given by
     \f[N~=~1 + P ~=~1 + \sum_{s=1}^{p} {\frac{1}{s!}} 
     \prod_{r=0}^{s-1} (n + r) ~=~\frac{(n+p)!}{n!p!}\f]
     Since the maximum integrand order is currently five for normal
     and uniform and two for all other types, at most second- and
     first-order expansions, respectively, will be used.  As a result,
     cubature is primarily useful for global sensitivity analysis,
     where the Sobol' indices will provide main effects and, at most,
     two-way interactions.  In addition, the random variable set must
     be independent and identically distributed (\e iid), so the use
     of \c askey or \c wiener transformations may be required to
     create \e iid variable sets in the transformed space (as well as
     to allow usage of the higher order cubature rules for normal and
     uniform).  Note that global sensitivity analysis often assumes
     uniform bounded regions, rather than precise probability
     distributions, so the \e iid restriction would not be problematic
     in that case.  In the case of an output level of verbose or
     higher, the cubature points and weights are exported in tabular
     form to the file \c dakota_cubature_tabular.dat.

\anchor T5d48
<table>
<caption align = "top">
\htmlonly
Table 5.48
\endhtmlonly
Specification detail for polynomial chaos expansion method: quadrature, 
cubature, and sparse grid approaches.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Quadrature order for PCE coefficient estimation
<td>\c quadrature_order
<td>list of integers (one per grid resolution)
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Sparse grid level for PCE coefficient estimation
<td>\c sparse_grid_level
<td>list of integers (one per grid resolution)
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Cubature integrand order for PCE coefficient estimation
<td>\c cubature_integrand
<td>integer (1, 2, 3, or 5 for normal or uniform; 1 or 2 for exponential, beta, or gamma, 2 for all other distribution types)
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Dimension preference for anisotropic tensor and sparse grids
<td>\c dimension_preference
<td>list of reals
<td>Optional
<td>isotropic grids
<tr>
<td>Sparse grid growth rule restriction
<td>\c restricted | \c unrestricted
<td>none
<td>Optional group
<td>\c restricted (except for generalized sparse grids)
<tr>
<td>Integration rule point nesting for \c quadrature_order or \c sparse_grid_level
<td>\c nested | \c non_nested
<td>None
<td>Optional
<td>quadrature: \c non_nested unless automated refinement; sparse grids: \c nested
</table>

<li> multidimensional integration by Latin hypercube sampling
     (specified with \c expansion_samples).  In this case, the
     expansion order \e p cannot be inferred from the numerical
     integration specification and it is necessary to provide an
     \c expansion_order to specify \e p for a total-order expansion.
<li> linear regression (specified with either \c collocation_points or
     \c collocation_ratio).  A total-order expansion is used and must
     be specified using \c expansion_order as described in the
     previous option.  <!-- Given \e p or \e N, the total number of
     collocation points (including any sample reuse) must be at least
     \e N, and an oversampling is generally advisable.  To more easily
     satisfy this requirement (i.e., to avoid requiring the user to
     calculate \e N from \e n and \e p), --> To avoid requiring the 
     user to calculate \e N from \e n and \e p), the \c collocation_ratio 
     allows for specification of a constant factor applied to \e
     N (e.g., \c collocation_ratio = \c 2. produces samples = \e 2N).
     In addition, the default linear relationship with \e N can be
     overridden using a real-valued exponent specified using \c
     ratio_order.  In this case, the number of samples becomes
     \f$cN^o\f$ where \f$c\f$ is the \c collocation_ratio and \f$o\f$
     is the \c ratio_order.  The \c use_derivatives flag informs the
     regression approach to include derivative matching equations
     (limited to gradients at present) in the least squares solutions,
     enabling the use of fewer collocation points for a given
     expansion order and dimension (number of points required becomes
     \f$\frac{cN^o}{n+1}\f$).  When admissible, a constrained least
     squares approach is employed in which response values are first
     reproduced exactly and error in reproducing response derivatives
     is minimized.  Two collocation grid options are supported: the
     default is Latin hypercube sampling ("point collocation"), and an
     alternate approach of "probabilistic collocation" is also
     available through inclusion of the \c tensor_grid keyword.  In
     this alternate case, the collocation grid is defined using a
     subset of tensor-product quadrature points: the order of the 
     tensor-product grid is selected as one more than the expansion
     order in each dimension (to avoid sampling at roots of the basis 
     polynomials) and then the tensor multi-index is uniformly sampled
     to generate a non-repeated subset of tensor quadrature points.
     <!-- the order of the tensor-product grid is the minimum required
     to meet or exceed the point requirement, and then this set of
     points is filtered down to the requirement based on the subset of
     points having highest product integration weight.  In our experience,
     the alternate probabilistic collocation approach using a structured
     grid tends to suffer from ill-conditioning more quickly than the
     default point collocation approach using an unstructured grid. -->
<li> coefficient import from a file (specified with \c
     import_expansion_file).  No type of expansion truncation is assumed 
     the file must simply specified the coefficient value and multi-index.

\anchor T5d49
<table>
<caption align = "top">
\htmlonly
Table 5.49
\endhtmlonly
Specification detail for polynomial chaos expansion method: expansion 
sampling, regression, and expansion import options.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Expansion order
<td>\c expansion_order
<td>list of integers (scalar input accepted for isotropic)
<td>Required
<td>N/A
<tr>
<td>Number simulation samples to estimate coeffs
<td>\c expansion_samples
<td>integer
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Use incremental LHS for \c expansion_samples
<td>\c incremental_lhs
<td>none
<td>Optional
<td>no sample reuse in coefficient estimation
<tr>
<td>Number collocation points to estimate coeffs
<td>\c collocation_points
<td>integer
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Collocation point oversampling ratio to estimate coeffs
<td>\c collocation_ratio
<td>real
<td>Required (1 of 7 selections)
<td>N/A
<tr>
<td>Order of collocation oversampling relationship
<td>\c ratio_order
<td>real
<td>Optional
<td>1.
<tr>
<td>Derivative usage with \c collocation_{points or \c ratio}
<td>\c use_derivatives
<td>none
<td>Optional
<td>estimate by function values alone
<tr>
<td>Reuse points flag with \c collocation_{points or \c ratio}
<td>\c reuse_points
<td>none
<td>Optional
<td>no sample reuse in coefficient estimation
<tr>
<td>Tensor grid flag with \c collocation_{points or \c ratio}
<td>\c tensor_grid
<td>none
<td>Optional
<td>regression with LHS sample set ("point collocation")
<tr>
<td>Import file for PCE coefficients
<td>\c import_expansion_file
<td>string
<td>Required (1 of 7 selections)
<td>N/A
</table>

If \c collocation_points or \c collocation_ratio is specified, the PCE
coefficients will be determined by regression. \ref T5d50 "Table 5.50"
lists a set of optional regression specifications.  If no regression
specification is provided, appropriate defaults are defined.
Specifically SVD-based least-squares will be used for solving
over-determined systems and under-determined systems will be solved
using LASSO. For the situation when the number of function values is
smaller than the number of terms in a PCE, but the total number of
samples including gradient values is greater than the number of terms,
the resulting over-determined system will be solved using equality
constrained least squares.  Technical information on the various
methods listed below can be found in the Linear regression section of
the Theory Manual. Some of the regression methods (OMP, LASSO, and
LARS) are able to produce a set of possible PCE coefficient vectors
(see the Linear regression section in the Theory Manual). If cross
validation is inactive, then only one solution, consistent with the \c
noise_tolerance, will be returned. If cross validation is active,
%Dakota will choose between possible coefficient vectors found
internally by the regression method across the set of expansion orders
(1,...,expansion_order) and the set of specified noise tolerances and
return the one with the lowest cross validation error indicator.

\anchor T5d50
<table>
<caption align = "top">
\htmlonly
Table 5.50
\endhtmlonly
Specification detail for polynomial chaos expansion method: additional regression options.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Least squares regression
<td>\c least_squares
<td>svd | equality_constrained
<td>Optional
<td>svd
<tr>
<td>L1 minimization via Basis Pursuit (BP)
<td>\c basis_pursuit
<td>none
<td>Optional
<td>N/A
<tr>
<td>L1 minimization via Basis Pursuit DeNoising (BPDN)
<td>\c basis_pursuit_denoising
<td>none
<td>Optional
<td>N/A
<tr>
<td>L1 minimization via Orthogonal Matching Pursuit (OMP)
<td>\c orthogonal_matching_pursuit
<td>real
<td>Optional
<td>N/A
<tr>
<td>L1 minimization via Least Absolute Shrinkage Operator (LASSO)
<td>\c least_absolute_shrinkage
<td>none
<td>Optional
<td>N/A
<tr>
<td>L1 minimization via Least Angle Regression (LARS)
<td>\c least_angle_regression
<td>none
<td>Optional
<td>N/A
<tr>
<td>Orthogonal Least Interpolation (OLI)
<td>\c orthogonal_least_interpolation
<td>none
<td>Optional
<td>N/A
<tr>
<td>Noise tolerance(s) used in conjuction with BPDN, OMP, LARS, LASSO 
as an exit condition 
<td>\c noise_tolerance
<td>list of reals
<td>Optional
<td>1e-3 for BPDN, 0. otherwise (algorithms run until termination)
<tr>
<td>l2_penalty used for elastic net modification of LASSO
<td>\c l2_penalty
<td>real
<td>Optional
<td>0. (reverts to standard LASSO formulation)
<tr>
<td>Specify whether to use cross validation
<td>\c cross_validation
<td>none
<td>Optional
<td>N/A
</table>
</ol>

If \e n is small (e.g., two or three), then tensor-product Gaussian
quadrature is quite effective and can be the preferred choice.  For
moderate to large \e n (e.g., five or more), tensor-product quadrature
quickly becomes too expensive and the sparse grid and regression
approaches are preferred.  <!-- For large \e n (e.g., more than ten),
point collocation may begin to suffer from ill-conditioning and sparse
grids are generally recommended. --> Random sampling for coefficient
estimation is generally not recommended due to its slow convergence
rate.  <!--, although it does hold the advantage that the simulation
budget is more flexible than that required by the other approaches.-->
For incremental studies, approaches 4 and 5 support reuse of previous
samples through the \c incremental_lhs (refer to \ref MethodNonDMC for
description of incremental LHS) and \c reuse_samples (refer to \ref
ModelSurrG for description of the "all" option of sample reuse)
specifications, respectively.

In the quadrature and sparse grid cases, growth rates for nested and
non-nested rules can be synchronized for consistency.  For a
non-nested Gauss rule used within a sparse grid, linear
one-dimensional growth rules of \f$m=2l+1\f$ are used to enforce odd
quadrature orders, where \e l is the grid level and \e m is the number
of points in the rule.  The precision of this Gauss rule is then
\f$i=2m-1=4l+1\f$.  For nested rules, order growth with level is
typically exponential; however, the default behavior is to restrict
the number of points to be the lowest order rule that is available
that meets the one-dimensional precision requirement implied by either
a level \e l for a sparse grid (\f$i=4l+1\f$) or an order \e m for a
tensor grid (\f$i=2m-1\f$).  This behavior is known as "restricted
growth" or "delayed sequences."  To override this default behavior in
the case of sparse grids, the \c unrestricted keyword can be used; it
cannot be overridden for tensor grids using nested rules since it also
provides a mapping to the available nested rule quadrature orders.  An
exception to the default usage of restricted growth is the \c
dimension_adaptive \c p_refinement \c generalized sparse grid case
described previously, since the ability to evolve the index sets of a
sparse grid in an unstructured manner eliminates the motivation for
restricting the exponential growth of nested rules.

Additional specifications include the level mappings described in \ref
MethodNonD and the \c sample_type, \c samples, \c seed, \c fixed_seed,
and \c rng specifications described in \ref MethodNonDMC, where the \c
sample_type options are restricted to \c random and \c lhs.  Each of
these sampling specifications refer to sampling on the PCE
approximation for the purposes of generating approximate statistics,
which should be distinguished from simulation sampling for generating
the chaos coefficients as described in options 4 and 5 above (although
options 4 and 5 will share the \c sample_type, \c seed, and \c rng
settings, if provided).  The \c probability_refinement specification
is identical to that of \ref MethodNonDLocalRel, with the
implementation difference that density reweighting must account for
additional non-Gaussian cases.  This option allows for refinement of
probability and generalized reliability results using importance
sampling. \ref T5d51 "Table 5.51" provide the details of these
sampling specifications for polynomial chaos.

\anchor T5d51
<table>
<caption align = "top">
\htmlonly
Table 5.51
\endhtmlonly
Specification detail for polynomial chaos expansion method: sampling controls.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Sampling type (random sampling for and on expansion)
<td>\c sample_type
<td>\c random | \c lhs
<td>Optional group
<td>\c lhs
<tr>
<td>Number of samples on PCE for generating statistics
<td>\c samples
<td>integer
<td>Optional (required if sampling-based statistics are requested)
<td>0
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Fixed seed flag
<td>\c fixed_seed
<td>none
<td>Optional
<td>seed not fixed: sampling patterns are variable among multiple PCE runs
<tr>
<td>Random number generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Importance sampling refinement
<td>\c probability_refinement
<td>\c import | \c adapt_import | \c mm_adapt_import
<td>Optional group
<td>No sampling refinement
<tr>
<td>Refinement samples
<td>\c refinement_samples
<td>integer
<td>Optional
<td>1000 (per iteration, if adaptive)
</table>

The advanced use case of multifidelity UQ automatically becomes active
if the model selected for iteration by the method specification is a
multifidelity surrogate model (refer to \ref ModelSurrH).  In this
case, an expansion will first be formed for the model discrepancy (the
difference between response results if \c additive \c correction or
the ratio of results if \c multiplicative \c correction), using the
first \c quadrature_order or \c sparse_grid_level value along with any
specified refinement strategy.  Second, an expansion will be formed
for the low fidelity surrogate model, using the second \c
quadrature_order or \c sparse_grid_level value (if present; the first
is reused if not present) along with any specified refinement
strategy.  Then the two expansions are combined (added or multiplied)
into an expansion that approximates the high fidelity model, from
which the final set of statistics are generated.  For polynomial chaos
expansions, this high fidelity expansion can differ significantly in 
form from the low fidelity and discrepancy expansions, particularly in
the \c multiplicative case where it is expanded to include all of the
basis products.


\subsubsection MethodNonDSC Stochastic collocation method
<!-- dakota subcat stoch_collocation -->

The stochastic collocation (SC) method is very similar to the PCE
method described above, with the key difference that the orthogonal
polynomial basis functions are replaced with interpolation polynomial
bases.  The interpolation polynomials may be either local or global
and either value-based or gradient-enhanced.  In the local case,
valued-based are piecewise linear splines and gradient-enhanced are
piecewise cubic splines, and in the global case, valued-based are
Lagrange interpolants and gradient-enhanced are Hermite interpolants. 
A value-based expansion takes the form

\f[R = \sum_{i=1}^{N_p} r_i L_i(\xi) \f]

where \f$N_p\f$ is the total number of collocation points, \f$r_i\f$
is a response value at the \f$i^{th}\f$ collocation point, \f$L_i\f$
is the \f$i^{th}\f$ multidimensional interpolation polynomial, and
\f$\xi\f$ is a vector of standardized random variables.  The
\f$i^{th}\f$ interpolation polynomial assumes the value of 1 at the
\f$i^{th}\f$ collocation point and 0 at all other collocation points,
involving either a global Lagrange polynomial basis or local piecewise
splines.  It is easy to see that the approximation reproduces the
response values at the collocation points and interpolates between
these values at other points.  A gradient-enhanced expansion (selected
via the \c use_derivatives keyword) involves both type 1 and type 2
basis functions as follows:

\f[R = \sum_{i=1}^{N_p} [ r_i H^{(1)}_i(\xi)
     + \sum_{j=1}^n \frac{dr_i}{d\xi_j} H^{(2)}_{ij}(\xi) ] \f]

where the \f$i^{th}\f$ type 1 interpolant produces 1 for the value at
the \f$i^{th}\f$ collocation point, 0 for values at all other
collocation points, and 0 for derivatives (when differentiated) at all
collocation points, and the \f$ij^{th}\f$ type 2 interpolant produces
0 for values at all collocation points, 1 for the \f$j^{th}\f$
derivative component at the \f$i^{th}\f$ collocation point, and 0 for
the \f$j^{th}\f$ derivative component at all other collocation points.
Again, this expansion reproduces the response values at each of the
collocation points, and when differentiated, also reproduces each
component of the gradient at each of the collocation points.  Since
this technique includes the derivative interpolation explicitly, it
eliminates issues with matrix ill-conditioning that can occur in the
gradient-enhanced PCE approach based on regression.  However, the
calculation of high-order global polynomials with the desired
interpolation properties can be similarly numerically challenging such
that the use of local cubic splines is recommended due to numerical
stability.

Thus, in PCE, one forms coefficients for known orthogonal polynomial
basis functions, whereas SC forms multidimensional interpolation
functions for known coefficients.  %Dakota provides access to SC
methods through the NonDStochCollocation class.  Refer to the
Uncertainty Quantification Capabilities chapter of the Users Manual
[\ref UsersMan "Adams et al., 2010"] for additional information on the
SC algorithm.

As for \ref MethodNonDPCE, the orthogonal polynomials used in defining
the Gauss points that make up the interpolation grid are governed by
the Wiener, Askey, or Extended options.  The Wiener option uses
interpolation points from Gauss-Hermite (non-nested) or Genz-Keister
(nested) integration rules for all random variables and employs the
same nonlinear variable transformation as the local and global
reliability methods (and therefore has the same variable support).
The Askey option, however, employs interpolation points from
Gauss-Hermite (Genz-Keister if nested), Gauss-Legendre
(Gauss-Patterson if nested), Gauss-Laguerre, Gauss-Jacobi, and
generalized Gauss-Laguerre quadrature.  The Extended option avoids the
use of any nonlinear variable transformations by augmenting the Askey
approach with Gauss points from numerically-generated orthogonal
polynomials for non-Askey probability density functions.  As for PCE,
the Wiener/Askey/Extended selection defaults to Extended, can be
overridden by the user using the keywords \c askey or \c wiener, and
automatically falls back from Extended/Askey to Wiener on a per
variable basis as needed to support prescribed correlations.  Unlike
PCE, however, SC also supports the option of \c piecewise local basis
functions.  These are piecewise linear splines, or in the case of
gradient-enhanced interpolation via the \c use_derivatives
specification, piecewise cubic Hermite splines.  Both of these basis
selections provide local support only over the range from the
interpolated point to its nearest 1D neighbors (within a tensor grid
or within each of the tensor grids underlying a sparse grid), which
exchanges the fast convergence of global bases for smooth functions
for robustness in the representation of nonsmooth response functions
(that can induce Gibbs oscillations when using high-order global basis
functions).  When local basis functions are used, the usage of
nonequidistant collocation points (e.g., the Gauss point selections
described above) is not well motivated, so equidistant Newton-Cotes
points are employed in this case, and all random variable types are
transformed to standard uniform probability space (refer to Tables
\ref T5d37 "5.37", \ref T5d38 "5.38", and \ref T5d39 "5.39" for
variable types for which this transformation is supported).  The
global gradient-enhanced interpolants (Hermite interpolation
polynomials) are also restricted to uniform or transformed uniform
random variables (due to the need to compute collocation weights by
integration of the basis polynomials) and share the variable support
shown in these tables for Piecewise SE.  Due to numerical instability
in these high-order basis polynomials, they are deactivated by default
but can be activated by developers using a compile-time switch.

Another distinguishing characteristic of stochastic collocation
relative to polynomial chaos is the ability to reformulate the
interpolation problem from a \c nodal interpolation approach into a \c
hierarchical formulation in which each new level of interpolation
defines a set of incremental refinements (known as hierarchical
surpluses) layered on top of the interpolants from previous levels.
This formulation lends itself naturally to uniform or adaptive
refinement strategies, since the hierarchical surpluses can be
interpreted as error estimates for the interpolant.  Either global or
local/piecewise interpolants in either value-based or
gradient-enhanced approaches can be formulated using \c hierarchical
interpolation.  The primary restriction for the hierarchical case is
that it currently requires a sparse grid approach using nested
quadrature rules (Genz-Keister, Gauss-Patterson, or Newton-Cotes for
standard normals and standard uniforms in a transformed space: Askey,
Wiener, or Piecewise settings may be required), although this
restriction can be relaxed in the future.  A selection of \c
hierarchical interpolation will provide greater precision in the
increments to mean, standard deviation, covariance, and
reliability-based level mappings induced by a grid change within
uniform or goal-oriented adaptive refinement approaches (see following
section).

Automated expansion refinement can be selected as either \c
p_refinement or \c h_refinement, and either refinement specification
can be either \c uniform or \c dimension_adaptive.  The \c
dimension_adaptive case can be further specified as either \c sobol or
\c generalized (\c decay not supported).  Each of these automated
refinement approaches makes use of the \c max_iterations and \c
convergence_tolerance iteration controls (see \ref T5d1 "Table 5.1").
The \c h_refinement specification involves use of the same piecewise
interpolants (linear or cubic Hermite splines) described above for the
\c piecewise specification option (it is not necessary to redundantly
specify \c piecewise in the case of \c h_refinement).  In future
releases, the \c hierarchical interpolation approach will enable local
refinement in addition to the current \c uniform and \c
dimension_adaptive options.

The \c variance_based_decomp, covariance, and \c export_points_file
controls are identical to that described in \ref MethodNonDPCE.  As a
default, the interpolation will be performed over continuous aleatory
uncertain variables.  To expand the dimensionality of the
interpolation to include continuous design, state, and epistemic
uncertain variables, it is necessary to specify which variables are
active in the variables specification block.  Interpolation points for
these dimensions are based on Gauss-Legendre rules if non-nested,
Gauss-Patterson rules if nested, and Newton-Cotes points in the case
of piecewise bases.  Again, when probability integrals are evaluated,
only the aleatory random variable domain is integrated, leaving behind
a polynomial relationship between the statistics and the remaining
design/state/epistemic variables.

\ref T5d52 "Table 5.52" shows these general SC controls, and it along
with \ref T5d53 "Table 5.53" to follow provide the details of the
SC specifications beyond those of Tables \ref T5d36 "5.36" and 
\ref T5d50 "5.50".

\anchor T5d52
<table>
<caption align = "top">
\htmlonly
Table 5.52
\endhtmlonly
Specification detail for stochastic collocation method: general controls.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Stochastic collocation method
<td>\c stoch_collocation
<td>none
<td>Required group
<td>N/A
<tr>
<td>Alternate basis selections for defining collocation points/weights
<td>\c askey | \c wiener | \c piecewise
<td>none
<td>Optional
<td>Gauss points/weights from extended set of global orthogonal polynomials (Askey + numerically generated)
<tr>
<td>Basis formulation
<td>\c nodal | \c hierarchical
<td>none
<td>Optional
<td>\c nodal
<tr>
<td>Derivative enhancement flag
<td>\c use_derivatives
<td>none
<td>Optional
<td>interpolation based on function values alone
<tr>
<td>Automated expansion refinement
<td>\c p_refinement | \c h_refinement
<td>\c uniform | \c dimension_adaptive
<td>Optional group
<td>No refinement
<tr>
<td>Dimension-adaptive refinement control
<td>\c sobol | \c generalized
<td>none
<td>Optional group
<td>\c generalized
<tr>
<td>Variance-based decomposition (VBD)
<td>\c variance_based_decomp
<td>none
<td>Optional group
<td>VBD indices not computed/printed
<tr>
<td>Restriction of order of VBD interations
<td>\c interaction_order
<td>integer > 0
<td>Optional
<td>Unrestricted (VBD includes all interaction orders present in the expansion)
<tr>
<td>VBD tolerance for omitting small indices
<td>\c drop_tolerance
<td>real
<td>Optional
<td>All VBD indices displayed
<tr>
<td>Covariance control
<td>\c diagonal_covariance | \c full_covariance
<td>none
<td>Optional
<td>\c diagonal_covariance for response vector > 10; else \c full_covariance
<tr>
<td>File name for exporting approximation-based samples from evaluating the interpolant
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>

To form the multidimensional interpolants \f$L_i\f$ of the expansion,
two options are provided and the specification details for these options
are provided in \ref T5d53 "Table 5.53".

<ol>
<li> interpolation on a tensor-product of Gaussian quadrature points
     (specified with \c quadrature_order and, optionally, \c
     dimension_preference for anisotropic tensor grids).  As for PCE,
     non-nested Gauss rules are employed by default, although the
     presence of \c p_refinement or \c h_refinement will result in
     default usage of nested rules for normal or uniform variables
     after any variable transformations have been applied (both
     defaults can be overridden using explicit \c nested or \c
     non_nested specifications).
<li> interpolation on a Smolyak sparse grid (specified with \c
     sparse_grid_level and, optionally, \c dimension_preference for
     anisotropic sparse grids) defined from Gaussian rules.  As for
     sparse PCE, nested rules are employed unless overridden with the
     \c non_nested option, and the growth rules are restricted unless
     overridden by the \c unrestricted keyword.

\anchor T5d53
<table>
<caption align = "top">
\htmlonly
Table 5.53
\endhtmlonly
Specification detail for stochastic collocation method: grid controls.
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Quadrature order for collocation points
<td>\c quadrature_order
<td>list of integers (one per grid resolution)
<td>Required (1 of 2 selections)
<td>N/A
<tr>
<td>Sparse grid level for collocation points
<td>\c sparse_grid_level
<td>list of integers (one per grid resolution)
<td>Required (1 of 2 selections)
<td>N/A
<tr>
<td>Dimension preference for anisotropic tensor and sparse grids
<td>\c dimension_preference
<td>list of reals
<td>Optional
<td>isotropic grids
<tr>
<td>Sparse grid growth rule restriction
<td>\c restricted | \c unrestricted
<td>none
<td>Optional group
<td>\c restricted (except for generalized sparse grids)
<tr>
<td>Integration rule point nesting
<td>\c nested | \c non_nested
<td>None
<td>Optional
<td>quadrature: \c non_nested unless automated refinement; sparse grids: \c nested
</table>
</ol>

If \e n is small, then tensor-product Gaussian quadrature is again the
preferred choice.  For larger \e n, tensor-product quadrature quickly
becomes too expensive and the sparse grid approach is preferred.  For
self-consistency in growth rates, nested rules employ restricted
exponential growth (with the exception of the \c dimension_adaptive \c
p_refinement \c generalized case) for consistency with the linear
growth used for non-nested Gauss rules (integrand precision
\f$i=4l+1\f$ for sparse grid level \e l and \f$i=2m-1\f$ for tensor
grid order \e m).

Additional specifications include the level mappings described in \ref
MethodNonD, the \c sample_type, \c samples, \c seed, \c fixed_seed,
and \c rng specifications described in \ref MethodNonDMC, and the \c
probability_refinement and \c refinement_samples specifications
described in \ref MethodNonDPCE.  Each of the sampling specifications
is identical to those for PCE shown in \ref T5d51 "Table 5.51" and
refer to sampling on the interpolant for the purposes of generating
approximate statistics, which should not be confused with collocation
evaluations used for forming the interpolant.  Finally, the process
for multifidelity UQ is identical to that described in \ref
MethodNonDPCE, with the exception that the high fidelity expansion
generated from combining the low fidelity and discrepancy expansions
retains the polynomial form of the low fidelity expansion (only the
coefficients are updated).


\subsection MethodNonDEpist Epistemic Uncertainty Quantification Methods

Epistemic uncertainty is also referred to as subjective uncertainty,
reducible uncertainty, model form uncertainty, or uncertainty due to
lack of knowledge.  Examples of epistemic uncertainty are little or no
experimental data for an unknown physical parameter, or the existence
of complex physics or behavior that is not included in the simulation
model of a system. Epistemic uncertainty can be modeled
probabilistically but is often modeled using non-probabilistic
approaches such as interval propagation, evidence theory, possibility
theory, information gap theory, etc.  In %Dakota, epistemic uncertainty
analysis is performed using interval analysis or Dempster-Shafer
theory of evidence.  Epistemic (or mixed aleatory-epistemic)
uncertainty may also be propagated through the use of the \ref
MethodNonDMC, although in this case, the output statistics are limited
to response intervals (any epistemic component suppresses all
probabilistic results).  Mixed uncertainty can also be addressed
through use of nested UQ (refer to the Users Manual 
[\ref UsersMan "Adams et al., 2010"] for %NestedModel
discussion and examples); in this case, epistemic and aleatory
analyses can be segregated and intervals on probabilistic results can
be reported.  A subtle distinction exists between \c sampling for
epistemic intervals and the \c lhs option of \c
global_interval_est: the former allows mixed aleatory-epistemic
uncertainty within a single level, whereas the latter supports only
epistemic variables and relies on nesting to address mixed
uncertainty.  In each of these cases, the \ref VarCEUV_Interval
specification is used to describe the epistemic uncertainty using
either simple intervals or basic probability assignments.
Note that for mixed UQ problems with both aleatory and epistemic 
variables, if the user defines the epistemic variables as intervals 
and aleatory variables as probability distribution types, 
the method \c sampling (in a simple, single-level study) will 
result in intervals only on the output.  Although the aleatory variables 
will be sampled according to their distributions, the output will only be 
reported as an interval given the presence of interval variables.  
There is also the option to perform nested sampling, where one 
separates the epistemic and aleatory uncertain variables, samples 
over epistemic variables in the outer loop and then samples the 
aleatory variables in the inner llop, resulting in intervals on statistics. 
The calculation of intervals on statistics can also be performed 
by using nested approaches with interval estimation or evidence methods 
in the outer loop and aleatory UQ methods on the 
inner loop such as stochastic expansion or reliability methods. 
More detail about these "intervals on statistics" approaches 
can be found in [\ref Eldred2009 "Eldred and Swiler, 2009"] 
and [\ref Eldred2011 "Eldred et al., 2011"]. 


\subsubsection MethodNonDLocalIntervalEst Local Interval Estimation
<!-- dakota subcat local_interval_est -->

In interval analysis, one assumes that nothing is known about
an epistemic uncertain variable except that its value lies
somewhere within an interval.  In this situation, it is NOT
assumed that the value has a uniform probability of occuring
within the interval.  Instead, the interpretation is that
any value within the interval is a possible value or a potential
realization of that variable.  In interval analysis, the
uncertainty quantification problem is one of determining the
resulting bounds on the output (defining the output interval)
given interval bounds on the inputs. Again, any output response
that falls within the output interval is a possible output
with no frequency information assigned to it.
 
We have the capability to perform interval analysis using either
local methods (\c local_interval_est) or global methods
(\c global_interval_est).
If the problem is amenable to local optimization
methods (e.g. can provide derivatives or use finite difference
method to calculate derivatives), then one can use local
methods to calculate these bounds.  \c local_interval_est
allows the user to specify either \c sqp which is sequential
quadratic programming, or \c nip which is a nonlinear interior point
method.  
\ref T5d54 "Table 5.54" provides the specification for the 
local interval method. 


\anchor T5d54
<table>
<caption align = "top">
\htmlonly
Table 5.54
\endhtmlonly
Specification detail for local interval estimation used in epistemic uncertainty
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Nondeterministic interval estimation
<td>\c local_interval_est
<td>none
<td>Required group
<td>N/A
<tr>
<td>Estimation method
<td>\c sqp | \c nip
<td>none
<td>Required group
<td>N/A
</table>

\subsubsection MethodNonDGlobalIntervalEst Global Interval Estimation
<!-- dakota subcat global_interval_est -->

As mentioned above, when performing interval analysis, 
one assumes that nothing is known about
an epistemic uncertain variable except that its value lies
somewhere within an interval.  The goal of uncertainty quantification 
in this context is to determine the 
resulting bounds on the output (defining the output interval)
given interval bounds on the inputs. 

In the global approach, one uses either a global optimization
method or a sampling method to assess the bounds.
\c global_interval_est
allows the user to specify several approaches to calculate 
interval bounds on the output responses. \c lhs performs
Latin Hypercube Sampling and takes the minimum and maximum of
the samples as the bounds (no optimization is
performed).  In the \c ego approach,
the efficient global optimization (EGO) method is used to calculate
bounds (see the EGO method on this page for more explanation).  By
default, the Surfpack GP (Kriging) model is used, but the %Dakota
implementation may be selected instead.  If \c use_derivatives is
specified the GP model will be built using available derivative data
(Surfpack GP only). If using \c sbo, a surrogate-based optimization
method will be used to find the interval bounds.  The surrogate used 
in \c sbo is a Gaussian process 
surrogate.  The main difference between \c ego and the 
\c sbo approach is the objective function that is used in the 
optimization. 
\c ego relies on an expected improvement function, while in 
\c sbo, the optimization proceeds using an evolutionary 
algorithm (\c coliny_ea described above) on the 
Gaussian process surrogate:  it is a standard surrogate-based
optimization.  Also note that the \c sbo option can support 
optimization over discrete variables (the discrete variables 
are relaxed) while \c ego cannot.  Finally, there is the 
\c ea approach.  In this approach, the evolutionary algorithm 
from Coliny (\c coliny_ea) is used to perform the interval optimization 
with no surrogate model involved. Again, this option of \c ea
can support interval optimization over discrete variables. 
When using \c lhs, \c ego, or \c sbo,
one can specify a seed for the number of LHS samples, the random
number generator, and the number of samples. The \c ea
option allows the seed to be specified.    The \c import_points_file and \c
export_points_file specifications are as described in \ref ModelSurrG,
(the use of an embedded global surrogate model necessitates repeating
selected surrogate model specifications within the method
specification).  \ref T5d55 "Table 5.55"
provides the specification for the global interval methods.

\anchor T5d55
<table>
<caption align = "top">
\htmlonly
Table 5.55
\endhtmlonly
Specification detail for global interval estimation used in epistemic uncertainty
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Nondeterministic interval estimation
<td>\c global_interval_est
<td>none
<td>Required group
<td>N/A
<tr>
<td>Estimation method
<td>\c lhs | \c ego | \c sbo | \c ea
<td>none
<td>Required group
<td>N/A
<tr>
<td>EGO GP selection
<td>\c gaussian_process
<td>\c surfpack | \c dakota
<td>Optional
<td>Surfpack Gaussian process
<tr>
<td>Derivative usage
<td>\c use_derivatives
<td>none
<td>Optional
<td>Use function values only
<tr>
<td>Random seed generator
<td>\c rng
<td>\c mt19937 | \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td>10,000 for LHS, approximately numVars^2 for EGO
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>


\subsubsection MethodNonDLocalEvid Local Evidence Theory (Dempster-Shafer) Methods
<!-- dakota subcat local_evidence -->

The above section discussed a pure interval approach. 
This section discusses Dempster-Shafer evidence theory. 
In this approach, one does not assign a probability
distribution to each uncertain input variable.  Rather, one divides
each uncertain input variable into one or more intervals. The input
parameters are only known to occur within intervals: nothing more is
assumed.  Each interval is defined by its upper and lower bounds, and
a Basic Probability Assignment (BPA) associated with that interval.
The BPA represents a probability of that uncertain variable being
located within that interval.  The intervals and BPAs are used to
construct uncertainty measures on the outputs called "belief" and
"plausibility."  Belief represents the smallest possible probability
that is consistent with the evidence, while plausibility represents
the largest possible probability that is consistent with the evidence.
For more information about the Dempster-Shafer theory of evidence, see
\ref Oberkampf2003 "Oberkampf and Helton, 2003" and 
\ref Helton2004 "Helton and Oberkampf, 2004".

Similar to the interval approaches, one may use global or local 
methods to determine plausbility and belief measures for the outputs. 
Note that to calculate the plausibility and belief 
cumulative distribution functions, 
one has to look at all combinations of
intervals for the uncertain variables.  Within each interval cell
combination, the minimum and maximum value of the objective function
determine the belief and plausibility, respectively.  In terms of
implementation, global methods use LHS sampling or global optimization 
to calculate the minimum and maximum values of the objective function
within each interval cell, 
while local methods use gradient-based optimization methods to 
calculate these minima and maxima. 

Finally, note that the nondeterministic general settings apply to 
the interval and evidence methods, 
but one needs to be careful about the interpretation
and translate probabilistic measures to epistemic ones. For example,
if the user specifies distribution of type complementary, a
complementary plausibility and belief function will be generated 
for the evidence methods (as
opposed to a complementary distribution function in the \c
sampling case).  If the user specifies a set of responses levels,
both the belief and plausibility will be calculated for each response
level. Likewise, if the user specifies a probability level, the
probability level will be interpreted both as a belief and
plausibility, and response levels corresponding to the belief and
plausibility levels will be calculated.  Finally, if generalized
reliability levels are specified, either as inputs (\c
gen_reliability_levels) or outputs (\c response_levels with \c compute
\c gen_reliabilities), then these are directly converted to/from
probability levels and the same probability-based mappings described
above are performed.

\ref T5d56 "Table 5.56" provides the specification for the \c
local_evidence method. Note that two local optimization methods 
are available:  \c sqp (sequential quadratic programming or \c nip
(nonlinear interior point method). 

\anchor T5d56
<table>
<caption align = "top">
\htmlonly
Table 5.56
\endhtmlonly
Specification detail for local evidence theory method for epistemic uncertainty
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Nondeterministic local evidence method
<td>\c local_evidence
<td>none
<td>Required group
<td>N/A
<tr>
<td>Estimation method
<td>\c sqp | \c nip
<td>none
<td>Required group
<td>N/A
</table>

\subsubsection MethodNonDGlobalEvid Global Evidence Theory (Dempster-Shafer) Methods

Evidence theory has been explained above in the Local Evidence Theory
section.  The basic idea is that one specifies an "evidence structure"
on uncertain inputs and propagates that to obtain belief and
plausibility functions on the response functions.  The inputs are
defined by sets of intervals and Basic Probability Assignments (BPAs).
Evidence propagation is computationally expensive, since the minimum
and maximum function value must be calculated for each "interval cell
combination."  These bounds are aggregated into belief and
plausibility.

\ref T5d57 "Table 5.57" provides the specification for the \c
global_evidence method.  \c global_evidence allows the user to specify
several approaches for calculating the belief and plausibility functions: 
\c lhs, \c ego, \c sbo, and \c ea.  
\c lhs performs Latin Hypercube Sampling and
takes the minimum and maximum of the samples as the bounds per
"interval cell combination."  In the case of \c ego, the efficient
global optimization (EGO) method is used to calculate bounds (see the
EGO method on this page for more explanation).  By default, the
Surfpack GP (Kriging) model is used, but the %Dakota implementation may
be selected instead.   If \c use_derivatives is
specified the GP model will be built using available derivative data
(Surfpack GP only).  
If using \c sbo, a surrogate-based optimization
method will be used to find the interval cell bounds. 
The surrogate employed in \c sbo is a Gaussian process 
surrogate.  However, the main difference between \c ego and the 
\c sbo approach is the objective function being optimized. 
\c ego relies on an expected improvement function, while in 
\c sbo, the optimization proceeds using an evolutionary 
algorithm (\c coliny_ea described above) on the 
Gaussian process surrogate:  it is a standard surrogate-based
optimization.  Also note that the \c sbo option can support 
optimization over discrete variables (the discrete variables 
are relaxed) while \c ego cannot.  Finally, there is the 
\c ea approach.  In this approach, the evolutionary algorithm 
from Coliny is used to perform the interval optimization 
with no surrogate model involved. Again, this option of \c ea
can support interval optimization over discrete variables. 
When using \c lhs, \c ego, or \c sbo, one can specify the
seed for the number of LHS samples, the random number generator, and
the number of samples. \c ea will use the seed specification also.
The \c import_points_file and \c
export_points_file specifications are as described in \ref ModelSurrG,
(the use of embedded global surrogate models necessitates repeating
selected surrogate model specifications within the method
specification).

Note that to calculate the plausibility and belief cumulative
distribution functions, one has to look at all combinations of
intervals for the uncertain variables.  In terms of implementation, if
one is using LHS sampling as outlined above, this method creates a
large sample over the response surface, then examines each cell to
determine the minimum and maximum sample values within each cell.  To
do this, one needs to set the number of samples relatively high: the
default is 10,000 and we recommend at least that number.  If the model
you are running is a simulation that is computationally quite
expensive, we recommend that you set up a surrogate model within the
%Dakota input file so that \c global_evidence performs its sampling and
calculations on the surrogate and not on the original model. If one
uses optimization methods instead to find the minimum and maximum
sample values within each cell, this can also be computationally
expensive.

\anchor T5d57
<table>
<caption align = "top">
\htmlonly
Table 5.57
\endhtmlonly
Specification detail for global evidence theory method for epistemic uncertainty
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Nondeterministic global evidence method
<td>\c global_evidence
<td>none
<td>Required group
<td>N/A
<tr>
<td>Estimation method
<td>\c lhs | \c ego | \c sbo | \c ea
<td>none
<td>Required group
<td>N/A
<tr>
<td>GP selection
<td>\c gaussian_process
<td>\c surfpack | \c dakota
<td>Optional
<td>Surfpack Gaussian process
<tr>
<td>Derivative usage
<td>\c use_derivatives
<td>none
<td>Optional
<td>Use function values only
<tr>
<td>Random seed generator
<td>\c rng
<td>\c mt19937 or \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td>10,000 for LHS, approximately numVars^2 for EGO
<tr>
<td>File name for points to be imported as the basis for the initial GP
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the GP
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>


\section MethodNonDCalib Nondeterministic Calibration Methods


This iterator branch is an important focus for upcoming releases.
Capabilities for inferring statistical models from data are important
for a variety of current and emerging mission areas.


\subsection MethodNonDBayesCalib Bayesian Calibration Methods

Currently, we are in the process of incorporating Bayesian calibration 
methods in %Dakota.  These methods take prior information on parameter 
values (in the form of prior distributions) and observational data 
(e.g. from experiments) and produce posterior distributions on the 
parameter values.  When the computational simulation is then executed
with samples from the posterior parameter distributions, the 
results that are produced are consistent with ("agree with") the 
experimental data.  In the case of calibrating parameters from a 
computational simulation model, we require a "likelihood function" that 
specifies the likelihood of observing a particular observation given 
the model and its associated parameterization.  We assume a Gaussian 
likelihood function currently.  The algorithms that produce 
the posterior distributions on model parameters are Monte Carlo Markov 
Chain (MCMC) sampling algorithms.  MCMC methods require many samples, often 
tens of thousands, so in the case of model calibration, often emulators 
of the computational simulation are used. For more details on the algorithms
underlying the methods, see the %Dakota User's manual.  

We have three Bayesian calibration methods under development in %Dakota: 
one called QUESO, one called DREAM, and one called GPMSA.  They are specified with the
\c bayes_calibration \c queso, \c bayes_calibration \c dream, 
or \c bayes_calibration \c gpmsa, respectively. 
The QUESO method uses components from the QUESO library 
(Quantification of Uncertainty for Estimation, Simulation, and 
Optimization) developed at The University of Texas at Austin. 
We are using a DRAM (Delayed Rejected Adaptive Metropolis) algorithm 
for the MCMC sampling from the QUESO library. 
DREAM (DiffeRential Evolution Adaptive
Metropolis) is a method that runs multiple different chains simultaneously 
for global exploration, and automatically tunes the proposal covariance
during the process by a self-adaptive randomized subspace sampling. 
[\ref Vrugt2009 "Vrugt et al. 2009"].
GPMSA (Gaussian Process Models for Simulation Analysis) is 
a code that has been developed at Los Alamos National Laboratory. 
It uses Gaussian process models as part of constructing 
an emulator for the expensive 
computational simulation.  GPMSA also has extensive features for 
calibration, such as the capability to include a "model discrepancy" term
and the capability to model functional data such as time series data. 
 
For the QUESO method, one can use an emulator in the MCMC sampling.  This will 
greatly improve the speed, since the Monte Carlo Markov Chain will generate 
thousands of samples on the emulator instead of the real simulation code. 
However, in the case of fast running evaluations, we recommend the use of 
no emulator.  An emulator may be specified with the keyword \c emulator, 
followed by a \c gaussian_process emulator, a \c pce emulator (polynomial chaos
expansion), or a \c sc emulator (stochastic collocation).  For the 
\c gaussian_process emulator, the user must specify whether to use the 
\c surfpack or \c dakota version of the Gaussian process. 
The user can define the number of samples 
\c emulator_samples from which the emulator should be built.  It is also 
possible to build the Gaussian process from points read in from the 
\c import_points_file and to export approximation-based sample evaluations 
using \c export_points_file.  For \c pce or \c sc, the user can define a \c sparse_grid_level. 

In terms of the MCMC sampling, one can specify the following for the QUESO method: 
With the \c metropolis type, we have the options \c hastings for a standard 
Metropolis-Hastings algorithm, or \c adaptive for the adaptive Metropolis 
in which the covariance of the proposal density is updated adaptively. 
For the delayed rejection part of the DRAM algorithm, one specifies \c rejection, 
followed by \c standard (no delayed rejection) or \c delayed.  Finally, the user 
has two scale factors which help control the scaling involved in the problem. 
The \c likelihood_scale is a number which scales the likelihood by dividing 
the log of the likelihood (e.g. dividing the sum of squared differences 
between the experimental data and simulation data or SSE).  This 
is useful for situations with very small likelihoods (e.g. the model is either 
very far away from the data or there is a lot of data so the likelihood function 
involves multiplying many likelihoods together, where the SSE term is large 
and the likelihood becomes very small). 
In some respects, the \c likelihood_scale can be seen as a normalizing factor
for the SSE.  If the SSE is large, the \c likelihood_scale should be large. 
The second factor is a \c proposal_covariance_scale which scales the proposal 
covariance.  This may be useful when the input variables being calibrated 
are of different magnitudes:  one may want to take a larger step in a direction 
with a larger magnitude, for example.  Finally, we offer the option 
to calibrate the sigma terms with the \c calibrate_sigma flag. 
The sigma terms refer to the error associated 
with the Gaussian process:  sigma is used in the likelihood calculation. 
If experimental measurement error is available to inform sigma, that is 
very useful, but often measurement uncertainty is not available.  Note that 
if \c calibrate_sigma is specified, a separate sigma term will be calibrated 
for each calibration term.  Thus, if there are 50 calibration terms (e.g. 
experimental points against which we are trying to match the model), 
50 sigma values will be added to the calibration process.  Calibration 
of the sigma values is turned off by default:  only the design parameters are 
calibrated in default mode.    

For the DREAM method, one can define the number of chains used with 
\c chains.  The total number of generations per chain in DREAM is 
the number of samples (\c samples) divided by the number of chains (\c chains).  
The minimum number of chains is three.  
The number of chains randomly selected to be used in the crossover 
each time a crossover occurs is \c crossover_chain_pairs.
There is an extra adaptation during burn-in, in which DREAM estimates a
distribution of crossover probabilities that favors large jumps over
smaller ones in each of the chains. 
Normalization is required to ensure that all of the input dimensions contribute 
equally.  In this process, a discrete number of candidate points for 
each crossover value is generated.  This parameter is \c num_cr. 
The \c gr_threshold is the convergence tolerance for the Gelman-Rubin 
statistic which will govern the convergence of the multiple chain 
process.  The integer \c jump_step forces a long jump every \c jump_step 
generations.
For more details about these parameters, see [\ref Vrugt2009 "Vrugt et al. 2009"].

For the GPMSA method, one can define the number of samples which will be used 
in construction of the emulator, \c emulator_samples.  The emulator 
involves Gaussian processes in GPMSA, so the user does not specify anything 
about emulator type. At this point, the only controls active for GPMSA 
are \c emulator_samples, \c seed and \c rng, and \c samples (the number of MCMC
samples).   

As mentioned above, the Bayesian capability in %Dakota currently relies 
on the QUESO library developed by The University of Texas at Austin.  
This integrated capability is still in prototype form and available to 
close collaborators of the %Dakota team.
If you are interested in this capability, contact the %Dakota developers 
at dakota-developers@development.sandia.gov.

\ref T5d58 "Table 5.58" provides the specification 
details for the \c bayes_calibration methods.

\anchor T5d58
<table>
<caption align = "top">
\htmlonly
Table 5.58
\endhtmlonly
Specification detail for the Bayesian calibration methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Bayesian calibration 
<td>\c bayes_calibration
<td>\c queso | \c gpmsa
<td>Required group
<td>N/A
<tr>
<td>Emulator type
<td>\c emulator  \c gaussian_process (\c surfpack | \c dakota) | \c pce | \c sc
<td>\c emulator_samples (for gaussian process), \c sparse_grid_level (for pce or sc)
<td>Optional
<td>N/A
<tr>
<td>File name for points to be imported as the basis for the initial emulator
<td>\c import_points_file
<td>string
<td>Optional
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>File name for exporting approximation-based samples from evaluating the emulator
<td>\c export_points_file
<td>string
<td>Optional
<td>no point export to a file
<tr>
<td>Export points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
<tr>
<td>Metropolis type for the MCMC algorithm 
<td>\c metropolis 
<td>\c hastings | \c adaptive
<td>Optional (QUESO only)
<td>hastings
<tr>
<td>Rejection type for the MCMC algorithms
<td>\c rejection (QUESO only)
<td>\c standard | \c delayed
<td>Optional
<td>standard
<tr>
<td>Random seed generator
<td>\c rng
<td>\c mt19937 or \c rnum2
<td>Optional
<td>Mersenne twister (\c mt19937)
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Number of samples taken in the MCMC sampling
<td>\c samples
<td>integer
<td>Optional
<td>10000
<tr>
<td>Likelihood scale factor
<td>\c likelihood_scale 
<td>real
<td>Optional (QUESO only)
<td>none
<tr>
<td>Proposal covariance scaling
<td>\c proposal_covariance_scale
<td>list of reals
<td>Optional (QUESO only)
<td>none
<tr>
<td>Calibrate sigma flag
<td>\c calibrate_sigma
<td>none
<td>Optional
<td>The sigma terms are not calibrated
<tr>
<td>Number of chains
<td>\c chains
<td>integer
<td>Optional (DREAM only)
<td>3
<tr>
<td>Number of chain pairs used in crossover 
<td>\c crossover_chain_pairs
<td>integer
<td>Optional (DREAM only)
<td>3
<tr>
<td>Number of candidate points used in burn-in adaptation
<td>\c num_cr
<td>integer
<td>Optional (DREAM only)
<td>1
<tr>
<td>Gelman-Rubin Threshold for convergence
<td>\c gr_threshold
<td>real
<td>Optional (DREAM only)
<td>1.2
<tr>
<td>Jump-Step 
<td>\c jump_step
<td>integer
<td>Optional (DREAM only)
<td>5
</table>


\section MethodSoln Solution Verification Methods


Solution verification procedures estimate the order of convergence of
the simulation response data during the course of a refinement study.
This branch of methods is new and currently only contains one algorithm:
Richardson extrapolation.


\subsection MethodSolnRichardson Richardson Extrapolation


This method utilizes state variables as active variables (continuous
state only at this time; discrete state to follow later) for
parameterizing the refinement of the discretizations, and employs the
\c max_iterations and \c convergence_tolerance method independent
controls to manage the iterative procedures.  The refinement path is
determined from the \c initial_state of the \c continuous_state
variables specification (refer to \ref VarSV) in combination with the
\c refinement_rate, where each of the state variables is treated as an
independent refinement factor and each of the initial state values is
repeatedly divided by the refinement rate value to define new
discretization states.  Three algorithm options are currently provided:

-# The \c estimate_order option is the simplest option.  For each of
   the refinement factors, it evaluates three points along the
   refinement path and uses these results to perform an estimate of
   the convergence order for each response function.

-# The \c converge_order option is initialized using the \c
   estimate_order aproach, and additional refinements are performed
   along the refinement path until the convergence order estimates
   converge (two-norm of the change in response orders is less than
   the convergence tolerance).

-# The \c converge_qoi option is similar to the \c converge_order
   option, except that the convergence criterion is that the two-norm
   of the response discretization errors (computed from extrapolation)
   must be less than the convergence tolerance.

In each of these cases, convergence order for a response quantity of 
interest (QOI) is estimated from
\f[p = ln(\frac{QOI_3 - QOI_2}{QOI_2 - QOI_1})/ln(r)\f]
where \f$r\f$ is the uniform refinement rate specified by \c 
refinement_rate.  \ref T5d59 "Table 5.59" provides the specification 
details for the \c richardson_extrap method.

\anchor T5d59
<table>
<caption align = "top">
\htmlonly
Table 5.59
\endhtmlonly
Specification detail for Richardson extrapolation method for solution verification
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Richardson extrapolation
<td>\c richardson_extrap
<td>none
<td>Required group
<td>N/A
<tr>
<td>Order estimation approach
<td>\c estimate_order | \c converge_order | \c converge_qoi
<td>none
<td>Required
<td>N/A
<tr>
<td>Refinement rate
<td>\c refinement_rate
<td>real
<td>Optional
<td>2.
</table>


\section MethodDACE Design of Computer Experiments Methods


Design and Analysis of Computer Experiments (DACE) methods compute
response data sets at a selection of points in the parameter space.
Three libraries are provided for performing these studies: DDACE, 
FSUDace, and PSUADE.  The design of experiments methods do not
currently make use of any of the method independent controls.


\subsection MethodDDACE DDACE
<!-- dakota subcat dace -->

The Distributed Design and Analysis of Computer Experiments (DDACE)
library provides the following DACE techniques: grid sampling (\c
grid), pure random sampling (\c random), orthogonal array sampling (\c
oas), latin hypercube sampling (\c lhs), orthogonal array latin
hypercube sampling (\c oa_lhs), Box-Behnken (\c box_behnken), and
central composite design (\c central_composite).  It is worth noting
that there is some overlap in sampling techniques with those available
from the nondeterministic branch.  The current distinction is that the
nondeterministic branch methods are designed to sample within a
variety of probability distributions for uncertain variables, whereas
the design of experiments methods treat all variables as having
uniform distributions.  As such, the design of experiments methods are
well-suited for performing parametric studies and for generating data
sets used in building global approximations (see \ref ModelSurrG),
but are not currently suited for assessing the effect of
uncertainties. If a design of experiments over both design/state
variables (treated as uniform) and uncertain variables (with
probability distributions) is desired, then \c sampling can
support this with \c active \c all specified in the Variables 
specification block.
%Dakota provides access to the DDACE library through the
DDACEDesignCompExp class.

In terms of method dependent controls, the specification structure is
straightforward.  First, there is a set of design of experiments
algorithm selections separated by logical OR's (\c grid or \c random
or \c oas or \c lhs or \c oa_lhs or \c box_behnken or \c
central_composite).  Second, there are optional specifications for the
random seed to use in generating the sample set (\c seed), for fixing
the seed (\c fixed_seed) among multiple sample sets (see \ref
MethodNonDMC for discussion), for the number of samples to perform (\c
samples), and for the number of symbols to use (\c symbols).  The \c
seed control is used to make sample sets repeatable, and the \c
symbols control is related to the number of replications in the sample
set (a larger number of symbols equates to more stratification and
fewer replications).  The \c main_effects control prints Analysis-of-Variance
main effects results (e.g. ANOVA tables with p-values per variable). 
The \c main_effects control is only operational with the 
orthogonal arrays or Latin Hypercube designs, not for Box Behnken or 
Central Composite designs.  The \c quality_metrics control is available 
for the DDACE library.  
This control turns on calculation of volumetric quality measures 
which measure the uniformity of the point samples. 
More details on the quality measures are given under the description of the 
FSU sampling methods. The \c variance_based_decomp control is also 
available.  This control enables the calculation of sensitivity 
indices which indicate how important the uncertainty in each input 
variable is in contributing to the output variance.  More details 
on variance based decomposition are given in \ref MethodNonDMC.
Design of experiments specification detail is
given in \ref T5d60 "Table 5.60".

\anchor T5d60
<table>
<caption align = "top">
\htmlonly
Table 5.60
\endhtmlonly
Specification detail for design of experiments methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Design of experiments method
<td>\c dace
<td>none
<td>Required group
<td>N/A
<tr>
<td>dace algorithm selection
<td>\c grid | \c random | \c oas | \c lhs | \c oa_lhs | \c box_behnken | \c central_composite
<td>none
<td>Required
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Fixed seed flag
<td>\c fixed_seed
<td>none
<td>Optional
<td>seed not fixed: sampling patterns are variable among multiple DACE runs
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td>minimum required
<tr>
<td>Number of symbols
<td>\c symbols
<td>integer
<td>Optional
<td>default for sampling algorithm
<tr>
<td>Main effects
<td>\c main_effects
<td>none
<td>Optional
<td>No main_effects
<tr>
<td>Quality metrics
<td>\c quality_metrics
<td>none
<td>Optional
<td>No quality_metrics
<tr>
<td>Variance based decomposition
<td>\c variance_based_decomp
<td>none
<td>Optional
<td>No variance_based_decomp
</table>


\subsection MethodFSUDACE FSUDace

The Florida State University Design and Analysis of Computer
Experiments (FSUDace) library provides the following DACE techniques:
quasi-Monte Carlo sampling (\c fsu_quasi_mc) based on the Halton
sequence (\c halton) or the Hammersley sequence (\c hammersley), 
and Centroidal Voronoi Tessellation (\c fsu_cvt). 
All three methods generate sets of uniform random variables on the 
interval [0,1]. If the user specifies lower and upper bounds for a 
variable, the [0,1] samples are mapped to the [lower, upper] interval.
The quasi-Monte Carlo and CVT methods are designed with the goal of low discrepancy.  
Discrepancy refers to the nonuniformity of the sample points 
within the hypercube. Discrepancy is defined as the difference between 
the actual number and the expected number of points one would expect 
in a particular set B (such as a hyper-rectangle within the unit 
hypercube), maximized over all such sets. 
Low discrepancy sequences tend to cover the 
unit hypercube reasonably uniformly. Quasi-Monte Carlo methods 
produce low discrepancy sequences, especially if one is interested 
in the uniformity of projections of the point sets onto 
lower dimensional faces of the hypercube (usually 1-D: how well do
the marginal distributions approximate a uniform?)  CVT 
does very well volumetrically:  it spaces the points fairly 
equally throughout the space, so that the points cover the region 
and are isotropically distributed with no directional bias in the 
point placement.  There are various measures of volumetric 
uniformity which take into account the distances between 
pairs of points, regularity measures, etc. 
Note that CVT does not produce low-discrepancy sequences 
in lower dimensions, however: the lower-dimension (such as 1-D) 
projections of CVT can have high discrepancy.  

The quasi-Monte Carlo sequences of Halton and Hammersley are deterministic 
sequences determined by a set of prime bases.  
Generally, we recommend that the user leave the default 
setting for the bases, which are the lowest primes. 
Thus, if one wants to generate a sample set for 3 random variables, 
the default bases used are 2, 3, and 5 in the Halton sequence.
To give an example of how these sequences look, the Halton sequence 
in base 2 starts with points 0.5, 0.25, 0.75, 0.125, 0.625, etc. 
The first few points in a Halton base 3 sequence are 
0.33333, 0.66667, 0.11111, 0.44444, 0.77777, etc.   Notice that the Halton 
sequence tends to alternate back and forth, generating a point closer to zero 
then a point closer to one.  An individual sequence is based on a radix 
inverse function defined on a prime base.  The prime base determines 
how quickly the [0,1] interval is filled in.  Generally, the lowest 
primes are recommended.

The Hammersley sequence is the same as the Halton sequence, except the values 
for the first random variable are equal to 1/N, where N is the number of 
samples.  Thus, if one wants to generate a sample set of 100 samples for 3 
random variables, the first random variable has values 1/100, 2/100, 3/100, 
etc. and the second and third variables are generated according to a Halton 
sequence with bases 2 and 3, respectively.  For more information about 
these sequences, see [\ref Halton1960 "Halton, 1960",
\ref Halton1964 "Halton and Smith, 1964", and 
\ref Kocis1997 "Kocis and Whiten, 1997"].
 
The specification for specifying quasi-Monte Carlo (\c fsu_quasi_mc) 
is given below in \ref T5d61 "Table 5.61".  
The user must specify if the sequence is 
(\c halton) or (\c hammersley).  The user must also specify the number 
of samples to generate for each variable (\c samples). 
Then, there are three optional lists the user may specify. 
The first list determines where in the sequence the user wants to start. 
For example, for the Halton sequence in base 2, if the user specifies 
sequence_start = 2, the sequence would not include 0.5 and 0.25, but 
instead would start at 0.75.  The default \c sequence_start is a 
vector with 0 for each variable, specifying that each sequence 
start with the first term. 
The \c sequence_leap control is similar but controls the "leaping" of 
terms in the sequence.  The default is 1 for each variable, 
meaning that each term in the sequence be returned.  If the user specifies 
a sequence_leap of 2 for a variable, the points returned would be every other 
term from the QMC sequence.  The advantage to using a leap value greater than 
one is mainly for high-dimensional sets of random deviates. In this case, 
setting a leap value to the next prime number larger than the largest
prime base can help maintain uniformity when generating sample sets for high
dimensions.  For more information about the efficacy of leaped 
Halton sequences, see [\ref Robinson1999 "Robinson and Atcitty, 1999"]. 
The final specification for the QMC sequences is the prime base.  It 
is recommended that the user not specify this and use the default values. 
For the Halton sequence, the default bases are primes in increasing order, 
starting with 2, 3, 5, etc. For the Hammersley sequence, the user specifies 
(s-1) primes if one is generating an s-dimensional set of random variables. 

The \c fixed_sequence control is similar to \c fixed_seed for other sampling 
methods.  If \c fixed_sequence is specified, the user will get the same 
sequence (meaning the same set of samples) for subsequent calls of 
the QMC sampling method (for example, this might be used in a surrogate 
based optimization method or a parameter study where one wants to 
fix the uncertain variables).  
The \c latinize command takes the QMC sequence and "latinizes" it, meaning 
that each original sample is moved so that it falls into one strata or 
bin in each dimension as in Latin Hypercube sampling.  The default setting 
is NOT to latinize a QMC sample. However, one may 
be interested in doing this in situations where one wants better discrepancy
of the 1-dimensional projections (the marginal distributions). 
The \c variance_based_decomp control is also 
available.  This control enables the calculation of sensitivity 
indices which indicate how important the uncertainty in each input 
variable is in contributing to the output variance.  More details 
on variance based decomposition are given in \ref MethodNonDMC.

Finally, \c quality_metrics calculates four quality metrics relating to the
volumetric spacing of the samples.  The four quality metrics measure 
different aspects relating to the uniformity of point samples in hypercubes. 
Desirable properties of such point samples are:  are the points equally
spaced, do the points cover the region, and are they isotropically 
distributed, with no directional bias in the spacing.  The four quality
metrics we report are h, chi, tau, and d.  h is the point distribution norm, 
which is a measure of uniformity of the point distribution.  Chi is a 
regularity measure, and provides a measure of local uniformity of a set of 
points.  Tau is the second moment trace measure, and d is the second moment 
determinant measure.  All of these values are scaled so that smaller is 
better (the smaller the metric, the better the uniformity of the point 
distribution).  Complete explanation of these measures can be found in 
[\ref Gunzburger2004 "Gunzburger and Burkardt, 2004."].

<!-- dakota subcat fsu_quasi_mc -->
\anchor T5d61
<table>
<caption align = "top">
\htmlonly
Table 5.61
\endhtmlonly
Specification detail for FSU Quasi-Monte Carlo sequences 
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>FSU Quasi-Monte Carlo
<td>\c fsu_quasi_mc
<td>none
<td>Required group
<td>N/A
<tr>
<td>Sequence type
<td>\c halton | \c hammersley
<td>none
<td>Required group
<td>N/A
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td> (0) for standalone sampling, (minimum required) for surrogates
<tr>
<td>Sequence starting indices
<td>\c sequence_start
<td>integer list (one integer per variable)
<td>Optional
<td>%Vector of zeroes
<tr>
<td>Sequence leaping indices
<td>\c sequence_leap
<td>integer list (one integer per variable)
<td>Optional
<td>%Vector of ones
<tr>
<td>Prime bases for sequences
<td>\c prime_base
<td>integer list (one integer per variable)
<td>Optional
<td>%Vector of the first s primes for s-dimensions in Halton, First (s-1) primes for Hammersley
<tr>
<td>Fixed sequence flag
<td>\c fixed_sequence
<td>none
<td>Optional
<td>sequence not fixed: sampling patterns are variable among multiple QMC runs
<tr>
<td>Latinization of samples
<td>\c latinize
<td>none
<td>Optional
<td>No latinization
<tr>
<td>Variance based decomposition
<td>\c variance_based_decomp
<td>none
<td>Optional
<td>No variance_based_decomp
<tr>
<td>Quality metrics
<td>\c quality_metrics
<td>none
<td>Optional
<td>No quality_metrics
</table>

The FSU CVT method (\c fsu_cvt) produces a set of sample points that are 
(approximately) a Centroidal Voronoi Tessellation.  The primary feature of 
such a set of points is that they have good volumetric spacing; the points 
tend to arrange themselves in a pattern of cells that are roughly the 
same shape.  To produce this set of points, an almost arbitrary set of
initial points is chosen, and then an internal set of 
iterations is carried out. These iterations repeatedly replace 
the current set of sample points by an estimate 
of the centroids of the corresponding Voronoi subregions.
[\ref Du1999 "Du, Faber, and Gunzburger, 1999"].

The user may generally ignore the details of this internal iteration.   If 
control is desired, however, there are a few variables with which the user
can influence the iteration.  The user may specify \c max_iterations, the
number of iterations carried out; \c num_trials, 
the number of secondary sample points generated to adjust the 
location of the primary sample points; and \c trial_type, 
which controls how these secondary sample points are
generated. In general, the variable with the most influence 
on the quality of the final sample set is \c num_trials, 
which determines how well the Voronoi
subregions are sampled.  
Generally, \c num_trials should be "large", certainly much
bigger than the number of sample points being requested; 
a reasonable value might be 10,000, but values of 100,000 
or 1 million are not unusual. 

CVT has a seed specification 
similar to that in DDACE:  
there are optional specifications for the
random seed to use in generating the sample set (\c seed), for fixing
the seed (\c fixed_seed) among multiple sample sets (see \ref
MethodNonDMC for discussion), and for the number of samples to perform (\c
samples). The \c
seed control is used to make sample sets repeatable.  Finally, 
the user has the option to specify the method by which the 
trials are created to adjust the centroids.  The \c trial_type
can be one of three types: 
\c random, where points are generated randomly;
\c halton, where points are generated according to the Halton sequence; 
and \c grid, where points are placed on a regular grid over the hyperspace. 

Finally, latinization is available for CVT as with QMC. 
The \c latinize control takes the CVT sequence and "latinizes" it, meaning 
that each original sample is moved so that it falls into one strata or 
bin in each dimension as in Latin Hypercube sampling.  The default setting 
is NOT to latinize a CVT sample. However, one may 
be interested in doing this in situations where one wants better discrepancy
of the 1-dimensional projections (the marginal distributions).
The \c variance_based_decomp control is also 
available.  This control enables the calculation of sensitivity 
indices which indicate how important the uncertainty in each input 
variable is in contributing to the output variance.  More details 
on variance based decomposition are given in \ref MethodNonDMC.
The \c quality_metrics control is available for CVT as with QMC.  
This command turns on calculation of volumetric quality measures 
which measure the "goodness" of the uniformity of the point samples. 
More details on the quality measures are given under the description of the 
QMC methods. 

The specification detail for the FSU CVT method is given in 
\ref T5d62 "Table 5.62".

<!-- dakota subcat fsu_cvt -->
\anchor T5d62
<table>
<caption align = "top">
\htmlonly
Table 5.62
\endhtmlonly
Specification detail for FSU Centroidal Voronoi Tesselation sampling
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>FSU CVT sampling
<td>\c fsu_cvt 
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Fixed seed flag
<td>\c fixed_seed
<td>none
<td>Optional
<td>seed not fixed: sampling patterns are variable among multiple CVT runs
<tr>
<td>Number of samples 
<td>\c samples
<td>integer
<td>Required
<td>(0) for standalone sampling, (minimum required) for surrogates
<tr>
<td>Number of trials  
<td>\c num_trials
<td>integer
<td>Optional
<td>10000
<tr>
<td>Trial type
<td>\c trial_type 
<td> \c random | \c grid | \c halton
<td>Optional
<td> \c random
<tr>
<td>Latinization of samples
<td>\c latinize
<td>none
<td>Optional
<td>No latinization
<tr>
<td>Variance based decomposition
<td>\c variance_based_decomp
<td>none
<td>Optional
<td>No variance_based_decomp
<tr>
<td>Quality metrics
<td>\c quality_metrics
<td>none
<td>Optional
<td>No quality_metrics
</table>

\subsection MethodPSUADE PSUADE

The Problem Solving Environment for Uncertainty Analysis and Design
Exploration (PSUADE) is a Lawrence Livermore National Laboratory tool
for metamodeling, sensitivity analysis, uncertainty quantification,
and optimization.  Its features include non-intrusive and parallel
function evaluations, sampling and analysis methods, an integrated
design and analysis framework, global optimization, numerical
integration, response surfaces (MARS and higher order regressions),
graphical output with Pgplot or Matlab, and fault tolerance [\ref
Tong2005 "C.H. Tong, 2005"].

The Morris One-At-A-Time (MOAT) method, originally proposed by Morris
[\ref Morris1991 "M.D. Morris, 1991"], is a screening method, designed
to explore a computational model to distinguish between input
variables that have negligible, linear and additive, or nonlinear or
interaction effects on the output.  The computer experiments performed
consist of individually randomized designs which vary one input factor
at a time to create a sample of its elementary effects.  The PSUADE
implementation of MOAT is selected with method keyword \c psuade_moat.
The number of samples (\c samples) must be a positive integer multiple
of (number of continuous design variable + 1) and will be
automatically adjusted if misspecified.  The number of partitions (\c
partitions) applies to each variable being studied and must be odd
(the number of MOAT levels per variable is partitions + 1).  This will
also be adjusted at runtime as necessary.  For information on
practical use of this method, see 
[\ref Saltelli2004 "Saltelli, et al., 2004"].  The specification detail
for the PSUADE MOAT method is given in \ref T5d63 "Table 5.63".

\anchor T5d63
<table>
<caption align = "top">
\htmlonly
Table 5.63
\endhtmlonly
Specification detail for PSUADE methods
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>PSUADE MOAT method
<td>\c psuade_moat
<td>none
<td>Required group
<td>N/A
<tr>
<td>Random seed
<td>\c seed
<td>integer
<td>Optional
<td>randomly generated seed
<tr>
<td>Number of samples
<td>\c samples
<td>integer
<td>Optional
<td>10*(num_cdv + 1)
<tr>
<td>Number of partitions
<td>\c partitions
<td>integer
<td>Optional
<td>3
</table>


\section MethodPS Parameter Study Methods


%Dakota's parameter study methods compute response data sets at a
selection of points in the parameter space. These points may be
specified as a vector, a list, a set of centered vectors, or a
multi-dimensional grid. Capability overviews and examples of the
different types of parameter studies are provided in the Users Manual
[\ref UsersMan "Adams et al., 2010"]. %Dakota implements all of the
parameter study methods within the ParamStudy class.

With the exception of output verbosity (a setting of \c silent will
suppress some parameter study diagnostic output), %Dakota's parameter
study methods do not make use of the method independent
controls. Therefore, the parameter study documentation which follows
is limited to the method dependent controls for the vector, list,
centered, and multidimensional parameter study methods.


\subsection MethodPSVPS Vector parameter study

%Dakota's vector parameter study computes response data sets at
selected intervals along a vector in parameter space. It is often used
for single-coordinate parameter studies (to study the effect of a
single variable on a response set), but it can be used more generally
for multiple coordinate vector studies (to investigate the response
variations along some n-dimensional vector such as an optimizer search
direction). This study is selected using the \c vector_parameter_study
specification followed by either a \c final_point or a \c step_vector
specification.

The vector for the study can be defined in several ways (refer to
dakota.input.summary). First, a \c final_point specification, when
combined with the initial values from the variables specification (in
\ref VarCommands, see \c initial_point and \c initial_state for design
and state variables as well as inferred initial values for uncertain
variables), uniquely defines an n-dimensional vector's direction and
magnitude through its start and end points. The values included in the
\c final_point specification are the actual variable values for
discrete sets, not the underlying set index value.  The intervals
along this vector are then specified with a \c num_steps
specification, for which the distance between the initial values and
the \c final_point is broken into \c num_steps intervals of equal
length.  For continuous and discrete range variables, distance is
measured in the actual values of the variables, but for discrete set
variables (either integer or real sets for design, uncertain, or state
types), distance is instead measured in index offsets.  Since discrete
sets may have nonuniform offsets in their enumerated set values but
have uniform offsets in their index values, defining steps in terms of
set indices allows for meaningful parameter study specifications for
these variable types.  This study performs function evaluations at
both ends, making the total number of evaluations equal to \c
num_steps+1.  The study has stringent requirements on performing
appropriate steps with any discrete range and discrete set variables.
A \c num_steps specification must result in discrete range and set
index steps that are integral: no remainder is currently permitted in
the integer step calculation and no rounding to integer steps will
occur.  The \c final_point specification detail is given in \ref T5d64
"Table 5.64".

\anchor T5d64
<table>
<caption align = "top">
\htmlonly
Table 5.64
\endhtmlonly
final_point specification detail for the vector parameter study
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>%Vector parameter study
<td>\c vector_parameter_study
<td>none
<td>Required group
<td>N/A
<tr>
<td>Termination point of vector
<td>\c final_point
<td>list of reals (actual values; no set indices)
<td>Required group
<td>N/A
<tr>
<td>Number of steps along vector
<td>\c num_steps
<td>integer
<td>Required
<td>N/A
</table>

The other technique for defining a vector in the study is the \c
step_vector specification. This parameter study begins at the initial
values and adds the increments specified in \c step_vector to obtain
new simulation points. For discrete set types (design, uncertain, or
state; real or integer), the steps are set index offsets, not steps
between the actual set values.  This increment process is performed \c
num_steps times, and since the initial values are included, the total
number of simulations is again equal to \c num_steps+1. The \c
step_vector specification detail is given in \ref T5d65 "Table 5.65".

\anchor T5d65
<table>
<caption align = "top">
\htmlonly
Table 5.65
\endhtmlonly
step_vector specification detail for the vector parameter study
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>%Vector parameter study
<td>\c vector_parameter_study
<td>none
<td>Required group
<td>N/A
<tr>
<td>Step vector
<td>\c step_vector
<td>list of reals (index offset components are cast to integers)
<td>Required group
<td>N/A
<tr>
<td>Number of steps along vector
<td>\c num_steps
<td>integer
<td>Required
<td>N/A
</table>


\subsection MethodPSLPS List parameter study

%Dakota's list parameter study allows for evaluations at user selected
points of interest which need not follow any particular
structure. This study is selected using the \c list_parameter_study
method specification followed by either a \c list_of_points or \c
import_points_file specification.  The imported points file may be in
annotated for free-form tabular format as described in the User's
manual.

The number of real values in the \c list_of_points specification or
file referenced by \c import_points_file must be a multiple of the
total number of variables (including continuous and discrete types)
contained in the variables specification. This parameter study simply
performs simulations for the first parameter set (the first \c n
entries in the list), followed by the next parameter set (the next \c
n entries), and so on, until the list of points has been
exhausted. Since the initial values from the variables specification
will not be used, they need not be specified. For discrete set types,
the actual values should be specified, not the set indices, although
the values will be validated for membership within the set value
specifications.  The list parameter study specification detail is
given in \ref T5d66 "Table 5.66".

\anchor T5d66
<table>
<caption align = "top">
\htmlonly
Table 5.66
\endhtmlonly
Specification detail for the list parameter study
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>%List parameter study
<td>\c list_parameter_study
<td>none
<td>Required group
<td>N/A
<tr>
<td>%List of points to evaluate
<td>\c list_of_points
<td>list of reals (actual values; no set indices)
<td>Required Group
<td>N/A
<tr>
<td>File containing points to evaluate
<td>\c import_points_file
<td>string
<td>Optional Group
<td>no point import from a file
<tr>
<td>Import points file format
<td>\c annotated | \c freeform
<td>boolean
<td>Optional
<td>annotated
</table>


\subsection MethodPSCPS Centered parameter study

%Dakota's centered parameter study computes response data sets along
multiple coordinate-based vectors, one per parameter, centered about
the initial values from the variables specification. This is useful
for investigation of function contours with respect to each parameter
individually in the vicinity of a specific point (e.g.,
post-optimality analysis for verification of a minimum), thereby
avoiding the cost associated with a multidimensional grid. It is
selected using the \c centered_parameter_study method specification
followed by \c step_vector and \c steps_per_variable specifications.
The \c step_vector specification provides the size of the increments
for each variable (employed sequentially, not all at once as for \ref
MethodPSVPS) in either actual values (continuous and discrete range)
or index offsets (discrete set). The \c steps_per_variable
specification provides the number of increments per variable (again,
employed sequentially) in each of the plus and minus directions. The
centered parameter study specification detail is given in \ref T5d67
"Table 5.67".

\anchor T5d67
<table>
<caption align = "top">
\htmlonly
Table 5.67
\endhtmlonly
Specification detail for the centered parameter study
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Centered parameter study
<td>\c centered_parameter_study
<td>none
<td>Required group
<td>N/A
<tr>
<td>Step vector
<td>\c step_vector
<td>list of reals (index offset components are cast to integers)
<td>Required group
<td>N/A
<tr>
<td>Number of steps per variable
<td>\c steps_per_variable
<td>list of integers
<td>Required
<td>N/A
</table>


\subsection MethodPSMPS Multidimensional parameter study

%Dakota's multidimensional parameter study computes response data sets
for an n-dimensional grid of points. Each continuous and discrete
range variable is partitioned into equally spaced intervals between
its upper and lower bounds, each discrete set variable is partitioned
into equally spaced index intervals, and each combination of the
values defined by the boundaries of these partitions is evaluated.

This study is selected using the \c multidim_parameter_study method
specification followed by a \c partitions specification, where the \c
partitions list specifies the number of partitions for each
variable. The number of entries in the partitions list must be equal
to the total number of variables contained in the variables
specification.  As for the vector and centered studies, remainders
within the integer division of the step calculations are not permitted
for discrete range or set types and therefore no integer rounding
occurs, so the partitions specification must be carefully selected in
the presence of these types.  Since the initial values from the
variables specification will not be used, they need not be
specified. The multidimensional parameter study specification detail
is given in \ref T5d68 "Table 5.68".

\anchor T5d68
<table>
<caption align = "top">
\htmlonly
Table 5.68
\endhtmlonly
Specification detail for the multidimensional parameter study
</caption>
<tr>
<td><b>Description</b>
<td><b>Keyword</b>
<td><b>Associated Data</b>
<td><b>Status</b>
<td><b>Default</b>
<tr>
<td>Multidimensional parameter study
<td>\c multidim_parameter_study
<td>none
<td>Required group
<td>N/A
<tr>
<td>Partitions per variable
<td>\c partitions
<td>list of integers
<td>Required
<td>N/A
</table>

\htmlonly
<hr>
<br><b><a href="EnvCommands.html#EnvCommands">Previous chapter</a></b>
<br>
<br><b><a href="ModelCommands.html#ModelCommands">Next chapter</a></b>
\endhtmlonly

*/

} // namespace Dakota
