Blurb::
Determine how Dakota responds to analysis driver failure
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:

- :dakkw:`interface-failure_capture-abort` (the default)
- :dakkw:`interface-failure_capture-retry`
- :dakkw:`interface-failure_capture-recover`
- :dakkw:`interface-failure_capture-continuation`

Refer to :ref:`failure` for additional information.
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.

Examples::

Theory::

Faq::

See_Also::
