Launch analysis drivers using fork command

Specification

Alias: none

Argument(s): none

Child Keywords:

Required/Optional	Dakota Keyword	Dakota Keyword Description
Optional	parameters_file	Specify the name of the parameters file
Optional	results_file	Specify the name of the results file
Optional	file_tag	Tag each parameters & results file name with the function evaluation number
Optional	file_save	Keep the parameters & results files after the analysis driver completes
Optional	labeled	Requires correct function value labels in results file
Optional	aprepro	Write parameters files in APREPRO syntax
Optional	work_directory	Perform each function evaluation in a separate working directory
Optional	allow_existing_results	Change how Dakota deals with existing results files
Optional	verbatim	Specify the command Dakota uses to launch analysis driver(s) and filters

Description

The fork interface is the most common means by which Dakota launches a separate application analysis process.

The fork interface is recommended over system for most analysis drivers that are external to Dakota, i.e., any driver not linked in via the direct interface.

As explained in the Users Manual, the parameters and results file names are passed on the command line to the analysis driver(s). If input/output filters are specified, they will be run before/after the analysis drivers. The verbatim keyword is used to modify the default driver/filter commands.

For additional information on invocation syntax, see the Interfaces chapter of the Users Manual[5].

Examples

Spawn (fork) an external executable/script called 'rosenbrock' which reads variables from params.in and writes responses to results.out. Preserve the analysis files for each function evaluation with tag and save.

interface
  analysis_drivers = 'rosenbrock'
    fork
      parameters_file = 'params.in'
      results_file   = 'results.out'
      file_tag
      file_save