1Blurb:: 2Run a pre-processing script before the analysis drivers 3Description:: 4The 5optional \c input_filter and \c output_filter specifications provide 6the names of separate pre- and post-processing programs or scripts 7which assist in mapping %Dakota parameters files into analysis input 8files and mapping analysis output files into %Dakota results files, 9respectively. 10 11If there is only a single analysis driver, then it is 12usually most convenient to combine pre- and post-processing 13requirements into a single analysis driver script and omit the 14separate input and output filters. However, in the case of multiple 15analysis drivers, the input and output filters provide a convenient 16location for non-repeated pre- and post-processing requirements. That 17is, input and output filters are only executed once per function 18evaluation, regardless of the number of analysis drivers, which makes 19them convenient locations for data processing operations that are 20shared among the analysis drivers. 21 22The \ref interface-analysis_drivers-fork-verbatim keyword applies 23to input and output filters as well as analysis drivers, and Dakota 24also will substitute the names of the parameters and results files for the 25tokens `{PARAMETERS}` and `{RESULTS}` in input and output filer strings, 26as explained in the documentation for \ref interface-analysis_drivers. 27 28Topics:: 29Examples:: 30Theory:: 31Faq:: 32See_Also:: 33