Dakota Reference Manual
Version 6.2
LargeScale Engineering Optimization and Uncertainty Analysis

The sub_method_pointer
specifies the method block for the subiterator
This keyword is related to the topics:
Alias: none
Argument(s): STRING
Required/Optional  Description of Group  Dakota Keyword  Dakota Keyword Description  

Optional  iterator_servers  Specify the number of iterator servers when Dakota is run in parallel  
Optional  iterator_scheduling  Specify the scheduling of concurrent iterators when Dakota is run in parallel  
Optional  processors_per_iterator  Specify the number of processors per iterator server when Dakota is run in parallel  
Optional  primary_variable_mapping  Primary mappning of toplevel variables to submodel variables  
Optional  secondary_variable_mapping  Secondary mappning of toplevel variables to submodel variables  
Optional  primary_response_mapping  Primary mappning of submodel responses to toplevel responses  
Optional  secondary_response_mapping  Secondary mappning of submodel responses to toplevel responses 
The sub_method_pointer
specifies the method block for the subiterator.
See block_pointer for details about pointers.
Nested models may employ mappings for both the variable inputs to the submodel and the response outputs from the submodel. In the former case, the primary_variable_mapping
and secondary_variable_mapping
specifications are used to map from the active toplevel variables into the submodel variables, and in the latter case, the primary_response_mapping
and secondary_response_mapping
specifications are used to compute the submodel response contributions to the toplevel responses.
For the variable mappings, the primary and secondary specifications provide lists of strings which are used to target specific submodel variables and their subparameters, respectively. The primary strings are matched to continuous or discrete variable labels such as 'cdv_1'
(either usersupplied or default labels), and the secondary strings are matched to either real or integer random variable distribution parameters such as 'mean'
or 'num_trials'
(the form of the uncertain distribution parameter keyword that is appropriate for a single variable instance) or continuous or discrete design/state variable subparameters such as 'lower_bound'
or 'upper_bound'
(again, keyword form appropriate for a single variable instance). No coercion of types is supported, so realvalued toplevel variables should map to either realvalued submodel variables or realvalued subparameters and integervalued toplevel variables should map to either integervalued submodel variables or integervalued subparameters. As long as these real versus integer constraints are satisfied, mappings are free to cross variable types (design, aleatory uncertain, epistemic uncertain, state) and domain types (continuous, discrete). Both primary_variable_mapping
and secondary_variable_mapping
specifications are optional, which is designed to support the following three possibilities:
'continuous_design'
variables which are active at the top level). Multiple submodel variable types may be updated in this manner, provided that they are all active in the toplevel variables. Since there is a direct variable correspondence for these default insertions, submodel bounds and labels are also updated from the toplevel bounds and labels in order to eliminate the need for redundant input file specifications. Thus, it is typical for the submodel variables specification to only contain the minimal required information, such as the number of variables, for these insertion targets. The submodel must allocate enough space for each of the types that will accept default insertions, and the leading set of matching submodel variables are updated (i.e., the submodel may allocate more than needed and the trailing set will be unmodified).These different variable mapping possibilities may be used in any combination by employing empty strings (''
) for particular omitted mappings (the number of strings in usersupplied primary and secondary variable mapping specifications must equal the total number of active toplevel variables, including both continuous and discrete types). The ordering of the active variables is the same as shown in dakota.input.summary on Input Spec Summary and as presented in variables.
If inactive variables are present at the outer level, then the default type 3 mapping is used for these variables; that is, outer loop inactive variables are inserted into inner loop variables (active or inactive) based on matching of variable types, toplevel bounds and labels are also propagated, the inner loop must allocate sufficient space to receive the outer loop values, and the leading subset within this inner loop allocation is updated. This capability is important for allowing nesting beyond two levels, since an active variable at the outermost loop may become inactive at the next lower level, but still needs to be further propagated down to lower levels in the recursion.
For the response mappings, the primary and secondary specifications provide realvalued multipliers to be applied to subiterator response results so that the responses from the inner loop can be mapped into a new set of responses at the outer loop. For example, if the nested model is being employed within a mixed aleatoryepistemic uncertainty quantification, then aleatory statistics from the inner loop (such as moments of the response) are mapped to the outer level, where minima and maxima of these aleatory statistics are computed as functions of the epistemic parameters. The response mapping defines a matrix which scales the values from the inner loop and determines their position in the outer loop response vector. Each row of the mapping corresponds to one outer loop response, where each column of the mapping corresponds to a value from the inner loop. Depending on the number of responses and the particular attributes calculated on the inner loop, there will be a vector of inner loop response values that need to be accounted for in the mapping. This vector of inner loop response results is defined as follows for different subiterator types:
response_levels
, probability_levels
, reliability_levels
, and/or gen_reliability_levels
, in that order.response_levels
, probability_levels
, reliability_levels
, and/or gen_reliability_levels
, in that order.The primary values map subiterator response results into toplevel objective functions, least squares terms, or generic response functions, depending on the declared toplevel response set. The secondary values map subiterator response results into toplevel nonlinear inequality and equality constraints.
Nested models utilize a subiterator and a submodel to perform a complete iterative study as part of every evaluation of the model. This subiteration accepts variables from the outer level, performs the sublevel analysis, and computes a set of sublevel responses which are passed back up to the outer level. Mappings are employed for both the variable inputs to the submodel and the response outputs from the submodel.
In the variable mapping case, primary and secondary variable mapping specifications are used to map from the toplevel variables into the submodel variables. These mappings support three possibilities in any combination: (1) insertion of an active toplevel variable value into an identified submodel distribution parameter for an identified active submodel variable, (2) insertion of an active toplevel variable value into an identified active submodel variable value, and (3) addition of an active toplevel variable value as an inactive submodel variable, augmenting the active submodel variables.
In the response mapping case, primary and secondary response mapping specifications are used to map from the submodel responses back to the toplevel responses. These specifications provide realvalued multipliers that are applied to the subiterator response results to define the outer level response set. These nested data results may be combined with nonnested data through use of the "optional interface" component within nested models.
The nested model constructs admit a wide variety of multiiterator, multimodel solution approaches. For example, optimization within optimization (for hierarchical multidisciplinary optimization), uncertainty quantification within uncertainty quantification (for secondorder probability), uncertainty quantification within optimization (for optimization under uncertainty), and optimization within uncertainty quantification (for uncertainty of optima) are all supported, with and without surrogate model indirection. Several examples of nested model usage are provided in the Users Manual, most notably mixed epistemicaleatory UQ, optimization under uncertainty (OUU), and surrogatebased UQ.