fork

Launch analysis drivers using fork command

Specification

• Alias: None

• Arguments: None

Child Keywords:

Required/Optional	Description of Group	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.

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, refer to Simulation Interfaces.

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