Dakota Input File (
Dakota inputs are grouped into five sections: environment, method, model, variables, interface and responses.
The general rule is to use keywords followed by values.
The alignment of keywords and values are not important.
They can share the same line or use multiple lines.
Indentations are not required and used in this example only for clarity and showing the hierarchical relation of keywords.
The equal sign
= is also optional.
Comments are specified by the character
For more details on the input syntax and keywords, please check the Dakota user manual and reference manual.
This section starts with the keyword
This section configurs some general settings such as the names of various output files.
output_file specifies the main output of the optimization.
This file is given the name
output_file = 'cs_tm_opt_soga.out'
write_restart specifies the file that is used to restart the optimization if it stops at some point for some reason.
This file is given the name
write_restart = 'cs_tm_opt_soga.rst'
error_file specifies the file that stores the error messages if Dakota stops with some exceptions.
This file is given the name
error_file = 'cs_tm_opt_soga.err'
tabular_data specifies a file that writes tabular results of variable and response history.
This file is given the name
tabular_data tabular_data_file = 'cs_tm_opt_soga_tabular.dat'
This section is specified by the keyword
method and configures the optimization method.
As stated earlier, this example will use Genetic Algorithm.
For this single objective optimization problem, the specific method is SOGA (Single Objective Genetic Algorithm) and the corresponding keyword is
The number of individual designs in a single generation is specified by the keyword
population_size, which is set to 50:
population_size = 50
The stopping condition of the optimization contains two aspects. One is the convergence checking and the other is the maximum number of functional evaluations. The settings are:
max_function_evaluations = 2000 convergence_type average_fitness_tracker percent_change = 0.1 num_generations = 10
To control the randomness in the algorithm, a randomness seed is specified using the keyword
seed = 1027
The following two settings can be used to provide more information of the optimization process.
print_each_pop ask Dakota to write tabular data (variables and responses) into a file after each generation.
The output file will be
i is the generation number.
log_file specifies the name for the file storing logging messages generated by SOGA.
The inputs are:
print_each_pop log_file = 'cs_tm_opt_soga.log'
For other settings that are not mentioned here, readers can go to the Dakota reference manual for their detailed usage and default values.
model section configures how variables are mapped into responses.
This example uses the default and simplest model:
single, where variables are mapped to responses through the process specified in
This section specifies variables in this optimization problem, using the keyword
Following the terminology of Dakota, variables in this example can be grouped into two types, design variables and state variables.
Design variables are those that will be changed in each iteration, while state variables are those that will be fixed in an optimization study.
As stated in Section: Optimization Formulation, there are two continuous design variables in this example. The corresponding inputs are:
continuous_design = 2 descriptors = 'wl_x2' 'wt_x2' upper_bounds = -0.10 -0.30 lower_bounds = -0.20 -0.50
All other parameters mentioned in Section: Cross-sectional Parameterization and Beam Properties are treated as state variables.
discrete_state_set is used to specify their fixed values.
There are eight real-type state variables:
real = 8 descriptors = 'mesh_size' 'mesh_size_fill' 'pnsmc_x3' 'pfte2_x2' 'pnsmc_x2' 'nsmr' 'chord' 'oa2' elements = 0.04 0.3 0 -0.9 -0.046 0.0094 20.76 -0.25
There are 15 integer-type state variables:
integer = 15 descriptors = 'mi_spar_1' 'mi_le' 'mi_te' 'np_spar_1' 'np_le' 'np_te' 'np_spar_2' 'np_spar_3' 'np_spar_4' 'fo_spar_1' 'fo_le' 'fo_te' 'fo_spar_2' 'fo_spar_3' 'fo_spar_4' elements = 4 1 4 16 16 13 16 14 19 50 -36 71 -9 53 -44
This section specifies how Dakota should run and change data with the analysis.
The keyword is
The command used to call the analysis is specified by the keyword
Since the analysis is coded in a Python script and data (inputs/outputs) are transferred through files, the
fork type is used for this analysis driver:
analysis_driver = 'python3 interface.py interface_args.json uh60a_section' fork
The names of the parameters file (written by Dakota) and the results file (read by Dakota) are specified as:
parameters_file = 'input.in' results_file = 'output.out'
Hence, the actual shell command called by Dakota will be
python3 interface.py interface_args.json uh60a_section input.in output.out
All files generated by the analysis can be saved by using the keyword
If the storage is limited, then all files can be deleted after each successful evaluation by commenting out this keyword.
To use the concurrent computing technique provided by Dakota, each individual analysis must be carried out in an isolated working directory.
In this example, each analysis is done in a folder named
i is the
directory_tag, which is also the evaluation number.
directory_save is also optional.
This is specified as:
work_directory named = 'evals/eval' directory_tag directory_save
To make the analysis driver work, the final step is to specify all files needed by the analysis driver, using the keyword
link_file (Linux) or
link_file = 'interface.py' 'interface_args.json' 'data_proc_funcs.py' 'design/*'
In this example, the following six files are needed:
design/uh60a_section.xml.tmp(see Section: Cross-section Main Input Template (uh60a_section.xml.tmp))
design/material_database.xml(see Section: Material Database (material_database.xml))
design/sc1095.dat(see Section: Cross-section Airfoil Data (sc1095.dat))
interface.py(see Section: Dakota Interface Scripts (interface.py))
interface_args.json(see Section: Interface Arguments (interface_args.json))
data_proc_funcs.py(see Section: Data Processing Functions (data_proc_funcs.py))
Finally, this example runs 20 concurrent analyses each time. This is specified as:
asynchronous evaluation_concurrency = 20
This section specifies the responses sent pack to Dakota from the analysis driver, including objectives and constraints. Based on the optimization formulation in Section: Optimization Formulation, Dakota will read two responses from the result file, one objective and one constraint:
responses descriptors = 'diff' 'mpl'
The objective is to minimize the difference between the calculated and target beam properties:
objective_functions = 1 sense = 'min'
The constraint is keep the calculated mass less than the target value:
nonlinear_inequality_constraints = 1 upper_bounds = 0.00149 lower_bounds = 0
Since the optimization method is Genetic Algorithm, there is no gradient and hessian results returned to Dakota.
# ==================================================================== environment output_file = 'cs_tm_opt_soga.out' write_restart = 'cs_tm_opt_soga.rst' error_file = 'cs_tm_opt_soga.err' tabular_data tabular_data_file = 'cs_tm_opt_soga_tabular.dat' # ==================================================================== method soga max_function_evaluations = 2000 population_size = 50 seed = 1027 convergence_type average_fitness_tracker # default percent_change = 0.1 # defualt: 0.1 num_generations = 10 # default: 10 print_each_pop log_file = 'cs_tm_opt_soga.log' # ==================================================================== model single # ==================================================================== variables active design continuous_design = 2 descriptors = 'wl_x2' 'wt_x2' upper_bounds = -0.10 -0.30 lower_bounds = -0.20 -0.50 discrete_state_set real = 8 descriptors = 'mesh_size' 'mesh_size_fill' 'pnsmc_x3' 'pfte2_x2' 'pnsmc_x2' 'nsmr' 'chord' 'oa2' elements = 0.04 0.3 0 -0.9 -0.046 0.0094 20.76 -0.25 integer = 15 descriptors = 'mi_spar_1' 'mi_le' 'mi_te' 'np_spar_1' 'np_le' 'np_te' 'np_spar_2' 'np_spar_3' 'np_spar_4' 'fo_spar_1' 'fo_le' 'fo_te' 'fo_spar_2' 'fo_spar_3' 'fo_spar_4' elements = 4 1 4 16 16 13 16 14 19 50 -36 71 -9 53 -44 # ==================================================================== interface analysis_driver = 'python3 interface.py interface_args.json' fork parameters_file = 'input.in' results_file = 'output.out' file_save work_directory named = 'evals/eval' directory_tag directory_save link_file = 'interface.py' 'interface_args.json' 'data_proc_funcs.py' 'design/*' asynchronous evaluation_concurrency = 20 # ==================================================================== responses descriptors = 'diff' 'mpl' objective_functions = 1 sense = 'min' nonlinear_inequality_constraints = 1 upper_bounds = 0.00149 lower_bounds = 0 no_gradients no_hessians