3Using The System

When the system is successfuly installed, it is the time to use it. In this chapter are described all neccessary steps.

3.1 Executables & Required Files

3.1.1 Parent

3.1.2 Child

3.2 Run

3.2.1 Demonstration of Parallel Computation

3.2.1 Demonstration of Serial Computation

3.2.3 Parameter File

3.3 Control

3.3.1 Console Shell (consh)

3.4 Monitoring

3.1Executables & Required Files

All binary files of the Antares package are situated in the directory summary. There are situated binary files of the system kernel and its utilities, X-Windows programs and also demo applications of the system.

3.1.1Parent

This is, roughly speaking, the heart of the system kernel. This program starts and controls the computation of child processes. It accepts the commands sent by the consh application and it collects the result populations.

The syntax of the parent binary file:
parent [ -t<type> ] [ <host> <host> ... ]
Where:

• <type> is type of the genetic algorithm. Possible values are:
  diffusion (default) for the diffusion parallel genetic algorithm
  serial for the serial genetic algorithm
• <host> is a hostname to be added to the PVM configuration

Important notes:

• <type> has to correspond with parameter file used to initialize the kernel. Else the kernel initialization fails. E.g. if you run the kernel with diffusion you have to initialize it with parameter file, which contains the parameter GAType set to "diffusion".
• if the kernel is started with serial no parallelization takes place. You can spawn more childs, but they will not cooperate.

3.1.2Child

Child process is the computation unit of the system kernel. It evolves the population and fulfils the parallelization. It is spawned by the parent process. You will never need to run the child process binary file directly.

3.2Run

To run the system kernel you have to initialize it with a valid parameter file. This special file has to contain all necessary information about the problem to be solved and about genetic algorithm and parallelisation settings. We recommend you to use prepared demo application parameter files for kernel initialisation (see the chapters 3.2.1 and 3.2.2). The demonstration parameter files correspond with the parameter files used during the performance test (see System Overview for details). For the parameter file syntax see the chapter 3.2.3. If you are ready to experiment, there is the list of important parameters prepared.

3.2.1Demonstration of Parallel Computation

The parallel computation demonstration is specified in parameter file diffusion.pf situated in directory summary. This file includes files *.diffusion.pf situated in directory summary/params. This demonstration is performed as a computation of four child proceses using the diffusion technique of cooperation.

Starting the Kernel

1. First thing you have to do is to set parameter "ChildFilename". This parameter specifies the path to the child process binary file (child). The reason is that PVM daemon does not search the actual directory. So you have to specify the relative path from your home directory (e.g. myantares/summary/child) or the full path (e.g. /home/myhome/myantares/summary/child). You can set the parameter using the xparam application (recommended) or directly edit file summary/params/system.diffusion.pf in any text editor.
2. Change your actual directory to summary.
3. To start the system kernel type parent <list of hosts> &
   Where <list of hosts> is a list of host names separated by space character. These hosts will participate on the kernel computation.
   Important: you have to install all required software packages on all specified hosts (Antares, PVM, QT Toolkit).
4. If an error is encountered during the initialization, then terminate the whole system (the console shell command exit) and see description of the error in file failure.log in the summary directory or in your home directory.
5. Start the consh typing consh.
6. Use the console shell command init diffusion.pf to initialize the kernel. You will see some messages generated by child processes during initialization.
7. When the kernel is initialized use the console shell command start
.
8. Now the computation is started.
9. You can wait until the system is paused by internal stopping conditions

Stopping the Kernel

1. To stop the computation use the console shell command stop.
2. The result is written to a file result.pf situated in the directory summary.
3. To terminate the whole system use the console shell command exit.
4. To stop PVM, start the PVM console (type pvm) and then use the PVM console command halt. This command causes termination of all PVM associated processes on all hosts.
5. To view the results of the computation type rviewer result.pf.

3.2.2Demonstration of Serial Computation

