![]() |
Dakota Reference Manual
Version 6.15
Explore and Predict with Confidence
|
Set the active variables view a method will see
Alias: none
Argument(s): none
Default: Infer from response or method specification
Child Keywords:
Required/Optional | Description of Group | Dakota Keyword | Dakota Keyword Description | |
---|---|---|---|---|
Required (Choose One) | Active Variables (Group 1) | all | Option for the active keyword | |
design | Option for the active keyword | |||
uncertain | Option for the active keyword | |||
aleatory | Option for the active keyword | |||
epistemic | Option for the active keyword | |||
state | Option for the active keyword |
There are certain situations where the user may want to explicitly control the subset of variables that is considered active for a certain Dakota method. This is done by specifying the keyword active
in the variables specification block, followed by one of the following: all
, design
, uncertain
, aleatory
, epistemic
, or state
.
Specifying one of these subsets of variables will allow the Dakota method to operate on the specified variable types and override the default active subset.
If the user does not specify any explicit override of the active view of the variables, Dakota first considers the response function specification.
response_functions
, then Dakota cannot infer the active variable subset from the response specification and will instead infer it from the method selection.dace_method_pointer
, the sampling used to generate the points is performed only over the design variables as a default unless otherwise specified (e.g. state variables will not be sampled for surrogate construction).As alluded to in the previous section, the iterative method selected for use in Dakota determines what subset, or view, of the variables data is active in the iteration. The general case of having a mixture of various different types of variables is supported within all of the Dakota methods even though certain methods will only modify certain types of variables (e.g., optimizers and least squares methods only modify design variables, and uncertainty quantification methods typically only utilize uncertain variables). This implies that variables which are not under the direct control of a particular iterator will be mapped through the interface in an unmodified state. This allows for a variety of parameterizations within the model in addition to those which are being used by a particular iterator, which can provide the convenience of consolidating the control over various modeling parameters in a single file (the Dakota input file). An important related point is that the variable set that is active with a particular iterator is the same variable set for which derivatives are typically computed.
For example, the default behavior for a nondeterministic sampling method is to sample the uncertain variables. However, if the user specifed active
all
in the variables specification block, the sampling would be performed over all variables (e.g. design and state variables in addition to the uncertain variables). This may be desired in situations such as surrogate-based optimization under uncertainty, where a surrogate may be constructed to span both design and uncertain variables. This is an example where we expand the active subset beyond the default, but in other situations, we may wish to restrict from the default. An example of this would be performing design of experiments in the presence of multiple variable types (for which all types are active by default), but only wanting to sample over the design variables for purposes of constructing a surrogate model for optimization.
The optional status of the different variable type specifications allows the user to specify only those variables which are present (rather than explicitly specifying that the number of a particular type of variables is zero). However, at least one type of variables that are active for the iterator in use must have nonzero size or an input error message will result.