1Blurb::
2Begins Dakota method selection and behavioral settings.
3
4Description::
5The \c method keyword signifies the start of a block in the Dakota
6input file.  A method block contains the various keywords necessary to
7select a method and to control its behavior.
8
9<b> Method Block Requirements </b>
10
11At least one \c method block must appear in the Dakota input
12file.  Multiple \c method blocks may be needed to fully define
13advanced analysis approaches.
14
15Each \c method block must specify one method and, optionally, any
16associated keywords that govern the behavior of the method.
17
18<b> The Methods </b>
19
20Each \c method block must select one method.
21
22Starting with Dakota v6.0, the methods are grouped into two types:
23standard methods and multi-component methods.
24
25The standard methods are
26stand-alone and self-contained in the sense that they only require
27a model to perform a study. They do not call other methods.
28While methods such as \c
29polynomial_chaos and \c efficient_global internally utilize multiple
30iterator and surrogate model components, these components are
31generally hidden from user control due to restrictions on modularity;
32thus, these methods are stand-alone.
33
34The multi-component group
35of methods provides a higher level "meta-algorithm" that points to
36other methods and models that support sub-iteration.
37For example, in a sequential hybrid method, the \c hybrid
38method specification must identify a list of subordinate methods, and
39the "meta-algorithm" executes these methods in sequence and transfers
40information between them. Surrogate-based minimizers provide another
41example in that they point both to other methods (e.g. what
42optimization method is used to solve the approximate subproblem) as
43well as to models (e.g. what type of surrogate model is employed).
44Multi-component methods generally provide some level of "plug and
45play" modularity, through their flexible support of a variety of
46method and model selections.
47
48<b> Component-Based Iterator Commands </b>
49
50Component-based iterator specifications include hybrid, multi-start,
51pareto set, surrogate-based local, surrogate-based global, and branch
52and bound methods. Whereas a standard iterator specification only
53needs an optional model pointer string (specified with \c
54model_pointer), component-based iterator specifications can include
55method pointer, method name, and model pointer specifications in order
56to define the components employed in the "meta-iteration." In
57particular, these specifications identify one or more methods (by
58pointer or by name) to specify the subordinate iterators that will be
59used in the top-level algorithm. Identifying a sub-iterator by name
60instead of by pointer is a lightweight option that relaxes the need
61for a separate method specification for the sub-iterator; however, a
62model pointer may be required in this case to provide the
63specification connectivity normally supported by the method pointer.
64Refer to these individual method descriptions for specific
65requirements for these advanced methods.
66
67<!-- Hybrid meta-iterators identify sub-iterators and sub-models using
68either (a) lists of method pointers or lists of method names with
69optional model pointers (sequential and collaborative hybrids), or (b)
70global and local method pointers or global and local method names with
71optional model pointers (embedded hybrid). Multi-start and pareto-set
72meta-iterators identify a single sub-method either by pointer or name,
73with the latter name case supporting an optional model pointer. The
74branch and bound, surrogate-based local, and surrogate-based global
75methods support a similar specification in identifying a sub-method by
76either pointer or by name and either a required (surrogate-based) or
77optional (branch and bound) model pointer. Each of the method
78specifications identified by pointer has the responsibility for
79identifying corresponding model specifications (using \c model_pointer),
80 whereas methods identified by name cannot
81delegate the need to identify a model by pointer. -->
82
83
84<b> Method Independent Controls </b>
85
86In addition to the method, there are 10 optional keywords, which
87are referred to as method independent controls.
88These controls are valid for enough methods that it was
89reasonable to pull them out of the method dependent blocks and consolidate the
90specifications, however, they are NOT universally respected by all methods.
91
92
93Topics::	block
94Examples::
95Several examples follow. The first example shows a minimal
96specification for an optimization method.
97\verbatim
98method
99  dot_sqp
100\endverbatim
101This example uses all of the defaults for this method.
102
103A more sophisticated example would be
104\verbatim
105method,
106  id_method = 'NLP1'
107  dot_sqp
108    max_iterations = 50
109    convergence_tolerance = 1e-4
110    output verbose
111    model_pointer = 'M1'
112\endverbatim
113This example demonstrates the use of identifiers and pointers
114as well as some method independent and method
115dependent controls for the sequential quadratic programming (SQP)
116algorithm from the DOT library. The \c max_iterations, \c
117convergence_tolerance, and \c output settings are method independent
118controls, in that they are defined for a variety of methods.
119
120The next example shows a specification for a least squares method.
121\verbatim
122method
123  optpp_g_newton
124    max_iterations = 10
125    convergence_tolerance = 1.e-8
126    search_method trust_region
127    gradient_tolerance = 1.e-6
128\endverbatim
129Some of the same method independent controls are present along with
130several method dependent controls (\c search_method and \c
131gradient_tolerance) which are only meaningful for OPT++ methods (see
132\ref topic-package_optpp).
133
134The next example shows a specification for a nondeterministic method
135with several method dependent controls (refer to \ref method-sampling).
136\verbatim
137method
138  sampling
139    samples = 100
140    seed = 12345
141    sample_type lhs
142    response_levels = 1000. 500.
143\endverbatim
144
145The last example shows a specification for a parameter study method
146where, again, each of the controls are method dependent (refer to \ref
147method-vector_parameter_study).
148\verbatim
149method
150  vector_parameter_study
151    step_vector = 1. 1. 1.
152    num_steps = 10
153\endverbatim
154
155Theory::
156Faq::
157See_Also::
158