|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |
java.lang.Objectec.Problem
ec.eval.MasterProblem
A MasterProblem object is a singleton object that uses remote slave processes to evaluate individuals in a distributed fashion. Evaluation of individuals is the only distributed behavior of the MasterProblem. All other behavior is delegated to a local instance of the actual problem (specified for the experiment via the eval.problem parameter). It is not intended for users to extend MasterProblem.
To take advantage of the distributed funtionality offered by MasterProblem, specify the eval.masterproblem parameter which must have a value of ec.eval.MasterProblem.
MasterProblem expects a number of slave processes to connect equal to the number of evaluation threads specified by the evalthreads parameter. The MasterProblem will not evaluate any individuals until the expected number of slave processes have registered. Any additional slave processes that register will be ignored.
There is no fault tolerance built in to the MasterProblem. If a slave process dies in the middle of evaluating an individual, the MasterProblem will become aware of the problem and abort the job. If a slave process hangs while processing an individual (if, for example, the slave is enters an infinite loop) the master process will hang waiting for a response.
Future versions of MasterProblem will take advantage of available Slave processes and adjust it's utilization of them as they come and go. This means that the MasterProblem will not abort unless all existing Slave processes die. The MasterProblem will also be equiped with a (user configurable) timeout mechanism. If the timeout expires while waiting for a response from a given slave, the evaluation will be aborted and the Slave will be considered dead. At this point, the MasterProblem will adjust it's utilization of available Slaves and restart the evaluation process.
Parameters
eval.compression bool =true or false (default) |
(whether to use compression when transmitting individuals to slave processes) |
eval.master.port int |
(port to which slave process will connect and register themselves with the master process) |
eval.masterproblem classname, == ec.eval.MasterProblem |
(the master problem class) |
Field Summary | |
boolean |
batchMode
|
Problem |
problem
|
ec.eval.MasterProblemServer |
server
|
java.lang.Thread |
serverThread
|
Fields inherited from class ec.Problem |
P_PROBLEM |
Constructor Summary | |
MasterProblem()
|
Method Summary | |
void |
describe(Individual ind,
EvolutionState state,
int threadnum,
int log,
int verbosity)
"Reevaluates" an individual, for the purpose of printing out interesting facts about the individual in the context of the Problem, and logs the results. |
void |
evaluate(EvolutionState state,
Individual[] inds,
boolean[] updateFitness,
boolean countVictoriesOnly,
int threadnum)
Evaluates the individuals found in ind together. |
void |
evaluate(EvolutionState state,
Individual ind,
int threadnum)
Evaluates the individual in ind, if necessary (perhaps not evaluating them if their evaluated flags are true), and sets their fitness appropriately. |
void |
finishEvaluating(EvolutionState state,
int threadnum)
Will be called by the Evaluator after prepareToEvaluate(...) is called and then a series of individuals are evaluated. |
void |
initializeContacts(EvolutionState state)
|
void |
postprocessPopulation(EvolutionState state,
Population pop)
Finish processing the population (such as fitness information) after evaluation. |
void |
prepareToEvaluate(EvolutionState state,
int threadnum)
May be called by the Evaluator prior to a series of individuals to evaluate, and then ended with a finishEvaluating(...). |
void |
preprocessPopulation(EvolutionState state,
Population pop)
Set up the population pop (such as fitness information) prior to evaluation. |
void |
reinitializeContacts(EvolutionState state)
|
void |
setup(EvolutionState state,
Parameter base)
Sets up the object by reading it from the parameters stored in state, built off of the parameter base base. |
void |
shutdown()
Called on the Problem prototype just before the system is shutting down. |
Methods inherited from class ec.Problem |
defaultBase, protoClone, protoCloneSimple, resetFromCheckpoint, restoreFromCheckpoint, setCheckpoint |
Methods inherited from class java.lang.Object |
clone, equals, finalize, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait |
Field Detail |
public Problem problem
public ec.eval.MasterProblemServer server
public java.lang.Thread serverThread
public boolean batchMode
Constructor Detail |
public MasterProblem()
Method Detail |
public void setup(EvolutionState state, Parameter base)
Prototype
For prototypes, setup(...) is typically called once for the prototype instance; cloned instances do not receive the setup(...) call. setup(...) may be called more than once; the only guarantee is that it will get called at least once on an instance or some "parent" object from which it was ultimately cloned.
setup
in interface Prototype
setup
in class Problem
public void prepareToEvaluate(EvolutionState state, int threadnum)
Problem
prepareToEvaluate
in class Problem
public void finishEvaluating(EvolutionState state, int threadnum)
Problem
finishEvaluating
in class Problem
public void evaluate(EvolutionState state, Individual ind, int threadnum)
SimpleProblemForm
evaluate
in interface SimpleProblemForm
public void describe(Individual ind, EvolutionState state, int threadnum, int log, int verbosity)
SimpleProblemForm
describe
in interface SimpleProblemForm
public void preprocessPopulation(EvolutionState state, Population pop)
GroupedProblemForm
preprocessPopulation
in interface GroupedProblemForm
public void postprocessPopulation(EvolutionState state, Population pop)
GroupedProblemForm
postprocessPopulation
in interface GroupedProblemForm
public void evaluate(EvolutionState state, Individual[] inds, boolean[] updateFitness, boolean countVictoriesOnly, int threadnum)
GroupedProblemForm
If countVictoriesOnly is true, you should update fitnesses such that if two individuals' fitnesses are compared, the one which has won the most times has a superior fitness. This will be used in single elimination tournament style evaluators.
evaluate
in interface GroupedProblemForm
public void initializeContacts(EvolutionState state)
initializeContacts
in class Problem
public void reinitializeContacts(EvolutionState state)
reinitializeContacts
in class Problem
public void shutdown()
Problem
shutdown
in class Problem
|
||||||||||
PREV CLASS NEXT CLASS | FRAMES NO FRAMES | |||||||||
SUMMARY: NESTED | FIELD | CONSTR | METHOD | DETAIL: FIELD | CONSTR | METHOD |