Beginners Guide Preview

BeginnersGuidePreview

BeginnersGuidePreview

BeginnersGuidePreview

BeginnersGuidePreview

BeginnersGuidePreview

User Manual: Pdf

Open the PDF directly: View PDF PDF.
Page Count: 110 [warning: Documents this large are best viewed by clicking the View PDF Link!]

Beginner’s Guide to the MOEA
Framework
David Hadka
For version 2.12 and later.
ii
Thank you for downloading the MOEA Framework. This is a preview of the Beginner's Guide to the
MOEA Framework. This preview provides access to introductory materials. Please consider purchasing the
complete guide using the link below to access the advanced topics and help fund the hosting, maintenance,
and continued development of this software.
Buy Online
Copyright 2011-2016 David Hadka. All Rights Reserved.
Thank you for purchasing this book! All revenue received from book sales helps fund the
continued development and maintenance of the MOEA Framework. We sincerely appreciate
your support and hope you find this software useful in your endeavors.
iii
iv
Contents
1 Background 1
1.1 MultiobjectiveProblem.............................. 3
1.2 ParetoOptimality................................. 4
1.3 Multiobjective Evolutionary Algorithms . . . . . . . . . . . . . . . . . . . . 5
1.4 MeasuringQuality ................................ 8
1.5 TheMOEAFramework.............................. 14
1.6 GettingHelp ................................... 15
2 Setup and First Example 17
2.1 InstallingJava................................... 17
2.2 InstallingEclipse ................................. 17
2.3 Setting up the MOEA Framework . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 YourFirstExample................................ 20
2.5 Running from Command Line . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.6 PlottingResults.................................. 26
3 Constrained Optimization 29
3.1 Constrained Optimization Example . . . . . . . . . . . . . . . . . . . . . . . 30
3.2 TheKnapsackProblem.............................. 33
3.3 Feasibility ..................................... 39
4 Choice of Optimization Algorithm 41
4.1 Running Different Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Parameterization ................................. 43
4.3 ComparingAlgorithms.............................. 47
4.4 RuntimeDynamics ................................ 52
5 Customizing Algorithms 57
5.1 Manually Running Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2 CustomInitialization............................... 59
5.3 CustomAlgorithms................................ 62
5.4 Creating Service Providers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.5 Hyperheuristics .................................. 67
v
5.6 Custom Types and Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.7 LearningtheAPI................................. 77
6 The Diagnostic Tool 79
6.1 Using the Diagnostic Tool . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.2 Adding Custom Algorithms . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.3 AddingCustomProblems ............................ 88
7 Subsets, Permutations, and Programs 91
7.1 Subsets....................................... 91
7.2 Permutations ................................... 94
7.3 Programs ..................................... 97
7.3.1 Type-based Rule System . . . . . . . . . . . . . . . . . . . . . . . . . 97
7.3.2 Defining the Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.3.3 CustomOperators ............................ 105
7.3.4 AntProblem ............................... 106
8 Integers and Mixed Integer Programming 109
8.1 TwoRepresentations ............................... 109
8.2 Mixed Integer Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9 I/O Basics 117
9.1 PrintingSolutions................................. 117
9.2 Files ........................................ 119
9.3 Checkpoints.................................... 120
9.4 Creating Reference Sets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
10 Performance Enhancements 125
10.1Multithreading .................................. 125
10.2 Termination Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
10.3NativeCompilation................................ 130
10.4StandardI/O ................................... 133
10.5 A Note on Concurrency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
11 Single Objective Optimization 137
11.1 Single Objective Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
11.2 Multiobjective Problems with Weights . . . . . . . . . . . . . . . . . . . . . 140
11.3 Repeated Single Objectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A List of Algorithms 145
A.1 Multiobjective Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.1.1 CMA-ES.................................. 145
A.1.2 DBEA................................... 146
A.1.3 -MOEA.................................. 146
vi
A.1.4 -NSGA-II................................. 147
A.1.5 GDE3 ................................... 147
A.1.6 IBEA ................................... 148
A.1.7 MOEA/D ................................. 148
A.1.8 MSOPS .................................. 149
A.1.9 NSGA-II.................................. 149
A.1.10NSGA-III ................................. 150
A.1.11OMOPSO................................. 150
A.1.12PAES ................................... 151
A.1.13PESA-II.................................. 151
A.1.14Random.................................. 151
A.1.15RSO .................................... 152
A.1.16RVEA ................................... 152
A.1.17SMPSO .................................. 152
A.1.18SMS-EMOA................................ 153
A.1.19SPEA2................................... 153
A.1.20VEGA................................... 153
A.2 Single-Objective Optimizers . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
A.2.1 GA..................................... 154
A.2.2 ES ..................................... 154
A.2.3 DE..................................... 154
B Additional Algorithms 155
B.1 JMetalAlgorithms ................................ 155
B.1.1 CellDE................................... 157
B.1.2 DENSEA ................................. 157
B.1.3 FastPGA ................................. 158
B.1.4 MOCell .................................. 158
B.1.5 MOCHC.................................. 158
B.2 PISAAlgorithms ................................. 159
B.2.1 Adding a PISA Selector . . . . . . . . . . . . . . . . . . . . . . . . . 160
B.2.2 Troubleshooting.............................. 161
C List of Variation Operators 163
C.1 Real-Valued Operators . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
C.2 Binary / Bit String Operators . . . . . . . . . . . . . . . . . . . . . . . . . . 168
C.3 Permutations ................................... 169
C.4 Subsets....................................... 169
C.5 Grammars..................................... 170
C.6 ProgramTree ................................... 170
C.7 GenericOperators ................................ 170
D List of Problems 173
vii
E Errors and Warning Messages 187
E.1 Errors ....................................... 187
E.2 Warnings ..................................... 196
Bibliography 201
viii
Chapter 1
Background
Optimization is the process of identifying the best solution among a set of alternatives (Miet-
tinen, 1999). Whereas single objective optimization employs a single criterion for identifying
the best solution among a set of alternatives, multiobjective optimization employs two or
more criteria. The criteria used to compare solutions are known as objectives. As multiple
objectives can conflict with one another — i.e., improving one objective leads to the deterio-
ration of another — there is, generally speaking, no single optimal solution to multiobjective
problems.
As an example, Figure 1.1 shows the tradeoff between two objectives: (1) cost and (2)
error. The shaded region depicts the set of candidate solutions to this hypothetical problem.
The top-left region contains low cost, high error candidate solutions. The bottom-right
region contains high cost, low error candidate solutions. Between these two extremes lie
the various degrees of tradeoff between the two objectives, where increases in cost lead to
reduced error.
Figure 1.1 demonstrates a fundamental issue in multiobjective optimization. Given that
there is no single optimal solution, rather a multitude of potential solutions with varying
degrees of tradeoff between the objectives, decision-makers are subsequently responsible for
exploring this set of potential solutions and identifying the solution(s) to be implemented.
While ultimately the selection of the final solution is the responsibility of the decision-
maker, optimization tools should assist this decision process to the best of their ability.
For instance, it may prove useful to identify points of diminishing returns. For example,
Figure 1.2 identifies the region where a large increase in cost is necessary to impart a marginal
decrease in error. To perform this type of analysis, it is necessary to provide the decision-
maker with an enumeration or approximation of these tradeoffs. This strategy of enumerating
or approximating the tradeoffs is known as a posteriori optimization (Coello Coello et al.,
2007), and is the focus of this book.
1
Error
Cost
Low cost
High error
High cost
Low error
Tradeo
Figure 1.1: Example of the tradeoff between two objectives: (1) cost and (2) error. A tradeoff
is formed between these two conflicting objectives where increases in cost lead to reduced
error. All figures in this dissertation showing objectives include arrows pointing towards the
ideal optimum.
Error
Cost
Figure 1.2: Example showing the effect of diminishing returns, where a large increase in cost
is necessary to impart a marginal reduction in error.
2
Error
Cost
Infeasible Region
Feasible Region
Error < ξ
Figure 1.3: Example showing how constraints define an infeasible region (the hashed region).
Valid solutions to the optimization problem are only found in the feasible region.
1.1 Multiobjective Problem
We can express the idea of a multiobjective problem (MOP) with Mobjectives formally as:
minimize
xF(x) = (f1(x), f2(x), . . . , fM(x))
subject to ci(x) = 0,i∈ E,
cj(x)0,j∈ I.
(1.1)
We call xthe decision variables, which is the vector of variables that are manipulated
during the optimization process:
x=
x1
x2
.
.
.
xL
(1.2)
Decision variables can be defined in a variety of ways, but it is common to see the following
types (B¨ack et al., 1997):
Real-Valued: 2.71
Binary: 001100010010100001011110101101110011
Permutation: 4,2,0,1,3
In some applications, it is possible for the number of decision variables, L, to not be a fixed
value. In this book, however, we assume that Lis constant for a given problem.
The decision space, Ω, is the set of all decision variables. The MOP may impose restric-
tions on the decision space, called constraints. As an example, in Figure 1.3, a hypothetical
3
f2(x)
f1(x)
DominatedNon-Dominated
Non-DominatedDominating
Figure 1.4: Depiction of the various Pareto dominance regions. These regions are relative
to each solution, which is centered in the figure. The dominated region is inferior in all
objectives, the dominating region is superior in all objectives and the non-dominated region
is superior in one objective but inferior in the other.
constraint would prevent any solutions from exceeding an error threshold. In this manner,
constraints inform the optimization process as to which solutions are infeasible or imprac-
tical. Equation (1.1) shows that zero or more constraints ci(x) can be defined to express
both equality and inequality constraints. The sets Eand Idefine whether the constraint is
an equality or inequality constraint. The set of all decision variables in Ω which are feasible
(i.e., satisfy all constraints) define the feasible region, Λ.
1.2 Pareto Optimality
The notion of optimality used today is adopted from the work of Francis Ysidro Edgeworth
and Vilfredo Pareto (Coello Coello et al., 2007), and is commonly referred to as Pareto
optimality. Pareto optimality considers solutions to be superior or inferior to another solution
only when it is superior in all objectives or inferior in all objectives, respectively. The
tradeoffs in an MOP are captured by solutions which are superior in some objectives but
inferior in others. Such pairs of solutions which are both superior and inferior with respect
to certain objectives are called non-dominated, as shown in Figure 1.4. More formally, the
notion of Pareto optimality is defined by the Pareto dominance relation:
Definition 1 A vector u= (u1, u2, . . . , uM)Pareto dominates another vector v=
(v1, v2, . . . , vM)if and only if i∈ {1,2, . . . , M}, uiviand j∈ {1,2, . . . , M}, uj< vj.
This is denoted by uv.
Two solutions are non-dominated if neither Pareto dominates the other (i.e., uvand
vu). The set of all non-dominated solutions is captured by the Pareto optimal set and
4
f(x)
f(x)
Variable 1
Variable 2
Variable 3
Pareto Optimal Set Pareto Front
Figure 1.5: Shows a hypothetical mapping between a 3-dimensional Pareto optimal set and
its associated 2-dimensional Pareto front. The shaded region in the Pareto front shows the
space dominated by the Pareto front.
the Pareto front. The former contains the decision variables while the latter contains the
objectives.
Definition 2 For a given multiobjective problem, the Pareto optimal set is defined by
P={x| ¬∃x0Λ, F (x0)F(x)}
Definition 3 For a given multiobjective problem with Pareto optimal set P, the Pareto
front is defined by
PF={F(x)|x∈ P}
In this dissertation, the Pareto dominance relation is applied to the objectives. For
convenience, we use xyinterchangeably with F(x)F(y).
Figure 1.5 shows an example Pareto optimal set and Pareto front, and the resulting
mapping between the two. The Pareto optimal set defines the decision variables, whereas
the Pareto front captures the objectives and their tradeoffs via Pareto optimality.
1.3 Multiobjective Evolutionary Algorithms
Evolutionary algorithms (EAs) are a class of search and optimization algorithms inspired
by processes of natural evolution (Holland, 1975). A broad overview of the design and
development of EAs is provided in B¨ack et al. (1997). The outline of a simple EA is shown
5
Selection of Parents
Recombination
Survival / Replacement
Initialization
Termination
Loop Until Termination
Figure 1.6: The outline of a simple EA. EAs begin with an initialization process, where the
initial search population is generated. They next enter a loop of selecting parent individuals
from the search population, applying a recombination operator (such as crossover and muta-
tion in genetic algorithms) to generate offspring, and finally updating the search population
with these offspring using a replacement strategy. This loop is repeated until some termina-
tion condition is met, usually after a fixed number of objective function evaluations (NFE).
Upon termination, the EA reports the set of optimal solutions discovered during search.
6
in Figure 1.6. EAs begin with an initialization process, where the initial search population is
generated. They next enter a loop of selecting parent individuals from the search population,
applying a recombination operator to generate offspring, and finally updating the search
population with these offspring using a replacement strategy. This loop is repeated until some
termination condition is met, usually after a fixed number of objective function evaluations
(NFE). Upon termination, the EA reports the set of optimal solutions discovered during
search.
The behavior of the selection, recombination and survival/replacement processes typically
depend on the “class” of EA. For instance, genetic algorithms (GAs) apply crossover and
mutation operators that mimic genetic reproduction via DNA (Holland, 1975). Particle
swarm optimization (PSO) algorithms simulate flocking behavior, where the direction of
travel of each individual is steered towards the direction of travel of surrounding individuals
(Kennedy and Eberhart, 1995). While the behavior of each class may be vastly different,
they all share a common attribute of utilizing a search population.
Their ability to maintain a population of diverse solutions makes EAs a natural choice
for solving MOPs. Early attempts at solving MOPs involved using aggregation-based ap-
proaches (B¨ack et al., 1997). In aggregation-based approaches, the decision-maker defines an
aggregate fitness function that transforms the MOP into a single objective problem, which
can subsequently be solved with an EA. Two commonly-used aggregate fitness functions are
linear weighting:
FL(x) =
M
X
i=1
λifi(x),(1.3)
and the weighted Chebyshev method:
FT(x) = max
i=1,2,...,M (λi|z
ifi(x)|),(1.4)
where λ= (λ1, λ2, . . . , λM) are the weights and z= (z
1, z
2, . . . , z
M) is a reference point
identifying the decision-maker’s goal (note: this reference point need not be a feasible solu-
tion).
Coello Coello et al. (2007) discusses the advantages and disadvantages of aggregate fit-
ness approaches. The primary advantage is the simplicity of the approach and the ability to
exploit existing EAs to solve MOPs. In addition, appropriately defined aggregate fitness func-
tions can provide very good approximations of the Pareto front. However, poorly-weighted
aggregate fitness functions may be unable to find non-convex regions of the Pareto front.
This is problematic since selecting appropriate weights is non-trivial, especially if the rela-
tive worth of each objective is unknown or difficult to quantify. Lastly, in order to generate
multiple Pareto optimal solutions, aggregate fitness approaches need to be run with differing
weights to generate solutions across the entire Pareto front.
These limitations lead to the development of multiobjective evolutionary algorithms
(MOEAs) that search for multiple Pareto optimal solutions in a single run. The first MOEA
to search for multiple Pareto optimal solutions, the Vector Evaluated Genetic Algorithm
(VEGA), was introduced by Schaffer (1984). VEGA was found to have problems similar
7
to aggregation-based approaches, such as an inability to generate concave regions of the
Pareto front. Goldberg (1989) was first to suggest the use of Pareto-based selection, but
this concept was not applied until 1993 in the Multiobjective Genetic Algorithm (MOGA)
(Fonseca and Fleming, 1993). Between 1993 and 2003, several first-generation MOEAs were
introduced demonstrating important design concepts such as elitism, diversity maintenance
and external archiving. Notable first-generation algorithms include the Niched-Pareto Ge-
netic Algorithm (NPGA) (Horn and Nafpliotis, 1993), the Non-dominated Sorting Genetic
Algorithm (NSGA) (Srinivas and Deb, 1994), the Strength Pareto Evolutionary Algorithm
(SPEA) (Zitzler and Thiele, 1999), the Pareto-Envelope based Selection Algorithm (PESA)
(Corne and Knowles, 2000) and the Pareto Archived Evolution Strategy (PAES) (Knowles
and Corne, 1999). Many of these MOEAs have since been revised to incorporate more
efficient algorithms and improved design concepts. To date, Pareto-based approaches out-
number aggregate fitness approaches (Coello Coello et al., 2007). For a more comprehensive
overview of the historical development of MOEAs, please refer to the text by Coello Coello
et al. (2007).
1.4 Measuring Quality
When running MOEAs on a MOP, the MOEA outputs an approximation of the Pareto op-
timal set and Pareto front. The approximation of the Pareto front, called the approximation
set, can be used to measure the quality of an MOEA on a particular problem. In some situa-
tions, such as with contrived test problems, a reference set of the globally optimal solutions
may be known. If known, the reference set can be used to measure the absolute performance
of an MOEA. If not known, the approximation sets from multiple MOEAs can be compared
to determine their relative quality.
There is no consensus in the literature of the appropriate procedure with which to com-
pare approximation sets. These procedures, called performance metrics, come in two forms:
(1) unary and (2) binary performance metrics (Zitzler et al., 2002c). Unary performance
metrics produce a single numeric value with which to compare approximation sets. Unary
performance metrics have the advantage of permitting the comparison of approximation sets
without requiring the actual approximation set, as one need only compare the numeric val-
ues. Binary performance metrics, on the other hand, compare pairs of approximation sets,
identifying which of the two approximation sets is superior. In order to allow comparisons
across studies, this book uses only unary performance metrics.
Zitzler et al. (2002b) contend that the number of unary performance metrics required to
determine if one approximation set is preferred over another must be at least the number
of objectives in the problem. Because different MOEAs tend to perform better in different
metrics (Bosman and Thierens, 2003), Deb and Jain (2002) suggest only using metrics for the
two main functional objectives of MOEAs: proximity and diversity. The following outlines
several of the commonly-used unary performance metrics. For details of these performance
metrics see Coello Coello et al. (2007).
8
f2(x)
f1(x)
Reference Point
Approximation Set
Hypervolume
Figure 1.7: Hypervolume measures the volume of the space dominated by the approximation
set, bounded by a reference point. This reference point is typically the nadir point (i.e., the
worst-case value for each objective) of the reference set plus some fixed delta. This delta
ensures extremal points contribute non-zero hypervolume.
Hypervolume As shown in Figure 1.7, the hypervolume metric computes the volume of
the space dominated by the approximation set. This volume is bounded by a reference point,
which is usually set by finding the nadir point (i.e., the worst-case objective value for each
objective) of the reference set plus some fixed increment. This fixed increment is necessary
to allow the extremal points in the approximation set to contribute to the hypervolume.
Knowles and Corne (2002) suggest the hypervolume metric because it is compatible with
the outperformance relations, scale independent, intuitive, and can reflect the degree of
outperformance between two approximation sets.
The major disadvantage of the hypervolume metric is its runtime complexity of O(nM1),
where nis the size of the non-dominated set. However, Beume and Rudolph (2006) provide
an implementation with runtime O(nlog n+nM/2) based on the Klee’s measure algorithm
by Overmars and Yap. This implementation permits computing the hypervolume metric
on moderately sized non-dominated sets up to M= 8 objectives in a reasonable amount of
time. Further improvements by While et al. (2012) improve the expected runtime further,
allowing the efficient calculation of hypervolume with ten or more objectives.
Generational Distance Generational distance (GD) is the average distance from every
solution in the approximation set to the nearest solution in the reference set, as shown
in Figure 1.8. As such, it measures proximity to the reference set. GD by itself can be
misleading, as an approximation set containing a single solution in close proximity to the
reference set produces low GD measurements, and is often combined with diversity measures
in practice (Hadka and Reed, 2012).
9
Figure 1.8: Generational distance is the average distance from every solution in the approx-
imation set to the nearest solution in the reference set.
Figure 1.9: Inverted generational distance is the average distance from every solution in the
reference set to the nearest solution in the approximation set.
10
f2(x)
f1(x)
Reference Set
Approximation Set
Distance Measurement
Maximum
Translation
Distance
Figure 1.10: +-indicator (also known as the additive -indicator) is the smallest distance
that the approximation set must be translated by in order to completely dominate the
reference set (Coello Coello et al., 2007).
Inverted Generational Distance As its name indicates, the inverted generational dis-
tance (IGD) is the inverse of GD — it is the average distance from every solution in the
reference set to the nearest solution in the approximation set. IGD measures diversity, as
shown in Figure 1.9, since an approximation set is required to have solutions near each
reference set point in order to achieve low IGD measurements (Coello Coello et al., 2007).
+-Indicator The additive -indicator (+-indicator) measures the smallest distance that
the approximation set must be translated by in order to completely dominate the reference
set, as shown in Figure 1.10. One observes that good proximity and good diversity both
result in low values, as the distance that the approximation needs to be translated is
reduced. However, if there is a region of the reference set that is poorly approximated by
the solutions in the approximation set, a large is required. Therefore, we claim the +-
indicator measures the consistency of an approximation set (Hadka and Reed, 2013). An
approximation set must be free from large gaps or regions of poor approximation in order to
be consistent.
Spacing Spacing, shown in Figure 1.11, measures the uniformity of the spacing between
solutions in an approximation set (Coello Coello et al., 2007). An approximation set that is
well-spaced will not contain dense clusters of solutions separated by large empty expanses.
Note that, since spacing does not involve a reference set in its calculation, an approximation
can register good spacing while having poor proximity to the reference set. It is therefore
recommended to use spacing in conjunction with a performance metric for proximity.
In academic works, it is common to see results published using GD, hypervolume and
+-indicator. These three metrics record proximity, diversity and consistency, respectively,
11
Figure 1.11: Spacing measures the uniformity of the spacing between solutions in an approx-
imation set.
which we claim are the three main functional objectives of MOEAs (Fonseca and Fleming,
1996). Figure 1.12 provides a graphical representation of the importance of the +-indicator
and consistency. MOEAs are expected to produce high-quality solutions covering the entire
extent of the tradeoff surface, with few gaps or regions of poor approximation.
In order to report these performance metrics consistently, all performance metrics are
normalized. This normalization converts all performance metrics to reside in the range
[0,1], with 1 representing the optimal value. First, the reference set is normalized by its
minimum and maximum bounds so that all points in the reference set lie in [0,1]N, the N-
dimensional unit hypercube. Second, each approximation set is normalized using the same
bounds. Third, the performance metrics are calculated using these normalized sets. Finally,
the performance metrics are transformed by the following equations to ensure a value of 1
represents the optimal value achievable by the metric. Hypervolume is transformed with:
M(As
p) = c
M(As
p)/M,(1.5)
where c
Mrepresents the raw metric value. GD and the +-indicator are transformed with:
M(As
p) = max(1 c
M(As
p),0).(1.6)
When solving test problems, the reference set is known analytically. For most real-world
problems, however, the reference set is not available. In these situations, it is often necessary
to construct a reference set from the union of all approximation sets generated during exper-
imentation. Then, performance metrics can be evaluated relative to this combined reference
set.
12
(a)
Average
Distance
(b)
(c) (d)
Figure 1.12: Demonstrates the importance of -indicator as a measure of consistency. (a) A
good approximation set to the reference set, indicated by the dashed line. (b) Generational
distance averages the distance between the approximation set and reference set, reducing
the impact of large gaps. The missing points are shaded light gray. (c) The change in
hypervolume due to a gap is small relative to the entire hypervolume. (d) -Indicator easily
identifies the gap, reporting a metric 2-3 times worse in this example.
13
1.5 The MOEA Framework
The MOEA Framework is a free and open source Java library for developing and experi-
menting with multiobjective evolutionary algorithms (MOEAs) and other general-purpose
optimization algorithms. We will be using the MOEA Framework throughout this book to
explore multiobjective optimization. Its key features includes:
Fast, reliable implementations of many state-of-the-art multiobjective evo-
lutionary algorithms. The MOEA Framework contains internally NSGA-II, NSGA-
III, -MOEA, -NSGA-II, PAES, PESA2, SPEA2, IBEA, SMS-EMOA, GDE3, SMPSO,
OMOPSO, CMA-ES, and MOEA/D. These algorithms are optimized for performance, mak-
ing them readily available for high performance applications. By also supporting the JMetal
and PISA libraries, the MOEA Framework provides access to 30 multiobjective optimization
algorithms.
Extensible with custom algorithms, problems and operators. The MOEA Frame-
work provides a base set of algorithms, test problems and search operators, but can also be
easily extended to include additional components. Using a Service Provider Interface (SPI),
new algorithms and problems are seamlessly integrated within the MOEA Framework.
Modular design for constructing new optimization algorithms from existing com-
ponents. The well-structured, object-oriented design of the MOEA Framework library
allows combining existing components to construct new optimization algorithms. And if
needed functionality is not available in the MOEA Framework, you can always extend an
existing class or add new classes to support any desired feature.
Permissive open source license. The MOEA Framework is licensed under the free and
open GNU Lesser General Public License, version 3 or (at your option) any later version.
This allows end users to study, modify, and distribute the MOEA Framework freely.
Fully documented source code. The source code is fully documented and is frequently
updated to remain consistent with any changes. Furthermore, an extensive user manual is
provided detailing the use of the MOEA Framework in detail.
Extensive support available online. As an actively maintained project, bug fixes and
new features are constantly added. We are constantly striving to improve this product. To
aid this process, our website provides the tools to report bugs, request new features, or get
answers to your questions.
Over 1200 test cases to ensure validity. Every release of the MOEA Framework un-
dergoes extensive testing and quality control checks. And, if any bugs are discovered that
survive this testing, we will promptly fix the issues and release patches.
14
1.6 Getting Help
This beginner’s guide is the most comprehensive resource for learning about the MOEA
Framework. Additional resources are available on our website at http://www.
moeaframework.org. This website also has links to file bugs or request new fea-
tures. If you still can not find an answer to your question, feel free to contact us at
support@moeaframework.org.
15
16
Chapter 2
Setup and First Example
In this chapter, we will setup the MOEA Framework on your computer and demonstrate a
simple example. These instructions are tailored for Windows users, but similar steps can be
taken to install the MOEA Framework on Linux or Mac OS.
2.1 Installing Java
The MOEA Framework runs on Java version 6 or any later version. Since we will need to
compile examples, you will need to install the Java Development Kit (JDK) for version 6 or
later. For Windows users, we recommend using Oracle’s JDK available at http://www.
oracle.com/technetwork/java/javase/. Make sure you download the JDK and
not the JRE (Java Runtime Environment).
2.2 Installing Eclipse
If this is your first time using the MOEA Framework, we suggest using Eclipse to build
projects. Eclipse is a free development environment for writing, debugging, testing, and
running Java programs. First, download Eclipse from http://www.eclipse.org/. To
install Eclipse, simply extract the ZIP archive to a location on your computer (e.g., your
desktop). Within the extracted folder, run eclipse.exe. First-time users of Eclipse
may be prompted to select a workspace location. The default location is typically fine. Click
the checkbox to no longer show this dialog and click Ok.
2.3 Setting up the MOEA Framework
We recommend starting with this book’s supplemental materials, which includes a full instal-
lation of the MOEA Framework and all of the code samples found in this book. The supple-
mental materials can be downloaded by following this link: <Link Removed in Preview>.
17
Note: that ends with the letter O and not the number 0. As you read this book, find the
appropriate Java file within the book folder to follow along.
Alternatively, you can download the MOEA Framework’s compiled binaries from http:
//www.moeaframework.org/ and manually type in the examples. The compiled binaries
are distributed as a compressed TAR file (.tar.gz) and need to be extracted. We recommend
using 7-Zip, a free and open source program, which can be downloaded from http://www.
7-zip.org/. Extract to your Desktop or any other convenient location.
Next, we need to create a project within Eclipse. Select File New Java Project from
the menu.
In the window that appears, uncheck ”Use default location”. Click the ”Browse...” button
and select the extracted MOEA Framework folder. Click Finish.
18
The MOEA Framework project will now appear within the ”Package Explorer” in Eclipse,
as shown below.
If you are using the supplemental materials, you can skip down to the next section titled
“Your First Example.” Otherwise, we will now create a source folder were our examples will
reside. Right-click on the project and select New Source Folder.
19
Give the new source folder the name ”book” and click Finish.
2.4 Your First Example
In Java, packages are used to organize source code into a hierarchical structure. We will
organize the examples from each chapter into its own package. Thus, for the first chapter,
we will create a package named chapter2. Right-click on the source folder we just created
and select New Package.
20
Enter the name chapter2 and click Finish.
Finally, we create the Java file for the actual code. In Java, these are called classes. Right-
click the chapter2 folder and select New Class.
21
Type the name SchafferProblem and click Finish.
At this point, your Eclipse workspace will contain one Java file named
SchafferProblem.java and that file will be opened in the text editor within
Eclipse, as shown below.
22
Now we can begin defining the problem.
1package chapter2;
2
3import org.moeaframework.core.Solution;
4import org.moeaframework.core.variable.EncodingUtils;
5import org.moeaframework.problem.AbstractProblem;
6
7public class SchafferProblem extends AbstractProblem {
8
9public SchafferProblem() {
10 super(1, 2);
11 }
12
13 @Override
14 public void evaluate(Solution solution) {
15 double x = EncodingUtils.getReal(solution.getVariable(0));
16
17 solution.setObjective(0, Math.pow(x, 2.0));
18 solution.setObjective(1, Math.pow(x - 2.0, 2.0));
19 }
20
21 @Override
22 public Solution newSolution() {
23 Solution solution = new Solution(1, 2);
24 solution.setVariable(0, EncodingUtils.newReal(-10.0, 10.0));
25 return solution;
26 }
27
28 }
MOEAFramework/book/chapter2/SchafferProblem.java
23
The anatomy of a problem is as follows. First, it must implement the Problem inter-
face. Rather that implement the Problem interface directly, it is often more convenient
to extend the AbstractProblem class, as seen on Line 7. Three methods are required
when extending AbstractProblem: the constructor, newSolution, and evaluate.
The constructor, shown on lines 9-11, is responsible for initializing the problem. For this
problem, we call super(1, 2) to indicate this problem will consist of one decision variable
and two objectives. The newSolution method, shown on lines 14-18, generates a proto-
type solution for the problem. A prototype solution describes each decision variable, and
were applicable, any bounds on the variables. For this problem, we create a single real-valued
decision variable bounded by [10,10]. Thus, on line 15 we create the prototype solution
with one variable and two objectives (e.g., new Solution(1, 2)), assign the variable
on line 16 (e.g., solution.setVariable(0, EncodingUtils.newReal(-10.0,
10.0));), and return the solution on line 17. Finally, we define the evaluate method on
lines 21-26, which is responsible for computing the objectives for a given candidate solution.
On line 22, we read the value of the decision variable (e.g., EncodingUtils.getReal(
solution.getVariable(0))), and on lines 24 and 25 evaluate the two objectives. For
the Schaffer problem, the two objectives are f1(x) = x2and f2(x)=(x2)2. Type this
code into the SchafferProblem.java file and save.
At this point, the problem is defined, but we also need to create the code to solve the
problem. To begin, create a new class called RunSchafferProblem with the following
code:
1package chapter2;
2
3import org.moeaframework.Executor;
4import org.moeaframework.core.NondominatedPopulation;
5import org.moeaframework.core.Solution;
6import org.moeaframework.core.variable.EncodingUtils;
7
8public class RunSchafferProblem {
9
10 public static void main(String[] args) {
11 NondominatedPopulation result = new Executor()
12 .withAlgorithm("NSGAII")
13 .withProblemClass(SchafferProblem.class)
14 .withMaxEvaluations(10000)
15 .run();
16
17 for (Solution solution : result) {
18 System.out.printf("%.5f => %.5f, %.5f\n",
19 EncodingUtils.getReal(solution.getVariable(0)),
20 solution.getObjective(0),
21 solution.getObjective(1));
22 }
23 }
24
25 }
24
MOEAFramework/book/chapter2/RunSchafferProblem.java
On line 10, we create a the main method. In Java, main methods are the starting points
for applications. This is the first method that is invoked when we run the application. To
solve our problem, we will use the Executor class. The executor is responsible for creating
instances of optimization algorithms and using them to solve problems. It is a sophisticated
class, but at the bare minimum it requires three pieces of information: 1) the name of the
optimization algorithm, 2) the problem, and 3) the maximum number of function evaluations
(NFE) permitted to solve the problem. We set the values on lines 12-14 and call run() on
line 15 to solve the problem. The result, a Pareto approximation set, is saved on line 10 to
aNondominatedPopulation. Lines 17-22 format and print the Pareto approximate set
to the screen. Each line on the output is a Pareto approximate solution where the left-most
value is the decision variable and the two values to the right of => are the objective values.
Run this application by right-clicking the file RunSchafferProblem.java and se-
lecting Run Java Application.
The output will appear in the Console within Eclipse and should appear similar to below.
25
Congratulations, you have just successfully optimized a problem using the MOEA Frame-
work!
2.5 Running from Command Line
If you are not using Eclipse to run these examples, they can also be run manually from
the command line. On Windows, open a new Command Prompt window and change the
directory to the MOEA Framework folder. Then type the following commands:
javac -cp "lib/*;book" book/chapter2/SchafferProblem.java
javac -cp "lib/*;book" book/chapter2/RunSchafferProblem.java
java -cp "lib/*;book" chapter2.RunSchafferProblem
The first two lines compile the two class files we created. Note the use of the -cp "
lib/*;book" argument that specifies the Java classpath. This tells Java where to locate
any referenced files. We will be referencing files in the lib folder, which contains all of the
MOEA Framework libraries, and the book folder, which contains the files we are compiling.
The last line runs the example. We again must specify the classpath, but note that we are
running the class chapter2.RunShafferProblem. This is the full class path for our
problem. It consists of the package (e.g., chapter2), followed by a period, followed by the
class name (e.g., RunSchafferProblem).
2.6 Plotting Results
In the previous example, we output the two objectives to the console. Outputting the raw
data like this is useful as you can save the data to a text file, load the data into Excel, etc.
For problems like this with only two objectives, we can plot the solutions as points in a
scatter plot, as shown below:
1package chapter2;
2
3import org.moeaframework.Executor;
4import org.moeaframework.analysis.plot.Plot;
5import org.moeaframework.core.NondominatedPopulation;
6
26
7public class PlotSchafferProblem {
8
9public static void main(String[] args) {
10 NondominatedPopulation result = new Executor()
11 .withAlgorithm("NSGAII")
12 .withProblemClass(SchafferProblem.class)
13 .withMaxEvaluations(10000)
14 .run();
15
16 new Plot()
17 .add("NSGAII", result)
18 .show();
19 }
20
21 }
MOEAFramework/book/chapter2/PlotSchafferProblem.java
Running this code produces the following plot:
Now we can see the shape of the Pareto approximation set produced by the optimization
algorithm.
27
28
Chapter 3
Constrained Optimization
In the previous chapter, we solved the two objective Schaffer problem. This was an un-
constrained problem, meaning that any solution we generate is a feasible design. Many
real-world problems have constraints, either caused by physical limitations (e.g., maximum
operating temperature), monetary (e.g., available capital), are risk-based (e.g., maximum
failure rate for a product), etc. In general, there are two types of constraints: equality and
inequality. Equality constraints are of the form g(x) = cfor some constant c. Inequality
constraints are of the form h(x)dfor some constant d. For example, takes the Srinivas
problem as defined below.
On the left, we see the two objective functions that we are minimizing. On the right, we
have the constraints. Note they are all inequality constraints.
The MOEA Framework represents constraints a bit differently. Instead of needing to
know the constraint formula, the MOEA Framework simply says “set the constraint value
to 0 if the solution is feasible, set it to any non-zero value if the constraint is violated.” For
example, take the constraint 0 x3y+ 10. You would typically express this constraint
within the MOEA Framework using the ternary if-else expression x-3y+10<=0?
0:x-3y+10. This expression begins with the comparator x-3y+10<=0
that tests if the constraint is satisfied. If satisfied, the resulting is 0. Otherwise, the result is
x-3y+10. Why do we set the value to x-3y+10when the constraint is violated?
It is useful in optimization to know how far a solution is from the feasibility boundary. By
setting the constraint value to smaller values the closer a solution likes in proximity to the
feasibility boundary, the optimization algorithm can guide search towards the feasible region.
For the Srinivas problem, we would evaluate the problem as follows:
1public void evaluate(Solution solution) {
2double x = EncodingUtils.getReal(solution.getVariable(0));
29
3double y = EncodingUtils.getReal(solution.getVariable(1));
4double f1 = Math.pow(x - 2.0, 2.0) + Math.pow(y - 1.0, 2.0) + 2.0;
5double f2 = 9.0*x - Math.pow(y - 1.0, 2.0);
6double c1 = Math.pow(x, 2.0) + Math.pow(y, 2.0) - 225.0;
7double c2 = x - 3.0*y + 10.0;
8
9solution.setObjective(0, f1);
10 solution.setObjective(1, f2);
11 solution.setConstraint(0, c1 <= 0.0 ? 0.0 : c1);
12 solution.setConstraint(1, c2 <= 0.0 ? 0.0 : c2);
13 }
Lets try another example. Suppose we have the constraint x2+y10. The trick here
is to remember that we want to assign non-zero values when the constraint is violated. It is
useful to convert the constraint into the form h(x)0, or x2+y10 0. The resulting
constraint calculation would be:
1double c = Math.pow(x, 2.0) + y - 10;
2solution.setConstraint(0, c <= 0.0 ? 0.0 : c);
Great! You’ll probably notice that there is an additional constraint in our Srinivas
problem: 20 x, y 20. This is different from equality and inequality constraints because
these are constraints placed on the decision variables. In the MOEA Framework, we do not
need to explicitly specify this as a constraint. As shown below, we set these bounds when
defining the decision variables.
1public Solution newSolution() {
2Solution solution = new Solution(2, 2, 2);
3
4solution.setVariable(0, EncodingUtils.newReal(-20.0, 20.0));
5solution.setVariable(1, EncodingUtils.newReal(-20.0, 20.0));
6
7return solution;
8}
3.1 Constrained Optimization Example
Ok, now we can fully define the constrained Srinivas problem. From the problem statement,
we see that the Srinivas problem has two decision variables, two objectives, and two con-
straints. The two decision variables are real-valued and bounded by [20,20]. The equations
for the objectives and constraints are given.
30
Within Eclipse, create a new package named chapter3 and create the class
SrinivasProblem. Enter the following code:
1package chapter3;
2
3import org.moeaframework.core.Solution;
4import org.moeaframework.core.variable.EncodingUtils;
5import org.moeaframework.problem.AbstractProblem;
6
7public class SrinivasProblem extends AbstractProblem {
8
9public SrinivasProblem() {
10 super(2, 2, 2);
11 }
12
13 @Override
14 public void evaluate(Solution solution) {
15 double x = EncodingUtils.getReal(solution.getVariable(0));
16 double y = EncodingUtils.getReal(solution.getVariable(1));
17 double f1 = Math.pow(x - 2.0, 2.0) + Math.pow(y - 1.0, 2.0) + 2.0;
18 double f2 = 9.0*x - Math.pow(y - 1.0, 2.0);
19 double c1 = Math.pow(x, 2.0) + Math.pow(y, 2.0) - 225.0;
20 double c2 = x - 3.0*y + 10.0;
21
22 solution.setObjective(0, f1);
23 solution.setObjective(1, f2);
24 solution.setConstraint(0, c1 <= 0.0 ? 0.0 : c1);
25 solution.setConstraint(1, c2 <= 0.0 ? 0.0 : c2);
26 }
27
28 @Override
29 public Solution newSolution() {
30 Solution solution = new Solution(2, 2, 2);
31
32 solution.setVariable(0, EncodingUtils.newReal(-20.0, 20.0));
33 solution.setVariable(1, EncodingUtils.newReal(-20.0, 20.0));
34
35 return solution;
36 }
37
38 }
MOEAFramework/book/chapter3/SrinivasProblem.java
We already explained the components of this code. The primary difference is the addition
of the constraints. First, on lines 10 and 28, we pass in three arguments instead of two.
The third argument indicates the number of constraints (e.g., super(2, 2, 2) and new
Solution(2, 2, 2)). Secondly, on lines 23-24 we set the constraints. Again, the
constraint is 0 when a solution is feasible.
As before, we also need a class to run this example. Create the class
31
RunSrinivasProblem with the code below:
1package chapter3;
2
3import org.moeaframework.Executor;
4import org.moeaframework.core.NondominatedPopulation;
5import org.moeaframework.core.Solution;
6
7public class RunSrinivasProblem {
8
9public static void main(String[] args) {
10 NondominatedPopulation result = new Executor()
11 .withAlgorithm("NSGAII")
12 .withProblemClass(SrinivasProblem.class)
13 .withMaxEvaluations(10000)
14 .run();
15
16 for (Solution solution : result) {
17 if (!solution.violatesConstraints()) {
18 System.out.format("%10.3f %10.3f%n",
19 solution.getObjective(0),
20 solution.getObjective(1));
21 }
22 }
23 }
24
25 }
MOEAFramework/book/chapter3/RunSrinivasProblem.java
There are a few changes to this code from the previous chapter. First, on line 12 we
use the new SrinivasProblem class. Second, on line 17, we check if the solutions are
feasible prior to printing the output. Most algorithms will only store feasible solutions, but
it’s always good practice to check if a solution violates any constraints. With this code
input, you can then run the RunSrinivasProblem class and view the output. We could
alternatively plot the results for easier viewing:
1package chapter3;
2
3import org.moeaframework.Executor;
4import org.moeaframework.analysis.plot.Plot;
5import org.moeaframework.core.NondominatedPopulation;
6
7public class PlotSrinivasProblem {
8
9public static void main(String[] args) {
10 NondominatedPopulation result = new Executor()
11 .withAlgorithm("NSGAII")
12 .withProblemClass(SrinivasProblem.class)
13 .withMaxEvaluations(10000)
32
14 .run();
15
16 new Plot()
17 .add("NSGAII", result)
18 .show();
19 }
20
21 }
MOEAFramework/book/chapter3/PlotSrinivasProblem.java
which produces the following plot:
3.2 The Knapsack Problem
Ok, now for a more complex example. Have you ever heard of the famous Knapsack prob-
lem? If not, check out the Wikipedia page at http://en.wikipedia.org/wiki/
Knapsack_problem for more details. This is a famous combinatorial problem that in-
volves choosing which items to place in a knapsack to maximize the value of the items
carried without exceeding the weight capacity of the knapsack. More formally, we are given
Nitems. Each item has a profit, P(i), and weight, W(i), for i= 1,2, . . . , N. Let d(i)
represent our decision to place the i-th item in the knapsack, where d(i) = 1 if the item is
put into the knapsack and d(i) = 0 otherwise. If the knapsack has a weight capacity of C,
then the knapsack problem is defined as:
33
Maximize
N
X
i=1
d(i)P(i) such that
N
X
i=1
d(i)W(i)C
The summation on the left (which we are maximizing) calculates the total profit we gain
from the items placed in the knapsack. The summation on the right side is a constraint that
ensures the items placed in the knapsack do not exceed the weight capacity of the knapsack.
Lets make it a little more interesting, after all this is a library for multiobjective opti-
mization. Instead of having one knapsack, lets have two (in fact, this can be generalized to
any number of knapsacks). Additionally, the profit and weights vary depending on which
knapsack is holding each item. For example, an item will have a profit of $25 and a weight
of 5 pounds in the first knapsack, but will have a profit of $15 and a weight of 8 pounds in
the second knapsack. (It may seem unusual that the weight changes, but that is how the
problem is defined in the literature.) Thus, profit is now defined by P(i, j) and weight by
W(i, j), where the j= 1,2 term is the knapsack index. Lastly, each knapsack defines its own
capacity, C1and C2. Combining all of this, the multiobjective knapsack problem is formally
defined as:
Maximize PN
i=1 d(i)P(i, 1) such that PN
i=1 d(i)W(i, 1) C1and
Maximize PN
i=1 d(i)P(i, 2) such that PN
i=1 d(i)W(i, 2) C2
This problem is a bit different from the others we have seen thus far. For the knapsack
problem, we are picking items to fit into the knapsack. The bit string representation works
well for situation where we are making many yes/no decisions (yes if it is included in the
knapsack). For example, if we have 5 items, we can represent the decision to include each
item using a bit string with 5 bits. Each bit in the string corresponds to an item, and is set
to 1if the item is included and 0if the item is excluded. For instance, the bit string 00110
would place items 3 and 4 inside the knapsacks, excluding the rest. Our newSolution
method is defined as follows:
1public Solution newSolution() {
2Solution solution = new Solution(1, nsacks, nsacks);
3solution.setVariable(0, EncodingUtils.newBinary(nitems));
4return solution;
5}
Observe on line 3 how we create the bit string representation (also called a binary string)
with nitems bits. Also note that the 5 bits are contained within a single decision variable,
so we define this problem with only a single decision variable.
Now for the evaluate method. Summing up the profits is straightforward. But there
is also a constraint we must deal with. We must ensure the weight of the items does not
exceed the capacity of the knapsack. Thus, we need to sum up the weights of the selected
items and compare to the capacity. The resulting method is shown below:
34
1public void evaluate(Solution solution) {
2boolean[] d = EncodingUtils.getBinary(solution.getVariable(0));
3double[] f = new double[nsacks];
4double[] g = new double[nsacks];
5
6// calculate the profits and weights for the knapsacks
7for (int i = 0; i < nitems; i++) {
8if (d[i]) {
9for (int j = 0; j < nsacks; j++) {
10 f[j] += profit[j][i];
11 g[j] += weight[j][i];
12 }
13 }
14 }
15
16 // check if any weights exceed the capacities
17 for (int j = 0; j < nsacks; j++) {
18 if (g[j] <= capacity[j]) {
19 g[j] = 0.0;
20 }else {
21 g[j] = g[j] - capacity[j];
22 }
23 }
24
25 // negate the objectives since Knapsack is maximization
26 solution.setObjectives(Vector.negate(f));
27 solution.setConstraints(g);
28 }
Note the comment on line 25. We are negating the objective values since our objectives
are being maximized. The MOEA Framework is designed to minimize objectives. To handle
maximized objectives, simply negate the value. Minimizing the negated value is equivalent
to maximizing the original value. Take caution, however, as the output from the MOEA
Framework will include the negative values. You should always negate the outputs to restore
them to their correct sign.
Below is the full implementation of the Knapsack problem. We have configured this
instance for a simple problem with 2 knapsacks and 5 items. Copy this code into the
KnapsackProblem class.
1package chapter3;
2
3import org.moeaframework.core.Solution;
4import org.moeaframework.core.variable.EncodingUtils;
5import org.moeaframework.problem.AbstractProblem;
6import org.moeaframework.util.Vector;
7
8public class KnapsackProblem extends AbstractProblem {
35
9
10 /**
11 *The number of sacks.
12 */
13 public static int nsacks = 2;
14
15 /**
16 *The number of items.
17 */
18 public static int nitems = 5;
19
20 /**
21 *Entry {@code profit[i][j]} is the profit from including item {@code j}
22 *in sack {@code i}.
23 */
24 public static int[][] profit = {
25 {2, 5},
26 {1, 4},
27 {6, 2},
28 {5, 1},
29 {3, 3}
30 };
31
32 /**
33 *Entry {@code weight[i][j]} is the weight incurred from including item
34 *{@code j} in sack {@code i}.
35 */
36 public static int[][] weight = {
37 {3, 3},
38 {4, 2},
39 {1, 5},
40 {5, 3},
41 {5, 2}
42 };
43
44 /**
45 *Entry {@code capacity[i]} is the weight capacity of sack {@code i}.
46 */
47 public static int[] capacity = { 10, 8 };
48
49 public KnapsackProblem() {
50 super(1, nsacks, nsacks);
51 }
52
53 public void evaluate(Solution solution) {
54 boolean[] d = EncodingUtils.getBinary(solution.getVariable(0));
55 double[] f = new double[nsacks];
56 double[] g = new double[nsacks];
57
58 // calculate the profits and weights for the knapsacks
59 for (int i = 0; i < nitems; i++) {
36
60 if (d[i]) {
61 for (int j = 0; j < nsacks; j++) {
62 f[j] += profit[j][i];
63 g[j] += weight[j][i];
64 }
65 }
66 }
67
68 // check if any weights exceed the capacities
69 for (int j = 0; j < nsacks; j++) {
70 if (g[j] <= capacity[j]) {
71 g[j] = 0.0;
72 }else {
73 g[j] = g[j] - capacity[j];
74 }
75 }
76
77 // negate the objectives since Knapsack is maximization
78 solution.setObjectives(Vector.negate(f));
79 solution.setConstraints(g);
80 }
81
82 public Solution newSolution() {
83 Solution solution = new Solution(1, nsacks, nsacks);
84 solution.setVariable(0, EncodingUtils.newBinary(nitems));
85 return solution;
86 }
87
88 }
MOEAFramework/book/chapter3/KnapsackProblem.java
Next, copy the following code into the RunKnapsackProblem class.
1package chapter3;
2
3import java.io.IOException;
4
5import org.moeaframework.Executor;
6import org.moeaframework.core.NondominatedPopulation;
7import org.moeaframework.core.Solution;
8import org.moeaframework.examples.ga.knapsack.Knapsack;
9import org.moeaframework.util.Vector;
10
11 public class RunKnapsackProblem {
12
13 public static void main(String[] args) throws IOException {
14 NondominatedPopulation result = new Executor()
15 .withProblemClass(Knapsack.class)
16 .withAlgorithm("NSGAII")
17 .withMaxEvaluations(10000)
18 .distributeOnAllCores()
37
19 .run();
20
21 for (int i = 0; i < result.size(); i++) {
22 Solution solution = result.get(i);
23 double[] objectives = solution.getObjectives();
24
25 // negate objectives to return them to their maximized form
26 objectives = Vector.negate(objectives);
27
28 System.out.println("Solution " + (i+1) + ":");
29 System.out.println(" Sack 1 Profit: " + objectives[0]);
30 System.out.println(" Sack 2 Profit: " + objectives[1]);
31 System.out.println(" Binary String: " + solution.getVariable(0));
32 }
33 }
34
35 }
MOEAFramework/book/chapter3/RunKnapsackProblem.java
As before, we specify the problem class when creating the Executor. Observe that
we do not need to thell the algorithm about any new features of our problem. It auto-
matically detects that the problem uses a bit string representation and constructs the algo-
rithm with the appropriate crossover and mutation operators. Also note on line 18 that we
call distributeOnAllCores(), which enables multithreading. For problems with time-
consuming evaluations, you can gain substantial performance improvements by spreading the
work across multiple processors on your computer. The MOEA Framework automatically
handles this for you.
Running this example will produce output similar to the following. Since this is a mul-
tiobjective problem, there is typically no single optimal solution. Instead, there are several
options, all equally “good”. Solution 1 has the maximum profit of 9.0 for Sack 1, but the
worst profit of 5.0 for Sack 2.
Solution 1:
Sack 1 Profit: 9.0
Sack 2 Profit: 5.0
Binary String: 01010
Solution 2:
Sack 1 Profit: 5.0
Sack 2 Profit: 8.0
Binary String: 00110
Solution 3:
Sack 1 Profit: 7.0
Sack 2 Profit: 6.0
Binary String: 00011
Solution 4:
Sack 1 Profit: 6.0
Sack 2 Profit: 7.0
Binary String: 01100
38
In this Knapsack problem, we hard-coded the profits, weights, and capacities. A more
generalized implementation is available with the MOEA Framework in the examples folder.
3.3 Feasibility
You may encounter problems that are severely constrained where the majority of the search
space is infeasible. Under these circumstances, it becomes very challenging for an optimiza-
tion algorithm to find feasible solutions. When this happens, the results from the MOEA
Framework will contain only infeasible solutions. It is important to check if solutions are
infeasible with the solution.violatesConstraints() method. This can be a chal-
lenging problem to address. In some cases, the problem can be reformulated or represented
in a different way to relax the constraints. This is outside the scope of this beginner’s guide,
but more details can be found in academic literature.
39
40
Thank you for downloading the MOEA Framework. This is a preview of the Beginner's Guide to the
MOEA Framework. This preview provides access to introductory materials. Please consider purchasing
the complete guide using the link below to access the advanced topics and help fund the hosting,
maintenance, and continued development of this software.
Buy Online
Appendix A
List of Algorithms
This appendix lists the optimization algorithms provided natively by the MOEA Framework,
a short description of the distinct features of the algorithm, and a list of the parameters
and default values. Most of these algorithms support a variety of crossover and/or mutation
operators. In those cases, refer to Appendix C for a list of the operators and their parameters.
Table 4.1 shows a list of these algorithms and their supported types.
In addition to the algorithms listed here, the MOEA Framework also supports third-party
libraries via a plugin mechanism. Currently, the MOEA Framework supports optimization
algorithms from JMetal and PISA. See Appendix B for more details on the available third-
party algorithms. Note that while you can execute these third-party algorithms, some func-
tionality may not be supported. In particular, runtime dynamics can not be collected from
JMetal algorithms.
A.1 Multiobjective Optimizers
A.1.1 CMA-ES
CMA-ES is a sophisticated covariance matrix adaptation evolution strategy algorithm
for real-valued global optimization (Hansen and Kern, 2004; Igel et al., 2007). CMA-ES
produces offspring by sampling a distribution formed by a covariance matrix, hence the
name, and updating the covariance matrix based on the surviving offspring. Single and
multi-objective variants exist in the literature and both are supported by the MOEA
Framework.
145
Parameters Description Default Value
lambda The offspring population size 100
cc The cumulation parameter 1
cs The step size of the cumulation parameter 1
damps The damping factor for the step size 1
ccov The learning rate 1
ccovsep The learning rate when in diagonal-only mode 1
sigma The initial standard deviation 0.5
diagonalIterations The number of iterations in which only the covari-
ance diagonal is used
0
indicator Either "hypervolume" or "epsilon" to spec-
ify the use of the hypervolume or additive-epsilon
indicator. If unset, crowding distance is used
Unset
initialSearchPoint Initial guess at the starting location (comma-
separated values). If unset, a random initial guess
is used
Unset
A.1.2 DBEA
DBEA, or I-DBEA, is the Improved Decomposition-Based Evolutionary Algorithm. DBEA
uses the same systematic sampling of reference points as NSGA-III, but utilizes distance
along each reference vector to measure convergence and the perpendicular distance to refer-
ence vectors to measure diversity (Asafuddoula et al., 2015). DBEA also proposes corner-sort
as a means to identify exteme points for normalization. For an M-objective problem, the
number of reference points is:
H=M+divisions 1
divisions (A.1)
To use the two-layer approach also used by NSGA-III, replace the divisions parameter
with divisionsOuter and divisionsInner.
Parameter Description Default Value
divisions The number of divisions Problem dependent
A.1.3 -MOEA
-MOEA is a steady-state MOEA that uses -dominance archiving to record a diverse
set of Pareto optimal solutions Deb et al. (2003). The term steady-state means that the
algorithm evolves one solution at a time. This is in contrast to generational algorithms,
which evolve the entire population every iteration. -dominance archives are useful since
they ensure convergence and diversity throughout search Laumanns et al. (2002). However,
1Parameter value is derived from other settings. See Igel et al. (2007) for details.
146
the algorithm requires an additional parameter which is problem dependent. The
parameter controls the granularity or resolution of the solutions in objective space.
Smaller values produce larger, more dense sets while larger values produce smaller sets.
In general, the values should be chosen to yield a moderately-sized Pareto approximate set.
Parameter Description Default Value
populationSize The size of the population 100
epsilon The values used by the -dominance archive,
which can either be a single value or a comma-
separated array
Problem dependent
A.1.4 -NSGA-II
-NSGA-II combines the generational search of NSGA-II with the guaranteed convergence
provided by an -dominance archive Kollat and Reed (2006). It also features randomized
restarts to enhance search and find a diverse set of Pareto optimal solutions. During
a random restart, the algorithm empties the current population and fills it with new,
randomly-generated solutions.
Parameter Description Default Values
populationSize The size of the population 100
epsilon The values used by the -dominance
archive, which can either be a single value
or a comma-separated array
Problem depen-
dent
injectionRate Controls the percentage of the population
after a restart this is “injected”, or copied,
from the -dominance archive
0.25
windowSize Frequency of checking if a randomized
restart should be triggered (number of it-
erations)
100
maxWindowSize The maximum number of iterations be-
tween successive randomized restarts
100
minimumPopulationSize The smallest possible population size
when injecting new solutions after a ran-
domized restart
100
maximumPopulationSize The largest possible population size when
injecting new solutions after a randomized
restart
10000
A.1.5 GDE3
GDE3 is the third version of the generalized differential evolution algorithm Kukkonen and
Lampinen (2005). The name differential evolution comes from how the algorithm evolves
147
offspring. It randomly selects three parents. Next, it computes the difference (the differ-
ential) between two of the parents. Finally, it offsets the remaining parent by this differential.
Parameter Description Default Values
populationSize The size of the population 100
de.crossoverRate The crossover rate for differential evolution 0.1
de.stepSize Control the size of each step taken by differential
evolution
0.5
A.1.6 IBEA
IBEA is a indicator-based MOEA that uses the hypervolume performance indicator as a
means to rank solutions Zitzler and K¨unzli (2004). Indicator-based algorithms are based
on the idea that a performance indicator, such as hypervolume or additive -indicator,
highlight solutions with desirable qualities. The primary disadvantage of indicator-based
methods is that the calculation of the performance indicator can become computationally
expensive, particularly as the number of objectives increases.
Parameter Description Default Value
populationSize The size of the population 100
indicator The indicator function (e.g., "hypervolume","
epsilon")
"hypervolume"
A.1.7 MOEA/D
MOEA/D is a relatively new optimization algorithm based on the concept of decomposing
the problem into many single-objective formulations . Several version of MOEA/D exist
in the literature. The most common variant seen in the literature, MOEA/D-DE (Li and
Zhang, 2009), is the default implementation in the MOEA Framework.
An extension to MOEA/D-DE variant called MOEA/D-DRA introduced a utility
function that aimed to reduce the amount of “wasted” effort by the algorithm (Zhang et al.,
2009). This variant is enabled by setting the updateUtility parameter to a non-zero
value.
148
Parameter Description Default
Value
populationSize The size of the population 100
de.crossoverRate The crossover rate for differential evolution 0.1
de.stepSize Control the size of each step taken by differential
evolution
0.5
pm.rate The mutation rate for polynomial mutation 1/N
pm.distributionIndex The distribution index for polynomial mutation 20.0
neighborhoodSize The size of the neighborhood used for mating,
given as a percentage of the population size
0.1
delta The probability of mating with an individual from
the neighborhood versus the entire population
0.9
eta The maximum number of spots in the population
that an offspring can replace, given as a percentage
of the population size
0.01
updateUtility The frequency, in generations, at which utility val-
ues are updated. If set, this uses the MOEA/D-
DRA variant; if unset, then then MOEA/D-DE
variant is used
Unset
A.1.8 MSOPS
MSOPS is the Multiple Single-Objective Pareto Search algorithm (Hughes, 2003). MSOPS
works by enumerating kreference vectors and applying a rank ordering based on two
aggregate functions: weighted min-max and vector angle distance scaling (VADS). Solutions
with higher rankings with respect to both metrics are preferred. MSOPS only supports
real-valued solutions using differential evolution.
Parameter Description Default Value
populationSize The size of the population 100
numberOfWeights The number of weight vectors 50
de.crossoverRate The crossover rate for differential evolution 0.1
de.stepSize Control the size of each step taken by differential
evolution
0.5
A.1.9 NSGA-II
NSGA-II is one of the first and most widely used MOEAs (Deb et al., 2000). It enhanced
it predecessor, NSGA, by introducing fast non-dominated sorting and using the more
computationally efficient crowding distance metric during survival selection.
149
Parameter Description Default Value
populationSize The size of the population 100
withReplacement Uses binary tournament selection with (true) or
without (false) replacement
true
A.1.10 NSGA-III
NSGA-III is the many-objective successor to NSGA-II, using reference points to direct solu-
tions towards a diverse set (Deb and Jain, 2014). The number of reference points is controlled
by the number of objectives and the divisions parameter. For an M-objective problem,
the number of reference points is:
H=M+divisions 1
divisions (A.2)
The authors also propose a two-layer approach for divisions for many-objective problems
where an outer and inner division number is specified. To use the two-layer approach,
replace the divisions parameter with divisionsOuter and divisionsInner.
Parameter Description Default Value
populationSize The size of the population. If unset, the popula-
tion size is equal to the number of reference points
Unset
divisions The number of divisions Problem dependent
A.1.11 OMOPSO
OMOPSO is a multiobjective particle swarm optimization algorithm that includes an
-dominance archive to discover a diverse set of Pareto optimal solutions (Sierra and
Coello Coello, 2005). This implementation of OMOPSO differs slightly from the original
author’s implementation in JMetal due to a discrepancy between the author’s code and the
paper. The paper returns the -dominance archive while the code returns the leaders. This
discrepancy causes a small difference in performance.
Parameter Description Default Value
populationSize The size of the population 100
archiveSize The size of the archive 100
maxEvaluations The maximum number of evaluations for
adapting non-uniform mutation
25000
mutationProbability The mutation probability for uniform and
non-uniform mutation
1/N
perturbationIndex Controls the shape of the distribution for
uniform and non-uniform mutation
0.5
epsilon The values used by the -dominance
archive
Problem dependent
150
A.1.12 PAES
PAES is a multiobjective version of evolution strategy (Knowles and Corne, 1999). PAES
tends to underperform when compared to other MOEAs, but it is often used as a baseline
algorithm for comparisons. Like PESA-II, PAES uses the adaptive grid archive to maintain
a fixed-size archive of solutions.
Parameter Description Default
Value
archiveSize The size of the archive 100
bisections The number of bisections in the adaptive grid
archive
8
pm.rate The mutation rate for polynomial mutation 1/N
pm.distributionIndex The distribution index for polynomial mutation 20.0
A.1.13 PESA-II
PESA-II is another multiobjective evolutionary algorithm that tends to underperform other
MOEAs but is often used as a baseline algorithm in comparative studies (Corne et al.,
2001). It is the successor to PESA (Corne and Knowles, 2000). Like PAES, PESA-II uses
the adaptive grid archive to maintain a fixed-size archive of solutions.
Parameter Description Default Value
populationSize The size of the population 10
archiveSize The size of the archive 100
bisections The number of bisections in the adaptive grid
archive
8
A.1.14 Random
The random search algorithm simply randomly generates new solutions uniformly through-
out the search space. It is not intended as an “optimization algorithm” per se, but as a way
to compare the performance of other MOEAs against random search. If an optimization
algorithm can not beat random search, then continued use of that optimization algorithm
should be questioned.
Parameter Description Default Value
populationSize This parameter only has a use when parallelizing
evaluations; it controls the number of solutions
that are generated and evaluated in parallel
100
epsilon The values used by the -dominance archive,
which can either be a single value or a comma-
separated array (this parameter is optional)
Unset
151
A.1.15 RSO
The repeated single objectives (RSO) algorithm solves multiobjective problems by running
several single-objective optimizers independently with varying weights (Hughes, 2005). Any
of the single-objective optimizers supported by the MOEA Framework can be utilized,
and any properties supported by that optimizer can be defined. RSO is a useful tool for
comparing single and multiobjective optimizers. The maximum number of evaluations is
spread evenly across each single-objective instance.
Parameter Description Default Value
algorithm The single-objective optimizer "GA"
method The scalarizing method "min-max"
instances The number of single-objective optimizers 100
A.1.16 RVEA
The reference vector guided evolutionary algorithm (RVEA) has many similarities with
NSGA-III, but avoids use of Pareto dominance and uses an angle-penalized distance function
for survival selection (Cheng et al., 2016). RVEA only works on problems with at least two
objectives and can only use genetic operators requiring two parents. Like NSGA-III, the
number of reference vectors is controlled by the number of objectives and the divisions
parameter. For an M-objective problem, the number of reference vectors is:
H=M+divisions 1
divisions (A.3)
To use the two-layer approach, replace the divisions parameter with divisionsOuter
and divisionsInner.
Parameter Description Default Value
populationSize The size of the population. If unset, the pop-
ulation size is equal to the number of refer-
ence vectors
Unset
divisions The number of divisions Problem dependent
alpha Controls the rate of change in the angle-
penalized distance function
2
adaptFrequency The frequency (in generations) in which the
weights are adapted / scaled
maxEvaluations /
(populationSize *
10)
A.1.17 SMPSO
SMPSO is a multiobjective particle swarm optimization algorithm (Nebro et al., 2009).
152
Parameter Description Default
Value
populationSize The size of the population 100
archiveSize The size of the archive 100
pm.rate The mutation rate for polynomial mutation 1/N
pm.distributionIndex The distribution index for polynomial mutation 20.0
A.1.18 SMS-EMOA
SMS-EMOA is an indicator-based MOEA that uses the volume of the dominated hypervol-
ume to rank individuals (Beume et al., 2007).
Parameter Description Default Value
populationSize The size of the population 100
offset The reference point offset for computing hypervol-
ume
100
A.1.19 SPEA2
SPEA2 is an older but popular benchmark MOEA that uses the so-called “strength-based”
method for ranking solutions (Zitzler et al., 2002a). The general idea is that the strength
or quality of a solution is related to the strength of solutions it dominates.
Parameter Description Default Value
populationSize The size of the population 100
offspringSize The number of offspring generated every iteration 100
k Crowding is based on the distance to the k-th near-
est neighbor
1
A.1.20 VEGA
VEGA is considered the earliest documented MOEA. While we provide support for VEGA,
other MOEAs should be preferred as they exhibit better performance. VEGA is provided
for its historical significance (Schaffer, 1985).
Parameter Description Default Value
populationSize The size of the population 100
A.2 Single-Objective Optimizers
In addition to the multiobjective optimizers listed above, the MOEA Framework supports
several single-objective optimizers. These single-objective optimizers can be used to solve
both single and multiobjective problems. For multiobjective problems, additional weighting
properties are provided.
153
All single objective algorithms support the "weights" and "method" properties. Both
are optional. If not weights are given, the default is equal weights. "method" can either be
"linear" or "min-max".
A.2.1 GA
GA is the standard genetic algorithm with elitism (Holland, 1975). A single elite individual
is guaranteed to survive between generations.
Parameter Description Default Value
populationSize The size of the population 100
method The scalarization method "linear"
weights The scalarization weights Equal weights
A.2.2 ES
ES is the standard (1 + 1) evolution strategies algorithm (Rechenberg, 1971). ES only
supports real-valued variables. This means the population is size 1 and only 1 offspring is
generated each iteration. The fittest solution survives to the next iteration. Additionally,
ES uses a self-adaptive variation operator.
Parameter Description Default Value
populationSize The size of the population 100
method The scalarization method "linear"
weights The scalarization weights Equal weights
A.2.3 DE
DE is the standard differential evolution algorithm (Storn and Price, 1997). DE only
supports real-valued variables using the differential evolution operator. DE works by calcu-
lating the difference between two randomly-selected points and applying that difference to
a third point.
Parameter Description Default Value
populationSize The size of the population 100
method The scalarization method "linear"
weights The scalarization weights Equal weights
de.crossoverRate The DE crossover rate See documenta-
tion
de.stepSize The DE step size See documenta-
tion
154
Appendix B
Additional Algorithms
In addition to the algorithms implemented natively within the MOEA Framework, as listed
in Appendix A, the MOEA Framework can also run third-party optimization algorithms via
a plugin mechanism. The current installation of MOEA Framework supports JMetal and the
PISA Framework. JMetal algorithms are included by default. PISA Framework algorithms
must be downloaded and compiled separately.
B.1 JMetal Algorithms
JMetal supports only the real-valued, binary, and permutation encodings. Each of the
descriptions below will indicate which of these encodings, if any, the algorithm supports.
For each encoding, a different set of parameters are available. For real-valued encodings,
the additional parameters are:
Parameters Description Default
Value
sbx.rate The crossover rate for simulated binary crossover 1.0
sbx.distributionIndex The distribution index for simulated binary
crossover
15.0
pm.rate The mutation rate for polynomial mutation 1.0/L
pm.distributionIndex The distribution index for polynomial mutation 20.0
For binary encodings, the additional parameters are:
Parameters Description Default Value
1x.rate The crossover rate for single-point crossover 0.9
bf.rate The mutation rate for bit flip mutation 1.0/L
For permutation encodings, the additional parameters are:
155
Table B.1: List of available third-party optimization algorithms.
Algorithm Type Real Binary Permutation Grammar Program Constraints Provider
AbYSS Scatter Search Yes No No No No Yes JMetal
CellDE Differential Evolution Yes No No No No Yes JMetal
DENSEA Genetic Algorithm Yes Yes Yes No No Yes JMetal
ECEA Genetic Algorithm Yes Yes Yes Yes Yes No PISA
FastPGA Genetic Algorithm Yes Yes Yes No No Yes JMetal
FEMO Genetic Algorithm Yes Yes Yes Yes Yes No PISA
HypE Indicator-Based Yes Yes Yes Yes Yes No PISA
MOCell Cellular Yes Yes Yes No No Yes JMetal
MOCHC CHC Algorithm No Yes No No No Yes JMetal
SEMO2 Genetic Algorithm Yes Yes Yes Yes Yes No PISA
SHV Indicator-Based Yes Yes Yes Yes Yes No PISA
SIBEA Indicator-Based Yes Yes Yes Yes Yes No PISA
SPAM Indicator-Based Yes Yes Yes Yes Yes No PISA
156
Parameters Description Default Value
pmx.rate The crossover rate for PMX crossover 1.0
swap.rate The mutation rate for the swap operator 0.35
Each of the supported JMetal algorithms and their parameters are detailed below.
AbYSS
AbYSS is a hybrid scatter search algorithm that uses genetic algorithm operators (Nebro
et al., 2008). Use the string "AbYSS" when creating instances of this algorithm with the
Executor. Only real-valued decision variables are supported. The following parameters
are available:
Parameters Description Default Value
populationSize The size of the population 20
archiveSize The size of the archive 100
refSet1Size The size of the first reference set 10
refSet2Size The size of the second reference set 10
improvementRounds The number of iterations that the local search op-
erator is applied
1
B.1.1 CellDE
CellDE is a hybrid cellular genetic algorithm (meaning mating only occurs among neighbors)
combined with differential evolution (Durillo et al., 2008). Use the string "CellDE" when
creating instances of this algorithm with the Executor. CellDE defines its own parameters
for its real-valued operators as listed below:
Parameters Description Default Value
populationSize The size of the population 100
archiveSize The size of the archive 100
feedBack Controls the number of solutions from the archive
that are fed back into the population
20
de.crossoverRate The crossover rate for differential evolution 0.1
de.stepSize Control the size of each step taken by differential
evolution
0.5
B.1.2 DENSEA
DENSEA is the duplicate elimination non-domination sorting evolutionary algorithm
(Greiner et al., 2006). Use the string "DENSEA" when creating instances of this algorithm
with the Executor. DENSEA supports real-valued, binary, and permutation encodings.
The following parameters are available:
157
Parameters Description Default Value
populationSize The size of the population 100
B.1.3 FastPGA
FastPGA is a genetic algorithm that uses adaptive population sizing to solve time-consuming
problems more efficiently (Eskandari et al., 2007). Use the string "FastPGA" when creating
instances of this algorithm with the Executor. FastPGA supports real-valued, binary,
and permutation encodings. The following parameters are available:
Parameters Description Default Value
maxPopSize The maximum size of the population 100
initialPopulationSize The initial size of the population 100
a Constant controlling the population size 20.0
b Multiplier controlling the population size 1.0
c Constant controlling the number of offspring 20.0
d Multiplier controlling the number of offspring 0.0
termination If 0, the algorithm terminates early if all solutions
like on the Pareto optimal front
1
B.1.4 MOCell
MOCell is the multiobjective version of a cellular genetic algorithm (Nebro et al., 2007b).
Use the string "MOCell" when creating instances of this algorithm with the Executor.
MOCell supports real-valued, binary, and permutation encodings. The following parameters
are available:
Parameters Description Default Value
populationSize The size of the population 100
archiveSize The size of the archive 100
feedBack Controls the number of solutions from the archive
that are fed back into the population
20
B.1.5 MOCHC
MOCHC is a genetic algorithm that combines a conservative selection strategy with highly
disruptive recombination, which unlike traditional MOEAs aims to produce offspring that
are maximally different from both parents (Nebro et al., 2007a). Use the string "MOCHC"
when creating instances of this algorithm with the Executor. MOCHC defines its own
parameters for its search operators as listed below:
158
Parameters Description Default
Value
initialConvergenceCount The threshold (as a percent of the number of bits in
the encoding) used to determine similarity between
solutions
0.25
preservedPopulation The percentage of the population that does not
undergo cataclysmic mutation
0.05
convergenceValue The convergence threshold that determines when
cataclysmic mutation is applied
3
populationSize The size of the population 100
hux.rate The crossover rate for the highly disruptive recom-
bination operator
1.0
bf.rate The mutation rate for bit-flip mutation 0.35
B.2 PISA Algorithms
The MOEA Framework has been extensively tested with the PISA algorithms listed in Ta-
ble B.1. PISA algorithms are provided by a third-party and are not distributed by the
MOEA Framework, but the MOEA Framework can be configured to run such optimiza-
tion algorithms. This section describes how to connect the MOEA Framework to a PISA
algorithm.
The Platform and Programming Language Independent Interface for Search Algorithms
(PISA), available at http://www.tik.ee.ethz.ch/pisa/, is a language-neutral pro-
gramming interface for creating search and optimization algorithms (Bleuler et al., 2003).
PISA specifies three components required for search algorithms:
1. selectors, which define the optimization algorithms;
2. variators, which define the optimization problems; and
3. a communication scheme using plaintext files.
This design offers several benefits. First, it clearly demarcates the responsibilities of algo-
rithm experts from those of application engineers. The algorithm experts focus on designing
and improving the behavior of optimization algorithms (i.e., selectors), whereas application
engineers are responsible for encoding the details of their problem (i.e., variators). Second,
the file-based communication scheme employed by PISA permits selectors and variators to be
written in nearly any programming language, which may be paired with a selector/variator
written in a completely different language. Third, the standardized communication scheme
enables plug-and-play integration, allowing one module to be swapped out for another with
little to no effort. For instance, one selector may be replaced by another simply by changing
which executable is run.
The fundamental drawback of PISA is a result of its reliance on a file-based communica-
tion scheme. File access on modern computers remains a (relatively) slow operation, which
159
is further exacerbated by the need to constantly poll the communication files for changes.
Nonetheless, PISA opens the door to a number of optimization algorithms, including:
1. Set Preference Algorithm for Multiobjective Optimization (SPAM)
2. Sampling-Based Hypervolume-Oriented Algorithm (SHV)
3. Simple Indicator-Based Evolutionary Algorithm (SIBEA)
4. Hypervolume Estimation Algorithm for Multiobjective Optimization (HypE)
5. Simple Evolutionary Multiobjective Optimizer (SEMO2)
6. Fair Evolutionary Multiobjective Optimizer (FEMO)
7. Epsilon-Constraint Evolutionary Algorithm (ECEA)
For this reason, the MOEA Framework provides the support necessary to integrate with
the PISA library. The PISAAlgorithm class acts as a variator, which knows how to
communicate with a PISA selector using the file-based communication protocol.
B.2.1 Adding a PISA Selector
A standardized method for adding PISA selectors to the MOEA Framework is provided.
The steps required to add a new PISA selector are:
1. Download and extract a PISA selector
2. Edit global.properties
(a) Add the name of the selector, NAME, to the comma-separated list of available
PISA selectors in org.moeaframework.algorithm.pisa.algorithms
(b) Add the property org.moeaframework.algorithm.pisa.NAME.command
, which points to the program executable which starts the PISA selector
(c) Provide a list of parameters, in the order required by the PISA selector, with the
property org.moeaframework.algorithm.pisa.NAME.parameters
(d) For each of the listed parameters, PARAM, add the property org.
moeaframework.algorithm.pisa.NAME.PARAM to set the default value for
the parameter. It is not necessary to list the seed parameter
For example, if we install the HypE selector, we would first download the HypE binaries
from http://www.tik.ee.ethz.ch/pisa/. These binaries are typically packaged as
a compressed file (.zip or .tar.gz). Next, extract the contents of this compressed file into
the MOEA Framework installation folder. In this example, we extracted the contents to the
folder pisa/hype_win. Finally, add the following lines to the global.properties
file:
160
org.moeaframework.algorithm.pisa.algorithms=HypE
org.moeaframework.algorithm.pisa.HypE.command = ./pisa/hype_win/hype.exe
org.moeaframework.algorithm.pisa.HypE.parameters = seed, tournament, mating,
bound, nrOfSamples
org.moeaframework.algorithm.pisa.HypE.parameter.tournament = 5
org.moeaframework.algorithm.pisa.HypE.parameter.mating = 1
org.moeaframework.algorithm.pisa.HypE.parameter.bound = 2000
org.moeaframework.algorithm.pisa.HypE.parameter.nrOfSamples = -1
Once completed, you should be able to run the diagnostic tool and confirm that HypE
appears in the list of available algorithms. Additionally, HypE may be referenced throughout
the MOEA Framework wherever the algorithm is specified as a string, such as:
1new Executor()
2.withProblem("Kursawe")
3.withAlgorithm("HypE")
4.withMaxEvaluations(10000)
5.withProperty("bound", 1000)
6.withProperty("tournament", 2)
7.run();
B.2.2 Troubleshooting
I’m attempting to run the PISA algorithm, but nothing is happening. The task manager
shows the PISA executable is running, but shows 0% CPU usage.
The MOEA Framework uses your system’s default temporary directory as the
location of the files used to communicate with the PISA selector. Some PISA
selectors do not support paths containing spaces, and the path to the default
temporary directory on older versions of Windows contains spaces. This causes
a miscommunication between the MOEA Framework and PISA, which generally
causes the MOEA Framework and PISA executables to stall.
The easiest workaround is to override the temporary directory location so that
the space is removed. This can be accomplished by editing the global.
properties file and adding the line:
java.io.tmpdir = C:/temp/
PISA runs fine for a while, but eventually crashes with the message “Assertion failed: fp !=
null”.
161
Some antivirus software is known to interfere with the file-based communica-
tion protocol used by PISA. Antivirus programs which actively monitor files for
changes may lock the file during a scan, potentially blocking access by the PISA
selector. Most PISA selectors will crash with the obscure message “Assertion
failed: fp != null”.
To verify this as the cause, you may temporarily disable your antivirus software
and re-run the program. Once verified, a permanent solution involves adding an
exception to the antivirus software to prevent scanning the PISA communication
files. To implement this solution, first define the location of temporary files by
adding the following line to the global.properties file:
java.io.tmpdir = C:/temp/
Then add an exception to your antivirus software to disable scanning files located
in this directory.
(Note: Disabling an antivirus program from scanning a folder will leave its con-
tents unprotected. Follow these steps at your own risk.)
162
Appendix C
List of Variation Operators
The following crossover and mutation operators are supported by the MOEA Framework.
Representation Type Abbr.
Real / Integer Simulated Binary Crossover sbx
Real / Integer Polynomial Mutation pm
Real / Integer Differential Evolution de
Real / Integer Parent-Centric Crossover pcx
Real / Integer Simplex Crossover spx
Real / Integer Unimodal Normal Distribution Crossover undx
Real / Integer Uniform Mutation um
Real / Integer Adaptive Metropolis am
Binary Half-Uniform Crossover hux
Binary Bit Flip Mutation bf
Permutation Partially-Mapped Crossover pmx
Permutation Element Insertion insertion
Permutation Element Swap swap
Subset Subset Crossover ssx
Subset Subset Replacement replace
Grammar Single-Point Crossover for Grammars gx
Grammar Uniform Mutation for Grammars gm
Program Branch (Subtree) Crossover bx
Program Point Mutation ptm
Any Single-Point Crossover 1x
Any Two-Point Crossover 2x
Any Uniform Crossover ux
163
C.1 Real-Valued Operators
Simulated Binary Crossover (SBX)
SBX attempts to simulate the offspring distribution of binary-encoded single-point crossover
on real-valued decision variables (Deb and Agrawal, 1994). It accepts two parents and
produces two offspring. An example of this distribution, which favors offspring nearer to the
two parents, is shown below.
The distribution index controls the shape of the offspring distribution. Larger values for the
distribution index generates offspring closer to the parents.
Parameters Description Default
Value
sbx.rate The probability that the SBX operator is applied
to a decision variable
1.0
sbx.distributionIndex The shape of the offspring distribution 15.0
Polynomial Mutation (PM)
PM attempts to simulate the offspring distribution of binary-encoded bit-flip mutation on
real-valued decision variables (Deb and Goyal, 1996). Similar to SBX, PM favors offspring
nearer to the parent. It is recommended each decision variable is mutated with a probability
of 1/N, where Nis the number of decision variables. This results in one mutation per
offspring on average.
The distribution index controls the shape of the offspring distribution. Larger values for
the distribution index generates offspring closer to the parents.
164
Parameters Description Default
Value
pm.rate The probability that the PM operator is applied
to a decision variable
1/N
pm.distributionIndex The shape of the offspring distribution (larger val-
ues produce offspring closer to the parent)
20.0
Differential Evolution (DE)
Differential evolution works by randomly selecting three distinct individuals from a pop-
ulation. A difference vector is calculated between the first two individuals (shown as the
left-most arrow in the figure below), which is subsequently applied to the third individual
(shown as the right-most arrow in the figure below).
The scaling factor parameter adjusts the magnitude of the difference vector, allowing the
user to decrease or increase the magnitude in relation to the actual difference between the
individuals (Storn and Price, 1997). The crossover rate parameter controls the fraction of
decision variables which are modified by the DE operator.
Parameters Description Default Value
de.crossoverRate The fraction of decision variables modified by the
DE operator
0.1
de.stepSize The scaling factor or step size used to adjust the
length of each step taken by the DE operator
0.5
Parent Centric Crossover (PCX)
PCX is a multiparent operator, allowing a user-defined number of parents and offspring (Deb
et al., 2002). Offspring are clustered around the parents, as depicted in the figure below.
165
Parameters Description Default Value
pcx.parents The number of parents 10
pcx.offspring The number of offspring generated by PCX 2
pcx.eta The standard deviation of the normal distribution
controlling the spread of solutions in the direction
of the selected parent
0.1
pcx.zeta The standard deviation of the normal distribution
controlling the spread of solutions in the directions
defined by the remaining parents
0.1
Unimodal Distribution Crossover (UNDX)
UNDX is a multiparent operator, allowing a user-defined number of parents and offspring
(Kita et al., 1999; Deb et al., 2002). Offspring are centered around the centroid, forming a
normal distribution whose shape is controlled by the positions of the parents, as depicted in
the figure below.
166
Parameters Description Default Value
undx.parents The number of parents 10
undx.offspring The number of offspring generated by UNDX 2
undx.zeta The standard deviation of the normal distribution
controlling the spread of solutions in the orthogo-
nal directions defined by the parents
0.5
undx.eta The standard deviation of the normal distribution
controlling the spread of solutions in the remaining
orthogonal directions not defined by the parents.
This value is divided by Nprior to use, where
Nis the number of decision variables.
0.35
Simplex Crossover (SPX)
SPX is a multiparent operator, allowing a user-defined number of parents and offspring
(Tsutsui et al., 1999; Higuchi et al., 2000). The parents form a convex hull, called a simplex.
Offspring are generated uniformly at random from within the simplex. The expansion rate
parameter can be used to expand the size of the simplex beyond the bounds of the parents.
For example, the figure below shows three parent points and the offspring distribution, clearly
filling an expanded triangular simplex.
Parameters Description Default Value
spx.parents The number of parents 10
spx.offspring The number of offspring generated by UNDX 2
spx.epsilon The expansion rate 3
Uniform Mutation (UM)
Each decision variable is mutated by selecting a new value within its bounds uniformly at
random. The figure below depicts the offspring distribution. It is recommended each decision
167
variable is mutated with a probability of 1/N, where Nis the number of decision variables.
This results in one mutation per offspring on average.
Parameters Description Default Value
um.rate The probability that the UM operator is applied
to a decision variable
1/N
Adaptive Metropolis (AM)
AM is a multiparent operator, allowing a user-defined number of parents and offspring (Vrugt
and Robinson, 2007; Vrugt et al., 2009). AM produces normally-distributed clusters around
each parent, where the shape of the distribution is controlled by the covariance of the parents.
Internally, the Cholesky decomposition is used to update the resulting offspring distri-
bution. Cholesky decomposition requires that its input be positive definite. In order to
guarantee this condition is satisfied, all parents must be unique. In the event that the pos-
itive definite condition is not satisifed, no offspring are produced and an empty array is
returned by
Parameters Description Default Value
am.parents The number of parents 10
am.offspring The number of offspring generated by AM 2
am.coefficient The jump rate coefficient, controlling the standard
deviation of the covariance matrix. The actual
jump rate is calculated as (am.coefficient/n)2
2.4
C.2 Binary / Bit String Operators
Half Uniform Crossover (HUX)
Half-uniform crossover (HUX) operator. Half of the non-matching bits are swapped between
the two parents.
Parameters Description Default Value
hux.rate The probability that the UM operator is applied
to a binary decision variable
1.0
Bit Flip Mutation (BF)
Each bit is flipped (switched from a 0 to a 1, or vice versa) using the specified probability.
Parameters Description Default Value
bf.rate The probability that a bit is flipped 0.01
168
C.3 Permutations
Partially Mapped Crossover (PMX)
PMX is similar to two-point crossover, but includes a repair operator to ensure the offspring
are valid permutations (Goldberg and Jr., 1985).
Parameters Description Default Value
pmx.rate The probability that the PMX operator is applied
to a permutation decision variable
1.0
Insertion Mutation
Randomly selects an entry in the permutation and inserts it at some other position in the
permutation.
Parameters Description Default Value
insertion.rate The probability that the insertion operator is ap-
plied to a permutation decision variable
0.3
Swap Mutation
Randomly selects two entries in the permutation and swaps their position.
Parameters Description Default Value
swap.rate The probability that the swap operator is applied
to a permutation decision variable
0.3
C.4 Subsets
Subset Crossover (SSX)
SSX is similar to HUX crossover for binary strings, where half of the non-matching members
are swapped between the two subsets.
Parameters Description Default Value
ssx.rate The probability that the SSX operator is applied
to a subset decision variable
0.9
Replace Mutation
Randomly replaces one of the members in the subset with a non-member.
Parameters Description Default Value
replace.rate The probability that the replace operator is ap-
plied to a subset decision variable
0.3
169
C.5 Grammars
Grammar Crossover (GX)
Single-point crossover for grammars. A crossover point is selected in both parents with the
tail portions swapped.
Parameters Description Default Value
gx.rate The probability that the GX operator is applied
to a grammar decision variable
1.0
Grammar Mutation (GM)
Uniform mutation for grammars. Each integer codon in the grammar representation is
uniformly mutated with a specified probability.
Parameters Description Default Value
gm.rate The probability that the GM operator is applied
to a grammar decision variable
1.0
C.6 Program Tree
Subtree Crossover (BX)
Exchanges a randomly-selected subtree from one program with a compatible, randomly-
selected subtree from another program.
Parameters Description Default Value
gm.rate The probability that the BX operator is applied to
a program tree decision variable
1.0
Point Mutation (PTM)
Mutates a program by randomly selecting nodes in the expression tree and replacing the
node with a new, compatible, randomly-selected node.
Parameters Description Default Value
gm.rate The probability that the PTM operator is applied
to a program tree decision variable
1.0
C.7 Generic Operators
Generic operators can be applied to any type. They work by simply swapping the value of
the decision variable between the parents.
170
One-Point Crossover (1X)
A crossover point is selected and all decision variables to the left/right are swapped between
the two parents. The two children resulting from this swapping are returned.
Parameters Description Default Value
1x.rate The probability that one-point crossover is applied
to produce offspring
1.0
Two-Point Crossover (2X)
Two crossover points are selected and all decision variables between the two points are
swapped between the two parents. The two children resulting from this swapping are re-
turned.
Parameters Description Default Value
2x.rate The probability that two-point crossover is applied
to produce offspring
1.0
Uniform Crossover (UX)
Crossover operator where each index is swapped with a specified probability.
Parameters Description Default Value
ux.rate The probability that uniform crossover is applied
to produce offspring
1.0
171
172
Appendix D
List of Problems
The following test problems are packaged with the MOEA Framework. Problems marked
with have maximized objectives. The MOEA Framework negates the values of maximized
objectives. Note that while many problems have similar Pareto fronts, their underlying
problem definitions and properties can differ greatly.
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
Belegundu 2 2 2 Real
Binh 2 2 0 Real
Binh2 2 2 2 Real
173
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
Binh3 2 3 0 Real
Binh4 2 3 2 Real
CF1 10 2 1 Real
CF2 10 2 1 Real
CF3 10 2 1 Real
CF4 10 2 1 Real
174
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
CF5 10 2 1 Real
CF6 10 2 2 Real
CF7 10 2 2 Real
CF8 10 3 1 Real
CF9 10 3 1 Real
CF10 10 3 1 Real
175
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
DTLZ1 N14 + NN 0 Real
DTLZ2 N 9 + NN 0 Real
DTLZ3 N 9 + NN 0 Real
DTLZ4 N 9 + NN 0 Real
DTLZ7 N 19 + NN 0 Real
Fonseca 2 2 0 Real
1DTLZ problems are scalable to any number of objectives. Replace Nwith the number of objectives.
176
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
Fonseca2 3 2 0 Real
Jimenez 2 2 4 Real
Kita 2 2 3 Real
Kursawe 3 2 0 Real
Laumanns 2 2 0 Real
Lis 2 2 0 Real
177
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
LZ1 30 2 0 Real
LZ2 30 2 0 Real
LZ3 30 2 0 Real
LZ4 30 2 0 Real
LZ5 30 2 0 Real
LZ6 10 3 0 Real
178
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
LZ7 10 2 0 Real
LZ8 10 2 0 Real
LZ9 30 2 0 Real
Murata 2 2 0 Real
Obayashi 2 2 1 Real
OKA1 2 2 0 Real
179
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
OKA2 3 2 0 Real
Osyczka 2 2 2 Real
Osyczka2 6 2 6 Real
Poloni 2 2 0 Real
Quagliarella 16 2 0 Real
Rendon 2 2 0 Real
180
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
Rendon2 2 2 0 Real
Schaffer 1 2 0 Real
Schaffer2 1 2 0 Real
Srinivas 2 2 2 Real
Tamaki 3 3 1 Real
Tanaka 2 2 2 Real
181
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
UF1 30 2 0 Real
UF2 30 2 0 Real
UF3 30 2 0 Real
UF4 30 2 0 Real
UF5 30 2 0 Real
UF6 30 2 0 Real
182
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
UF7 30 2 0 Real
UF8 30 3 0 Real
UF9 30 3 0 Real
UF10 30 3 0 Real
UF11 30 5 0 Real
UF12 30 5 0 Real
UF13 30 5 0 Real
Viennet 2 3 0 Real
Viennet2 2 3 0 Real
183
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
Viennet3 2 3 0 Real
Viennet4 2 3 3 Real
WFG1 N29 + NN 0 Real
WFG2 N 9 + NN 0 Real
WFG3 N 9 + NN 0 Real
WFG4 N 9 + NN 0 Real
2WFG problems are scalable to any number of objectives. Replace Nwith the number of objectives.
184
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
WFG5 N 9 + NN 0 Real
WFG6 N 9 + NN 0 Real
WFG7 N 9 + NN 0 Real
WFG8 N 9 + NN 0 Real
WFG9 N 9 + NN 0 Real
ZDT1 30 2 0 Real
185
Problem # of
Vars
# of
Objs
# of
Constrs Type Pareto Front
ZDT2 30 2 0 Real
ZDT3 30 2 0 Real
ZDT4 10 2 0 Real
ZDT5 80 2 0 Binary
ZDT6 10 2 0 Real
186
Appendix E
Errors and Warning Messages
This chapter provides a comprehensive list of errors and warning messages that may be
encountered when using the MOEA Framework. The error or warning message is shown in
italic text, followed by details and possible fixes for the issue.
E.1 Errors
Errors halt the execution of the program and produce an error message to the standard error
stream (i.e., the console). Most errors can be corrected by the user.
Exception in thread ”main” java.lang.NoClassDefFoundError: <class>
Thrown when Java is starting but is unable to find the specified class. Ensure the
specified class is located on the Java classpath. If the class is located in a JAR file, use
java -classpath "$CLASSPATH:/path/to/library.jar" ...
If the class is an individual .class file in a folder, use
java -classpath "$CLASSPATH:/path/to/folder/"
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above examples demonstrate. Windows and Cygwin users should use
the semi-colon (;).
Error occurred during initialization of VM or
Too small initial heap for new size specified
This Java error occurs when the initial heap size (allocated memory) is too small to
instantiate the Java virtual machine (VM). This error is likely caused by the -Xmx
command line option requesting less memory than is necessary to start the VM.
Increasing the -Xmx value may resolve this issue. Also ensure the -Xmx argument is
properly formatted. For instance, use -Xmx128m and NOT -Xmx128.
187
Error occurred during initialization of VM or
Could not reserve enough space for object heap or
Could not create the Java virtual machine
This Java error occurs when there is insufficient heap size (allocated memory) to instan-
tiate the Java virtual machine (VM). This error is likely caused by the -Xmx command
line option requesting more memory than is available on the host system. This er-
ror may also occur if other running processes consume large quantities of memory.
Lowering the -Xmx value may resolve this issue.
Exception in thread “main” java.lang.OutOfMemoryError: GC overhead limit exceeded
Java relies on a garbage collector to detect and free memory which is no longer in use.
This process is usually fast. However, if Java determines it is spending too much time
performing garbage collection (98% of the time) and is only recovering a small amount
of memory (2% of the heap), this error is thrown. This is likely caused when the in-
use memory approaches the maximum heap size, leaving little unallocated memory for
temporary objects. Try increasing the maximum heap size with the -Xmx command
line argument.
Assertion failed: fp != NULL, file <filename>, line <linenumber>
PISA modules communicate using the file system. Some anti-virus software scans the
contents of files before read and after write operations. This may cause one of the
PISA communication files to become inaccessible and cause this error. To test if this
is the cause, try disabling your anti-virus and re-run the program.
A more permanent and secure solution involves adding an exception to the anti-virus
software to prevent active monitoring of PISA communication files. For example, first
add the line
java.io.tmpdir=<folder>
to global.properties and set <folder> to some temporary folder where the
PISA communication files will be stored. Then configure your anti-virus software to
ignore the contents of <folder>.
problem does not have an analytical solution
Attempted to use SetGenerator to produce a reference set for a problem which does
not implement AnalyticalProblem. Only AnalyticalProblems, which provide
a method for generating Pareto optimal solutions, can be used with SetGenerator.
input appears to be newer than output
Several of the command line utilities read entries in an input file and write the cor-
responding outputs to a separate output file. If the last modified date on the input
file is newer than the date on the output file, this exception is thrown. This suggests
that the input file has been modified unexpectedly, and attempting to resume with a
partially evaluated output file may result in incorrect results. To resolve:
188
1. If the input file is unchanged, use the --force command line option to override
this check.
2. If the input file is changed, delete the output file and restart evaluation from the
beginning.
no reference set available
Several of the command line utilities require a reference set. The reference set either is
provided by the problem (through the ProblemProvider), or supplied by the user
via a command line argument. This exception occurs if neither approach provides a
reference set.
unable to load reference set
Indicates that a reference set is specified, but it could not be loaded. The error message
should contain additional information about the underlying cause for the load failure.
output has more entries than input
Thrown by the Evaluator or ResultFileEvaluator command line utilities when
attempting to resume evaluation of a partially evaluated file, but the output file con-
tains more entries than the input file. This implies the input file was either modified,
or a different input file was supplied than originally used to produce the output file.
Unless the original input file is found, do not attempt to recover from this exception.
Delete the output file and restart evaluation from the beginning.
maxEvaluations not defined
Thrown by the Evaluator command line utility if the maxEvaluations property
has not been defined. This property must either be defined in the parameter input file
or through the -x maxEvaluations=<value> command line argument.
unsupported decision variable type
Thrown when the user attempts to use an algorithm that does not support the given
problem’s decision variable encoding. For instance, GDE3 only supports real-valued
encodings, and will throw this exception if binary or permutation encoded problems
are provided.
not enough bits or
not enough dimensions
The Sobol sequence generator supports up to 21000 dimensions and can produce up to
2147483647 samples (231 1). While unlikely, if either of these two limits are exceeded,
these exceptions are thrown.
invalid number of parents
189
Attempting to use CompoundVariation in a manner inconsistent with its API spec-
ification will result in this exception. Refer to the API documentation and the restric-
tions on the number of parents for a variation operator.
binary variables not same length or
permutations not same size
Thrown by variation operators which require binary variables or permutations of equal
length, but the supplied variables differ in length.
invalid bit string
Thrown by ResultFileReader if either of the following two cases occurs:
1. The binary variable length differs from that specified in the problem definition.
2. The string encoding in the file contains invalid characters.
In either case, the binary variable stored in the result file could not be read.
invalid permutation
Thrown by ResultFileReader if either of the following two cases occurs: 1) the
permutation length differs from that specified in the problem definition; and 2) the
string encoding in the file does not represent a valid permutation. In either case, the
permutation stored in the result file could not be read.
no provider for <name>
Thrown by the service provider interface (org.moeaframework.core.spi) codes when no
provider for the requested service is available. Check the following:
1. If a nested exception is reported, the nested exception will identify the failure.
2. Ensure <name> is in fact provided by a built-in or third-party provider. Check
spelling and case sensitivity.
3. If <name> is supplied by a third-party provider, ensure the provider is located on
the Java classpath. If the provider is in a JAR file, use
java -classpath "$CLASSPATH:/path/to/provider.jar"
...
If the provider is supplied as class files in a folder, use
java -classpath "$CLASSPATH:/path/to/folder/"
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above examples demonstrate. Windows and Cygwin users should
use the semi-colon (;).
190
error sending variables to external process or
error receiving variables from external process
Thrown when communicating with an external problem, but an I/O error occurred
that disrupted the communication. Numerous situations may cause this exception,
such as the external process terminating unexpectedly.
end of stream reached when response expected
Thrown when communicating with an external process, but the connection to the
external process closed. This is most likely the result of an error on the external process
side which caused the external process to terminate unexpectedly. Error messages
printed to the standard error stream should appear in the Java error stream.
response contained fewer tokens than expected
Thrown when communicating with an external problem, and the external process has
returned an unexpected number of entries. This is most likely a configuration error
where the defined number of objectives or constraints differs from what is actually
returned by the external process.
unable to serialize variable
Attempted to serialize a decision variable to send to an external problem, but the
decision variable is not one of the supported types. Only real variables are supported.
restart not supported
PISA supports the ability to reuse a selector after a run has completed. The MOEA
Framework currently does not support this feature. This exception is thrown if the
PISA selector attempts to reset.
expected END on last line or
unexpected end of file or
invalid selection length
These exceptions are thrown when communicating with PISA processes, and the files
produced by the PISA process appear to be incomplete or malformed. Check the
implementation of the PISA codes to ensure they follow the correct protocol and syntax.
invalid variation length
This exception is caused by an incorrect configuration of PISA. The following equality
must hold
children (mu/parents) = lambda,
where mu is the number of parents selected by the PISA process, parents is the num-
ber of parent solutions required by the variation operator, children is the number of
offspring produced by a single invocation of the variation operator, and lambda is the
total number of offspring produced during a generation.
191
no digest file
Thrown when attempting to validate a data file using a digest file, but no such digest
file exists. Processing of the data file should cease immediately for sensitive applications
where data integrity is essential. If the digest file simply hasn’t yet been produced but
the file contents are verified, the FileProtection command line utility can optionally
generate digest files.
invalid digest file
Thrown when attempting to validate a date file using a digest file, but the digest file
is corrupted or does not contain a valid digest. Processing of the data file should cease
immediately for sensitive applications where data integrity is essential.
digest does not match
Thrown when attempting to validate a data file using a digest file, but the actual digest
of the data file does not match the expected digest contained in the digest file. This
indicates that the data file or the digest file are corrupted. Processing of the data file
should cease immediately for sensitive applications where data integrity is essential.
unexpected rule separator or
rule must contain at least one production or
invalid symbol or
rule must start with non-terminal or
rule must contain at least one production or
codon array is empty
Each of these exceptions originates in the grammatical evolution code, and indicate
specific errors when loading or processing a context free grammar. The specific error
message details the cause.
unable to mkdir ¡directory¿
For an unknown reason, the underlying operating system was unable to create a direc-
tory. Check to ensure the location of the directory is writable. One may also manually
create the directory.
no scripting engine for extension ¡ext¿
Attempted to use the Java Scripting APIs, but no engine for the specified file extension
could be found. To resolve:
1. Check that the extension is valid. If not, supply the file extension for the scripting
language required.
2. Ensure the scripting language engine is listed on the classpath. The engine, if
packaged in a JAR, can be specified with
192
java -classpath "$CLASSPATH:/path/to/engine.jar"
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above example demonstrates. Windows and Cygwin users should
use the semi-colon (;).
no scripting engine for ¡name¿
Attempted to use the Java Scripting APIs, but no engine with the specified name was
found.
1. Check that the name is valid. If not, supply the correct name for the scripting
language engine as required.
2. Ensure the scripting language engine is listed on the classpath. The engine, if
packaged in a JAR, can be specified with
java -classpath "$CLASSPATH:/path/to/engine.jar"
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above example demonstrates. Windows and Cygwin users should
use the semi-colon (;).
file has no extension
Attempted to use a script file with ScriptedProblem, but the filename does not
contain a valid extension. Either supply the file extension for the scripting language
required, or use the constructor which accepts the engine name as an argument.
scripting engine not invocable
Thrown when using a scripting language engine which does not implement the
Invocable interface. The scripting language does not support methods or functions,
and thus can not be used as intended.
requires two or more groups
Attempted to use one of the n-ary statistical tests which require at least two groups.
Either add a second group to compare against, or remove the statistical test.
could not locate resource ¡name¿
Thrown when attempting to access a resource packages within the MOEA Framework,
but the resource could not be located. This is an error with the distribution. Please
contact the distributor to correct this issue.
insufficient number of entries in row
Attempted to read a data file, but the row was missing one or more entries. The exact
meaning depends on the specific data file, but generally this error means the file is
incomplete, improperly formatted or corrupted. See the documentation on the various
file types to determine if this error can be corrected.
193
invalid entry in row
Attempted to read a data file, but an entry was not formatted correctly. See the
documentation on the various file types to determine if this error can be corrected.
invoke calculate prior to getting indicator values
Attempted to retrieve one of the indicator values prior to invoking the calculate method.
When using QualityIndicator, the calculate method must be invoked prior to
retrieving any of the indicator values.
not a real variable or
not a binary variable or
not a boolean variable or
not a permutation
The EncodingUtils class handles all the type checking internally. If any of the
arguments are not of the expected type, one of these exceptions is thrown. Ensure the
argument is of the expected type. For example, ensure variable is a BinaryVariable
when calling EncodingUtils.asBinary(variable).
invalid number of values or
invalid number of bits
Attempted to set the decision variable values using an array, but the number of elements
in the array does not match the required number of elements. For EncodingUtils.
setReal and EncodingUtils.setInt, ensure the number of real-valued/integer-
valued decision variables being set matches the array length. For EncodingUtils.
setBinary, ensure the number of bits expressed in the binary variable matches the
array length.
lambda function is not valid
In genetic programming, a lambda function was created with an invalid body. The body
of a lambda function must be fully defined and strongly typed. If not, this exception
is thrown. Check the definition of the lambda function and ensure all arguments are
non-null and are of the correct type. Check the error output to see if any warning
messages were printed that detail the cause of this exception.
index does not reference node in tree
Attempted to use one of the node.getXXXAt() methods, but the index referred to
a node not within the tree. This is similar to an out-of-bounds exception, as the index
pointed to a node outside the tree. Ensure the index is valid.
malformed property argument
194
The Evaluator and Solve command line utilities support setting algorithm pa-
rameters on the command line with the -x option. The parameters should be of the
form:
-x name=value
or if multiple parameters are set:
-x name1=value1;name2=value2;name3=value3
This error is thrown if the command line argument is not in either of these two forms.
Check the command line argument to ensure it is formatted correctly.
key not defined in accumulator: <key>
Thrown when attempting to access a key in an Accumulator object that is not
contained within the Accumulator. Use accumulator.keySet() to see what
keys are available and ensure the requested key exists within the accumulator.
an unclean version of the file exists from a previous run, requires manual intervention
Thrown when ResultFileWriter or MetricFileWriter attempt to recover data
from an interrupted run, but it appears there already exists an “unclean” file from a
previous recovery attempt. If the user believes the unclean file contains valid data, she
can copy the unclean file to its original location. Or, she can delete the unclean file
to start fresh. The org.moeaframework.analysis.sensitivity.cleanup
property in global.properties controls the default behavior in this scenario.
requires at least two solutions or objective with empty range
These two exceptions are thrown when using the Normalizer with a degenerate pop-
ulation. A degenerate population either has fewer than two solutions or the range of
any objective is below computer precision. In this scenario, the population can not be
normalized.
lower bound and upper bounds not the same length
When specifying the --lowerBounds and --upperBounds arguments to the
Solve utility, the number of values in the comma-separated list must match.
invalid variable specification ¡value¿, not properly formatted invalid real specification ¡value¿,
expected R(¡lb¿,¡ub¿) invalid binary specification ¡value¿, expected B(¡length¿) invalid permu-
tation specification ¡value¿, expected P(¡length¿) invalid variable specification ¡value¿, un-
known type
The --variables argument to the Solve utility allows specifying the types and
ranges of the decision variables. These error messages indicate that one or more of the
variable specifications is invalid. The message will identify the problem. An example
variable specification is provided below:
195
--variables "R(0;1),B(5),P(10),R(-1;1)"
Also, always surround the argument with quotes as shown in this example.
must specify either the problem, the variables, or the lower and upper bounds arguments
The Solve command line utility operates on both problems defined within the MOEA
Framework (by name) or problems external to the MOEA Framework, such as an
executable. For problems identified by name, the --problem argument must be
specified. For external problems, (1) if the problem is real-valued, you can use the
--lowerBounds and --upperBounds arguments; or (2) use the --variables
argument to specify the decision variables and their types.
E.2 Warnings
Warnings are messages printed to the standard error stream (i.e., the console) that indicate
an abnormal or unsafe condition. While warnings do not indicate an error occurred, they do
indicate caution is required by the user.
no digest file exists to validate <FILE>
Attempted to validate the file but no digest file exists. This indicates that the frame-
work could not verify the authenticity of the file.
saving result file without variables, may become unstable
Occurs when writing a result file with the output of decision variables suppressed. The
suppression of decision variable output is a user-specified option. The warning “may
become unstable” indicates that further use of the result file may result in unexpected
errors if the decision variables are required.
unsupported decision variable type, may become unstable
Occurs when reading or writing result files which use unsupported decision variable
types. When this occurs, the program is unable to read or write the decision variable,
and its value is therefore lost. The warning “may become unstable” indicates that
further use of the result file may result in unexpected errors if the decision variables
are required.
duplicate solution found
Issued by ReferenceSetMerger if any of the algorithms contribute identical solu-
tions. If this warning is emitted, the contribution of each algorithm to the reference
set is invalid. Use SetContribution instead to compute the contribution of overlapping
sets to a reference set.
196
can not initialize unknown type
Emitted by RandomInitialization if the problem uses unsupported decision vari-
able types. The algorithm will continue to run, but the unsupported decision variables
will remain initialized to their default values.
an error occurred while writing the state file or
an error occurred while reading the state file
Occurs when checkpoints are enabled, but the algorithm does not support checkpoints
or an error occurred while reading or writing the checkpoint. The execution of the
algorithm will continue normally, but no checkpoints will be produced.
multiple constraints not supported, aggregating into first constraint
Occurs when an algorithm implementation does not support multiple constraints. This
occurs primarily with the JMetal library, which only uses a single aggregate constraint
violation value. When translating between JMetal and the MOEA Framework, the
first objective in the MOEA Framework is assigned the aggregate constraint violation
value; the remaining objectives become 0.
increasing MOEA/D population size
The population size of MOEA/D must be at least the number of objectives of the
problem. If not, the population size is automatically increased.
checkpoints not supported when running multiple seeds
Emitted by the Executor when the withCheckpointFile(...) and
accumulateAcrossSeeds(...) options are both used. Checkpoints are only sup-
ported for single-seed evaluation. The Executor will continue without checkpoints.
checkpoints not supported by algorithm
Emitted by the Executor if the algorithm is not Resumable (i.e., does not support
checkpoints). The Executor will continue without checkpoints.
Provider org.moeaframework.algorithm.jmetal.JMetalAlgorithms could not be instantiated:
java.lang.NoClassDefFoundError: <class>
This warning occurs when attempting to instantiate the JMetal algorithm provider, but
the JMetal library could not be found on the classpath. This is treated as a warning
and not an exception since a secondary provider may exist for the specified algorithm.
If no secondary provider exists, a ProviderNotFoundException will be thrown.
To correct, obtain the latest JMetal library from http://jmetal.sourceforge.
net/ and list it on the classpath as follows:
java -classpath "$CLASSPATH:/path/to/JMetal.jar"
197
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above example demonstrates. Windows and Cygwin users should use
the semi-colon (;).
unable to negate values in <file>, incorrect number of values in a row
Emitted by the Negater command line utility when one of the files it is processing
contains an invalid number of values in a row. The file is expected to contain the same
number of values in a row as values passed to the -d,--direction command line
argument. The file will not be modified if this issue is detected.
unable to negate values in <file>, unable to parse number
Emitted by the Negater command line utility when one of the files it is processing
encounters a value it is unable to parse. The columns being negated must be numeric
values. The file will not be modified if this issue is detected.
argument is null or
<class> not assignable from <class>
When validating an expression tree using the node.isValid() method, details iden-
tifying why the tree is invalid are printed. The warning “argument is null” indicates
the tree is incomplete and contains a missing argument. Check to ensure all arguments
of all nodes within the tree are non-null. The warning “<class> not assignable from
<class>” indicates the required type of an argument did not match the return type of
the argument. If this warning appears when using Sequence,For or While nodes,
ensure you specify the return type of these nodes using the appropriate constructor.
unable to parse solution, ignoring remaining entries in the file or
insufficient number of entries in row, ignoring remaining rows in the file
Occurs when MetricFileReader or ResultFileReader encounter invalid data
in an input file. They automatically discard any remaining entries in the file, assuming
they are corrupt. This is primarily intended to allow the software to automatically
recover from a previous, interrupted execution. These warnings are provided to inform
the user that invalid entries are being discarded.
Unable to find the file ¡file¿
This warning is shown when running an example that must load a data file but the
data file could not be found. Ensure that the examples directory is located on your
classpath:
java -classpath "$CLASSPATH:examples" ...
Also ensure you are using the correct classpath separator. Linux users will use the
colon (:) as the above example demonstrates. Windows and Cygwin users should use
the semi-colon (;).
198
incorrect number of names, using defaults
Occurs when using the --names argument provided by ARFFConverter and
AerovisConverter to provide custom names for the decision variables and/or ob-
jectives, but the number of names provided is not correct. When providing names for
only the objectives, the number of names must match the number of objectives. When
providing names for both variables and objectives, the number of names must match
the number of variables and objectives in the data file. Otherwise, this warning is
displayed and the program uses default names.
population is empty, can not generate ARFF file
The ARFFConverter outputs an ARFF file using the last entry in a result file. If the
last entry is empty, then no ARFF file is generated.
199
200
Bibliography
Asafuddoula, M., Ray, T., and Sarker, R. (2015). A decomposition-based evolutionary algo-
rithm for many-objective optimization. IEEE Transactions on Evolutionary Computation,
19:445–460.
ack, T., Fogel, D. B., and Michalewicz, Z. (1997). Handbook of Evolutionary Computation.
Taylor & Francis, New York, NY.
Beume, N., Naujoks, B., and Emmerich, M. (2007). Sms-emoa: Multiobjective selec-
tion based on dominated hypervolume. European Journal of Operational Research,
181(3):1653–1669.
Beume, N. and Rudolph, G. (2006). Faster S-metric calculation by considering dominated
hypervolume as Klee’s measure problem. In Second International Association of Science
and Technology for Development (IASTED) Conference on Computational Intelligence,
pages 231–236, San Francisco, CA.
Bleuler, S., Laumanns, M., Thiele, L., and Zitzler, E. (2003). PISA—a platform and pro-
gramming language independent interface for search algorithms. In Evolutionary Multi-
Criterion Optimization (EMO 2003), pages 494–508, Faro, Portugal.
Bosman, P. A. and Thierens, D. (2003). The balance between proximity and diversity in
multiobjective evolutionary algorithms. IEEE Transactions on Evolutionary Computation,
7(2):174–188.
Cheng, R., Jin, Y., Olhofer, M., and Sendhoff, B. (2016). A reference vector guided evolu-
tionary algorithm for many-objective optimization. IEEE Transactions on Evolutionary
Computation, 99.
Coello Coello, C. A., Lamont, G. B., and Van Veldhuizen, D. A. (2007). Evolutionary
Algorithms for Solving Multi-Objective Problems. Springer Science+Business Media LLC,
New York, NY.
Corne, D. W., Jerram, N. R., Knowles, J. D., and Oates, M. J. (2001). PESA-II: Region-
based selection in evolutionary multiobjective optimization. In Proceedings of the Genetic
and Evolutionary Computation Conference (GECCO 2001), pages 283–290, San Francisco,
CA.
201
Corne, D. W. and Knowles, J. D. (2000). The Pareto envelope-based selection algorithm
for multiobjective optimization. In Proceedings of the 6th International Conference on
Parallel Problem Solving from Nature (PPSN VI), pages 839–848, Paris, France.
Deb, K. and Agrawal, R. B. (1994). Simulated binary crossover for continuous search space.
Technical Report No. IITK/ME/SMD-94027, Indian Institute of Technology, Kanpur,
India.
Deb, K., Anand, A., and Joshi, D. (2002). A computationally efficient evolutionary algorithm
for real-parameter optimization. Evolutionary Computation, 10:371–395.
Deb, K. and Goyal, M. (1996). A combined genetic adaptive search (geneas) for engineering
design. Computer Science and Informatics, 26(4):30–45.
Deb, K. and Jain, H. (2014). An evolutionary many-objective optimization algorithm using
reference-point-based nondominated sorting approach, part i: Solving problems with box
constraints. IEEE Transactions on Evolutionary Computation, 18(4):577–601.
Deb, K. and Jain, S. (2002). Running performance metrics for evolutionary multi-objective
optimization. KanGAL Report No. 2002004, Kanpur Genetic Algorithms Laboratory
(KanGAL), Indian Institute of Technology, Kanpur, India.
Deb, K., Mohan, M., and Mishra, S. (2003). A fast multi-objective evolutionary algorithm
for finding well-spread Pareto-optimal solutions. KanGAL Report No. 2003002, Kanpur
Genetic Algorithms Laboratory (KanGAL), Indian Institute of Technology, Kanpur, India.
Deb, K., Pratap, A., Agarwal, S., and Meyarivan, T. (2000). A fast elitist multi-objective
genetic algorithm: NSGA-II. IEEE Transactions on Evolutionary Computation, 6(2):182–
197.
Durillo, J. J., Nebro, A. J., Luna, F., and Alba, E. (2008). Solving three-objective optimiza-
tion problems using a new hybrid cellular genetic algorithm. In Parallel Problem Solving
form Nature - PPSN X, pages 661–670. Springer.
Eskandari, H., Geiger, C. D., and Lamont, G. B. (2007). Fastpga: A dynamic population
sizing approach for solving expensive multiobjective optimization problems. In Evolution-
ary Multi-Criterion Optimization: 4th International Conference, EMO 2007, Matsushima,
Japan, March 5-8, 2007, pages 141–155. Springer Berlin Heidelberg.
Fonseca, C. M. and Fleming, P. J. (1993). Genetic algorithms for multiobjective optimiza-
tion: Formulation, discussion and generalization. In Proceedings of the Fifth International
Conference Genetic Algorithms (ICGA 1993), pages 416–423, Urbana-Champaign, IL.
Fonseca, C. M. and Fleming, P. J. (1996). On the performance assessment and comparison of
stochastic multiobjective optimizers. In Parallel Problem Solving from Nature (PPSN IV),
pages 584–593, Berlin, Germany.
202
Goldberg, D. E. (1989). Genetic Algorithms in Search, Optimization and Machine Learning.
Addison-Wesley Publishing Company, Reading, MA.
Goldberg, D. E. and Jr., R. L. (1985). Alleles, loci, and the traveling salesman problem. In
1st International Conference on Genetic Algorithms and Their Applications.
Greiner, D., Winter, G., and Emperador, J. M. (2006). Enhancing the multiobjective opti-
mum design of structural trusses with evolutionary algorithms using DENSEA. In 44th
AIAA Aerospace Sciences Meeting and Exhibit, Aerospace Sciences Meetings.
Hadka, D. and Reed, P. (2012). Diagnostic assessment of search controls and failure modes
in many-objective evolutionary optimization. Evolutionary Computation, 20(3):423–452.
Hadka, D. and Reed, P. (2013). Borg: An auto-adaptive many-objective evolutionary com-
puting framework. Evolutionary Computation, 21(2):231–259.
Hansen and Kern (2004). Evaluating the cma evolution strategy on multimodal test func-
tions. In Eighth International Conference on Parallel Problem Solving from Nature PPSN
VIII, pages 282–291.
Hansen, M. P., Hansen, M. P., Jaszkiewicz, A., and Jaszkiewicz, A. (1998). Evaluating the
quality of approximations to the non-dominated set. Technical Report IMM-REP-1998-7,
Technical University of Denmark.
Higuchi, T., Tsutsui, S., and Yamamura, M. (2000). Theoretical analysis of simplex crossover
for real-coded genetic algorithms. In Parallel Problem Solving from Nature (PPSN VI),
pages 365–374.
Holland, J. H. (1975). Adaptation in Natural and Artificial Systems. University of Michigan
Press, Ann Arbor, MI.
Horn, J. and Nafpliotis, N. (1993). Multiobjective optimization using the Niched Pareto
Genetic Algorithm. IlliGAL Report No. 93005, Illinois Genetic Algorithms Laboratory
(IlliGAL), University of Illinois, Urbana-Champaign, IL.
Hughes, E. J. (2003). Multiple single objective pareto sampling. In Congress on Evolutionary
Computation, pages 2678–2684.
Hughes, E. J. (2005). Evolutionary many-objective optimisation: Many once or one many?
In The 2005 IEEE Congress on Evolutionary Computation (CEC 2005), pages 222–227,
Edinburgh, UK.
Igel, C., Hansen, N., and Roth, S. (2007). Covariance matrix adaptation for multi-objective
optimization. Evolutionary Computation, 15:1–28.
Kennedy, J. and Eberhart, R. (1995). Particle swarm optimization. In Proceedings of IEEE
International Conference on Neural Networks, volume 4, pages 1942–1948, Perth, Aus-
tralia.
203
Kita, H., Ono, I., and Kobayashi, S. (1999). Multi-parental extension of the unimodal
normal distribution crossover for real-coded genetic algorithms. In Proceedings of the
1999 Congress on Evolutionary Computation (CEC 1999), pages 1581–1588, Washington,
DC.
Knowles, J. and Corne, D. (2002). On metrics for comparing non-dominated sets. In Congress
on Evolutionary Computation (CEC 2002), pages 711–716, Honolulu, HI.
Knowles, J. D. and Corne, D. W. (1999). Approximating the nondominated front using the
Pareto Archived Evolution Strategy. Evolutionary Computation, 8:149–172.
Kollat, J. B. and Reed, P. M. (2006). Comparison of multi-objective evolutionary algorithms
for long-term monitoring design. Advances in Water Resources, 29(6):792–807.
Kukkonen, S. and Lampinen, J. (2005). GDE3: The third evolution step of generalized differ-
ential evolution. In The 2005 IEEE Congress on Evolutionary Computation (CEC 2005),
pages 443–450, Guanajuato, Mexico.
Laumanns, M., Thiele, L., Deb, K., and Zitzler, E. (2002). Combining convergence and diver-
sity in evolutionary multi-objective optimization. Evolutionary Computation, 10(3):263–
282.
Li, H. and Zhang, Q. (2009). Multiobjective optimization problems with complicated
Pareto sets, MOEA/D and NSGA-II. IEEE Transactions on Evolutionary Computation,
13(2):284–302.
Miettinen, K. M. (1999). Nonlinear Multiobjective Optimization. Kluwer Academic Publish-
ers, Norwell, MA.
Nebro, A. J., Alba, E., Molina, G., Chicano, F., Luna, F., and Durillo, J. J. (2007a). Optimal
antenna placement using a new multi-objective chc algorithm. In Proceedings of the 9th
Annual Conference on Genetic and Evolutionary Computation, pages 876–883.
Nebro, A. J., Durillo, J. J., Garc´ıa-Nieto, J., Coello Coello, C. A., Luna, F., and Alba,
E. (2009). SMPSO: A new PSO-based metaheuristic for multi-objective optimization.
In IEEE Symposium on Computational Intelligence in Multicriteria Decision-Making
(MCDM 2009), pages 66–73, Nashville, TN.
Nebro, A. J., Durillo, J. J., Luna, F., and Dorronsoro, B. (2007b). MOCell: A cellular genetic
algorithm for multiobjective optimization. International Journal of Intelligent Systems,
pages 25–36.
Nebro, A. J., Luna, F., Alba, E., Dorronsoro, B., Durillo, J. J., and Beham, A. (2008).
AbYSS: Adapting scatter search to multiobjective optimization. IEEE Transactions on
Evolutionary Computation, 12(4):439–457.
204
Rechenberg, I. (1971). Evolutionsstrategie: Optimierung technischer Systeme nach Prinzip-
ien der biologischen Evolution. PhD thesis, Fromman-Holzboog.
Schaffer, D. J. (1984). Multiple Objective Optimization with Vector Evaluated Genetic Algo-
rithms. PhD thesis, Vanderbilt University, Nashville, TN.
Schaffer, D. J. (1985). Multiple objective optimization with vector evaluated genetic algo-
rithms. In 1st International Conference on Genetic Algorithms, pages 93–100.
Sierra, M. R. and Coello Coello, C. A. (2005). Improving PSO-based multi-objective op-
timization using crowding, mutation and -dominance. In Evolutionary Multi-Criterion
Optimization (EMO 2005), pages 505–519, Guanajuato, Mexico.
Srinivas, N. and Deb, K. (1994). Multiobjective optimization using nondominated sorting
in genetic algorithms. Evolutionary Computation, 2(3):221–248.
Storn, R. and Price, K. (1997). Differential evolution — a simple and efficient heuristic for
global optimization over continuous spaces. Journal of Global Optimization, 11(4):341–359.
Tsutsui, S., Yamamura, M., and Higuchi, T. (1999). Multi-parent recombination with sim-
plex crossover in real coded genetic algorithms. In Genetic and Evolutionary Computation
Conference (GECCO 1999), pages 657–664, Orlando, FL.
Vrugt, J. A. and Robinson, B. A. (2007). Improved evolutionary optimization from genet-
ically adaptive multimethod search. Proceedings of the National Academy of Sciences,
104(3):708–711.
Vrugt, J. A., Robinson, B. A., and Hyman, J. M. (2009). Self-adaptive multimethod search
for global optimization in real-parameter spaces. IEEE Transactions on Evolutionary
Computation, 13(2):243–259.
While, L., Bradstreet, L., and Barone, L. (2012). A fast way of calculating exact hypervol-
umes. IEEE Transactions on Evolutionary Computation, 16(1):86–95.
Zhang, Q., Liu, W., and Li, H. (2009). The performance of a new version of MOEA/D
on CEC09 unconstrained MOP test instances. In Congress on Evolutionary Computation
(CEC 2009), pages 203–208, Trondheim, Norway.
Zitzler, E. and K¨unzli, S. (2004). Indicator-based selection in multiobjective search. In
Parallel Problem Solving from Nature (PPSN VIII), pages 832–842, Birmingham, UK.
Zitzler, E., Laumanns, M., and Thiele, L. (2002a). SPEA2: Improving the Strength Pareto
Evolutionary Algorithm For Multiobjective Optimization. International Center for Numer-
ical Methods in Engineering (CIMNE), Barcelona, Spain.
Zitzler, E., Laumanns, M., Thiele, L., Fonseca, C. M., and da Fonseca, V. G. (2002b). Why
quality assessment of multiobjective optimizers is difficult. In Genetic and Evolutionary
Computation Conference (GECCO 2002), pages 666–674, New York, NY.
205
Zitzler, E. and Thiele, L. (1999). Multiobjective evolutionary algorithms: A comparative
case study and the strength Pareto approach. IEEE Transactions on Evolutionary Com-
putation, 3(4):257–271.
Zitzler, E., Thiele, L., Laumanns, M., Fonseca, C. M., and da Fonseca, V. G. (2002c).
Performance assessment of multiobjective optimizers: An analysis and review. IEEE
Transactions on Evolutionary Computation, 7(2):117–132.
206

Navigation menu