ec.exchange.README Maven / Gradle / Ivy

Go to download

Show more of this group Show more artifacts with this name
Show all versions of ecj Show documentation

ECJ, A Java-based Evolutionary Computation Research System. ECJ is a research EC system written in Java. It was designed to be highly flexible, with nearly all classes (and all of their settings) dynamically determined at runtime by a user-provided parameter file. All structures in the system are arranged to be easily modifiable. Even so, the system was designed with an eye toward efficiency. ECJ is developed at George Mason University's ECLab Evolutionary Computation Laboratory. The software has nothing to do with its initials' namesake, Evolutionary Computation Journal. ECJ's sister project is MASON, a multi-agent simulation system which dovetails with ECJ nicely.

The newest version!

This package contains two implementations of the Exchange facility in ECJ to
perform island models.  The first implementation:

	ec.exchange.InterPopulationExchange

... works within a single evolutionary process, and treats each subpopulation 
as a separate "island", performing a synchronous island model among the
subpopulations.  This is mostly of academic interest, as it only runs on a 
single evolutionary process.  Note that it's also incompatable with other
uses of subpopulations, such as coevolution.  See the inter.params file for
an example.


The second implementation:

	ec.exchange.IslandExchange

... is an elaborate multi-process, multi-machine island model.  The system
can perform both synchronous and asynchronous island models of any topology
you like.  It is graceful in handling islands which disappear but cannot handle
new islands or replacement islands.  The system is (or should be!) entirely
compatible with the distributed evaluator, so you can have multiple islands,
each with their own little master/slave evaluation facility.  The system also
handles (or should) checkpointing properly.

IslandExchange requires that you define an ECJ process as a "server" and
the others as "clients".  If you like, a process can serve both as a server
and as a client.  The clients all connect to the server and are told by the
server how to hook up with one another in the desired topology.  The server
also communicates signals to the clients, notably telling them to shut 
themselves down when one of the clients has discovered an optimal solution.

The directories

	3-Island	8-Island

...contain examples of 3- and 8-island models where the server is also a
client.  The directory

	2-Island

... contains an example of a simple 2-Island model with a separate server 
(thus 2 clients and 1 server).  Note that to run the server separately, you
fire up ECJ not with ec.Evolve but with ec.exchange.IslandExchange.  See the
README file in that directory for more information.

There are a number of options in the island model, described more fully
in the IslandExchange class documentation.  Here's a quick overview of some
of them.

A process is told to be a server (possibly in addition to being a client) with
the parameter

	exch.i-am-server=true

Servers work by listening in on a socket port.  You specify this port as an
integer, ideally above 2000 or so.  The clients will all need to know this
port number as well.  The port is defined as:

	exch.server-port= ...

Communication between clients is by default compressed.  Note that Java's
compression routines are broken (they don't support PARTIAL_FLUSH), so we
have to rely on a third-party library called JZLIB.  You can get the jar
file for this library on the ECJ main web page or at
http://www.jcraft.com/jzlib/

To turn compression OFF for some reason, you'd say

	exch.compression = false

A synchronous island model (where all islands send and receive at the same
time) is defined by the server parameter:

	exch.sync=true

If this is the case, then the server can specify when the at what generation
the exchanges begin with

	exch.start= ...

... and also specify the interval between exchanges as:

	exch.mode= ...

By default, ECJ does *asynchronous* exchanges instead, where each island is
told independently what generation it should start at and what interval it
should use, and the islands are free to go at their own pace rather than wait
for the other islands synchronously.  

Islands each have a "mailbox" which receives incoming individuals from the 
other islands, and after breeding they check and empty that mailbox, 
replacing some individuals in the current population with the incoming 
immigrants.  The selection procedure for the individuals to be replaced is by 
default random selection, but you can change that (see below).

The server defines the number of islands as:

	exch.num-islands= ...

Each island is defined with several parameters in the server's parameter files.
In the examples below, replace n with the numbers 0 through the number of
islands (minus 1).

	exch.island.n.id	The name of island number n (a string)
	exch.island.n.num-mig	How many islands this island sends to.
	exch.island.n.mig.m	The name of island number m that this island
				sends to.  (m is a number from 0 to
				exch.island.n.num-mig minus 1).
	exch.island.n.size
	exch.size (default)	How many individuals this island sends to
				each of the other islands at one time.
	exch.island.n.start	
	exch.start (default)	What generation the island should start sending
				(only used if asynchronous)
	exch.island.n.mod	
	exch.mod (default)	The interval between sends (only used with
				asynchronous)
	exch.island.n.mailbox-capacity	
	exch.mailbox-capacity (default)	How large the island's mailbox should
					be.  This should be large enough to
					accept enough individuals from other
					islands, but not so big that it's
					larger than your population size!
					The mailbox will overflow if full.
					You'll need to tune this size if
					you have some islands that are much
					faster at sending out individuals
					than others are at incorporating them.

Once your server has defined all these topology elements, you just need to make
some clients.  Client parameters are quite simple.  The primary ones are:

	exch.server-addr	The IP address of the server, so the client
				knows where to connect and get its marching
				orders.
	exch.server-port	The socket port of the server.
	exch.client-port	The desired socket port of the client that
				other clients will connect to it via to set up
				the island model.  This should be different 
				than server-port if you have a client which is
				also a server.
	exch.id			The name of the client's island.  The server
				will use this name information to determine the
				topology as above.
	exch.select		The selection method used to pick individuals
				to emigrate TO other islands.
	exch.select-to-die	The selection method used to pick individuals
				to be replaced by incoming immigrants.  By
				default this is random selection.

There's more than this, but it's sufficient to understand what's going on in
the example directories.  For more description of how things work, see
the IslandExchange class documentation.