Robin McDougallScott Nokleby

Mechatronic and Robotic Systems Laboratory

1

Outline

Context and BackgroundMulti-Objective PSO (MOPSO) via Pareto

DominanceParallelization of PSO (PAPSO)MOPAPSOResults

2

IntroductionIncreasing role for global optimization

techniques in engineering designAmbition in design leads to more highly-

parameterized systemsMore parameters lead to increasingly non-

linear objective function surfaces

3

IntroductionParticle 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

MotivationOptimization-Based Mechanism Synthesis

(OBMS)Highly parameterized systemUse optimization techniques to choose

parametersMore parameters typically lead to more non-

linear objective function surfacesEffects of which can confound

traditional optimization techniques

5

MotivationReplace 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

MotivationA typical OBMS objective could be to design

a system to follow a given path…

7

MotivationOBMS with PSO synthesized mechanisms

which could fulfill this task better than deterministic algorithms

8

MotivationWith 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 OptimizationCould 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 OptimizationWhat 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 OptimizationMOPSO uses Pareto Dominance to determine

set of solutions for one or more competing objectives

Each point in the optimal set constitutes a non-dominated solution

Two objective function systems form a front, more, a hyper-surface

14

Multi-Objective OptimizationImagine a two objective function system:

15

•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

MOPSOMOPSO 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

MOPSONo 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

PAPSOReduce runtime by performing swarm

activities simultaneouslyPSO lends itself well to parallelizationFitness, velocity, position updates

independent per swarmProcessors:

Master Processor to administrate swarm Slave Processors perform Objective Function

Evaluations and Particle Updates

18

PAPSONotes: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

MOPAPSOThe 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

MOPAPSOTwo Roles for Processors…

21

One Master N# of Slaves

Initializes the swarm

Creates a FIFO particle queue

Dispatches the first “N” jobs

Catch GBEST, PPOS, PVEL

Update Velocity

Calculate OFs for each Object

Return OFs, PPOS and PVELCatch updated particle specs.

Dispatch next particle job

Update the repositoryEvery “m” iterations

MOPAPSO – Benchmark TestsTo test effectiveness of MOPAPSO implementation:

Used two MOPSO benchmarks from the literature before applying to OBMS

Configuration:Nine-node grid running Rocks Cluster Distribution5 dual core 2.0 GHz processors with 1GB RAM eachacslX Interpconsole v2.4.1 using MPICH240 Particles, 100 “Iterations” (100 x 40 = Updates)

22

MOPAPSO – Benchmark One

23

MOPAPSO – Benchmark One

24

MOPAPSO – Benchmark Two

25

MOPAPSO – Benchmark Two

26

27

Objective Functions

28

Results

29

Runtime Improvements

30

Conclusions

31

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

Acknowledgements

32

Ontario Research Fund