Documentation:Tutorials:Distributed GP (Island)
From Beagle
This section is a tutorial distributed computing with Open BEAGLE as a genetic programming framework. It first discusses how to run an example, and then discusses the parameters of the distributed computation.
Contents |
Objective of SymbRegIsland
Find a function of one independent variable and one dependent variable, in symbolic form, that fits a given sample of 20 (xi,yi) pairs, where the target function is the quadratic polynomial y = x4 + x2 + x2 + x. SymbRegIsland is a distributed variant of SymbReg.
Getting the SymbRegIsland example to work
- Download and compile the beagle framework in the directory <beaglePath> of your choice.
- Then go into directory <beaglePath>/examples/Distrib/symbreg_island and compile the example sources.
- Start the example via ./symbreg_island -OBconf="symbreg_island_peer1.conf" & ./symbreg_island -OBconf="symbreg_island_peer2.conf" >/dev/null (as described in the README of the example diectory). This will start two processes of symbref_island whereby the first one will print some logging information to the console in directory <beaglePath>/examples/Distrib/symbreg_island/symbreg_island.
The distributed evolution of the first process will write something similar to the console as shown here:
<?xml version="1.0" encoding="ISO-8859-1"?> <Beagle version="3.1.0"> <Logger> <Log>Open BEAGLE, version 3.1.0</Log> <Log>Setting console log level 2</Log> <Log>Setting file log level 5</Log> <Log>Logging to file 'symbreg_island_peer1.log'</Log> <Log>Reading file 'symbreg_island_peer1.conf' for evolver configuration</Log> <Log>Reading file 'symbreg_island_peer1.conf' for system configuration</Log> <Log>Reading file 'symbreg_island_peer1.conf' for system configuration</Log> <Log>Randomizer seed used: 4166492235</Log> <Log>Starting an evolution</Log>
By increasing the console log level to 5 (with -OBconsole.lg.level=5) of the first process the transmit and receive operations will appear in the console log output.
<Log>Applying 'DBIM-CommunicationsOp'</Log> <Log>Applying 'DBIM-TransportSendOp'</Log> <Log>Selecting 5 individuals for transportation from 1st deme using 'SelectRandomOp'</Log> <Log>Selecting 5 individuals from a pool of 100 individuals</Log> <Log>Transporting individuals</Log> <Log>Applying 'DBIM-TransportReceiveOp'</Log> <Log>Received 5 individuals.</Log> <Log>The maximum number of individuals to replace is 20</Log> <Log>Replacing 5 individuals</Log> <Log>Obtained 5 indices from transport component</Log> <Log>Applying 'DBIM-TermReceiveOp'</Log> <Log>Checking if 'DBIM-TermReceiveOp' termination criterion reached for the 1st deme</Log> <Log>Checking messages for termination request</Log> <Log>Applying 'DBIM-TermSendOp'</Log>
If you have a two core machine you will see two processes of symbreg running - each keeping one core busy.
After some generations there is a good chance that you will see this warning:
<Log>WARNING: failed to send message to 'symbreg_island_peer2' (recipient 'DBIM-TransportReceiveOp'); couldn't connect to 127.0.0.1:4502</Log>
This will occur when one process (in this case process 2 - otherwise the log goes to /dev/null ;)) will terminate before the other process, which is the case when
- One process reached the target fitness (in the symbreg_island example the target fitness = 1)
<Stats type="Stats" id="vivarium" generation="11" popsize="100">
<Item key="processed">81</Item>
<Item key="total-processed">1011</Item>
<Measure id="fitness">
<Avg>0.779566124695</Avg>
<Std>0.145148711681</Std>
<Max>1</Max>
<Min>0.00107816036325</Min>
</Measure>
- One process will reach the maximum generation number (in the symbreg_island the maximum generation number = 50)
<Stats type="Stats" id="vivarium" generation="50" popsize="100">
<Item key="processed">72</Item>
<Item key="total-processed">4136</Item>
<Measure id="fitness">
<Avg>0.81400375817</Avg>
<Std>0.206338521644</Std>
<Max>0.935984492302</Max>
<Min>0.0159675553441</Min>
Since the processes are loosely coupled they notice/log (according to their log level) if their peer process(es) are not available but they don't stop computing. With this feature you can easily switch on/off processes (on different nodes) distributing the load even after a computation started.
Changes of SymbRegIslandMain.cpp in relation to SymbRegMain.cpp
There is only a single line to add to make SymbRegIsland of SymReg:
// Build a system with GP package ... lSystem->addPackage(new Distrib::Island::PackageTCPIP);
This new package tells SymbReg how the communication in (technically) done. In this case it's TCPIP (Transmission Control Protocol (TCP) and the Internet Protocol (IP)). There is also a MPI (Message Passing Interface) package.
(Communication related) Changes of Configuration File(s) in relation to (most) SymbReg config files
The example configuration starts by introducing a header specifying that the TCPIP communication protocol should be used. Required parameters to use this protocol is the local reception port <Port>4501</Port> (first occurance of Port), as well as a list of all connected processes. All connected processes are defined by a name, a host IP number, and a port. In the example there is one connected process symbreg_island_peer2 on localhost with IP 127.0.0.1 on port 4502. Standard Port number (for standard OSs) ranges from 0 - 1023 and should there be not used. Additional common used port numbers depend on the applications run on this host (see for example Portlist).
<Beagle>
<System>
<DBIM-CommunicationsTCPIP>
<Port>4501</Port>
<Address name="symbreg_island_peer2">
<Host>127.0.0.1</Host><Port>4502</Port>
</Address>
</DBIM-CommunicationsTCPIP>
- ec.transport.maxreplace (type=double with a valid range of x>, x<=1, default value = 0.2) specifies the maximal proportion of replaced individuals (when received from another process). In the example its 20% of 100 individuals. If the maxreplace value has been reached and still more individuals have been received, the most recently received individuals will replace randomly selected older individuals (of the individuals previously chosen for a replacement in this generation).
- ec.transport.recvinterval (type=unsigned int, default value=1) specifies the receive interval in number of generations, whereby 0 disables the receive.
- ec.transport.sendinterval (type=unsigned int, default value=1) specifies the send interval in number of generations, whereby 0 disables the send.
- ec.transport.send (type=float, default value=0.05) specifies the proportion of sent individuals. In the example its 5% of 100 individuals.
- ec.transport.replaceop (type=boolean, default value=0) indicates if a (specified) replacement selection operator should be used. A value of 0 equals false, 1 equals true.
- ec.transport.replacesent (type=boolean, default value=1) indicates if incoming individuals should replace sent individuals. If both this and ec.transport.replaceop are set, then sent individuals are replaced by first and any unplaced individuals will replace those selected by the replacement selection operator. If this is set and ec.transport.replaceop is not set then unplaced individuals will be discarded. A value of 0 equals false, 1 equals true.
The example file closes the System section as follows:
<Register>
<Entry key="ec.transport.maxreplace">0.2</Entry>
<Entry key="ec.transport.send">0.05</Entry>
</Register>
</System>
The initial BootStrap specifies some DBIM (Distributed Beagle Island Model) Communication related stuff ...
<Evolver>
<BootStrapSet>
...
<DBIM-CommunicationsOp/>
<DBIM-TransportSendOp/>
<DBIM-TransportReceiveOp/>
<DBIM-TermReceiveOp/>
<DBIM-TermSendOp/>
...
</BootStrapSet>
- DBIM-CommunicationsOp introduces communication in general (TCP or MPI).
- DBIM-TransportSendOp and DBIM-TransportReceiveOp introduce operators to send and receive transported individuals via Communications components.
- DBIM-TermSendOp and DBIM-TermReceiveOp introduce operators to send and receive termination criteria (e.g., best possible individual was found).
The MainLoopSet repeats those Communication by extending the Send Operation with (previously) defined addresses (in the example symbreg_island_peer2).
<MainLoopSet>
....
<DBIM-CommunicationsOp/>
<DBIM-TransportSendOp>
<SendTo address="symbreg_island_peer2" recipient="DBIM-TransportReceiveOp"/>
</DBIM-TransportSendOp>
<DBIM-TransportReceiveOp/>
<DBIM-TermReceiveOp/>
<DBIM-TermSendOp>
<SendTo address="symbreg_island_peer2" recipient="DBIM-TermReceiveOp"/>
</DBIM-TermSendOp>
....
</MainLoopSet>
</Evolver>
</Beagle>
