Dakota Reference Manual: asynch_pattern_search

| Dakota Reference Manual Version 6.15 Explore and Predict with Confidence

- Main Page
- Related Pages

All Pages
asynch_pattern_search

Pattern search, derivative free optimization method

## Topics

This keyword is related to the topics:

- package_hopspack
- global_optimization_methods

## Specification

Alias: coliny_apps

Argument(s): none

Child Keywords:

| Required/Optional | Description of Group | Dakota Keyword | Dakota Keyword Description
--- | --- | --- | --- | ---
| Optional | initial_delta | Initial step size for derivative-free optimizers
| Optional | contraction_factor | Amount by which step length is rescaled
| Optional | variable_tolerance | Step length-based stopping criteria for derivative-free optimizers
| Optional | solution_target | Stopping criteria based on objective function value
| Optional | synchronization | Select how Dakota schedules a batch of concurrent function evaluations in a parallel algorithm
| Optional | merit_function | Balance goals of reducing objective function and satisfying constraints
| Optional | constraint_penalty | Multiplier for the penalty function
| Optional | smoothing_factor | Smoothing value for smoothed penalty functions
| Optional | constraint_tolerance | Maximum allowable constraint violation still considered feasible
| Optional | max_function_evaluations | Number of function evaluations allowed for optimizers
| Optional | scaling | Turn on scaling for variables, responses, and constraints
| Optional | model_pointer | Identifier for model block to be used by a method

## Description

The asynchronous parallel pattern search (APPS) algorithm [37] 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.

Currently, APPS only supports coordinate bases with a total of 2n function evaluations in the pattern, and these patterns may only contract.

Concurrency

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.

Algorithm Behavior

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

Merit Functions

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 `merit_function` control. The options are as follows:

- `merit_max:` based on norm
- `merit_max_smooth:` based on smoothed norm
- `merit1:` based on norm
- `merit1_smooth:` based on smoothed norm
- `merit2:` based on norm
- `merit2_smooth:` based on smoothed norm
- `merit2_squared:` based on norm

The user can also specify the following to affect the merit functions:

- `constraint_penalty`
- `smoothing_parameter`

Method Independent Controls

The only method independent controls that are currently mapped to APPS are:

- max_function_evaluations
- constraint_tolerance
- output

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 `constraint_tolerance`.

The APPS internal display level is mapped to the Dakota `output` settings as follows:

- `debug:` display final solution, all input parameters, variable and constraint info, trial points, search directions, and execution details
- `verbose:` display final solution, all input parameters, variable and constraint info, and trial points
- `normal:` display final solution, all input parameters, variable and constraint summaries, and new best points
- `quiet:` display final solution and all input parameters
- `silent:` display final solution

Expected HDF5 Output

If Dakota was built with HDF5 support and run with the hdf5 keyword, this method writes the following results to HDF5:

- Best Parameters
- Best Objective Functions (when objective_functions) are specified)
- Best Nonlinear Constraints
- Calibration (when calibration_terms are specified)