The syntax of DAKOTA specification is governed by the New Input Deck Reader (NIDR) parsing system [Gay, 2008], which uses the dakota.input.nspec file to describe the allowable inputs to the system. A shortened form of this input specification file, dakota.input.summary, provides a quick reference to the allowable system inputs from which a particular input file (e.g., dakota.in) can be derived. This automatically derived shortened form omits implementation details not needed in a quick reference.
This Reference Manual focuses on providing complete details for the allowable specifications in an input file to the DAKOTA program. Related details on the name and location of the DAKOTA program, command line inputs, and execution syntax are provided in the Users Manual [Adams et al., 2010].
Refer to the dakota.input.summary file for current input specifications. From this file listing, it can be seen that the main structure of the strategy specification is that of several required group specifications separated by logical OR's: either hybrid OR multi-start OR pareto set OR single method. The method keyword is the most lengthy specification; however, its structure is again relatively simple. The structure is that of a set of optional method-independent settings followed by a long list of possible methods appearing as required group specifications (containing a variety of method-dependent settings) separated by OR's. The model keyword reflects a structure of three required group specifications separated by OR's. Within the surrogate model type, the type of approximation must be specified with either a global OR multipoint OR local OR hierarchical required group specification. The structure of the variables keyword is that of optional group specifications for continuous and discrete design variables, a number of different uncertain variable distribution types, and continuous and discrete state variables. Each of these specifications can either appear or not appear as a group. Next, the interface keyword allows the specification of either algebraic mappings, simulation-based analysis driver mappings, or both. Within the analysis drivers specification, a system OR fork OR direct OR grid group specification must be selected. Finally, within the responses keyword, the primary structure is the required specification of the function set (either optimization functions OR least squares functions OR generic response functions), followed by the required specification of the gradients (either none OR numerical OR analytic OR mixed) and the required specification of the Hessians (either none OR numerical OR quasi OR analytic OR mixed). Refer to Strategy Commands, Method Commands, Model Commands, Variables Commands, Interface Commands, and Responses Commands for detailed information on the keywords and their various optional and required specifications. And for additional details on NIDR specification logic and rules, refer to [Gay, 2008].
Some keywords, such as those providing bounds on variables, have an associated list of values. When the same value should be repeated several times in a row, you can use a notation of the form n*value instead of repeating the value n times. For example, in Sample 2: Least Squares below,
lower_bounds -2.0 -2.0
upper_bounds 2.0 2.0
lower_bounds 2*-2.0
upper_bounds 2 * 2.0
* ). Another possible abbreviation is for sequences: L:S:U (with optional spaces around the : ) is expanded to L L+S L+2*S ... U, and L:U (with no second colon) is treated as L:1:U. For example, in one of the test examples distributed with DAKOTA (test case 2 of test/dakota_uq_textbook_sop_lhs.in ), histogram_point = 2
abscissas = 50. 60. 70. 80. 90.
30. 40. 50. 60. 70.
counts = 10 20 30 20 10
10 20 30 20 10
histogram_point = 2
abscissas = 50 : 10 : 90
30 : 10 : 70
counts = 10:10:30 20 10
10:10:30 20 10
# Comment about the following "responses" keyword...
responses,
num_objective_functions = 1
# Comment within keyword "responses"
analytic_gradients
# Another comment within keyword "responses"
no_hessians
# Comment about the following "responses" keyword...
responses, \
num_objective_functions = 1 \
# Comment within keyword "responses" \
analytic_gradients \
# Another comment within keyword "responses" \
no_hessians
Dakota/examples/tutorial/dakota_textbook.in.
strategy,
single_method
method,
# DOT performs better, but may not be available
dot_mmfd,
# conmin_mfd,
max_iterations = 50,
convergence_tolerance = 1e-4
variables,
continuous_design = 2
initial_point 0.9 1.1
upper_bounds 5.8 2.9
lower_bounds 0.5 -2.9
descriptors 'x1' 'x2'
interface,
direct
analysis_driver = 'text_book'
responses,
num_objective_functions = 1
num_nonlinear_inequality_constraints = 2
numerical_gradients
method_source dakota
interval_type central
fd_gradient_step_size = 1.e-4
no_hessians
Dakota/examples/tutorial/dakota_rosenbrock_ls.in.
strategy,
single_method
method,
nl2sol
max_iterations = 50
convergence_tolerance = 1e-4
model,
single
variables,
continuous_design = 2
initial_point -1.2 1.0
lower_bounds -2.0 -2.0
upper_bounds 2.0 2.0
descriptor 'x1' 'x2'
interface,
system
analysis_driver = 'rosenbrock'
responses,
num_least_squares_terms = 2
analytic_gradients
no_hessians
Dakota/test/dakota_uq_textbook_lhs.in.
strategy,
single_method
method,
nond_sampling,
samples = 100 seed = 1
complementary distribution
response_levels = 3.6e+11 4.0e+11 4.4e+11
6.0e+04 6.5e+04 7.0e+04
3.5e+05 4.0e+05 4.5e+05
sample_type lhs
variables,
normal_uncertain = 2
means = 248.89, 593.33
std_deviations = 12.4, 29.7
descriptors = 'TF1n' 'TF2n'
uniform_uncertain = 2
lower_bounds = 199.3, 474.63
upper_bounds = 298.5, 712.
descriptors = 'TF1u' 'TF2u'
weibull_uncertain = 2
alphas = 12., 30.
betas = 250., 590.
descriptors = 'TF1w' 'TF2w'
histogram_bin_uncertain = 2
num_pairs = 3 4
abscissas = 5 8 10 .1 .2 .3 .4
counts = 17 21 0 12 24 12 0
descriptors = 'TF1h' 'TF2h'
histogram_point_uncertain = 1
num_pairs = 2
abscissas = 3 4
counts = 1 1
descriptors = 'TF3h'
interface,
system asynch evaluation_concurrency = 5
analysis_driver = 'text_book'
responses,
num_response_functions = 3
no_gradients
no_hessians
single_method and single, respectively). A similar file is available in the test directory as Dakota/examples/tutorial/dakota_rosenbrock_vector.in.
strategy,
single_method
method,
vector_parameter_study
final_point = 1.1 1.3
num_steps = 10
model,
single
variables,
continuous_design = 2
initial_point -0.3 0.2
descriptors 'x1' "x2"
interface,
direct
analysis_driver = 'rosenbrock'
responses,
num_objective_functions = 1
no_gradients
no_hessians
Dakota/test/dakota_hybrid.in.
strategy,
graphics
hybrid sequential
method_list = 'GA' 'PS' 'NLP'
method,
id_method = 'GA'
model_pointer = 'M1'
coliny_ea
seed = 1234
population_size = 10
verbose output
method,
id_method = 'PS'
model_pointer = 'M1'
coliny_pattern_search stochastic
seed = 1234
initial_delta = 0.1
threshold_delta = 1.e-4
solution_accuracy = 1.e-10
exploratory_moves basic_pattern
verbose output
method,
id_method = 'PS2'
model_pointer = 'M1'
max_function_evaluations = 10
coliny_pattern_search stochastic
seed = 1234
initial_delta = 0.1
threshold_delta = 1.e-4
solution_accuracy = 1.e-10
exploratory_moves basic_pattern
verbose output
method,
id_method = 'NLP'
model_pointer = 'M2'
optpp_newton
gradient_tolerance = 1.e-12
convergence_tolerance = 1.e-15
verbose output
model,
id_model = 'M1'
single
variables_pointer = 'V1'
interface_pointer = 'I1'
responses_pointer = 'R1'
model,
id_model = 'M2'
single
variables_pointer = 'V1'
interface_pointer = 'I1'
responses_pointer = 'R2'
variables,
id_variables = 'V1'
continuous_design = 2
initial_point 0.6 0.7
upper_bounds 5.8 2.9
lower_bounds 0.5 -2.9
descriptors 'x1' 'x2'
interface,
id_interface = 'I1'
direct
analysis_driver= 'text_book'
responses,
id_responses = 'R1'
num_objective_functions = 1
no_gradients
no_hessians
responses,
id_responses = 'R2'
num_objective_functions = 1
analytic_gradients
analytic_hessians
Additional example input files, as well as the corresponding output and graphics, are provided in the Getting Started chapter of the Users Manual [Adams et al., 2010].
It can be difficult to capture in a simple tabular format the complex relationships that can occur when specifications are nested within multiple groupings. For example, in the model keyword, the actual_model_pointer specification is a required specification within the multipoint and local required group specifications, which are separated from each other and from other required group specifications (global and hierarchical) by logical OR's. The selection between the global, multipoint, local, or hierarchical required groups is contained within another required group specification (surrogate), which is separated from the single and nested required group specifications by logical OR's. Rather than unnecessarily proliferate the number of tables in attempting to capture all of these inter-relationships, a balance is sought, since some inter-relationships are more easily discussed in the associated text. The general structure of the following sections is to present the outermost specification groups first (e.g., single, surrogate, or nested in Table 6.1), followed by lower levels of group specifications (e.g., global, multipoint, local, or hierarchical surrogates in Table 6.3), followed by the components of each group (e.g., Tables 6.4 through 6.8) in succession.
1.4.7