Table of Contents
Introduction
One of the most popular use cases for Dakota is to drive and analyze an external black-box simulation model. In other words, we have a black-box simulation model that we're interested in studying. This black-box simulation model could be a binary executable file, or a scripted simulation analysis workflow. We need to figure out how to connect Dakota to that simulation model, so we can study it.
Dakota "talks to" these black-box simulation models via an exchange of parameters and responses. Dakota specifies the parameter values that go into your simulation model, and receives the corresponding responses that come out of your simulation model. As such, you should think about how to define your simulation model in terms of parameters and responses.
Note on Terminology: Throughout this section (and the rest of the Dakota GUI manual), the terms "parameter", "variable", and "input" are used interchangeably based on the most appropriate word for the context, but they all mean the same thing. Likewise, "response", "output", and "QOI" (quantity of interest) will also be used interchangeably based on context.
Dakota uses analysis drivers to handle the transfer of parameter and response information between itself and the external simulation model. Analysis drivers can be thought of as the “glue” between Dakota and the simulation model.
An analysis driver could be:
- A script file that was manually authored by an analyst.
- A script file that was automatically generated by the Dakota GUI, based on knowledge about the black-box simulation model.
- A workflow file created in Next-Gen Workflow, with inputs and outputs that mirror the inputs and outputs of the simulation model.
The analysis driver understands how to:
- Translate from Dakota variables to simulation model variables.
- Translate from simulation model responses back to Dakota responses.
The process by which Dakota uses an analysis driver to communicate with a simulation model is demonstrated in the following flowchart:
On each iteration of a Dakota run…
- Dakota specifies new variable values, based on your chosen model and method.
- Dakota writes the new variable values to a parameters file.
- The analysis driver is called with two arguments – the Dakota parameters file, and the destination results file, where data will eventually be written out.
- The interface driver is responsible for preparing input to the simulation model. This step is referred to as pre-processing.
- The simulation model is executed with the pre-processed input data.
- After the simulation model has finished running, the analysis driver is responsible for extracting quantities of interest from the simulation model's output (usually from console output, or from a log file) and preparing it for Dakota. This step is referred to as post-processing.
- The analysis driver must write the response values (i.e. quantities of interest) from the simulation model to Dakota’s destination result file.
- Finally, Dakota collects the response values from the results file, and moves on to the next iteration, which starts this sequence over again.
Parameter File and Response File Format
Dakota uses a very specific format for the parameter files handed to the simulation model, and for the response files it expects to receive back from the simulation model.
Recommended Reading
- Basic Model Format (BMF) files allow you to formally define your simulation model's input parameters and output responses.
- You can use the Next-Gen Workflow tool to create a node-based workflow that will act as a Dakota analysis driver.
- You can use the Script-Based Dakota Driver wizard to auto-generate a Python script that will act as a Dakota analysis driver.
- You can import existing script files and "define" them as analysis drivers by creating interface manifest files.
- If your external simulation model receives a text-based input file, you can use the "Markup File" context menu tool to markup a text file with pre-processing syntax.