1    Introduction

THINK can be used in a distributed computing system where several PCs can perform THINK searches in the background or when they are idle, thereby making use of processing power that would otherwise go to waste. This can be particularly useful when:

In all cases, each individual THINK search is run as an independent calculation (it does not depend upon the results of other searches) and two or more searches can be run simultaneously on different PCs.

To use THINK in a distributed computing system requires one or more PCs connected to an intranet. These PCs are known as client PCs and will perform the actual searches. One PC on the intranet is nominated as the server PC. This PC is responsible for allocating the searches to the client PCs. The server PC can also function as a client, thereby using its own idle time to contribute to the project.

Although some knowledge of THINK and its command structure is required to create the command scripts and data files used to define the searches, no knowledge of the application is required to monitor the day by day operation of the server and clients.

1.1   Requirements

1.2   THINK Jobs

When used in a distributed computing system, THINK runs in client-server mode. This means that THINK automatically runs in the background or as a screen saver and takes all its instructions from a command script. Each THINK calculation run in this mode is known as a job.

Each THINK job requires the following files:

  1. a command script file containing the instructions to perform the search (eg read the query molecule, perform the search)

  2. a data file containing the query molecule for the search

  3. the data file of molecules to be scanned during the search

Although the data files (items 2 and 3 in the list) may be shared by two or more jobs, each job requires its own individual command script with a unique name. A sample script is listed below:

  CUSTOMIZE SINGLE=12 ALPHA=12
  LET #NTWUMX = 10
  OPEN FILE=1ir3-q2.pdb
  SEARCH MODE=SITE FILE=job2.smi QUERY=#1 OUTPUT=-h1.sdf CUTOFF=0.
  DELETE MOLECULE=*
  RETURN

