When using an external program with CAESES/FFW, there is one major requirement to that program: Once the executable is finished, all result files need to exist. This is true no matter whether the external software is called directly as a local application or through the SshResourceManager as a remote application.

Why is that so?

CAESES/FFW needs to know when the external program is done writing its results, in order to be able to read in those results. So, what it does is to assume that once the executable that was called returns, all results are available.

What does that mean for the user?

In general the user can safely assume that a program's executable will not return until the actual process is finished. However, there are some exceptions to that rule. One example for such a behavior (although it is highly unlikely that it will be used from within CAESES/FFW) is Firefox. Only the first instance of Firefox will behave in the required way. When starting a second instance of Firefox, the process will return right away, as it uses the original Firefox process to run.

Another example that is a lot more likely to be used from within CAESES/FFW is when trying to execute an external program through a grid engine, for example the Oracle Grid Engine (formerly Sun Grid Engine). In general, submitting jobs (i.e. requests to run a certain program) to a grid engine through a program like qsub is a non-blocking process. The job is added to the waiting queue of the grid engine and the submitting program will return right away. Additional tools (e.g. qstat) can then be used to monitor the state of the job. However, when using qsub or a similar program as the executable in CAESES/FFW, it will be recognized that the executable has returned and assumed that all result files are present, which is not the case.

In the example of the Oracle Grid Engine there is a way to tell qsub that it should not return until the job has finished. That execution mode is done by providing the "sync y" option to qsub (either on the command line or in the configuration file). Note that the Sun Grid Engine must be configured to allow blocking jobs (i.e. must allow to use the "sync y" option).

How can I find out if my executable is affected?

Well, if one never experiences the problem that CAESES/FFW complains about result files not being there, although they are when you look in the file browser, or that a computation finished although you know that the external program is still running, you don't need to worry about it.

If, however, you do experience one of those two problems, or are planning to use a grid engine like the Oracle Grid Engine, you can do the following to ensure that the described problem does not affect you:

Run the program from a terminal (cmd.exe on Windows). If the terminal returns to the command prompt right away although the program continues to run, you have identified the problem. As the Firefox example shows, even if it does not return right away, you may have to double check by starting a second instance of the program through another terminal.

If the external program indeed shows this behavior and is this the problem why the integration does not work, one way to solve the problem, is to wrap the call to the executable in a shell script that stores the process ID of the started executable in a variable and periodically looks whether the PID still exists. Once it does not exist anymore, the shell script should exit. An alternative to a shell script would be to write a simple program using your favorite programming or scripting language.

If you have further questions, please consider to visit also:

Our company’s website

Our public CAESES Forum

Our company’s YOUTUBE channel