Running Dakota

The Dakota executable file is named dakota (dakota.exe on Windows) and is most commonly run from a terminal or command prompt.

Usage

If the dakota command is entered at the command prompt without any arguments, a usage message similar to the following appears:

usage: dakota [options and <args>]
    -help (Print this summary)
    -version (Print DAKOTA version number)
    -input <$val> (REQUIRED DAKOTA input file $val)
    -preproc [$val] (Pre-process input file with pyprepro or tool $val)
    -output <$val> (Redirect DAKOTA standard output to file $val)
    -error <$val> (Redirect DAKOTA standard error to file $val)
    -parser <$val> (Parsing technology: nidr[strict][:dumpfile])
    -no_input_echo (Do not echo DAKOTA input file)
    -check (Perform input checks)
    -pre_run [$val] (Perform pre-run (variables generation) phase)
    -run [$val] (Perform run (model evaluation) phase)
    -post_run [$val] (Perform post-run (final results) phase)
    -read_restart [$val] (Read an existing DAKOTA restart file $val)
    -stop_restart <$val> (Stop restart file processing at evaluation $val)
    -write_restart [$val] (Write a new DAKOTA restart file $val)

Of these command line options, only input is required, and the -input switch can be omitted if the input file name is the final item appearing on the command line (see Examples); all other command-line inputs are optional.

• help prints the usage message above.

• version prints version information for the executable.

• check invokes a dry-run mode in which the input file is processed and checked for errors, but the study is not performed.

• input provides the name of the Dakota input file, which can optionally be pre-processed as a template using the preproc option.

• output and error options provide file names for redirection of the Dakota standard output (stdout) and standard error (stderr), respectively.

• The parser option is for debugging and will not be further described here.

• By default, Dakota will echo the input file to the output stream, but no_input_echo can override this behavior.

• read_restart and write_restart commands provide the names of restart databases to read from and write to, respectively.

• stop_restart command limits the number of function evaluations read from the restart database (the default is all the evaluations) for those cases in which some evaluations were erroneous or corrupted. Restart management is an important technique for retaining data from expensive engineering applications.

• -pre_run, -run, and -post_run instruct Dakota to run one or more execution phases, excluding others. The commands must be followed by filenames as described in Execution Phases.

Command line switches can be abbreviated so long as the abbreviation is unique, so the following are valid, unambiguous specifications: -h, -v, -c, -i, -o, -e, -s, -w, -re, -ru, and -po and can be used in place of the longer forms of the command line options.

For information on restarting Dakota, see Restarting Dakota Studies and The Dakota Restart Utility.

Examples

To run Dakota with a particular input file, the following syntax can be used:

    dakota -i dakota.in

or more simply

    dakota dakota.in

This will echo the standard output (stdout) and standard error (stderr) messages to the terminal. To redirect stdout and stderr to separate files, the -o and -e command line options may be used:

    dakota -i dakota.in -o dakota.out -e dakota.err

or

    dakota -o dakota.out -e dakota.err dakota.in

Alternatively, any of a variety of Unix redirection variants can be used. Refer to[5] for more information on Unix redirection. The simplest of these redirects stdout to another file:

    dakota dakota.in > dakota.out

The specified Dakota input file may instead be an dprepro/aprepro-style template file to be pre-processed prior to running Dakota. For example it might contain template expressions in curly braces:

# {MyLB = 2.0} {MyUB = 8.6}
variables
  uniform_uncertain 3
    upper_bounds {MyUB} {MyUB} {MyUB}
    lower_bounds {MyLB} {MyLB} {MyLB}

(See the Interfaces chapter in the Dakota User's ManualUserMan for more information and use cases.) To pre-process the input file, specify the preproc flag which generates an intermediate temporary input file for use in Dakota. If Dakota's pyprepro.py utility is not available on the execution PATH and/or additional pre-processing options are needed, the tool location and syntax can be specified, for example:

# Assumes pyprepro.py is on PATH:
dakota -i dakota_rosen.tmpl -preproc

# Specify path/name of pre-processor:
dakota -i dakota_rosen.tmpl \
  -preproc "/home/user/dakota/bin/pyprepro"

# Specify Python interpreter to use, for example on Windows
dakota -i dakota_rosen.tmpl -preproc "C:/python27/python.exe \
  C:/dakota/6.10/bin/pyprepro/pyprepro.py"

# Specify additional options to pyprepro, e.g., include file:
dakota -i dakota_rosen.tmpl -preproc "pyprepro.py -I default.params"

Execution Phases

Dakota has three execution phases: pre-run, run, and post-run.

• pre-run can be used to generate variable sets
• run (core run) invokes the simulation to evaluate variables, producing responses
• post-run accepts variable/response sets and analyzes the results (for example, calculate correlations from a set of samples). Currently only two modes are supported and only for sampling, parameter study, and DACE methods:

(1) pre-run only with optional tabular output of variables:

    dakota -i dakota.in -pre_run [::myvariables.dat]

(2) post-run only with required tabular input of variables/responses:

    dakota -i dakota.in -post_run myvarsresponses.dat::