Dakota Reference Manual: Running Dakota

| Dakota Reference Manual Version 6.15 Explore and Predict with Confidence

- Main Page
- Related Pages

All Pages
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::