1Blurb:: 2Set the active variables view a method will see 3 4Description:: 5There are certain situations where the user may want to explicitly 6control the subset of variables that is considered active for a 7certain %Dakota method. This is done by specifying the keyword \c 8active in the variables specification block, followed by one of the 9following: \c all, \c design, \c uncertain, \c aleatory, \c epistemic, 10or \c state. 11 12Specifying one of these subsets of variables will allow 13the %Dakota method to operate on the specified variable types and 14override the default active subset. 15 16If the user does not specify any explicit override of the active view 17of the variables, %Dakota first considers the response function 18specification. 19 20- If the user specifies objective 21functions or calibration terms in the response specification block, 22then we can infer that the active variables should be the design 23variables (since design variables are used within optimization and 24least squares methods). 25- If the user instead specifies the generic 26response type of \c response_functions, then 27%Dakota cannot infer the active variable subset from the response 28specification and will instead infer it from the method selection. 29 -# If 30the method is a parameter study, or any of the methods available under 31dace, psuade, or fsu methods, the active view is set to all 32variables. 33 -# For uncertainty quantification methods, if the method is 34sampling, then the view is set to aleatory if only aleatory variables 35are present, epistemic if only epistemic variables are present, or 36uncertain (covering both aleatory and epistemic) if both are 37present. 38 -# If the uncertainty method involves interval estimation or 39evidence calculations, the view is set to epistemic. 40 -# For other 41uncertainty quantification methods not mentioned in the previous 42sentences (e.g., reliability methods or stochastic expansion methods), 43the default view is set to aleatory. 44 -# Finally, for verification studies 45using the Richardson extrapolation method, the active view is set to 46state. 47 -# Note that in surrogate-based optimization, where the surrogate 48is built on points defined by the method defined by the 49\c dace_method_pointer, the sampling used to generate the points 50is performed only over the design variables as a default unless 51otherwise specified (e.g. state variables will not be sampled 52for surrogate construction). 53 54As alluded to in the previous section, the iterative method selected 55for use in Dakota determines what subset, or view, of the variables 56data is active in the iteration. The general case of having a mixture 57of various different types of variables is supported within all of the 58Dakota methods even though certain methods will only modify certain 59types of variables (e.g., optimizers and least squares methods only 60modify design variables, and uncertainty quantification methods 61typically only utilize uncertain variables). 62This implies that variables which are not under the 63direct control of a particular iterator will be mapped through the 64interface in an unmodified state. This allows for a variety of 65parameterizations within the model in addition to those which are 66being used by a particular iterator, which can provide the convenience 67of consolidating the control over various modeling parameters in a 68single file (the Dakota input file). An important related point is 69that the variable set that is active with a particular iterator is the 70same variable set for which derivatives are typically computed. 71 72 73Topics:: 74Examples:: 75For example, the default behavior 76for a nondeterministic sampling method is to sample the uncertain 77variables. However, if the user specifed \c active \c all in the 78variables specification block, the sampling would be performed over 79all variables (e.g. design and state variables in addition to the 80uncertain variables). This may be desired in situations such as 81surrogate-based optimization under uncertainty, where a surrogate may 82be constructed to span both design and uncertain variables. This is 83an example where we expand the active subset beyond the default, but 84in other situations, we may wish to restrict from the default. An 85example of this would be performing design of experiments in the 86presence of multiple variable types (for which all types are active by 87default), but only wanting to sample over the design variables for 88purposes of constructing a surrogate model for optimization. <!-- 89Another (automated) example would be forming a polynomial chaos 90expansion over design, aleatory, and epistemic variables, but for 91which probabilities are evaluated only over an aleatory subset. 92Finally, more sophisticated uncertainty studies may involve various 93combinations of epistemic vs. aleatory variables being active in 94nested models. --> 95 96Theory:: 97The optional status of the different variable type specifications 98allows the user to specify only those variables which are present 99(rather than explicitly specifying that the number of a particular 100type of variables is zero). However, at least one type of variables 101that are active for the iterator in use must have nonzero size or an 102input error message will result. 103Faq:: 104See_Also:: 105