Analysis driver blocking mode flag

[brownp2k]

After Dakota spawns the specified analysis_driver, it will either block (wait) for it to exit and then read the result file, or it will not block and simply read the result file as soon as it is detected.

For custom analysis drivers, it would be great if Dakota would pass the blocking mode as a parameter, which would allow the analysis driver to know whether it needs to stay alive or not. As it stands, due to how Dakota functions internally, the only way to ensure correct behavior is for the analysis driver to operate in "blocking" mode.

[brownp2k]

I should clarify that this pertains to running analysis_drivers via "system" since in that mode Dakota is not monitoring the analysis_driver process, and thus it can be allowed to exit, and the results file will be written by some other program. In high evaluation_concurrency configurations, this can eliminate the need for a lot of processes on the system.

[jadamstephens]

That's an interesting idea. We usually think of the need to check for the results file as a limitation of the system interface, not a feature. Another idea along similar lines might be a keyword for the fork interface that tells Dakota to use system interface behavior (poll for the existence of the results file instead of expecting to find it when the driver exits).

[brownp2k]

A keyword to specify file-watching vs process-watching would be amazing. We've already discussed internally what it would take to create a direct driver that does this, but we certainly aren't keen on maintaining multiple custom Dakota builds across various platforms.