1. Robin McDougall Scott Nokleby Mechatronic and Robotic Systems Laboratory 1

2. Outline Context and Background Multi-Objective PSO (MOPSO) via Pareto Dominance Parallelization of PSO (PAPSO) MOPAPSO Results 2

3. 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 3

4. 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

5. 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

6. 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

7. Motivation A typical OBMS objective could be to design a system to follow a given path… 7

8. Motivation OBMS with PSO synthesized mechanisms which could fulfill this task better than deterministic algorithms 8

9. Motivation With one major caveat…. PSO took hours instead of minutes 9

10. 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

11. 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

12. 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

13. 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

14. 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 14

15. Multi-Objective Optimization Imagine 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

16. 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

17. 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

18. 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

19. 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

20. 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

21. MOPAPSO Two Roles for Processors… 21 One MasterN# 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 PVEL Catch updated particle specs. Dispatch next particle job Update the repositoryEvery “m” iterations

22. 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

23. MOPAPSO – Benchmark One 23

24. MOPAPSO – Benchmark One 24

25. MOPAPSO – Benchmark Two 25

26. MOPAPSO – Benchmark Two 26

27. OBMS Example 27

28. Objective Functions 28

29. Results 29

30. Runtime Improvements 30

31. 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

32. Acknowledgements 32 Ontario Research Fund