Appendices

Appendix A - Input Components

A.1 Parameter Editor

A.2 Neural Network Training

Appendix B - Run-Time Components

B.1 Histogram (kihistogram)

B.2 Parallel Monitoring (kijerry)

B.3 Grid Monitor (kimarthy)

Appendix C - Output Component

C.1 Results Viewer


Appendix AInput Components

A.1Parameter Editor (xparam)

The use of xparam Parameter Editor is very easy, since the application is fairly simple.

Start

You can specify the name of the parameter file from the command line. If you do not do so, the default parameter file name default.ini will be used instead. If the parameter file is not found, parameter editor will not run. Parameter editor does not require kernel to be running./

Usage

The screen of the Parameter Editor (xparam) is divided into two parts. The left part shows tree of groups and their parameters. The right side of the window displays information about the parameter selected from the tree and allows it's editing.

Each changed value is stored to the internal structure when other parameter is about to be edited or explicitly, when the user chooses save command from the menu.

Parameters are stored to the file when the application is closing.

A.2Neural Network Training

How to train neural network

Before neural network can be used for gene evaluation it must be trained first. Training is process of setting network inner state into position when it can to given input values find appropriate output value (then we say that network is trained). To train network we must know some input values and corresponding outputs - training set (set of training patterns). Both input and output values must be from the range <0,1>.
Training set must be stored in parameters NNIni[j] (float), NNOuti[j] (float) and NumSamples (Integer) in parameter file. The format is as follows:

NNIni[j]_Type=Float
NNIni[j]_Value=(desired value)

Let xi=[x0,x1,...xn-1] ; i=0,2,..m-1
m - number of training patterns
n - number of inputs (number of input neurones)

NNOuti[0]_Type=Float
NNOuti[0]_Value=(desired value)

Let yi=[y] is ; i=0,1,..m-1
m - number of training patterns

NumSample_Type=Integer
NumSample_Value=(number of patterns)

We must also know how many input, how many output and how many hidden neurones will our network have (we must know network topology) The topology must be stored in parameter Topology in parameter file in the following form:

inputs-1st_layer-2nd_layer- .... -output

inputs - number of input neurones
1st layer, 2nd_layer - number of hidden neurones in 1st layer
output - number of output neurones (always 1)

Topology_Type=String
Topology_Value=(desired topology)

Other training parameters (optional):
PerSample (Integer) def.value=5 - number of iterations done over each pattern
NumIter (Integer) def.value=100 - number of iterations done over whole training set

When the parameter file is ready you can start learning process:

train parameter_file training_set output_file

where:
parameter_file is parameter file where are learning parameters (must contain at least Topology and NumSample parameters)
training_set is parameter file where only the training set is stored (parameters NNIni[j] and NNOuti[j] can be stored in separate file). Use parameter_file if you have only one parameter file.
output_file is parameter file that will be created (if successful). It can be used for neural network evaluation (see neural network in fitness expression).

How to check neural network

Checking is the way of getting to know how good have the network trained. It is not necessary, but it can help you to decide if the training was successful or not. Parameters differ very little from the parameters required in training program (see neural network training).
The first difference is that checking_set (same as training set but no outputs are required) is expected instead of training_set (its recommended to use the same file). The second difference is that no output file is created, but there is output to the screen (that says the trained value for the given pattern). The third difference is that instead of parameter NumSample is NumCheck and PerSample and NumIter are ignored.

check parameter_file checking_set

parameter_file must contain Topology and NumCheck parameters
checking_set use parameter_file if you have all parameters in one file.



 

Appendix BRun-Time Components

B.1Histogram (kihistogram)

Histogram is X Windows application. It is the runtime component of the system, enabling to monitor the computation in run-time. It provides a graphical representation of the histogram of different values occurrences in the actual population.

This section provides you with information on using Histogram and all its features.
It is organized as follows:

B.1.1 Starting Histogram

B.1.2 Understanding the Histogram Interface

B.1.3 Working with Histogram;

B.1.4 Customizing Histogram

B.1.5 Quitting Histogram

B.1.1Starting Histogram

