A DAKOTA model specifies how variables are mapped into a set of responses in support of an iterative method and the model specification in an input file dictates the components to be used in constructing a particular model instance. This specification selects a Model from the model hierarchy, which includes SingleModel, DataFitSurrModel, HierarchSurrModel, and NestedModel derived classes. Depending on the type of derived model, different sub-specifications are needed to construct different components of the model.
Several examples follow. The first example shows a minimal specification for a single model, which is the default model when no models are specified by the user.
model, single
This example does not provide any pointer strings and therefore relies on the default behavior of constructing the model with the last variables, interface, and responses specifications parsed.
The next example displays a surrogate model specification which selects a quadratic polynomial from among the global approximation methods. It uses a pointer to a design of experiments method for generating the data needed for building the global approximation, reuses any old data available for the current approximation region, and employs the first-order multiplicative approach to correcting the approximation at the center of the current approximation region.
model, id_model = 'M1' variables_pointer = 'V1' responses_pointer = 'R1' surrogate global polynomial quadratic dace_method_pointer = 'DACE' reuse_samples region correction multiplicative first_order
This example demonstrates the use of identifiers and pointers. It provides the optional model independent specifications for model identifier, variables pointer, and responses pointer (see Model Independent Controls) as well as model dependent specifications for global surrogates (see Global approximations).
Finally, an advanced nested model example would be
model, id_model = 'M1' variables_pointer = 'V1' responses_pointer = 'R1' nested optional_interface_pointer = 'OI1' optional_interface_responses_pointer = 'OIR1' sub_method_pointer = 'SM1' primary_variable_mapping = '' '' 'X' 'Y' secondary_variable_mapping = '' '' 'mean' 'mean' primary_response_mapping = 1. 0. 0. 0. 0. 0. 0. 0. 0. secondary_response_mapping = 0. 0. 0. 1. 3. 0. 0. 0. 0. 0. 0. 0. 0. 0. 0. 1. 3. 0.
This example also supplies model independent controls for model identifier, variables pointer, and responses pointer (see Model Independent Controls), and supplies model dependent controls for specifying details of the nested mapping (see Nested Model Controls).
As alluded to in the examples above, the model specification has the following structure:
model, <model independent controls> <model selection> <model dependent controls>
The <model independent controls> are those controls which are valid for all models. Referring to dakota.input.summary, these controls are defined externally from and prior to the model selection blocks. The model selection blocks are all required group specifications separated by logical OR's, where the model selection must be single OR surrogate OR nested. If a surrogate model is specified, a secondary selection must be made for its type: global, multipoint, local, or hierarchical. The <model dependent controls> are those controls which are only meaningful for a specific model. These controls are defined within each model selection block. Defaults for model independent and model dependent controls are defined in DataModel. The following sections provide additional detail on the model independent controls followed by the model selections and their corresponding model dependent controls.
The model independent controls include a model identifier string, pointers to variables and responses specifications, and a model type specification. The model identifier string is supplied with id_model and is used to provide a unique identifier string for use within method specifications (refer to model_pointer in Method Independent Controls).
The type of model can be single, nested, or surrogate. Each of these model specifications supports variables_pointer and responses_pointer strings for identifying the variables and responses specifications used in constructing the model (by cross-referencing with id_variables and id_responses strings from particular variables and responses keyword specifications). These pointers are valid for each model type since each model contains a set of variables that is mapped into a set of responses -- only the specifics of the mapping differ. Additional pointers are used for each model type for constructing the components of the variable to response mapping. As a strategy specification identifies one or more methods and a method specification identifies a model, a model specification identifies variables, interface, and responses specifications. This top-down flow specifies all of the object interrelationships.
For each of these pointer specifications, if a pointer string is specified and no corresponding id string is available, DAKOTA will exit with an error message. If the pointer is optional and no pointer string is specified, then the last specification parsed will be used. It is appropriate to omit optional cross-referencing whenever the relationships are unambiguous due to the presence of only one specification.
Table 6.1 provides the specification detail for the model independent controls involving identifiers, model type controls, and pointers.
Description | Keyword | Associated Data | Status | Default |
Model set identifier |
| string | Optional | method use of last model parsed |
Model type |
| none | Required group | N/A ( |
Variables set pointer |
| string | Optional | model use of last variables parsed |
Responses set pointer |
| string | Optional | model use of last responses parsed |
In the single model case, a single interface is used to map the variables into responses. The optional interface_pointer specification identifies this interface by cross-referencing with the id_interface string input from a particular interface keyword specification.
Table 6.2 provides the specification detail for single models.
Description | Keyword | Associated Data | Status | Default |
Interface set pointer |
| string | Optional | model use of last interface parsed |
In the surrogate model case, the specification first allows a mixture of surrogate and actual response mappings through the use of the optional id_surrogates specification. This identifies the subset of the response functions by number that are to be approximated (the default is all functions). The valid response function identifiers range from 1 through the total number of response functions (see Function Specification). Next, the specification selects a global, multipoint, local, or hierarchical approximation. Table 6.3 provides the specification detail for surrogate models.
Description | Keyword | Associated Data | Status | Default |
Surrogate response ids |
| list of integers | Optional | All response functions are approximated |
Surrogate type selection |
| none | Required group | N/A |
Each of these surrogate types provides an approximate representation of a "truth" model which is used to perform the parameter to response mappings. This approximation is built and updated using data from the truth model. This data is generated in some cases using a design of experiments iterator applied to the truth model (global approximations with a dace_method_pointer). In other cases, truth model data from a single point (local, hierarchical approximations), from a few previously evaluated points (multipoint approximations), or from the restart database (global approximations with reuse_samples) can be used. Surrogate models are used extensively in the surrogate-based optimization and least squares methods (see SurrBasedMinimizer and its derived classes and Surrogate-Based Minimization Methods), in which the goals are to reduce expense by minimizing the number of truth function evaluations and to smooth out noisy data with a global data fit. However, the use of surrogate models is not restricted to optimization techniques; uncertainty quantification and optimization under uncertainty methods are other primary users.
The following sections present the global, multipoint, local, and hierarchical specification groups in further detail.
The global surrogate model requires specification of one of the following approximation types: polynomial, gaussian_process (Kriging), neural_network, mars, moving_least_squares, or radial_basis. These specifications will create a polynomial, a Gaussian process (Kriging interpolation), layered perceptron artificial neural network approximation, multivariate adaptive regression spline, moving least squares, or radial basis function approximation, respectively. All these approximations are implemented in SurfPack except an alternate Gaussian process model, which is implemented directly in DAKOTA.
In the polynomial case, the order of the polynomial (linear, quadratic, or cubic) must be specified.
DAKOTA has two Gaussian process (GP) or Kriging models, one that resides in DAKOTA proper and the other in DAKOTA's Surfpack subpackage. Choice of the GP implmentation is made by specifying gaussian_process (alternately kriging) followed by either dakota or surfpack. Historically these models were drastically different, but in DAKOTA 5.1, they became quite similar. They now differ in that the Surfpack GP has a richer set of features/options and tends to be more accurate than the DAKOTA version. Due to how the Surfpack GP handles ill-conditioned correlation matrices (which significantly contributes to its greater accuracy), the Surfpack GP can be a factor of two or three slower than DAKOTA's. As of DAKOTA 5.2, the Surfpack implementation is the default in all contexts except Bayesian calibration. The DAKOTA GP is provided for continuity, but may be deprecated in the future.
The trend function of both GP models is selected using the trend keyword, with options constant, linear, or reduced_quadratic (default). The Surfpack GP has the additional option of (a full) quadratic. The reduced_quadratic trend function includes the main effects, but not mixed/interaction terms. NOTE: prior to DAKOTA 5.1, reduced_quadratic was selected for the DAKOTA GP via the quadratic option.
The DAKOTA GP always determines its correlation parameters via maximum likelihood estimate (MLE) using a global optimization procedure. Ill-conditioning induced by poorly spaced sample points is a common challenge in the construction of Gaussian process models. DAKOTA's GP deals with ill-conditioning in two ways. First, when it encounters a non-invertible correlation matrix it iteratively increases the size of a "nugget," but in such cases the resulting approximation smooths rather than interpolates the data. Second, it has a point_selection option (default off) that uses a greedy algorithm to select a well-spaced subset of points prior to the construction of the GP. In this case, the GP will only interpolate the selected subset. Typically, one should not need point selection in trust-region methods because a small number of points are used to develop a surrogate within each trust region. Point selection is most beneficial when constructing with a large number of points, typically more than order one hundred, though this depends on the number of variables and spacing of the sample points.
By default, the Surfpack GP also selects its correlation parameters using a global optimizer, but its search is concentrated in a smaller feasible region of correlation parameters. However, one may force the Surfpack GP to use a different search algorithm by specifying optimization_method followed by any of 'global', 'local', 'sampling', or 'none'. The none option and starting location of the local search default to the center of the small feasible region of correlation lengths. However, one may also directly specify correlation_lengths as a list of N real numbers where N is the number of input dimensions. As of DAKOTA 5.2, the Surfpack GP handles ill-conditioning by selecting the subset of points that tightly meets a constraint on the condition number and provides the maximum amount of useful information for the correlation lengths chosen by MLE. For each set of correlation lengths examined during the MLE optimization, the optimal subset of points for those correlation lengths is used. The subset of points used to build the Surfpack GP is the one associated with the most likely set of correlation lengths. This differs from the point_selection option of the DAKOTA GP which initially chooses a well-spaced subset of points and finds the correlation parameters that are most likely for that one subset. It is similar to the DAKOTA GP's point selection in that the Surfpack GP will only interpolate the selected subset of points.
The use_derivatives keyword will cause the Surfpack GP to be constructed from a combination of function value and gradient information (if available). This is only beneficial when a function value plus a gradient can be computed at a computational cost comparable to a function value only. This rules out gradients computed by finite differences (which also tend to be insufficiently accurate). However, the accurate and inexpensive derivatives calculated by analytical, automatic differentiation, or continuous adjoint techniques can be cost effective and beneficial provided that they are not infinite or nearly so. Although a function value plus gradient can be often be obtained more cheaply than two function value only evaluations, each scalar derivative equation costs as much as a scalar function value equation during the construction of the emulator. Since the cost to build a GP is cubic in the number of equations, the cost to build a gradient-enhanced GP/Kriging model will be roughly (N+1)^3 times greater than one that is not gradient-enhanced, where N is the number of input dimensions. Also, a poorly spaced sample design has a greater adverse affect on the conditioning of the correlation matrix when derivative information is included. This can result in significantly more points being discarded and hence providing no benefit to the derivative enhanced GP/Kriging model's accuracy.
Tables 6.4 and 6.5 summarize the global approximation selection specifications.
Description | Keyword | Associated Data | Status | Default | |
Global approximations |
| none | Required group (1 of 4 selections) | N/A | |
Polynomial |
|
| Required group (1 of 7 selections) | N/A | |
DAKOTA Gaussian process |
| dakota | Required (1 of 7 selections) | N/A | |
GP trend function |
|
| Optional | reduced_quadratic trend | |
GP point selection |
| none | Optional | no point selection | |
Surfpack Gaussian process (Kriging) |
| surfpack | Required group (1 of 7 selections) | N/A | |
Surfpack GP trend function |
|
| Optional |
| |
Surfpack GP correlation lengths |
| list of reals | Optional for none/local | internally computed correlation_lengths | |
Surfpack GP optimization method |
|
| Optional | global | |
Surfpack GP maximum trials |
| integer | Optional | ||
Surfpack GP gradient enhancement |
| none | Optional | no gradient enhancement | |
Artificial neural network |
| none | Required (1 of 7 selections) | N/A | |
ANN number nodes |
| integer | Optional | ||
ANN range |
| real | Optional | ||
ANN random weight |
| integer | Optional |
Description | Keyword | Associated Data | Status | Default |
Multivariate adaptive regression splines |
| none | Required (1 of 7 selections) | N/A |
MARS maximum bases |
| integer | Optional | |
MARS interpolation |
|
| Optional | |
Moving least squares |
| none | Required (1 of 7 selections) | N/A |
MLS polynomial order |
| integer | Optional | |
MLS weight function |
| integer | Optional | |
Radial basis functions |
| none | Required group (1 of 7 selections) | N/A |
RBF number of bases |
| integer | Optional | |
RBF maximum points |
| integer | Optional | |
RBF minimum partitions |
| integer | Optional | |
RBF maximum subsets |
| integer | Optional |
Table 6.6 summarizes the remaining (optional) global approximation specifications, including controls for the number of points requested to build the surrogate, the source of the points (dace_method_pointer and reuse_samples), the use of derivative information in constructions (use_derivatives), calculation of fitness metrics, and the correction method.
The number of points used in building a global approximation is determined by three point counts:
minimum_points and recommended_points (default), respectively, within a global surrogate model specification. Alternately an integer total_points may be specified to request a specific number of points in each surrogate build (a lower bound of minimum points is enforced). This count, then, can be summarized as Model points = (minimum | recommended | max(minimum, total)).reuse_samples keyword (described below) are always used to build. This count defaults to zero.samples specified within the DACE method specification (identified via dace_method_pointer) always provide a lower bound on the number of fresh DACE samples used to build the surrogate. This count defaults to zero.The number of new points to be evaluated by the DACE method is defined by New points = max(Model points - Reused points, Iterator points), using the logic that the number of points needed is Model points minus Reused points, but respecting a lower bound DACE samples specification when present. The total number of points used in the surrogate build is then New points + Reused points. The DACE iterator will only be invoked if it has new samples to perform, and if new samples are required and no DACE iterator has been provided, an error will result.
The dace_method_pointer links to design of experiments iterator used to generate truth model data for building a global data fit. The reuse_samples specification can be used to employ old data (either from previous function evaluations performed in the run or from function evaluations read from a restart database or text file) in the building of new global approximations. The default is no reuse of old data (since this can induce directional bias), and the settings of all, region, and points_file result in reuse of all available data, reuse of all data available in the current trust region, and reuse of all data from a specified text file, respectively. Both dace_method_pointer and reuse_samples are optional specifications, which gives the user maximum flexibility in using design of experiments data, restart/text file data, or both. Note that the default format for a samples data file has changed in DAKOTA 5.2 (see User's Manual).
The use_derivatives flag specifies that any available derivative information should be used in global approximation builds. This capability is currently supported in SurrBasedLocalMinimizer, Pecos::SurrogateDataPoint, and Approximation::build(), and will soon be supported for global_kriging models, but is not yet supported in any global approximation derived class redefinitions of build().
To assess the goodness of fit of a global surrogate, a variety of diagnostics are available for the following global approximation methods: polynomial regressions, kriging, mars, moving least squares, neural networks, and radial basis functions. The diagnostics are specified by the keyword diagnostics, followed by a list of strings specifying the actual metrics. The diagnostic metrics available are: sum_squared, mean_squared, root_mean_squared, max_squared, sum_scaled, max_scaled, sum_abs, mean_abs, max_abs, press, cv, and rsquared. Most of these diagnostics refer to some operation on the residuals (the difference between the surrogate model and the truth model at the data points upon which the surrogate is built). For example, sum_squared refers to the sum of the squared residuals, mean_abs refers to the mean of the absolute value of the residuals, and max_scaled refers to the maximum scaled value of the residual, where the scaled value is taken by dividing the residual by the true function value at that point. In addition, press refers to a leave-one-out cross validation metric, and cv refers to a general cross validation metric. rsquared refers to the R-squared value typically used in regression analysis (the proportion of the variability in the response that can be accounted for by the surrogate model).
The correction specification specifies that the approximation will be corrected to match truth data, either matching truth values in the case of zeroth_order matching, matching truth values and gradients in the case of first_order matching, or matching truth values, gradients, and Hessians in the case of second_order matching. For additive and multiplicative corrections, the correction is local in that the truth data is matched at a single point, typically the center of the approximation region. The additive correction adds a scalar offset (zeroth_order), a linear function (first_order), or a quadratic function (second_order) to the approximation to match the truth data at the point, and the multiplicative correction multiplies the approximation by a scalar (zeroth_order), a linear function (first_order), or a quadratic function (second_order) to match the truth data at the point. The additive first_order case is due to [Lewis and Nash, 2000] and the multiplicative first_order case is commonly known as beta correction [Haftka, 1991]. For the combined correction, the use of both additive and multiplicative corrections allows the satisfaction of an additional matching condition, typically the truth function values at the previous correction point (e.g., the center of the previous trust region). The combined correction is then a multipoint correction, as opposed to the local additive and multiplicative corrections. Each of these correction capabilities is described in detail in [Eldred et al., 2004a].
Description | Keyword | Associated Data | Status | Default |
Number of build points |
| integer | none | none | Optional | recommended_points |
Design of experiments method pointer |
| string | Optional | no design of experiments data |
Sample reuse in global approximation |
|
| Optional group |
|
File import of samples for global approximation builds |
| string | Optional | no point import from a file |
Data file in annotated format |
| boolean | Optional | annotated |
Data file in freeform format |
| boolean | Optional | annotated |
Use of gradient data in global approximation builds |
| none | Optional | gradient data not used in global approximation builds |
Print diagnostic metrics about the surrogate goodness of fit |
| string list (as many as desired): | Optional | No diagnostics printed |
Surrogate correction approach |
|
| Optional group | no surrogate correction |
Multipoint approximations use data from previous design points to improve the accuracy of local approximations. Currently, the Two-point Adaptive Nonlinearity Approximation (TANA-3) method of [Xu and Grandhi, 1998] is supported. This method requires response value and gradient information from two points, and uses a first-order Taylor series if only one point is available. The truth model to be used to generate the value/gradient data used in the approximation is identified through the required actual_model_pointer specification. Table 6.7 summarizes the multipoint approximation specifications.
Description | Keyword | Associated Data | Status | Default |
Multipoint approximation |
| none | Required group (1 of 4 selections) | N/A |
Two-point adaptive nonlinear approximation |
| none | Required | N/A |
Pointer to the truth model specification |
| string | Required | N/A |
Local approximations use value, gradient, and possibly Hessian data from a single point to form a series expansion for approximating data in the vicinity of this point. The currently available local approximation is the taylor_series selection. The order of the Taylor series may be either first-order or second-order, which is automatically determined from the gradient and Hessian specifications in the responses specification (see Gradient Specification and Hessian Specification) for the truth model.
The truth model to be used to generate the value/gradient/Hessian data used in the series expansion is identified through the required actual_model_pointer specification. The use of a model pointer (as opposed to an interface pointer) allows additional flexibility in defining the approximation. In particular, the derivative specification for the truth model may differ from the derivative specification for the approximation , and the truth model results being approximated may involve a model recursion (e.g., the values/gradients from a nested model). Table 6.8 summarizes the local approximation interface specifications.
Description | Keyword | Associated Data | Status | Default |
Local approximation |
| none | Required group (1 of 4 selections) | N/A |
Taylor series local approximation |
| none | Required | N/A |
Pointer to the truth model specification |
| string | Required | N/A |
Hierarchical approximations use corrected results from a low fidelity model as an approximation to the results of a high fidelity "truth" model. These approximations are also known as model hierarchy, multifidelity, variable fidelity, and variable complexity approximations. The required low_fidelity_model_pointer specification points to the low fidelity model specification. This model is used to generate low fidelity responses which are then corrected and returned to an iterator. The required high_fidelity_model_pointer specification points to the specification for the high fidelity truth model. This model is used only for verifying low fidelity results and updating low fidelity corrections. The correction specification specifies which correction technique will be applied to the low fidelity results in order to match the high fidelity results at one or more points. In the hierarchical case (as compared to the global case), the correction specification is required, since the omission of a correction technique would effectively eliminate the purpose of the high fidelity model. If it is desired to use a low fidelity model without corrections, then a hierarchical approximation is not needed and a single model should be used. Refer to Global approximations for additional information on available correction approaches. Table 6.9 summarizes the hierarchical approximation specifications.
Description | Keyword | Associated Data | Status | Default |
Hierarchical approximation |
| none | Required group (1 of 4 selections) | N/A |
Pointer to the low fidelity model specification |
| string | Required | N/A |
Pointer to the high fidelity model specification |
| string | Required | N/A |
Surrogate correction approach |
|
| Required group | N/A |
Instead of appealing directly to a primary interface, a nested model maps parameters to responses by executing a sub-iterator for each evaluation of the nested model; the sub-iterator in turn operates on a sub-model. The sub-iterator responses may be combined with those from an optional interface specification.
In the nested model case, a sub_method_pointer must be provided in order to specify the nested iterator, and optional_interface_pointer and optional_interface_responses_pointer provide an optional group specification for the optional interface portion of nested models (where optional_interface_pointer points to the interface specification and optional_interface_responses_pointer points to a responses specification describing the data to be returned by this interface). This interface is used to provide non-nested data, which is then combined with data from the nested iterator using the primary_response_mapping and secondary_response_mapping inputs (see mapping discussion below).
Table 6.10 provides the specification detail for nested model pointers.
Description | Keyword | Associated Data | Status | Default |
Optional interface set pointer |
| string | Optional group | no optional interface |
Responses pointer for nested model optional interfaces |
| string | Optional | reuse of top-level responses specification |
Sub-method pointer for nested models |
| string | Required | N/A |
Nested models may employ mappings for both the variable inputs to the sub-model and the response outputs from the sub-model. In the former case, the primary_variable_mapping and secondary_variable_mapping specifications are used to map from the active top-level variables into the sub-model variables, and in the latter case, the primary_response_mapping and secondary_response_mapping specifications are used to compute the sub-model response contributions to the top-level responses. For the variable mappings, the primary and secondary specifications provide lists of strings which are used to target specific sub-model variables and their sub-parameters, respectively. The primary strings are matched to continuous or discrete variable labels such as 'cdv_1' (either user-supplied 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 sub-parameters such as 'lower_bound' or 'upper_bound' (again, keyword form appropriate for a single variable instance). No coercion of types is supported, so real-valued top-level variables should map to either real-valued sub-model variables or real-valued sub-parameters and integer-valued top-level variables should map to either integer-valued sub-model variables or integer-valued sub-parameters. 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 sub-model variable types may be updated in this manner, provided that they are all active in the top-level variables. Since there is a direct variable correspondence for these default insertions, sub-model bounds and labels are also updated from the top-level bounds and labels in order to eliminate the need for redundant input file specifications. Thus, it is typical for the sub-model variables specification to only contain the minimal required information, such as the number of variables, for these insertion targets. The sub-model must allocate enough space for each of the types that will accept default insertions, and the leading set of matching sub-model variables are updated (i.e., the sub-model 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 user-supplied primary and secondary variable mapping specifications must equal the total number of active top-level variables, including both continuous and discrete types). The ordering of the active variables is the same as shown in dakota.input.summary and as presented in Variables Commands.
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, top-level 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 outer-most loop may become inactive at the next lower level, but still need to be further propagated down the recursion.
For the response mappings, the primary and secondary specifications provide real-valued multipliers to be applied to sub-iterator response results. The idea is that the responses from the inner loop are mapped to the outer loop. For example, if the nested model is an uncertainty quantification, aleatory statistics from the inner loop such as the mean inner loop response are mapped to the outer level, where they are treated epistemically, so that intervals on the mean (for example) are calculated. The response mapping defines a vector which multiplies the values from the inner loop to the outer loop. 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. The sub-iterator response results are defined as follows for different sub-iterator 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 sub-iterator response results into top-level objective functions, least squares terms, or generic response functions, depending on the declared top-level response set. The secondary values map sub-iterator response results into top-level nonlinear inequality and equality constraints. Refer to NestedModel::response_mapping() for additional details.
An example of variable and response mappings is provided below:
primary_variable_mapping = '' '' 'X' 'Y'
secondary_variable_mapping = '' '' 'mean' 'mean'
primary_response_mapping = 1. 0. 0. 0. 0. 0. 0. 0. 0.
secondary_response_mapping = 0. 0. 0. 1. 3. 0. 0. 0. 0.
0. 0. 0. 0. 0. 0. 1. 3. 0.
The variable mappings correspond to 4 top-level variables, the first two of which employ the default mappings from active top-level variables to sub-model variables of the same type (option 3 above) and the latter two of which are inserted into the mean distribution parameters of sub-model variables 'X' and 'Y' (option 1 above). In this particular example, there are 9 inner loop response attributes and 3 outer loop response functions (one primary response function and 2 secondary functions, such as one objective and two constraints). Each row of the response mapping is a vector which is multiplied (e.g. dot-product) against the 9 sub-iterator values to determine the outer loop function. For example, the primary response mapping only picks up the first value from the inner loop. This first value is the mean of the first response function on the inner loop. The response mappings correspond to 9 sub-iterator response functions (e.g., there are 3 response functions, each with a set of UQ final statistics: each has a mean, a standard deviation, and a level mapping in this example. If no probability or reliability levels are specified, the responses would only have a mean and standard deviation). The primary response mapping maps the first sub-iterator response function (mean) into a single objective function, least squares term, or generic response function (as dictated by the top-level response specification), and the secondary response mapping maps the fourth sub-iterator response function plus 3 times the fifth sub-iterator response function (mean plus 3 standard deviations) into one top-level nonlinear constraint and the seventh sub-iterator response function plus 3 times the eighth sub-iterator response function (mean plus 3 standard deviations) into another top-level nonlinear constraint (these top-level nonlinear constraints may be inequality or equality, as dictated by the top-level response specification). Note that in many cases, each particular sub-iterator response will be mapped to a unique outer loop response (for example, in the nested UQ case where one wants to determine an interval on each inner loop statistic). In these cases, the response mapping will be the identity matrix. That is, the primary response mapping will have N rows and N columns corresponding to the N sub-iterator response values, and the mapping matrix will have a value of one along the diagonal and zeros elsewhere.
Table 6.11 provides the specification detail for the model independent controls involving nested model mappings.
Description | Keyword | Associated Data | Status | Default |
Primary variable mappings for nested models |
| list of strings | Optional | default variable insertions based on variable type |
Secondary variable mappings for nested models |
| list of strings | Optional | primary mappings into sub-model variables are value-based |
Primary response mappings for nested models |
| list of reals | Optional | no sub-iterator contribution to primary functions |
Secondary response mappings for nested models |
| list of reals | Optional | no sub-iterator contribution to secondary functions |
1.6.1