Robin McDougall
Scott Nokleby
Mechatronic and Robotic Systems Laboratory
1
Outline
 Context and Background
 Multi-Objective PSO (MOPSO) via Pareto Dominance
 Parallelization of PSO (PAPSO)
 MOPAPSO
 Results
2
Introduction
 Increasing role for global optimization techniques in
engineering design
 Ambition in design leads to more highlyparameterized systems
 More parameters lead to increasingly non-linear
objective function surfaces
3
Introduction
 Particle Swarm Optimization (PSO) gaining
increasing attention in both research and applications
 Over time a number of variants have been utilized
with great success
 Many on the “Particle” level:




Particle Accelerations
Transient Social and Personal Weights
Dynamic Forms
… and many more
4
Motivation
 Optimization-Based Mechanism Synthesis (OBMS)
 Highly parameterized system
 Use optimization techniques to choose parameters
 More parameters typically lead to more non-linear
objective function surfaces
 Effects of which can confound
traditional optimization
techniques
5
Motivation
 Replace previously used deterministic techniques with
a global optimization technique


No need for parameter transforms
No need for “pseudo-global” techniques
 Prevent artificial constriction
of search space
6
Motivation
 A typical OBMS objective could be to design a system
to follow a given path…
7
Motivation
 OBMS with PSO synthesized mechanisms which could
fulfill this task better than deterministic algorithms
8
Motivation
 With one major caveat….
 PSO took hours instead of minutes
9
Objectives
 Use Multi-Objective PSO (MOPSO) to handle multi-
objective problem specifications
 Use Parallel Asynchronous PSO (PAPSO) to speed
things up
 Both topics well covered in the literature individually
 Little mention of combining the two
10
Multi-Objective Optimization
 Engineering design choices often involve balancing
competitive objectives:



Cost vs. Performance
Size vs. Strength
Effectiveness vs. Efficiency
 What options are available to us to deal with these
competing objectives?
11
Multi-Objective Optimization
 Could use a weighting scheme
 Concerns:


With no prior knowledge, how do you select the weights?
Potential to unfairly influence optimization before execution
begins
12
Multi-Objective Optimization
 What we would like to do is change:
to
 Shift the decision on when to decide how influential
each objective will be to after the optimization effort
instead of before hand
13
Multi-Objective Optimization
 MOPSO uses Pareto Dominance to determine set of
solutions for one or more competing objectives
 Each point in the optimal set constitutes a nondominated solution
 Two objective function systems form a front, more, a
hyper-surface
14
Multi-Objective Optimization
 Imagine a two objective function system:
•Instead of a single
optimum solution,
MOPSO delivers a front
of non-dominated
solutions
•Each point on the front
represents the best
possible solution for a
given objective function
with respect to the other
objective functions
15
MOPSO
 MOPSO requires two significant changes to the basic
form of PSO:
 Creation and active maintenance of a repository to
collect the non-dominated candidate solutions
 Modification of the basic form of the velocity equation
to choose a social leader form this repository instead of
of a global best
16
MOPSO
 No longer a single social leader (SL) available in
MOPSO
 Instead, need to choose a particle from the repository
to serve as the SL
 Use weighted Roulette Wheel procedure to select SL
 Biased towards sparsely populated regions of the
emerging front
17
PAPSO
 Reduce runtime by performing swarm activities
simultaneously
 PSO lends itself well to parallelization
 Fitness, velocity, position updates independent per
swarm
 Processors:
 Master Processor to administrate swarm
 Slave Processors perform Objective Function
Evaluations and Particle Updates
18
PAPSO
Notes:
 If (# Particles > Number of Processors)

FIFO queue for particles
 Asynchronous nature mitigates negative performance
effects caused by runtime variability
 Runtime improvement proportional to ratio of
Objective Function Calculation time to Network
Transmission Time
19
MOPAPSO
 The idea is to combine these variants:


MOPSO to provide formal multi-objective support
PAPSO to speed things up
 Requirements:


Should match MOPSO results
Should reduce overall runtime
20
MOPAPSO
Two Roles for Processors…
One Master
N# of Slaves
Initializes the swarm
Catch GBEST, PPOS, PVEL
Creates a FIFO particle queue
Update Velocity
Dispatches the first “N” jobs
Calculate OFs for each Object
Catch updated particle specs.
Return OFs, PPOS and PVEL
Dispatch next particle job
Update
Every “m”
theiterations
repository
21
MOPAPSO – Benchmark Tests
 To test effectiveness of MOPAPSO implementation:
 Used two MOPSO benchmarks from the literature
before applying to OBMS
 Configuration:
 Nine-node grid running Rocks Cluster Distribution
 5 dual core 2.0 GHz processors with 1GB RAM each
 acslX Interpconsole v2.4.1 using MPICH2
 40 Particles, 100 “Iterations” (100 x 40 = Updates)
22
MOPAPSO – Benchmark One
23
MOPAPSO – Benchmark One
24
MOPAPSO – Benchmark Two
25
MOPAPSO – Benchmark Two
26
OBMS Example
27
Objective Functions
28
Results
29
Runtime Improvements
30
Conclusions
 A high-level implementation of MOPAPSO has been
developed
 Testing of the algorithm on two benchmark problems
showed that MOPAPSO can easily locate Pareto-fronts
for multi-objective problems
 MOPAPSO effectively solved OBMS featuring multiple
objectives
31
Acknowledgements
 Ontario Research Fund
32