.. _interface-deactivate-active_set_vector:

"""""""""""""""""
active_set_vector
"""""""""""""""""


Deactivate the Active Set Vector


.. toctree::
   :hidden:
   :maxdepth: 1



**Specification**

- *Alias:* None

- *Arguments:* None


**Description**


Allows the user to turn off any variability in ASV values so that
active set logic can be omitted in the user's simulation
interface. This option trades some efficiency for simplicity in
interface development.

The default behavior is to request the minimum amount of data required
by an algorithm at any given time, which implies that the ASV values
may vary from one function evaluation to the next. Since the user's
interface must return the data set requested by the ASV values, this
interface must contain additional logic to account for any variations
in ASV content.

Deactivating this ASV control causes Dakota to always request a
"full" data set (the full function, gradient, and Hessian data that is
available from the interface as specified in the responses
specification) on each function evaluation.

For example, if ASV control has been deactivated and the responses
section specifies four response functions, analytic gradients, and no
Hessians, then the ASV on every function evaluation will be { 3 3 3 3
}, regardless of what subset of this data is currently needed. While
wasteful of computations in many instances, this simplifies the
interface and allows the user to return the same data set on every
evaluation.  Conversely, if ASV control is active (the default
behavior), then the ASV requests in this example might vary from { 1 1
1 1 } to { 2 0 0 2 }, etc., according to the specific data needed on a
particular function evaluation. This will require the user's interface
to read the ASV requests and perform the appropriate logic in
conditionally returning only the data requested.

*Usage Tips*


- In general, the default ASV behavior is recommended for the sake     of computational efficiency, unless interface development time is     a critical concern.
- Whether active or inactive, the data returned to Dakota from the     user's interface must match the ASV passed in, or else a response     recovery error will result. However, when the ASV control is     deactivated, the ASV values are invariant and need not be checked     on every evaluation.
- Deactivating the ASV control can have a positive effect on load     balancing for parallel Dakota executions. Thus, there is     significant overlap in this ASV control option with speculative     gradients.  There is also overlap with the mode override approach     used with certain optimizers to combine individual value,     gradient, and Hessian requests.