The Histogram needs (as a runtime component) the system kernel to be started during its execution. To start the Histogram type the following command in the antares_root/summary directory:

> kihistogram <paramfile> & or > kihistogram &

Where <paramfile> is a name of the parameter file that the kernel was initialized with. The default name of the kernel result parameter file is "default.ini". For the proper Histogram functionality it is necessary the specified parameter file to be the same as the kernel initialization parameter file. It is also necessary to start a new instance of Histogram for every initialization of the system kernel (with proper parameter file specified).

The Histogram can terminate with an error, whenever the parameter file is not found or it is not consistent. In these cases the Histogram is terminated and the failure.log file is created in the antares_root/summary. This file contains the error description. 

B.1.2Understanding the Histogram Interface

After the successful start-up displays the Histogram a histogram of different values occurrences in the actual population of the kernel. For an example see Fig. B-1.

The histogram represent occurrences of values, that are encoded in the specified part of genes. See chapter Gene Parts for details on the gene parts. The available parts of genes present in the actual population are listed in the application toolbar. There can be the represented gene part selected.

The histogram consists of two axes. The horizontal axis represent the possible values of the selected gene part. The integer values are marked on this axis and the limits of the range are specified. The scale of this axis is determined by the range of represented values. The range limits of this axis can be changed by the user (see section Customizing Histogram). The vertical axis represents the count of occurrence of a given value. The range is from 0 to the total number of genes present in the actual global population. This range cannot be changed by the user. The red lines then represent the values encoded in the actual population (in selected gene part). This value is specified by the line position in the horizontal axis. The number of occurrences of this value is specified by the length of the line (position in the vertical axis).

Figure B-1: An example of histogram of occurrences of values encoded into the gene part "x" are shown in this histogram. The range of values is <-10,0>, the range of occurrences is <0,100> . The histogram shows, that many genes in the actual population contain value 2 in their part "x". 

B.1.3Working with Histogram

Use Histogram to monitor the kernel global population development. Choose the desired part of the gene from the application toolbar. The range of values (horizontal axis) is automatically set to the minimum and maximum value of the selected gene part. If the scale of the horizontal axis is too small, then set the range limits (see section Customizing Histogram).

The histogram view is refreshed whenever a kernel info object arrive from the kernel. This event is noted on the application status bar. The period of view refresh is referred as the polling time of the application. This time is initially set to 2 seconds, but it can be changed by the user (see section Customizing Histogram). In fact, the period of view refresh depends also on the network traffic.

Whenever the kernel computation is terminated, the connection between the kernel and application is lost. This event is announced by the proper dialogue box and also by the application status bar. After this event is the connection lost and cannot be newly established. To monitor a new kernel computation a new instance of application must be started. 

B.1.4 Customizing Histogram

To set the range limits of the horizontal axis of the actual histogram choose "View->Range" from the application menu. Then set the minimum value and maximum value in the dialogue box.

To set the polling time of the application choose "File->Preferences" from the application menu and enter a new period (in seconds) into the dialogue box. 

B.1.5Quitting Histogram

To exit the Histogram choose "File->Quit" from the application menu.

B.2Parallel Monitoring (kijerry)

Purpose

