330 likes | 580 Views
Grashof Mechanism Synthesis Using Multi-Objective Parallel Asynchronous Particle Swarm Optimization. Robin McDougall Scott Nokleby Mechatronic and Robotic Systems Laboratory. Outline. Context and Background Multi-Objective PSO (MOPSO) via Pareto Dominance Parallelization of PSO (PAPSO)
E N D
Grashof Mechanism Synthesis Using Multi-Objective Parallel Asynchronous Particle Swarm Optimization Robin McDougall Scott Nokleby Mechatronic and Robotic Systems Laboratory
Outline • Context and Background • Multi-Objective PSO (MOPSO) via Pareto Dominance • Parallelization of PSO (PAPSO) • MOPAPSO • Results
Introduction • Increasing role for global optimization techniques in engineering design • Ambition in design leads to more highly-parameterized systems • More parameters lead to increasingly non-linear objective function surfaces
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
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 confoundtraditional optimization techniques
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
Motivation • A typical OBMS objective could be to design a system to follow a given path…
Motivation • OBMS with PSO synthesized mechanisms which could fulfill this task better than deterministic algorithms
Motivation • With one major caveat…. • PSO took hours instead of minutes
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
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?
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
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
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 non-dominated solution • Two objective function systems form a front, more, a hyper-surface
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
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
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
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
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
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
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 Return OFs, PPOS and PVEL Catch updated particle specs. Dispatch next particle job Update the repository Every “m” iterations
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)
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
Acknowledgements • Ontario Research Fund