The serial computation demonstration is specified in parameter files classic.pf and dynamic.pf situated in directory summary. File classic.pf includes files *.classic.pf situated in directory summary/params. File dynamic.pf includes files *.dynamic.pf situated in directory summary/params. These demonstarations are performed as a computation of a single child proceses.

Starting the Kernel

1. First thing you have to do is to set parameter "ChildFilename". This parameter specifies the path to the child process binary file (child). The reason is that PVM daemon does not search the actual directory. So you have to specify the relative path from your home directory (e.g. myantares/summary/child) or the full path (e.g. /home/myhome/myantares/summary/child). You can set the parameter using the xparam application (recommended) or directly edit file summary/params/system.classic.pf or summary/params/system.dynamic.pf in any text editor.
2. Change your actual directory to summary.
3. To start the system kernel type parent -tserial &
4. If an error is encountered during the initialization, then terminate the whole system (the console shell command exit) and see description of the error in file failure.log in the summary directory or in your home directory.
5. Start the consh typing consh.
6. Use the console shell command init classic.pf or init dynamic.pf to initialize the kernel. You will see some messages generated by the child process during its initialization.
7. When the kernel is initialized use the console shell command start
.
8. Now the computation is started.
9. You can wait until the system is paused by internal stopping conditions

Stopping the Kernel

1. To stop the computation use the console shell command stop.
2. The result is written to a file result.pf situated in the directory summary.
3. To terminate the whole system use the console shell command exit.
4. To stop PVM, start the PVM console (type pvm) and then use the PVM console command halt. This command causes termination of all PVM associated processes.
5. To view the results of the computation type rviewer result.pf.

3.2.3Parameter File

3.2.1.1 Parameters

3.2.1.2 Groups

3.2.1.3 Directives

3.2.1.4 Comments

3.2.1.5 Complete example

Parameter File is a text file with a special format. The idea of the format follows:

• each parameter is specified by its name. The specification must also include value and value type of the parameter
• parameters are divided into groups
• it is possible to use directives
• parameter specification can determine also a caption
• each file and each parameter can have its own comments

We strongly recommend to use the xparam utility to edit the parameters, however a situation may arise when you would wish to edit the parameters manually. A description of the syntax of such a file follows.

3.2.1.1Parameters

Each parameter is specified by its unique name. It is necessary to define the parameter's data type and its value. Also a caption can be specified as a flag, if the parameter can be changed during the run of the whole system. The type specification must be defined before the value definition appears. The definitions are specified by the parameter name, underline sign, keyword and equal sign followed by the definition.
An example:

DemoParameter_Type=String
DemoParameter_Value=Hello world
DemoParameter_Caption=Just a demo
DemoParameter_Change=Yes

The keywords are

The type specifiers are:

The definition of change can be Yes or No. If the definition does not exists Yes is taken as a default value.

3.2.1.2Groups

The groups should simplify the orientation in the text file. They are also used by the Parameter editor to place the parameters onto a different sheets. Sometimes they can also speed up the access to the parameter inside the program.
The definition is quite simple: the group starts with a groupname enclosed in brackets and all the following parameters belong to the group.

[Our first group]

3.2.1.3Directives

Directives can be specified at the beginning of he file . Only one directive is supported right now . It is a directive #include. It causes the specified file to be icluded into the ParamFile structure.
The parameters of the directive are:
1) the filename closed in the quotation marks ("")
2) optionally :

• R force the file to be opened as read-only
• W always write back the changes

Otherwise the file is opened in the same way as the file containing the directive.

#include "DemoFile.ini"

3.2.1.4Comments

Comments are just an explanation for the reader. Every line of comment begins with a semicolon (;).

;Look at this comment

Every comment before a first parameter definition is considered as a file comment. All others are a part of the last defined parameter (comments can be in the middle of the definition).

3.2.1.5Complete example

;This is a demo
#include "File1"
;Open as read-only
#include "File2" R
;always write back
#include "File3" W

[First group]

DemoParameter_Type=String
DemoParameter_Value=Hello world
DemoParameter_Caption=Just a demo
DemoParameter_Change=Yes

[Second group]

