A.1 Parameter Editor
C.1 Results Viewer
The use of xparam Parameter Editor is very easy, since the application is fairly simple.
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./
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.
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).
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.
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
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.
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).
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.
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.
To exit the Histogram choose "File->Quit" from the application menu.
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.
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).
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.
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.
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).
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.
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).
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).
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).
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 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".
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
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.
After the successful start-up the Grid Monitor provides three different views on the actual state of the kernel computation:
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.
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.
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.
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.
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.
To exit the Grid Monitor choose "File->Quit" from the application menu.
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
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:
orrviewer <paramfile> &
> 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.
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.
To exit the Result Viewer choose "File->Quit" from the application menu.