1Blurb:: 2Perform each function evaluation in a separate working directory 3 4Description:: 5When performing concurrent evaluations, it is typically necessary to 6cloister simulation input and output files in separate directories to 7avoid conflicts. When the \c work_directory feature is enabled, 8Dakota will create a directory for each evaluation, with optional 9tagging (\c directory_tag) and saving (\c directory_save ), as with 10files, and execute the analysis driver from that working directory. 11 12The directory may be \c named with a string, or left anonymous to use 13an automatically-generated directory in the system's temporary file 14space, e.g., /tmp/dakota_work_c93vb71z/. The optional \c link_files 15and \c copy_files keywords specify files or directories which should 16appear in each working directory. 17 18When using work_directory, the \ref interface-analysis_drivers may be 19given by an absolute path, located in (or relative to) the startup 20directory alongside the Dakota input file, in the list of template 21files linked or copied, or on the $PATH (%Path% on Windows). 22 23Topics:: 24Examples:: 25Theory:: 26Faq:: 27See_Also:: 28