Strategy Commands

Strategy Commands Table of Contents

Strategy Description

The strategy section in a DAKOTA input file specifies the top level technique which will govern the management of iterators and models in the solution of the problem of interest. Four strategies currently exist: hybrid, multi_start, pareto_set, and single_method. These algorithms are implemented within the Strategy class hierarchy in the CollaborativeHybridStrategy, EmbeddedHybridStrategy, SequentialHybridStrategy, ConcurrentStrategy, and SingleMethodStrategy classes. For each of the strategies, a brief algorithm description is given below. Additional information on the algorithm logic is available in the Users Manual [Adams et al., 2010].

In a hybrid minimization strategy (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.

In the multi-start iteration strategy (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. An important feature is that these iterator runs may be performed concurrently.

In the pareto set optimization strategy (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. Again, these optimizations can be performed concurrently, similar to the multi-start strategy discussed above. The code is similar enough to the multi_start technique that both strategies are implemented in the same ConcurrentStrategy class.

Lastly, the single_method strategy is the default strategy in that it does not provide control over multiple iterators or multiple models. Rather, it provides the means for simple execution of a single iterator on a single model. It is most commonly used when specifying other strategy-independent controls, e.g., tabular output, where the existence of the strategy block mandates selection of a strategy.

Each of the strategy specifications identifies one or more method pointers (e.g., method_list, method_pointer) to identify the iterators that will be used in the strategy. These method pointers are strings that correspond to the id_method identifier strings from the method specifications (see Method Independent Controls). These string identifiers (e.g., 'NLP1') should not be confused with method selections (e.g., dot_mmfd). Each of the method specifications identified in this manner has the responsibility for identifying corresponding model specifications (using model_pointer from Method Independent Controls), which in turn identify the variables, interface, and responses specifications (using variables_pointer, interface_pointer, and responses_pointer from Model Commands) that are used to build the model used by the iterator. If one of these specifications does not provide an optional pointer, then that component will be constructed using the last specification parsed. In addition to method pointers, a variety of graphics options (e.g., tabular_graphics_data), iterator concurrency controls (e.g., iterator_servers), and strategy data (e.g., starting_points) can be specified.

Specification of a strategy block in an input file is optional, with single_method being the default strategy. If no strategy is specified or if single_method is specified without its optional method_pointer specification, then the default behavior is to employ the last method, variables, interface, and responses specifications parsed. This default behavior is most appropriate if only one specification is present for method, variables, interface, and responses, since there is no ambiguity in this case.

Example specifications for each of the strategies follow. A hybrid example is:

strategy,
	hybrid sequential
	  method_list = 'GA', 'PS', 'NLP'

A multi_start example specification is:

strategy,
	multi_start
	  method_pointer = 'NLP1'
	  random_starts = 10

A pareto_set example specification is:

strategy,
	pareto_set
	  method_pointer = 'NLP1'
          random_weight_sets = 10

And finally, a single_method example specification is:

strategy,
	single_method
	  method_pointer = 'NLP1'

Strategy Specification

The strategy specification has the following structure:

strategy,
	<strategy independent controls>
	<strategy selection>
	  <strategy dependent controls>

where <strategy selection> is one of the following: hybrid, multi_start, pareto_set, or single_method.

The <strategy independent controls> are those controls which are valid for a variety of strategies. Unlike the Method Independent Controls, which can be abstractions with slightly different implementations from one method to the next, the implementations of each of the strategy independent controls are consistent for all strategies that use them. The <strategy dependent controls> are those controls which are only meaningful for a specific strategy. Referring to dakota.input.summary, the strategy independent controls are those controls defined externally from and prior to the strategy selection blocks. They are all optional. The strategy selection blocks are all required group specifications separated by logical OR's (hybrid OR multi_start OR pareto_set OR single_method). Thus, one and only one strategy selection must be provided. The strategy dependent controls are those controls defined within the strategy selection blocks. Defaults for strategy independent and strategy dependent controls are defined in DataStrategy. The following sections provide additional detail on the strategy independent controls followed by the strategy selections and their corresponding strategy dependent controls.

Strategy Independent Controls

The strategy independent controls are summarized in Table 4.1, including graphics, output data, and iterator scheduling controls. The graphics flag activates a 2D graphics window containing history plots for the variables and response functions in the study. This window is updated in an event loop with approximately a 2 second cycle time. The tabular_graphics_data flag activates file tabulation of the same variables and response function history data that gets passed to graphics windows with use of the graphics flag. The tabular_graphics_file specification optionally specifies a name to use for this file (dakota_tabular.dat is the default). Within the file, the variables and response functions appear as columns and each function evaluation provides a new table row. This capability is most useful for post-processing of DAKOTA results with third-party graphics tools such as MATLAB, Tecplot, etc. There is no dependence between the graphics flag and the tabular_graphics_data flag; they may be used independently or concurrently. Numeric output precision (as passed to the C++ control std::setprecision) can be controlled with output_precision with an upper limit of 16 enforced at run-time. When this control is not specified, most DAKOTA output will default to a precision of 10, though filesystem interfaces and pre-run output use higher precision for accuracy and better results reproducibility.

The iterator_servers, iterator_self_scheduling, and iterator_static_scheduling specifications provide manual overrides for the number of concurrent iterator partitions and the scheduling policy 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. The graphics, tabular_graphics_data, and tabular_graphics_file specifications are valid for all strategies. However, the iterator_servers, iterator_self_scheduling, and iterator_static_scheduling overrides are only useful inputs for those strategies supporting concurrency in iterators, i.e., multi_start and pareto_set.

Table 4.1 Specification detail for strategy independent controls
Description	Keyword	Associated Data	Status	Default
Graphics flag	`graphics`	none	Optional	no graphics
Tabulation of graphics data	`tabular_graphics_data`	none	Optional group	no data tabulation
File name for tabular graphics data	`tabular_graphics_file`	string	Optional	`dakota_tabular.dat`
Numeric output precision	`output_precision`	integer	Optional	10 (for most output)
Number of iterator servers	`iterator_servers`	integer	Optional	no override of auto configure
Self-scheduling of iterator jobs	`iterator_self_scheduling`	none	Optional	no override of auto configure
Static scheduling of iterator jobs	`iterator_static_scheduling`	none	Optional	no override of auto configure

Hybrid Minimization Commands

The hybrid minimization strategy has sequential,embedded, and collaborative approaches (see the Users Manual [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 sequential approach, a list of method strings supplied with the method_list specification specifies the identity and sequence of iterators to be used. Any number of iterators may be specified. In the sequential approach, method switching is managed through the separate convergence controls of each method. The number of solutions transferred between methods is specified by the particular method through its final_solutions method control. For example, if one sets up a two-level strategy 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. Table 4.2 summarizes the sequential hybrid strategy inputs.

Table 4.2 Specification detail for sequential hybrid strategies
Description	Keyword	Associated Data	Status	Default
Hybrid strategy	`hybrid`	none	Required group (1 of 4 selections)	N/A
Sequential hybrid	`sequential`	none	Required group (1 of 3 selections)	N/A
List of methods	`method_list`	list of strings	Required	N/A

In the embedded approach, global and local method strings supplied with the global_method_pointer and local_method_pointer specifications identify the two methods to be used. The 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. Table 4.3 summarizes the embedded hybrid strategy inputs.

Table 4.3 Specification detail for embedded hybrid strategies
Description	Keyword	Associated Data	Status	Default
Hybrid strategy	`hybrid`	none	Required group (1 of 4 selections)	N/A
Embedded hybrid	`embedded`	none	Required group (1 of 3 selections)	N/A
Pointer to the global method specification	`global_method_pointer`	string	Required	N/A
Pointer to the local method specification	`local_method_pointer`	string	Required	N/A
Probability of executing local searches	`local_search_probability`	real	Optional	0.1

In the collaborative approach, a list of method strings supplied with the method_list specification specifies the pool of iterators to be used. Any number of iterators may be specified. The method collaboration logic follows that of either the Agent-Based Optimization or HOPSPACK codes and is currently under development. Table 4.4 summarizes the collaborative hybrid strategy inputs.

Table 4.4 Specification detail for collaborative hybrid strategies
Description	Keyword	Associated Data	Status	Default
Hybrid strategy	`hybrid`	none	Required group (1 of 4 selections)	N/A
Collaborative hybrid	`collaborative`	none	Required group (1 of 3 selections)	N/A
List of methods	`method_list`	list of strings	Required	N/A

Multistart Iteration Commands

The multi_start strategy must specify an iterator using method_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 random_starts, for which the specified number of starting points are selected randomly within the variable bounds, (2) using starting_points, in which the starting values are provided in a list, or (3) using both random_starts and 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 strategy 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. Table 4.5 summarizes the multi-start strategy inputs.

Table 4.5 Specification detail for multi-start strategies
Description	Keyword	Associated Data	Status	Default
Multi-start iteration strategy	`multi_start`	none	Required group (1 of 4 selections)	N/A
Method pointer	`method_pointer`	string	Required	N/A
Number of random starting points	`random_starts`	integer	Optional group	no random starting points
Seed for random starting points	`seed`	integer	Optional	system-generated seed
List of user-specified starting points	`starting_points`	list of reals	Optional	no user-specified starting points

Pareto Set Optimization Commands

The pareto_set strategy must specify an optimization or least squares calibration method using method_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 random_weight_sets, in which case weightings are selected randomly within [0,1] bounds, (2) using weight_sets, in which the weighting sets are specified in a list, or (3) using both random_weight_sets and 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. Table 4.6 summarizes the pareto set strategy inputs.

Table 4.6 Specification detail for pareto set strategies
Description	Keyword	Associated Data	Status	Default
Pareto set optimization strategy	`pareto_set`	none	Required group (1 of 4 selections)	N/A
Optimization method pointer	`method_pointer`	string	Required	N/A
Number of random weighting sets	`random_weight_sets`	integer	Optional	no random weighting sets
Seed for random weighting sets	`seed`	integer	Optional	system-generated seed
List of user-specified weighting sets	`weight_sets`	list of reals	Optional	no user-specified weighting sets

Single Method Commands

The single method strategy is the default if no strategy specification is included in a user input file. It may also be specified using the single_method keyword within a strategy specification. An optional method_pointer specification may be used to point to a particular method specification. If method_pointer is not used, then the last method specification parsed will be used as the iterator. Table 4.7 summarizes the single method strategy inputs.

Table 4.7 Specification detail for single method strategies
Description	Keyword	Associated Data	Status	Default
Single method strategy	`single_method`	string	Required group (1 of 4 selections)	N/A
Method pointer	`method_pointer`	string	Optional	use of last method parsed

Previous chapter

Next chapter