The scripts that define the jobs are stored in a common folder on the server PC. The data files may be stored on the same PC or on a separate fileserver that can be accessed by all the client PCs. The files containing the search results (the results files) may also be stored on the server or on a separate fileserver. The job scripts must include the correct path (from the clients' point of view) to the data files.

The data files should not be copied onto each client: keeping them in a single shared folder has many advantages, particularly when several search queries need to be executed against a single file of molecules, or if the set of molecules being searched has been divided into a series of files. It also means that changes and corrections to the data files need only be made once, instead of being required on each client PC.

1.3   THINK Server

Each set of PCs that will be running THINK in client-server mode require one PC to be designated as the server PC which runs the THINK Job Queue Server application. This manages the server queue and controls the allocation of jobs to the client PCs.

One shared folder, or directory, on this PC is used to store the server queue file "server.dat" and the command scripts that define the jobs to be executed by the client PCs. This is known as the server folder. All communications between the server and the clients take place through this folder, so it is essential that all client PCs have write access to the folder (see the section on Requirements for software recommendations).

A second shared folder is used to store the log files generated by the server and the client PCs, known as the working folder. The server and all client PCs must have write access to this folder. If desired, this can be the same folder as the server folder.

The THINK Job Queue Server generates its own log file that records its progress. This is stored in the file "server.log" in the working folder.

The server folder may also be used to store the molecule files being searched and the results files generated by the clients. Alternatively, these files may be placed in a shared folder or directory on a fileserver that can be accessed by all the clients.

The THINK software may also be stored on the server PC or on a common fileserver.

1.3.1  Server Queue File

The server queue file is the key file for THINK when running in client-server mode. It is stored in the server folder on the server PC and contains information about all the jobs that have been scheduled, are currently executing or have been executed by the client PCs. The clients update the server queue file when they start or finish a job, and at regular intervals while executing a job. Therefore it is essential that all client PCs have write access to the server queue file.

1.4   THINK Clients

THINK may be run in one of two modes on each client PC:

Mode Operating
System
Description
Background Windows
Linux
THINK runs at a low priority and automatically gives way to any interactive application
Screen saver Windows THINK automatically runs when the PC has been idle for a set time interval (usually 1-15 minutes) and stops when the user moves the mouse or presses a key on the keyboard

When THINK is running as a screen saver, the molecule being processed will be displayed in 3D or the message "THINK is idling" will appear. If THINK is being run in the background under Windows, the user has the option of displaying a graphics window that shows the molecule being processed. The graphics window is not available under Linux in THINK v1.23.

When a client is ready for a job, it sends a request to the THINK Job Queue Server. The server application finds the next job that is waiting to be executed and passes it to the client. The server queue file is updated to indicate that the job is in progress. When the job is finished, the client updates the queue file to show that the job is complete and sends a request for another job. This continues until all the jobs in the queue file have been executed.

1.4.1  Files on the Client

The command script and data files associated with a job are not copied onto the client PC when the job is started; they are read directly from their original location. Therefore it is essential that they are available to the client at all times.

Each client PC uses the working folder to store its log file and any temporary files created while THINK is running. This is the shared folder that is also used by the server application to store its log file. The client must have write access to the working folder. See the section on configuring the server for details on how to define the working folder.

While a job is executing, THINK periodically writes a temporary file, known as a checkpoint file, to the working folder. This file contains information about the query being used, the file of molecules being searched, and the progress of the search to date. The name of the checkpoint file is derived from the name of the command script that defines the job: if the script is called "jobname.cms" then the checkpoint file will be called "jobname.dat". The checkpoint file is used to restart a search, for instance when the client PC is again idle and the THINK screen saver restarts.

2    Installing THINK for Use in Client-Server Mode

To install and configure THINK to run in client-server mode, the following operations need to be performed:

  1. Install the THINK software

  2. Configure the server PC:
    1. create the server folder (a shared folder)
    2. create the working folder (a shared folder)
    3. define the THINK environment

  3. Configure each client PC:
    1. check the client computer name
    2. create the screen saver files (only required if THINK is to be run as a screen-saver)

  4. Customise the master command script "screen.srt"

  5. Start the server and the clients

2.1   Install the THINK Software

The THINK software does not need to be installed on every client PC, but it must be installed on at least one PC or fileserver that is accessible from all clients.

When running in a mixed Linux and Windows configuration, the Linux version of THINK should be installed, and then the following files added from the Windows kit:

think.exe
server.exe
salflibc.dll
think.bmp

The Linux version of THINK uses lowercase letters for all file specifications (file paths, names and extensions). Therefore it is important that the Samba configuration (used to share files between the operating systems) does not result in files being created with uppercase letters in their names or paths.

2.2   Configure the Server

The folders or directories that will be used to store the server queue file, the job command scripts and the log files must be shared so the files can be accessed by all the client PCs. In order to maintain the queue file, each client PC must be able to write to the server folder. A client PC also needs to be able to write to the working folder so that its log file can be saved. It is recommended that a system administrator should take responsibility for ensuring only the required PCs have read and write access to the shared folders.

THINK uses three variables to determine its environment:

Variable Translation
THINK_EXEC absolute path to the folder containing the THINK software (this is only required if the client is being run as a screen saver)
THINK_SERVER absolute path to the shared server folder containing the server queue file and job command scripts
THINK_WORKDIR absolute path to the shared working folder containing the log files

These variables are defined through the environment file "think.env" that is stored in the same folder as the THINK software. Within the file each variable is defined in a separate record using the format variable=translation.

eg THINK_EXEC=\\server\think\software\
THINK_SERVER=\\server\think\data\
THINK_WORKDIR=\\server\think\work\

It is advisable to include the final "\" in each folder path.

2.3   Configure Each Client

Each client PC must have a different computer name (node name) on the intranet. This is used to identify the log file produced by the client PC, and therefore must be unique (since all client PCs write their log files into the same shared folder).

The computer name is normally assigned by the system manager, and set when the PC is first connected to the intranet. The tool used to check this name differs between operating systems, and between different versions. For instance, under Windows NT the name can be checked through the Network tool in the Control Panel. For Windows XP the name can be found through the Computer Name tab within the System tool in the Control Panel. Under Linux, the computer name can be found through the shell command "hostname". The computer name must not be changed without consulting the system manager for the intranet.

2.3.1  Windows Screen Saver

If THINK is to be used as a screen saver (Windows only), the following additional steps must be performed on each client PC:

  1. Copy the following files from the THINK software folder to the Windows folder (normally C:\Windows or C:\Winnt):

    think.exe
    salflibc.dll
    think.env

    The "think.env" file must define the THINK_EXEC variable (pointing to the folder containing the THINK software) for the screen saver to run successfully - see the section on configuring the server for more information on the "think.env" file.

  2. Change the name of "think.exe" in the Windows folder to "think.scr".

  3. Use the Display tool in the Control Panel to select THINK as the current screen saver and set the desired delay. The Preview button can be used to check that the screen saver starts correctly.

Note that changing the THINK options through the Settings button in the Display tool is not supported in THINK v1.23.

2.4   Customise "screen.srt"

When THINK starts in client-server mode, it automatically executes the file "screen.srt" in the software folder. This file contains the instructions for THINK to loop over command scripts read from the server folder. This file may contain any CUSTOMISE commands or other setup options which are common to all jobs, for instance setting IUDMOD (see below). See the THINK User Guide and Theory Manual for details on the commands used to modify the THINK settings.

By default, the value of IUDMOD is set to 513, which configures the screen to be updated every second to display the conformer of the molecule then being processed. Molecules that are processed in less than 1 second may never be displayed. A value of 514 is used to display only the starting conformer of each molecule. This is marginally more efficient but less interesting, and usually results in periods of graphical inactivity (although examining the server indicates that processing is continuing).

2.5   Starting the Server and Clients

This section describes the basic commands used to start the THINK Job Queue Server and the clients. A full list of commands is available in the sections describing controlling the server and controlling the client.

The exact method used to start the server and clients depends upon the operating system being used.

2.5.1  Windows

The server may be started by double-clicking on the "server.exe" file in the file explorer, or by issuing the following command from a "Command Prompt" or "cmd" window:

path\server /visible

where path is the path to the folder containing the THINK software. The environment file "think.env" file defining the THINK environment (see the section on configuring the server) must be created before the server is started.

If THINK is configured to run as a screen saver on a client PC (see the section on configuring the screen saver) it will be started automatically when the PC is idle. If THINK is to be run in the background on the client then the application must be started with the command:

path\think /v

As with Linux, if the PC contains multiple CPUs then a separate instance of THINK should be started on each CPU using the command:

path\think /v c

where c is 1 for the second CPU, 2 for the third, etc.

The server may be stopped using the Windows Task Manager or, if the server GUI is being used, by closing the GUI window. A client copy of THINK may be stopped by closing the graphics window.

2.5.2  Linux

The environment file "think.env" file defining the THINK environment (see the section on configuring the server) must be created before the server application is started.

Only one instance of the server should be started, using the command:

path/server -visible &

where path is the path to the folder containing the THINK software. The "&" at the end of the command indicates that the server should be run in the background. This instance of the server will assign jobs to the clients, but cannot be used to load new jobs into the queue. See the section on controlling the server using commands for more information on the commands available.

THINK can be started on each client PC using the command:

path/think -n 0 &

If the PC contains multiple CPUs then a separate instance of THINK should be started on each CPU using the command:

path/think -n c &

where c is 1 for the second CPU, 2 for the third, etc.

Both the THINK Job Queue Server and the client copies of THINK may be stopped using any of the normal system utilities for stopping processes (eg "kill"). Note that the clients will continue to execute their current jobs if the server has been stopped, but will be unable to download new jobs.

3    Controlling the Server

The THINK Job Queue Server may be controlled through commands or through the graphical interface (GUI). It is recommended that the GUI is used whenever possible. However, the GUI is not available under Linux in THINK v1.23, so a command interface has also been implemented for both Linux and Windows.

3.1   Graphical Interface (GUI)

In THINK v1.23, the graphical interface to the server is only available under Windows. It is automatically invoked when the server is started with the command:

server /visible

The GUI displays a list of jobs in the server queue, sorted by date with the jobs most recently added to the queue appearing at the top of the list. It is used to manage the jobs in the queue and to monitor their progress.

The following information is displayed for each job in the queue:

Field Description
Job The name of the command script defining the job
Node The name of the client PC which executed/is executing the job. If the job is unexecuted, this field will either be blank or will contain one of the following: a client name if the job has been allocated to a specific client PC; the word "Hold" if the job is on explicit hold
Started The date and time the job started
Updated The date and time when the Status was last updated. For jobs that have been completed, this is the date and time when the job finished
Status A code 0-5, an optional asterisk and, for jobs which have been started, the percentage of molecules processed
Results The number of hits from the search

3.1.1  Job Status

Each job in the queue has a status showing its current condition. The status is represented by a number and a description, as follows:

Status Colour Description
0 Queued White Job queued, awaiting execution
1 On Hold Grey Job has been placed on explicit hold
2 Finished Cyan Job has been successfully executed by a client
3 Failed Red Job has been interrupted or failed during execution (eg error in the defining command script)
4 Stopping Yellow Job has been interrupted by the server and is in the process of closing down
5 n% Green Job is being executed by a client: the percentage shows the progress of the job
05 Stalled Yellow Job is stalled

If the job is currently executing, the percentage of the molecules processed is displayed, and the background in the Started and Updated fields in the GUI is gradually changed from green to blue to reflect the job's progress.

3.1.2  Selecting Jobs

When a job is selected, an asterisk is added to the Status field, and the job is highlighted in black with the status colour being used for the text. Jobs are selected by picking them with the mouse using the normal Windows picking conventions, namely:

The Reset, Cancel, Hold, Release and Remove functions operate on the selected jobs.

3.1.3  Buttons and Menus

There are three ways in which the server can be controlled:

Some functionality is available through the buttons and both menus but other options are only accessible through the buttons or the pop-up menu. The following table describes the functions available:

Function Position Description
Add Button
File menu
Adds a single command script as a job using the standard file open dialogue. The script must be present in the server folder before it can be added to the queue. It can be more convenient to use the Windows Explorer to drop selected script(s) into the THINK Server window
Auto Add Button
File menu
This is provided to automatically add all command scripts in the server directory. Duplicates are avoided by checking the jobs already in the queue (this implicitly turns off the Current Jobs toggle). Any file with the name "think.log" is ignored
Reset Button
Pop-up Edit menu
If a job stops because of an error in the command script or a server request (via the Cancel button), this button is used to return the job to an unexecuted state. There are no checks on the current status prior to resetting a job
Cancel Button
Pop-up Edit menu
For the selected executing jobs, this button sends an interrupt to the client PC which will stop the job the next time the client interacts with the server file
Hold Button
Pop-up Edit menu
Places the selected queued jobs on explicit hold
Release Button
Pop-up Edit menu
Releases the selected jobs, providing their status is Hold or Failed
Remove Button
Pop-up Edit menu
Removes the selected jobs from the queue, unless they are currently executing
Client Info Pop-up Displays information on the job. If the job has been executed or otherwise allocated to a client, displays information on the number of jobs executed by that client
Allocate Pop-up Allows the job to be allocated to a specific client selected from a drop-down list of available clients
Deallocate Pop-up Deallocates the job from a specific client so it can be executed by any client
Exit Button
File menu
Closes the THINK Job Queue Server (but leaves the clients executing)

The pull-down View menu controls the visibility of the THINK Job Queue Server and any copies of the THINK client application running on the server PC.

3.1.4  Toggles

Two toggles are located at the bottom of the GUI window:.

Toggle Description
Current Jobs By default, only jobs after the first current job are shown. The first current job is the first that is executing or waiting to be executed. Clearing this toggle allows all jobs, including those which have already been completed, to be seen
Lockout Clients There are times when it is desirable to prevent client PCs starting to execute new jobs (eg if the necessary data files are not available in a shared folder or directory). Under these circumstances, setting the Lockout Clients toggle will prevent clients being allocated new jobs from the server queue

When command scripts are dropped into the window or added through the Auto Add function, the server automatically clears the Current Jobs toggle and displays all jobs in order to eliminate duplicates.

3.2   Command Mode

The server commands take the form:

    server -option [argument1 [argument2]]

where the number of arguments depends upon the option specified. Under Linux an ampersand "&" should be appended to the end of the command to indicate that the server instance is to be run in the background. This is essential when starting the server (see the section on Starting the Server - Linux)

The option keywords may be divided into three groups according to their function:

Function Option keywords
Starting the server
-auto
-invisible
-monitor
-visible
General
-help
-list
-status
Managing jobs
-add -hold
-allocate -release
-cancel -remove
-deallocate -reset

Each time a server command is issued, a new instance of the server is started to execute the command. If any keyword from the first group is supplied then the server instance will persist until it is stopped by the user (see the section on Starting and Stopping the Server). Only one copy of the THINK Job Queue Server application should be running at any time (apart from the exception described below).

The server queue file is controlled by a single copy of the server application. This means that the queue file cannot be modified using any of the options in group three (managing jobs) while the server is running. Consequently the server must be stopped before any option in group three is used.

If any of the general options from group two in the table is issued, a new instance of the THINK Job Queue Server is started to report the desired information. Under Windows the information is displayed in a separate window until it is closed by the user, at which time the server instance is terminated. This is the only circumstance under which two copies of the server can be running simultaneously: one controlling the server queue file and one reporting information to the user.

3.2.1  Starting the Server

Under Windows the server may be started in visible mode (-visible) when the graphical interface (GUI) is created, or invisible mode (-invisible). When running in invisible mode, the server can only be controlled through commands and all server error messages are only written to the server log file ("server.log").

The GUI is not available under Linux in THINK v1.23, and visible mode is almost identical to invisible mode except that server error messages are displayed on the screen as well as being written to the server log file.

The -monitor option starts the server in visible mode without the GUI, and displays a server status report at regular intervals. This is intended for use when debugging the server application. There is an -auto option which also starts the server in visible mode without the GUI and is reserved for future development.

3.2.2  General Options

The -list option is the most useful of the general server commands, as it lists the jobs that are currently recorded in the server queue file. For each job, the server reports its name, the node to which it has been allocated (if any) and its status. If the job is currently executing, the server also reports when the job was started and its progress (including the number of hits found). If the job has been completed, the server reports the time that the job finished and the number of hits found.

The -status option reports a summary of the information provided by the -list option, while -help lists the THINK Job Queue Server help text.

3.2.3  Managing Jobs

A new job is added to the queue through the -add option. This has one mandatory argument: the name of the command script (including any file extension) that defines the job:

server -add 3est-mol3.cms

Note that wildcards are not supported with the -add option.

Once a job is in the queue it is identified by its job name in all subsequent server commands. The job name is taken directly from the file name of the script that defines the job; thus the job added in the above example would be called "3est-mol3". Many server commands can operate on a single job or on a range of jobs, eg "3est-mol1:3est-mol5". Note that when a range is used, the command affects the two jobs identified in the range and all jobs in the queue file that lie between them.

The following server options can be used to manage jobs in the queue. Note that only the -cancel and -reset options can be used if a job is already being executed by a client:

Option Description
-allocate job client Allocate the specified job(s) to the named client
-deallocate job Deallocate the specified job(s) so it can be executed on any client
-hold job Place the specified job(s) on explicit hold so it will not be executed
-release job Release the specified job(s) so they can be executed by a client. The job may have been placed on explicit hold through the -hold option, or on implicit hold by being interrupted or by failing during execution
-cancel job Interrupt a job that is executing on a client. The job is placed on implicit hold. It is not re-queued until it is released
-reset job Deallocate and release the specified job(s). If the job has already been executed by a client, it is re-queued so it can be executed again. If the job is currently being executed on a client, it is interrupted and re-queued.
-remove job Remove the specified job(s) from the queue

3.3  Stopping the Server

On Windows, the THINK Job Queue Server may be stopped though the "Exit" button on the GUI or by using the Task Manager. If the GUI is being used, an application called "THINK Server" will be seen on the Applications page of the Task Manager; this corresponds to a process called "server" on the Processes page. If the server is being used in invisible mode then only the "server" process will be seen. Under Linux, the server may be stopped with any of the normal system utilities for stopping processes (eg "kill"). Note that the clients will continue to execute their current jobs whilst the server is stopped, but will be unable to start new jobs.

4    Controlling the Client

When used in client-server mode, THINK is designed to run in the background or as a screen saver with very little intervention from the user. Consequently, there are very few commands or options used to control the clients.

4.1   Starting the Client

The exact command used to start a client copy of THINK depends upon the operating system being used on the client PC.

4.1.1  Windows

If THINK is configured to run as a screen saver on a client PC (see the section on configuring the screen saver) it will be started automatically when the PC is idle. If THINK is to be run in the background on the client then the application must be started with one of the following commands:

Command Description
think /v c Makes the client graphics visible
think /i c Leaves the client invisible (ie no graphics displayed)
think /m c Makes the graphics visible but minimised

where c is only required if the PC contains multiple CPUs. Under these circumstances a separate copy of THINK should be started on each CPU, and c is 0 for the first CPU, 1 for the second, etc.

eg think /v
  think /v 0
  think /m 1

4.1.2  Linux

THINK can be started on each client PC using the command:

path/think -n 0 &

If the PC contains multiple CPUs then a separate instance of THINK should be started on each CPU using the command:

path/think -n c &

where c is 1 for the second CPU, 2 for the third, etc.

4.2   Changing the Client Display

There are various display options that can be changed independently for each client copy of THINK.

4.2.1  Visibility

When THINK is run in the background under Windows, it is possible to monitor the progress of each job by displaying the molecules being searched. This occurs automatically if the client application is started with the graphics visible. In all other circumstances the graphics can be enabled by picking the THINK icon in the system tray using the right mouse button. This displays a short pop-up menu which includes an item called "Graphics" that controls the visibility of the THINK client application.

A client can be made invisible through the tray icon or by using the "Graphics" item on the View pull-down menu within the client graphics window.

4.2.2  Display Style

The style used to depict the molecules in the client graphics window can be changed through the View pull-down menu. Options include stick, ball-and-stick and space-filling styles.

4.2.3  Job Information

In addition to the graphical display, the progress of the client application can be monitored through the job information window. This is enabled by picking the "Job Info" item on the View pull-down menu, or the "Info" item on the pop-up menu on the system tray icon.

The job information window includes information on file and molecule being searched, the number of hits found and the time taken. It also includes the name of the project for the current job. This information is picked up from the environment variable THINK_PROJECT defined on the client PC. If the environment variable is not set, the project will be listed as "Undefined".

The window also includes a button which can be used to direct users to a selected web site, for instance to obtain more information about the projects for which their client PCs are being used. The destination of this button is taken from the environment variable THINK_WEBSITE defined on the client PC. If the variable is not defined then the button will take users to the Treweren Consultants web site www.treweren.com.

4.3   Stopping the Client

The exact command used to start a client copy of THINK depends upon the operating system being used on the client PC.

4.3.1  Windows

A client copy of THINK can be stopped by picking "Exit" from the pop-up menu displayed when the THINK icon in the system tray is picked with the right mouse button. If the graphics are visible, the client application can also be stopped by picking "Exit" from the File pull-down menu or by closing the graphics window.

4.3.2  Linux

Client copies of THINK may be stopped using any of the normal system utilities for stopping processes (eg "kill").

5    Creating Jobs and Analysing Results

In client-server mode, THINK can be used to search large numbers of target molecules by:

For the clients to operate efficiently, it is necessary to avoid excessive communication with the server and/or the fileserver used to store the data files, as would occur if a set of target molecules was divided into subsets or jobs that were too small. For optimum performance it is suggested that each job should take between 5 and 10 hours to process. With default configurations, this means that each subset could consist of about 100,000 molecules. Ideally the target molecules should be stored in SMILES format files (developed by Daylight Chemical Information Systems, Inc - see www.daylight.com/smiles) as these are less verbose than SDfiles (SDfile format developed by MDL Information Systems, Inc - see www.mdli.com). If 3D coordinates are to be provided (instead of using the 3D builder within THINK) then 3D SDfiles must be used.

Treweren Consultants does not provide any tools for automatically splitting a file of molecules into subsets or generating the series of command scripts to process these subsets. It may be advantageous to avoid creating subsets that place all flexible molecules or similar molecules in the same file as this may result in some subsets taking much longer than others.

Each job is defined by a command script which must:

Each job should save its results in a separate output file to avoid overwriting the results of other searches. For a site search, the results normally consist of the 3D conformations of the hits, aligned to fit within the active site. It may be desirable to concatenate these to a single file for viewing.

5.1   Checkpoint Files

The checkpoint file for each client PC is stored in the working folder, using the name "jobname.dat", where jobname is the name of the command script for the job currently being executed on the client PC (with the ".cms" extension removed). References to the query and to the file being searched are written to the checkpoint file, as well as information on the progress to date. If a client restarts a search using the same query and target files, the search will restart from the position saved in the checkpoint file and will append the output to the existing output file. This will usually occur when the screen saver restarts after the PC has been used normally.

5.2   Log Files

The THINK Job Queue Server creates a log file called "server.log" in the working folder. This contains information on when the server was started and stopped; job assignments and all server error messages. The server also produces a file called "server.tip" which is for internal use and can be ignored.

Each copy of THINK running as a client application produces its own log file called "node.tlg" in the working folder, where node is the name of the client PC. This records the jobs executed by the client; the hits found during each search and any relevant error messages. For PCs with multiple CPUs, an additional suffix -n (where n is a number) is added to node to distinguish the log files.

THINK also produces the following files on the client PC: "node.nnn" (where nnn is a number) and "node.tip". These files are for internal use and can be ignored.

6    Trouble Shooting

The THINK Job Queue Server writes messages and information about the jobs allocated to the clients into its log file "server.log" in the working folder. The clients write messages about the jobs received and their progress into their own log files "node.tlg" in the working folder.

Before placing a series of job command scripts in the server folder, it may be worth checking that a script is correct by starting THINK in native mode and typing "CALL script".

THINK does not appear in the list of screen saver choices in the Windows Display tool

Check that the file "think.scr" is present in the Windows (or WinNT) folder or directory - look for other screen saver files with the extension ".scr" to identify the correct folder. If the file is not present, copy the file "think.exe" from the THINK software folder and change the extension to ".scr".

Screen saver does not start properly

Check that the THINK_EXEC variable is defined in the environment file "think.env" in the THINK software folder (see the section on configuring the server for more information about this file). This variable must contain the full path from the client PC to the THINK executable files.

If the variable is defined correctly, use the Preview button in the Display tool to start the THINK screen saver, and then check the contents of the "node.tlg" file created by the screen saver in the working folder to see if there are any error messages.

Cannot find "node.tlg" (or "node-n.tlg") or the checkpoint file "jobname.dat"

The working folder must be explicitly defined by setting the THINK_WORKDIR variable in the environment file "think.env" in the THINK software folder (see the section on configuring the server). If this is not set, THINK will attempt to create the log files and checkpoint files in the THINK software folder.

Jobs do not start

Check the values of the THINK_SERVER and THINK_WORKDIR variables (see the section on configuring the server), remembering that each client PC must be allocated a unique node name. Once these have been set correctly, it should be possible to run the THINK Job Queue Server from any client PC. Before starting the server , all other copies of the server should be closed down.

You should also attempt to run THINK in background mode from a command window using the command line:

Windows: path\think /v
Linux: path/think -n 0

and check the contents of the client's log file "node.tlg", where node is the name of the client PC.

Date and time shown by THINK Job Queue Server look wrong

The date and time from the client PC (not the server) is written to the queue file. Consequently any incorrect value on the client will be seen in the server. The elapsed time will be correct, providing the clock on the client PC is not changed while THINK is running (which is tricky to do, but possible).

No progress updates are seen in the server, but THINK clients are changing molecules

The server queue file is probably locked, possibly by the manager or by a defunct client. The log file "node.tlg" on the client PC will contain an error message indicating that the server queue is unavailable and will include the name of the defunct client (in which case there is no simple way of forcing unlocking).

Job(s) stop with status=3

Status value 3 is seen under two circumstances:

In the latter case, the client log file "node.tlg" will contain an error message indicating the cause of the error

Job(s) stop with status=05 (stalled)

A job will be marked as "stalled" with status=05 if its progress has not been updated in the server queue file within the last 60 seconds. This will occur if the server queue file is locked (eg the "Lockout Clients" toggle has been checked in the server GUI - see the section on the GUI). It may also be seen if the clock on the client is more than one minute behind the clock on the server: under these circumstances the job is still running on the client and its progress will be seen in the server, despite the status being set to 05.

Jobs complete almost instantly with progress remaining at 0%

This will be the result of errors in the command script. Check that all data files are correctly referenced in the command script, and check the client log file "node.tlg" file for more information.

Job(s) appear to skip part of the input file

Delete any checkpoint files "jobname.dat" files in the working folder and ensure that the file names used to refer to the query molecule and data files within the job command scripts are as unique as possible (eg do not use generic query molecule names or refer to the query molecule as #1), otherwise any client restarting from a checkpoint may misinterpret the restart data.

"node.tlg" reports error number 342 with IOSTAT 146 or 296

The text of error message 342 is "Error accessing server file" and the probable cause can be deduced from the IOSTAT number. 146 corresponds to the path not being defined and implies that the THINK_SERVER variable is not set correctly (if at all). 296 corresponds to access being denied and implies that a password is required to access files in the common server folder. Try mapping a disk drive to the server folder before starting the THINK client (eg on login).

Jobs are not assigned to a client

The clocks on the client PCs need to be approximately synchronised with the server. If a client clock is slow by more than 60 minutes, that client may be deemed to be inactive and no jobs will be assigned to it.

Network failures

Any network failure can cause unpredictable results. The client application will stop, but the error message may be confusing (and unrelated to the actual problem) because the client was unable to access the necessary part of the THINK application or associated files (eg the file containing the text of the error messages). It is not uncommon for the error message to include a traceback complaining about stack size, etc.