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