|CCP4i: Graphical User Interface|
|Running a Job|
Running Jobs Remotely/Later/In Batch
How Jobs are Run
Jobs can be run from the Run menubutton at the bottom of task interfaces or from the ReRun Job interface. There are three modes of running a job:
Selecting this mode will bring up a window with a menu option to select whether to run the job remotely, or later, or submit to batch. Not all of these options will necessarily appear - it depends on your local setup which is defined in the file $CCP4I_top/etc/resources.def and can be edited using the Configure Interface option at the bottom of the menu on the right hand side of the Main Window.
The job is run remotely using the rsh command - this will only work for Unix machines on the same network which can see the same file system.
Delayed jobs are run using the at command and the time input should be in a format suitable for at. A subset of suitable formats is:
The status of the job reported in the Job List will be:
Note that the usual mechanism by which jobs report their status to the main Interface, does not work across machines. To overcome this, the Interface will periodically check on the contents of the log file and if the usual termination statement is not present, it will assume the task is still runnning. This means there may be a short delay (less than a minute) before the termination is reported. Another possibility to consider if a job appears to have taken a very long time is that the script running on the remote machine has failed but the termination may not be written to the log.
The View Files from Job option to View Log File will list a log file being generated on a remote machine.
You do NOT NEED to know what follows but you may be interested or it may help in figuring out any problems.
A run script called (job_number)_(task_name).def (e.g. 32_refmac.def) is created in the CCP4_DATABASE subdirectory of the current project directory. This file begins with a header section (lines beginning with #CCP4I) which lists information about the job, e.g. the job ID, the taskname, the server to be used, etc. The header is then followed by a list of the parameters taken from the task interface.
The .def file for the job is run by the script set by $configure(RUN_CCP4I), which defaults to bin/ccp4i.tcl. The taskname is taken from the identifier in the header of the .def file so that the script can source the appropriate taskname.script file.
The script is run as an independent process - it uses sockets to send updates on progress back to the main interface. The progress is recorded in the status column in the Job List.
As the task runs, the output is listed to a log file (project_name)_(job_number)_(task_name).log. The output from all the programs run will be concatenated into this file. For some tasks there may also be some extra output from the run script.
The run file could potentially be run external to the Interface with the command:
ccp4ish -r (job_number)_(task_name).defNote that ccp4ish is ccp4i without the graphics.
To run each individual CCP4 program, the script creates a temporary file which contains the command input. This is put in a file rather than simply streamed to the program, because of limitations running on VMS. If you are running the Run&View Com File mode, the script will pause here to display the com file and the run command line. You can edit either of these before continuing.
To run the job on a remote machine or in batch, the Interface creates a short .com file in the TEMPORARY directory. This will have the name of the run script with an extra extension .com. The com file contains the following:
setup_ccp4 /y/programs/ccp4i/bin/ccp4ish -r 163_scala.def
The first line is the command to setup CCP4 and the second line is the full path name of the CCP4i program and the name of the run file. This com file will not work if the path name for either the CCP4i directory or the TEMPORARY directory are different on the remote machine.