P1_Type=Fit
P1_Value=0.65
;You see no caption

P2_Type=Prob
P2_Caption=Success chance
P2_Value=95.5%

3.3Control

You can control the behaviour of the system kernel even during its computation using the application consh.

3.3.2Console Shell (consh)

3.3.2.1 What is Console Shell

3.3.2.2 Commands

3.3.2.3 Known Bugs

3.3.2.1What is Console Shell

Console shell is a simple tool which serves to control the computation from an ordinary UNIX command line. It supports nearly all commands from the control interface of the kernel. It offers satisfactory level of control over it. It is able to initialize, to start, to stop, to pause and to abort the computation. On the other side it cannot retrieve any kind of data neither from the kernel or children. Other components are designed to serve this purpose.

Basic feedback from the kernel (and children) is also made possible through supported event interface. Both information text and error messages are displayed.

Batch jobs can be processed by invoking the shell with the name of the batch description file as a parameter.

Console shell is case sensitive.

3.3.2.2Commands

Here is the list of commands console shell can understand:

• help
  Prints brief description of all available console shell commands.
• init <ini_file_name>
  Starts the initialization by sending the init message to the kernel. Requires the name of the parameter file as parameter.
  The parameter file must exist, otherwise the kernel is stopped.
• start
  When initialized succesfully, the computation can be started by this command.
• stop
  Stops the computation.
• pause/continue
  Use this command to stop the computation temporarily or to continue computing respectively.
• abort
  Aborts the computation. Stops as quick as possible, does not care about the results or data consistency.
• exit
  Exists console shell, stops the computation and terminates all associated processes.
• quit
  Exist console shell, but leaves associated kernel processes running.
• state
  Returns the state of the kernel (computation).
• script <script_file_name>
  Interprets each line from the file named as parameter as a command.
• parchange <ini_file_name>
  Changes the parameters of the running system, using the values from the specified parameter file.
  The parameter file must exist, otherwise the kernel is stopped.
• onepch <parameter_name <parameter_value>
  Changes the value of one of the parameters of the running system.

3.3.2.3Known Bugs

• Running console shell with redirected standard input doesn't work properly.

3.4Monitoring

3.4.1.1 Console Shell

3.4.1.2 X Windows applications

3.4.1.3 Log Files

3.4.1.1Console Shell

The console shell can monitor the state of kernel through the command state.

The system kernel has its internal state defined in every moment of its execution. This states determine the behaviour of the kernel. A change of the internal state is performed as a reaction on user's command or can be evoked by an internal event e.g. an internal error.

Fig. 3-2 represents the scheme of the kernel state development with respect to the user's commands and internal events. There exist six user commands: INIT, START, PAUSE, STOP, ABORT and EXIT. Except for the last command are commands valid only in certain states, as noted in the fig. 3.4-1. Only the command EXIT is valid in every state of the kernel. In addition there are two possible internal events: an internal error and the satisfaction of the termination condition.

Fig. 3-3 contains the complete list of the kernel states with the description of kernel external behaviour and actions performed by the change of the state. Note that the data interface of the kernel is available just in states RUNNING, PAUSED and ERROR. So the user can monitor the kernel only in these states. In the last two states is the computation stopped and the data interface refreshed by a timer (set to 10 seconds). So the frequency of the information refresh is reduced, while the kernel is in state PAUSED or ERROR.

Figure 3-2: The scheme of the kernel state development.

The fig. 3-4 presents all possible state-command combinations. Command sent to a kernel in wrong state is ignored.

3.4.1.2X Windows applications

There are special X Windows applications, that can monitor events and states of the system kernel computation in a user-friendly way. A detailed description of these applications can be found in Appendices part of this book. The only thing to mention now is: they cannot be run successfully without the parent process already running.

3.4.1.3Log Files

Both the parent process and child processes reports the most important information into two text files. These files are journal.log for important state changes and failure.log for failure information. These files generated by the parent process are placed into the summary directory. The files generated by a child process can be found in your home directory.

User's quideProject Antares