Upload
angelina-wilkins
View
223
Download
1
Tags:
Embed Size (px)
Citation preview
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