![]() |
Dakota Reference Manual
Version 6.15
Explore and Predict with Confidence
|
Dakota input is specified in a text file, e.g., dakota_uq.in
containing blocks of keywords that control program behavior. This section describes the format and admissible elements of an input file.
Valid Dakota input keywords are dictated by dakota.xml
, included in source and binary distributions of Dakota. This specification file is used with the NIDR[29] parser to validate user input and is therefore the definitive source for input syntax, capability options, and optional and required capability sub-parameters for any given Dakota version. A more readable variant of the specification dakota.input.summary
is also distributed.
While complete, users may find dakota.input.summary
overwhelming or confusing and will likely derive more benefit from adapting example input files to a particular problem. Some examples can be found here: Sample Input Files. Advanced users can master the many input specification possibilities by understanding the structure of the input specification file.
Refer to the dakota.input.summary file, in Input Spec Summary, for all current valid input keywords.
ARGUMENTS
(always required) Additional notes about ARGUMENTS
can be found here: Specifying Arguments.ALIAS
, or synonymSpelling mistakes and omission of required parameters are the most common errors. Some causes of errors are more obscure:
dakota.input.summary
used in building the executable, which is installed alongside the executable, will often resolve the errors.# Comment about the following "responses" keyword... responses, objective_functions = 1 # Comment within keyword "responses" analytic_gradients # Another comment within keyword "responses" no_hessiansyou would need to write
# Comment about the following "responses" keyword... responses, \ objective_functions = 1 \ # Comment within keyword "responses" \ analytic_gradients \ # Another comment within keyword "responses" \ no_hessianswith no white space (blanks or tabs) after the \ character.
In most cases, the Dakota parser provides error messages that help the user isolate errors in input files. Running dakota
-input
dakota_study.in
-check
will validate the input file without running the study.
Some keywords, such as those providing bounds on variables, have an associated list of values or strings, referred to as arguments.
When the same value should be repeated several times in a row, you can use the notation N*value
instead of repeating the value N times.
For example
lower_bounds -2.0 -2.0 -2.0 upper_bounds 2.0 2.0 2.0
could also be written
lower_bounds 3*-2.0 upper_bounds 3* 2.0
(with optional spaces around the *
).
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
could also be written
histogram_point = 2 abscissas = 50 : 10 : 90 30 : 10 : 70 counts = 10:10:30 20 10 10:10:30 20 10
Count and sequence abbreviations can be used together. For example
response_levels = 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
can be abbreviated
response_levels = 2*0.0:0.1:1.0