failure_capture

Determine how Dakota responds to analysis driver failure

Topics

Default Behavior: If no failure capturing specification is provided, then the default behavior is method dependent. For those iterative algorithms that provide internal failure mitigation strategies (currently NL2SOL), the default is to transfer the failure information from the interface back to the algorithm for mitigation, with no specific action taken by Dakota. For all other algorithms, the default is to abort.

Specification

  • Alias: None

  • Arguments: None

  • Default: abort

Child Keywords:

Required/Optional

Description of Group

Dakota Keyword

Dakota Keyword Description

Required (Choose One)

Failure Mitigation

abort

(Default) Abort the Dakota job

retry

Rerun failed analyses

recover

Substitute dummy values for the responses

continuation

Cause Dakota to step toward the failed “target” simulation from a nearby successful “source”

Description

Dakota can deal with analysis failure in a few ways.

The first step is that Dakota must detect analysis failure. Importantly, Dakota always expects a results file to be written by the analysis driver, even when a failure has occurred. If the file does not exist when the analysis driver exits, a Dakota error results, causing Dakota itself to terminate. The analysis driver communicates an analysis failure to Dakota by writing a results file beginning with the (case-insensitive) word “fail”. Any file contents after “fail” are ignored.

Once Dakota detects analysis failure, the failure can be mitigated in four ways:

Refer to Simulation Failure Capturing for additional information.