The following is a description of application "kijerry" designed for monitoring of parallel configuration and for monitoring of data transfer. The purpose is to visualize in a user-friendly way information supplied by PVM (see User's Manual) and by various currently running processes.

Starting

The application can be spawned from a UNIX console by "kijerry" command. It is necessary to have the parent running, otherwise the application will refuse to start (but it is not necessary to have any genetic optimization in progress). Once the application is started it retrieves all information automatically. The user can switch between different view modes or change the refresh period: polling time (this period also influences how often will information come from parent). It is needed to wait in the beginning until the first info arrives (typically a few seconds).

Information supplied

This application retrieves four types of information :

The first three are transferred from child processes to parent and from parent to this application in form of "kernel info" (see Overview and for details of object hierarchy see Reference). The last info is retrieved directly from PVM. Applications are not subject designed for monitoring. So except the "Process info" there is no information about applications displayed.

View Modes

There are six view modes that the user can switch between:

The mode switch is accessible from main menu item "Mode". Within each view mode there is usually some way to move through the actual information. It is possible to use mouse as well as keyboard input.

Process Graph mode

This mode displays all registered tasks in kernel (see overview) and the connections between them. There are three frames. The above frame refers to parent, the left frame refers to applications and the bottom frame contains child processes. Each process is displayed as an ellipse with text inside. Parent process is displayed with red background, child processes are displayed generally with yellow and applications in green and blue. This color scheme is used also for other modes. The text inside each ellipse is in form (C notation) : parent : "P:%x", child : "C:%x", application : "A:%x". Where "%x" is formatted to process ID (see Overview). This notation is also used in other view modes. It is possible to see also connections between processes represented by lines leading from a small circle to one of the ellipses. This can be interpreted that the owner of the small circle (owner identified by color) has the other processes registered (small circles are sometimes dislocated from the process they refer to for better orientation, lines always lead from dislocated circles). As application activity is not monitored there are no lines from applications (only from parent to each application).

Figure B.2.1 : Example of process graph :

Journal List mode

This mode is designed to display an overall statistics of process registration and deregistration (journals in kernel processes). There are two list boxes. The above list box displays all processes registered in the kernel in form (C notation): parent : "PARENT : %x", child : "CHILD : %x" (applications are not monitored). By double-clicking one of the lines the user can display adequate journal info in the bottom list box. The format of journal info (example for parent) :


PARENT : <PID>

<each line : TIME ............... IN/OUT , PID , TYPE>

----------------------------------------------------------

<time string> ............. <flag> , <PID> , <process type>
Time string refers to the time this journal entry was made. Flag is either "IN" (registration) or "OUT" (deregistration). PID refers to the process ID. Process type is one of the following : "PARENT", "CHILD", "APPLICATION". Process journals are not available from applications since they only register parent process.

Cover Message List mode

This mode is designed to monitor overall message statistics. There are two list boxes. The above list box has the same format as in Journal List mode. By double-clicking one of the lines the user can display adequate message info in the bottom list box. The format of message info (example for parent):

PARENT : <PID>
----------------------------------------------------
Start time : <time string>
Fresh time : <time string>
Seconds ellapsed : <amount of seconds>
Sending messages : amount ... <amount of sent messages>
 size ... <sum of message sizes in bytes>
Receiving messages : amount ... <amount of received messages>
 size ... <sum of message sizes in bytes>
Wasting messages : amount ... <amount of messages wasted>
 size ... <sum of message sizes in bytes>
Start time refers to the time the questioned process started. Fresh time is the time of this information retrieval. Seconds ellapsed is simply the difference of the two times in seconds. Next three paragraphs refer to global amount of messages sent resp. received resp. wasted by the particular process. Amounts of messages refer to the real amount of messages PVM is asked to transfer (this number is smaller than the amount sent and received by various layers in the object hierarchy due to buffering - see Overview).

Cover Message Graph mode

This mode is designed to visualize the overall message statistics in graphics. There are two graphs. The higher one displays sending activity the bottom one displays receiving activity (by PVM_COVER). In both cases the horizontal axis refers to particular kernel processes (parent is red, child processes are yellow). The vertical axes refers to percentage. Each process has a column above its ellipse. The height of the column is proportional to percentual ratio of activity of this process (so the sum of heights of all columns in both graphs adds up to 100% +- approximation error).

Figure B.2.2 : Example of cover message graph :

Codec Message List mode

This mode is designed to show the message transfer activity in maximum detail. There is no monitoring performed for applications, but all activities of kernel processes are monitored. There is one table list above and one list box at the bottom. The table list has list of all kernel processes on both axis. Each cell beginning from the second row and second column refers to sending and receiving info of process on the left about a process in the top. The notation in the first column and in the first row is identical to Process Graph mode. The notation in the cells is analogical. By double-clicking in a cell the user can display particular info in the list box beneath. Its format is very similar to the one in Cover Message List mode . But in the sending paragraph there is one more line :


Sending Messages : ...
 ...
 buffered ... <amount of buffered messages>
The buffered refers to amount of messages passed to PVM_COVER to be sent. The average amount of messages in one buffered message can be calculated as (amount / buffered) (see Overview).

PVM Configuration mode

This mode displays only information supplied directly by PVM. It is designed to monitor amount of computers in PVM configuration and amounts and PIDs of processes hosted by them. The listing has this format :

Amount of hosts ... <amount>
Amount of architectures ... <amount>
---------------------------------------------------
Host no.0 :
 Host ID ........ <HID>
 Name ........... <host name string>
 Architecture ... <architecture name>
 Speed .......... <speed>
Host no.1 :
 .
 .
 .
###################################################

Amount of tasks ... <amount>
---------------------------------------------------
<host name> : <PID0>, <PID1> ...
 .
 .
 .
Amount of hosts and amount of architectures are numbers supplied in time of the last update as well as all subsequent information. Following this there is a list hosts (computers) in the current PVM configuration. Host ID is number unique for each host. Name and architecture are strings taken from the environment variables "HOST_NAME" resp. "PVM_ARCH". Speed means the relative speed of the computer. The second part displays information about tasks. First is the amount of tasks currently present in PVM (this number does not have to match the amount of processes displayed in other modes as foreign unknown processes can be running). Each line consists of host name (the same as above) and a list of process PIDs.

Polling Time

Polling period is a number saying how often should the kernel info arrive and how often should the application produce them. Any arrival of kernel info causes the application to update the display. The polling period can be modified from the main menu item "File" -> "Preferences".

B.3Grid Monitor (kimarthy)

Grid Monitor is X Windows application. It is the runtime component of the system, enabling to monitor the computation of kernel in run-time. It provides a graphical representation of the diffusion parallelisation method. See chapter Parallelisation in System Overview for details on diffusion method.

This section provides you with information on using Grid Monitor and all its features.
It is organized as follows:

B.3.1 Starting Grid Monitor
B.3.2 Understanding the Grid Monitor Interface
B.3.3 Working with Grid Monitor;
B.3.4 Customizing Grid Monitor
B.3.5 Quitting Grid Monitor

B.3.1 Starting Grid Monitor

The Grid Monitor needs (as a runtime component) the system kernel to be started during its execution. This application is intended only for monitoring diffusion parallel genetic algorithm. This component will not work if another parallelisation method or a serial genetic algorithm is computed by the kernel. To start the Grid Monitor type the following command in the antares_root/summary directory:

> kimarthy <paramfile> &

or

> kimarthy &

Where <paramfile> is a name of the parameter file that the kernel was initialized with. The default name of the kernel result parameter file is "default.ini". For the proper Grid Monitor functionality it is necessary the specified parameter file to be the same as the kernel initialization parameter file. It is also necessary to start a new instance of Grid Monitor for every initialization of the system kernel (with proper parameter file specified).

The Grid Monitor can terminate with an error, whenever the parameter file is not found or it is not consistent. In these cases the Grid Monitor is terminated and the failure.log file is created in the antares_root/summary. This file contains the error description.

B.3.2Understanding the Grid Monitor Interface

After the successful start-up the Grid Monitor provides three different views on the actual state of the kernel computation:

Global Coarse View

The global coarse view provide the user with possibility to monitor the grid structure established between the child processes (local genetic algorithms). The white points represent the child processes that participate in the computation. Their internal kernel number of the local genetic algorithm and PID number (hexadecimal) of the process is specified below the point. The direct neighbourhood relationship between two child processes is represented as a line connecting the proper points of the grid. For an example see Fig. B-1.

Figure B-3: An example of global coarse view of the grid. Four child processes participate in the computation (white points). Two processes are direct neighbours when they are connected in this view e.g. processes 0:40051 and 1:40052 are direct neighbours. This is an example of a 4 neighbours grid structure. 

Global Fine View

The global fine view of Grid Monitor provide similar view as the global coarse view. It is, in fact, representation of grid of places established between all genes of the global population. All child processes are represented by their subpopulations. Their position is equivalent to the global coarse view. The green points represent genes. The grid structure is represented by the line connections between the points i.e. two genes are direct neighbours when they are connected by a line. Genes from different subpopulations are not connected at all. The quality of each gene (i.e. its fitness value) is represented by the color brightness of the point i.e. a black point represents a gene with its fitness value near 0, bright green point represents a gene with its fitness value near 1. See Fig. B-4 for an example.

Figure B-4: An example of global fine view of the grid. Two child processes participate in the computation. They are represented by their subpopulations of size 20 (grid 5x4). Two genes are direct neighbours in grid when they are connected in this view. The color brightness of a point represents the fitness value of the proper gene. 

Local View

The local view of Grid Monitor provides a graphical representation of the grid structure of the chosen subpopulation. The subpopulation is determined by the internal kernel number of the local genetic algorithm (child process) participating on the computation (see section Global Coarse View). This number can be selected in the application toolbar.

The green points represent own genes of the selected subpopulation. Each red point represents a shadow copy of a gene present in the subpopulation of the direct neighbour of the represented child process. The grid structure is represented by the line connections between the points i.e. two genes are direct neighbours when they are connected by a line. The quality of each gene (i.e. its fitness value) is represented by the color brightness of the point i.e. a black point represents a gene with its fitness value near 0, bright green or red point represents a gene with its fitness value near 1. See Fig. B-5 for an example.

Figure B-5: An example of local view of grid (5x4) structure of the subpopulation maintained by the child process 0. The green points represent genes owned by the process. The red genes are the shadow copies. Represented child process has just one direct neighbour (down direction) Two genes are direct neighbours in grid when they are connected in this view. The color brightness of a point represents the fitness value of the proper gene. 

B.3.3Working with Grid Monitor

Use Grid Monitor to monitor the diffusion parallel computation development. Choose the desired view and watch the grid structure established between child processes, their subpopulations and genes. You can also watch the actual fitness value of genes.

The Grid Monitor view is refreshed whenever a kernel info object arrive from the kernel. This event is noted on the application status bar. The period of view refresh is referred as the polling time of the application. This time is initially set to 2 seconds, but it can be changed by the user (see section Customizing Grid Monitor). In fact, the period of view refresh depends also on the network traffic.

Whenever the kernel computation is terminated, the connection between the kernel and application is lost. This event is announced by the proper dialogue box and also by the application status bar. After this event is the connection lost and cannot be newly established. To monitor a new kernel computation a new instance of application must be started. 

B.3.4 Customizing Grid Monitor

To set the polling time of the application choose "File->Preferences" from the application menu and enter a new period (in seconds) into the dialogue box. 

B.3.5Quitting Grid Monitor

To exit the Grid Monitor choose "File->Quit" from the application menu.

 

Appendix COutput Component

C.1Result Viewer

Result Viewer is a standalone X Windows application. It provides a graphical representation of the computation results.

This section provides you with information on using Result Viewer and all its features.
It is organized as follows:

C.1.1 Starting Result Viewer

C.1.2 Understanding the Result Viewer Interface

C.1.3 Quitting Result Viewer

C.1.1 Starting Result Viewer

The Result Viewer does not need the kernel to be started during its execution. To start the Result viewer type the following command in the antares_root/summary directory:

rviewer <paramfile> &

or

> rviewer &

Where <paramfile> is a name of the result parameter file, created by the system kernel when its computation was terminated. The default name of the kernel result parameter file is "result.pf".

The Result Viewer can terminate with an error, whenever the parameter file is not found or it is not consistent. In these cases the Result Viewer is terminated and the failure.log file is created in the antares_root/summary. This file contains the error description. 

C.1.2Understanding the Result Viewer Interface

After the successful start-up displays the Result Viewer the listing of the result population. See Fig. C-1 for an example. This population listing consists of descriptions of particular genes and separators. Each gene has a unique number in the population specified. The gene is described by its fitness value in range <0,1> and by a list of its parts and their decoded values. Every value of the part is listed as a real number.

In the toolbar is, in addition, specified the number of the best gene of the listed population (a gene with the highest fitness value). Use the scrollbar to locate the best gene.

Figure C-1: The result population listing of the Result Viewer. A genes consists of a single part "x" in this example. 

C.1.3Quitting Result Viewer

To exit the Result Viewer choose "File->Quit" from the application menu.

 

User's quideProject Antares