HEURISTISCHE OPLOSSINGSMETHODEN VOOR HET TIME-CONSTRAINED PROJECT SCHEDULING PROBLEM

Transcriptie

1 Faculteit Economie en Bedrijfskunde Academiejaar HEURISTISCHE OPLOSSINGSMETHODEN VOOR HET TIME-CONSTRAINED PROJECT SCHEDULING PROBLEM Masterproef voorgedragen tot het behalen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur Matthias De Beule onder leiding van Prof. dr. M. Vanhoucke

2 Faculteit Economie en Bedrijfskunde Academiejaar HEURISTISCHE OPLOSSINGSMETHODEN VOOR HET TIME-CONSTRAINED PROJECT SCHEDULING PROBLEM Masterproef voorgedragen tot het behalen van de graad van Master in de Toegepaste Economische Wetenschappen: Handelsingenieur Matthias De Beule onder leiding van Prof. dr. M. Vanhoucke

3 PERMISSION Ondergetekende verklaart dat de inhoud van deze masterproef mag geraadpleegd en/of gereproduceerd worden, mits bronvermelding. Matthias De Beule

4 Woord vooraf U staat op het punt een masterproef te lezen die de resultaten en bevindingen bevat van een onderzoek naar metaheuristieken tot het oplossen van het Time-Constrained Project Scheduling Problem. Met dit onderzoek zal ik mijn studie Master in de Toegepaste Economische Wetenschappen: Handelsingenieur afronden. Gedurende de 5 jarige opleiding aan de Universiteit Gent vond ik het domein rond projectplanning één van de meest interessante en uitdagende. De keuze voor het TCPS-probleem als thesisonderwerp, een subdomein dat academisch nog in zijn kinderschoenen staat, lag dan ook in het verlengde van deze gedachte. En hoewel ik later hoogstwaarschijnlijk nauwelijks met het TCPS-probleem zal geconfronteerd worden, geloof ik rotsvast in de gedachte dat deze thesis van zeer grote waarde zal zijn in mijn latere professionele carrière. Het gezegde Het doel is de weg, niet het resultaat sluit hier naadloos bij aan. Het blijven zoeken naar oplossingen en verbeteringen, het kritisch bediscussiëren van stellingen en het helder communiceren van bevindingen zijn de grootste vruchten van dit werk. Ook met betrekking tot metaheuristieken meen ik mijn theoretische baggage op nuttig wijze vergroot te hebben, wat alleen maar voordelig kan zijn voor het doctoraat dat ik in september 2011 bij GeoIntelligence zal aanvangen. ii

5 iii Tenslotte wil ik nog een woord van dank richten aan diverse personen die bijgedragen hebben tot het welslagen van deze masterproef. Vooreerst dank ik deheer Van Peteghem, begeleider van deze masterproef, voor zijn eeuwige bereidheid tot hulp en sturing. Vervolgens dank ik Cédric Verbeeck, met wie ik dit thesisonderwerp deel, voor zijn kritische blik op mijn werk en de vreugde en relativering die hij er toe bijbracht. Om dezelfde reden dank ik ook Maarten Verruyssen, de derde persoon die rond hetzelfde onderwerp onderzoek deed. Verder richt ik ook mijn dank aan Annelies De Beule, voor het zeer grondig nalezen van deze masterproef. Het laatste dankwoord is voor mijn ouders, die mij de kans en de tijd hebben gegeven zowel mijn studies als deze masterproef tot een goed einde te brengen. Ik wens U veel leesplezier, Matthias De Beule Mei 2011

6 Inhoudsopgave Lijst van figuren Lijst van tabellen Gebruikte afkortingen Gebruikte variabelen vii xi xiii xv 1 Inleiding Situering Projectplanning Het Resource-Constrained Project Scheduling Problem Het Time-Constrained Project Scheduling Problem Kadering Mathematisch Model Voorbeeld en Voorstelling Overzicht van de literatuur Onderzoeksdoelstelling Oplossingsmethoden Exacte oplossingsmethoden Heuristische oplossingsmethoden Metaheuristische oplossingsmethoden Representatie van een oplossing Overzicht van komende hoofdstukken Darwinian Particle Swarm Optimization Inleiding Particle Swarm Optimization Werking van het basis PSO algoritme Uitbreidingen op het basismodel Darwinian Particle Swarm Optimization iv

7 Inhoudsopgave v 2.2 Oplossingsmethode Populatie generatie Global Search Local DPSO Greedy Random Adaptive Search Procedure Inleiding Oplossingsmethode Constructie van een initiële oplossing Verbetering van een oplossing Local search Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer Inleiding Oplossingsmethode Fase 1: GRASP Fase 2: LDPSO Performantie van de methoden Test datasets Measures of Performance Stopcriterium DPSO-LDPSO Parameters Parameterkalibratie Performantie van de verschillende componenten GRASP Parameters Parameterkalibratie Performantie van de verschillende componenten GRASP-LDPSO Parameters Parameterkalibratie Performantie van de verschillende componenten Vergelijking van de performantie tussen de methoden Robuustheid van de methoden Variatie op het stopcriterium Variatie op de deadline Variatie op de datasets

8 Inhoudsopgave vi 6 Vergelijking met externe methoden Introductie tot de twee andere metaheuristieken Vergelijking van de performantie bij een een oplopend aantal schedules Totale kost Percentage optimaal opgeloste projecten Vergelijking van de performantie op basis van wisselende deadlines Vergelijken van de performantie op basis van projectkarakteristieken Conclusie Algemeen besluit Gevoerd onderzoek Beperkingen van het onderzoek Suggesties tot verder onderzoek A Kenmerken van de j30 projectset 115 B Bijlagen bij performantie van de methoden 116 C Testresultaten DPSO-LDPSO 127 D Testresultaten GRASP 151 E Testresultaten GRASP-LDPSO 178 Bibliografie 205

9 Lijst van figuren 1.1 Voorstelling van de release time, de deadline en de duurtijd van activiteit j Een voorbeeldproject met 12 activiteiten, waarvan 0 en 11 dummy activiteiten zijn die de start en het einde van het project aanduiden. De getallen boven de activiteiten zijn respectievelijk hun duurtijd en hun vraag naar resource R De optimale oplossing voor de RCPSP-variant van het probleem Een mogelijke oplossing voor het voorbeeldprobleem De optimale oplossing voor een deadline van 16 tijdseenheden Een andere optimale oplossing voor een deadline van 16 tijdseenheden Voorstelling van een shift van een activiteit Voorstelling van shift-gebaseerde representatieschemas Grafische weergave van het swarmgedrag van partikels. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en Flowchart van het basis PSO algoritme Illustratie van de populatie generatie methode Grafische weergave van de populatie generatie. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en Flowchart van het DPSO Grafische weergave van lokale swarms. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en Flowchart van het basis GRASP Flowchart van de constructiefase van de GRASP Gemiddelde projectkost voor DPSO-LDPSO voor variatie over parameters nrofswarms en pop. De lengte-as varieert over pop, de diepte-as over nrofswarms Percentage optimale oplossingen in functie van parameters c 1 en c 2. De lengteas varieert over c 1, de diepte-as over c Gemiddelde projectkost in functie van parameters c 1 en c 2. De lengte-as varieert over c 2, de diepte-as over c vii

10 Lijst van figuren viii 5.4 Kalibratie van parameters α en β naar percentage optimaal opgeloste projecten. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as Kalibratie van parameters α en β naar gemiddelde projectkost. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as Gemiddelde kost per project in functie van Resource Frequentie Gemiddelde kost per project in functie van Resource Sterkte Gemiddelde kost per project in functie van Netwerkcomplexiteit Gemiddelde kwadratische afwijking van de gemiddelde projectkost ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken Gemiddelde kwadratische afwijking van de niet-beïnvloede situatie voor het percentage gevonden optimale oplossingen voor de verschillende projectkenmerken Vergelijking tussen het percentage optimale oplossingen gevonden door de methoden voor verschillend aantal schedules Vergelijking tussen het percentage bijna optimale oplossingen gevonden door de methoden voor verschillend aantal schedules Vergelijking tussen de gemiddelde projectkost voor de methoden voor verschillend aantal schedules Vergelijking tussen de maximale projectkost voor de methoden voor verschillend aantal schedules Vergelijking tussen de gemiddelde projectkost voor de methoden voor verschillende waarden van α Vergelijking tussen de maximale projectkost voor de methoden voor verschillende waarden van α Vergelijking tussen het percentage optimale oplossingen gevonden door de methoden voor verschillende waarden van α Vergelijking tussen het percentage bijna optimale oplossingen gevonden door de methoden voor verschillende waarden van α Vergelijking van de gemiddelde kost bij projecten met de minimal makespan als deadline Procentuele verbetering van de gemiddelde kost bij projecten met de minimal makespan als deadline Vergelijking van het percentage correct opgeloste projecten met de minimal makespan als deadline Procentuele verbetering van het percentage correct opgeloste projecten met de minimal makespan als deadline Gemiddelde kost bij toenemende waarden van α Verbetering van de gemiddelde kost bij toenemende waarden van α

11 Lijst van figuren ix 6.7 Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde resourcefrequentie Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde resourcesterkte Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde netwerkcomplexiteit Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde resourcefrequentie Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde resourcesterkte Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde netwerkcomplexiteit Gemiddelde kwadratische afwijking van de gemiddelde projectkost ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken Gemiddelde kwadratische afwijking van het percentage niet gevonden optimale oplossingen ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken B.1 Kalibratie van parameters α en β naar maximale projectkost. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as B.2 Gemiddelde kost per project van het DPSO-LDPSO volgens verschillende projectkarakteristieken. De bovenste rij waarden (0.25, 0.5, 0.75, 1.0) zijn de verschillende RF waarden. De groeperende rij waarden eronder (0.2, 0.5, 0.7, 1.0) zijn de verschillende RS waarden. De verschillende curven tonen ten slotte de kostperformantie voor de verschillende NC waarden B.3 Gemiddelde kost per project van de GRASP volgens verschillende projectkarakteristieken. De bovenste rij waarden (0.25, 0.5, 0.75, 1.0) zijn de verschillende RF waarden. De groeperende rij waarden eronder (0.2, 0.5, 0.7, 1.0) zijn de verschillende RS waarden. De verschillende curven tonen ten slotte de kostperformantie voor de verschillende NC waarden B.4 Gemiddelde kost per project van de GRASP-LDPSO volgens verschillende projectkarakteristieken. De bovenste rij waarden (0.25, 0.5, 0.75, 1.0) zijn de verschillende RF waarden. De groeperende rij waarden eronder (0.2, 0.5, 0.7, 1.0) zijn de verschillende RS waarden. De verschillende curven tonen ten slotte de kostperformantie voor de verschillende NC waarden B.5 Percentage projecten optimaal opgelost door het DPSO-LDPSO volgens verschillende projectkarakteristieken B.6 Percentage projecten optimaal opgelost door GRASP volgens verschillende projectkarakteristieken

12 Lijst van figuren x B.7 Percentage projecten optimaal opgelost door het GRASP-LDPSO volgens verschillende projectkarakteristieken B.8 Percentage projecten optimaal opgelost naar Resource Frequentie B.9 Percentage projecten optimaal opgelost naar Resource Strength B.10 Percentage projecten optimaal opgelost naar Netwerkcomplexiteit

13 Lijst van tabellen 5.1 Standaard parameterwaarden voor het DPSO-LDPSO Kalibratie van parameter fase Kalibratie van parameter Max Search Counter (msc) Kalibratie van parameter Particles in Temporary Swarm Kalibratie van parameter Mutation Rate (mur) Kalibratie van parameter pop Kalibratie van parameter nrofswarms Gezamenlijke kalibratie van parameters nrofswarms en pop Kalibratie van parameter w Kalibratie van parameter inertiaweight reduction (iwr) Kalibratie van parameter γ Kalibratie van parameters c 1 en c 2 naar percentage optimale oplossingen Kalibratie van parameters c 1 en c 2 naar gemiddelde projectkost Performantie van DPSO-LDPSO na de global search en de local search fase Verschil in performantie tussen DPSO en DPSO-LDPSO Verschil in performantie tussen DPSO-LDPSO met of zonder local search methode Kalibratie van parameters α en β naar percentage optimaal opgeloste projecten Kalibratie van parameters α en β naar gemiddelde projectkost Performantie van GRASP zonder oplossingsverbetering (2) en local search (3) Performantie van GRASP zonder local search Standaard parameterwaarden voor het GRASP-LDPSO Kalibratie van parameter fase Kalibratie van parameter b Verschil in performantie tussen eerste en tweede fase van de GRASP-LDPSO Verschil in performantie tussen eerste en tweede fase zonder Local Search methode Overzicht kostperformantie DPSO-LDPSO Overzicht kostperformantie GRASP Overzicht kostperformantie GRASP-LDPSO xi

14 Lijst van tabellen xii 5.29 Vergelijking tussen het percentage strikt bijna optimale oplossingen gevonden door de methoden voor verschillend aantal schedules Percentage strikt bijna optimale oplossingen gevonden door de verschillende methoden voor verschillende waarden van α Performantie van de methoden op de j60 projectset Performantie van de methoden op de j120 projectset Evolutie van de performantie van de drie algoritmen op de verschillende projectsets A.1 Kenmerken van de j30 projectset B.1 Kalibratie van parameters α en β naar maximale kost B.2 Overzicht optimaliteitsperformantie DPSO-LDPSO B.3 Overzicht optimaliteitsperformantie GRASP B.4 Overzicht optimaliteitsperformantie GRASP-LDPSO

15 Gebruikte afkortingen ACO Ant Colony Optimization AHPSO Adaptive Hierarchical Particle Swarm Optimizer AIS Artificial Immune System ARPSO Attractive Repulsive Particle Swarm Optimization CPM Critical Path Method CPSO Charged Particle Swarm Optimizer DMS-PSO Dynamic Multi-Swarm Particle Swarm Optimization DPSO Darwinian Particle Swarm Optimization / Darwinian Particle Swarm Optimizer EM Electro Magnetism EST Earliest Start Time FIPS Fully Informed Particle Swarm GA Genetic Algorithm GRASP Greedy Random Adaptive Search Procedure HPSO-TVAC self-organizing Hierarchical Particle Swarm Optimizer met Time-varying Acceleration Coefficients ILP Integer Linear Programming IWR Inertiaweight Reduction LST Latest Start Time LDPSO Local Darwinian Particle Swarm Optimization / Local Darwinian Particle Swarm Optimizer xiii

16 Hoofdstuk 0. Gebruikte afkortingen xiv MPSO-TVAC Particle Swarm Optimizer met Mutatie en Time-Varying Acceleration Coefficients msc Max Search Counter MSPSP Multi-Skill Project Scheduling Problem mur Mutation Rate NC Netwerk Complexiteit NPV Net Present Value PMBOK Project Management Body of Knowledge PMI Project Management Institute PSO Particle Swarm Optimization / Particle Swarm Optimizer PSPLib Project Scheduling Problem Library PERT Program Evaluation and Review Technique RCL Restricted Candidate List RCPSP Resource-Constrained Project Scheduling Problem RF Resource Frequentie RIP Resource Investment Problem RLP Resource Levelling Problem RS Resource Sterkte SA Simulated Annealing SGS Schedule Generation Scheme SMS Single Machine Scheduling SS Scatter Search TCPSP Time-Constrained Project Scheduling Problem TS Tabu Search TVAC Time-Variant Acceleration Coefficients

17 Gebruikte variabelen r j d j geplande starttijd van activiteit j deadline van activiteit j p j duurtijd van activiteit j, = DUR j Q kt voorziene basiscapaciteit van resource k voor tijdseenheid t c H kt huurkost op tijdstip t per resource bijgehuurd van type k H kt aantal resources van type k bijgehuurd op tijdstip t Q min k Q max k minimale nodige basiscapaciteit van resourcetype k om een individuele activiteit in het project zonder huurkost te kunnen schedulen nodige basiscapaciteit van resourcetype k om alle activiteiten binnen het project op hun Earliest Start Time te kunnen schedulen zonder huurkosten F (x i ) evaluatie van oplossingsvector x i volgens de doelfunctie, i.e. de totale huurkost V m i,t X m i,t snelheid van partikel/oplossing i in dimensie/voor activiteit m tijdens iteratie t waarde van partikel i in dimensie m tijdens iteratie t / shift van activiteit m in oplossing i tijdens iteratie t pbest i = [ pbest 1 i,..., ] pbestm i, lokaal beste oplossing gevonden door partikel/oplossing i ( dimensies/activiteiten m M) gbest = [ gbest 1,..., gbest M], globaal beste oplossing gevonden door de hele swarm ( dimensies/activiteiten m M) S max j maximaal toelaatbare verschuiving van activiteit j ST max j EST j maximaal toelaatbare starttijd van activiteit j earliest start time van activiteit j LST j latest start time van activiteit j xv

18 Hoofdstuk 1 Inleiding 1.1 Situering Projectplanning Het Project Management Institute (PMI) definieert een project als: Een tijdelijke groepsactiviteit, gevormd met het doel een uniek product, dienst of resultaat voort te brengen. Het is tijdelijk in die zin dat het een gekend begin en einde in de tijd heeft, en daardoor ook gekende dimensies en noodzakelijke hulpmiddelen. Bovendien is een project uniek in die zin dat het geen routineklus is, maar een specifieke verzameling van handelingen, ontworpen om één doel te bereiken. [...] (Project Management Institute, 2011) De gegeven definitie ziet het concept project dus heel breed. De constructie van een brug of de bouw van een stadion zijn logische voorbeelden, maar de ontwikkeling van software, de overname van en integratie in een ander bedrijf of het opzetten van een reddingsactie na een natuurramp zijn dat evenzeer. Al deze projecten worden in de huidige technisch-economische omgeving groter en complexer, wat de kans op slagen van het project negatief beïnvloedt. Volgens een studie van de Standish Group in 2009, die zich vooral toespitst op projecten in de IT-sector, waren projecten slechts in 32% van de onderzochte gevallen een succes, terwijl 24% bestempeld werden als complete falingen. Tot slot werden 44% van de projecten niet opgeleverd binnen de oorspronkelijk toegekende tijdslimiet (The Standish Group, 2009). Tegelijkertijd is er een toenemende druk om projecten tijdig en zo financieel zuinig mogelijk te voltooien. De toenemende complexiteit van projecten en de toenemende druk op project managers hebben aanleiding gegeven tot de opkomst van geautomatiseerde hulpmiddelen binnen het Project Management vakgebied die de menselijke werklast en werkdruk moeten verlichten en de kans op succes van het project moeten vergroten. 1

19 Hoofdstuk 1. Inleiding 2 Project Management wordt door het PMI gedefinieerd als: De toepassing van kennis, vaardigheden en technieken om projecten effectief en efficiënt uit te voeren. Het is een strategische competentie voor organisaties, dat hen in staat stelt de resultaten van projecten te linken aan business goals en dus om beter te kunnen concurreren in de markt. Deze definitie wijst op het belang van goede technieken en vaardigheden voor het plannen en uitvoeren van projecten omdat ze de bedrijven in staat stellen een competitief voordeel in de markt te behalen. Goede technieken en vaardigheden maken dus een integraal deel uit van succesvol Project Management. Het boek A Guide to the Project Management Body of Knowledge (PMBOK Guide) (PMI, 2008) stelt vervolgens dat er 5 terugkerende processen binnen Project Management plaatsvinden: ˆ Initialisatie van een project ˆ Planning van het project ˆ Uitvoering van het project ˆ Opvolging van en controle op het project ˆ Afsluiten van het project In een typeproject dat effectief gemanaged wordt, is het plannen van het project dus één van de essentiële bouwstenen in de voorbereiding op de uitvoering van het project. Een oudere survey, uitgevoerd door Spikes Cavell, identificeert het gebrek aan planning (39%) als één van de top drie redenen waarom projecten falen, naast slechte communicatie (57%) en het gebrek aan kwaliteitscontrole (35%) (Spikes Cavell & Company, 1998). Deze observaties uit de praktijk tonen het belang aan van goede planning en schedules voor het welslagen van een project. Eén van de subprocessen binnen de Planningsfase is de creatie van het projectplan (inclusief het project schedule, i.e. het planningsrooster van alle nodige activiteiten binnen het project). Deze thesis heeft als doel het geautomatiseerd aanleveren van dergelijke schedules voor een type complexe projectplannen (waarover later meer), die door hun grootte en complexiteit niet meer efficiënt en effectief met de hand door de projectmanager kunnen opgesteld worden en als dusdanig mee de oorzaak vormen voor het falen van projecten. Bovendien moet het de project managers in staat stellen adequaat op de toenemende druk van hoger hand (i.e. het tijdig en zo economisch mogelijk opleveren van het project) te reageren.

20 Hoofdstuk 1. Inleiding 3 Om deze projectplannen geautomatiseerd aan te leveren wordt er gebruik gemaakt van verscheidene technieken uit de tak van de Operations Research. In Operations Research wordt er intensief rond optimalisatie gewerkt. Optimalisatie is immers ook het doel van Project Planning, i.e. het opstellen van een volgens bepaalde maatstaven optimaal projectplan. In deze thesis worden projectschedules automatisch aangeleverd voor een bepaald type project planning probleem. Er bestaan binnen het domein van projectplanning immers verschillende types planningsproblemen, elk met hun eigen praktische toepassingen. Voor deze thesis wordt het subdomein van resource-constrained scheduling problems gebruikt. In tegenstelling tot PERT of CPM, de basisproblemen binnen projectplanning, worden er bij resource-constrained scheduling problems hulpmiddelen (resources) geïntroduceerd die nodig zijn om activiteiten uit te kunnen voeren en waarvan het probleem er slechts een beperkte capaciteit of hoeveelheid voorziet. Het archetype van het resource-constrained scheduling problem is het Resource- Constrained Project Scheduling Problem (RCPSP), dat hieronder verder wordt uitgelegd Het Resource-Constrained Project Scheduling Problem Binnen het uitgebreide domein van de resource-constrained scheduling problems is het Resource-Constrained Project Scheduling Problem, kortweg RCPSP, het overkoepelend algemeen probleem. Het RCPSP is een combinatorieel probleem (combinatorial problem), wat wil zeggen dat er minstens één element uit de eindige verzameling van mogelijke oplossingen voor het probleem, optimaal is. Een RCPS-probleem bestaat uit n te schedulen activiteiten. Het RCPSP kent daarbij starttijden toe aan elke activiteit binnen het project. Elke activiteit wordt in de eerste plaats gekenmerkt door een specifieke duurtijd. De uitvoering van een activiteit neemt bijvoorbeeld 5 tijdseenheden in beslag. Tussen de activiteiten bestaan er vervolgens volgorderelaties. Zo moet een zekere activiteit 7 (bijvoorbeeld het graven van de fundering) voltooid zijn voor activiteit 9 (gieten van beton voor de fundering) kan beginnen. Activiteit 7 wordt de predecessor van activiteit 9 genoemd en omgekeerd heet activiteit 9 de successor van activiteit 7. Verder vraagt elke activiteit gedurende diens uitvoering bepaalde hulpmiddelden (resources). Het RCPSP voorziet K resourcetypes. Van elk type is op elk tijdstip voor de gehele duurtijd van het project slechts een beperkte capaciteit voorhanden. Het doel van het RCPSP is het minimaliseren van de totale duurtijd van het project, ook wel de makespan genoemd. Daarbij moeten alle activiteiten binnen de makespan gescheduled worden zonder dat op gelijk welke moment de vraag naar resources het aanbod overschrijdt en zonder de volgorderelaties tussen de activiteiten te schenden.

21 Hoofdstuk 1. Inleiding 4 Binnen het RCPSP-domein bestaan er nog tal van varianten: Multi-mode RCPSP Eén van deze varianten is het Multi-mode RCPSP, waarbij activiteiten verschillende modi kunnen aannemen, elk met hun eigen duurtijd en hulpmiddelenvereisten. Voor elke activiteit moet dus niet enkel over de starttijd beslist worden, maar ook over de modus waarin de activiteit uitgevoerd wordt. RCPSP met preemptive scheduling Bij het reguliere RCPSP moeten activiteiten die reeds begonnen zijn, ook afgewerkt worden. Er bestaat echter een variant op het RCPSP die deze vereiste relaxeert en scheiding van de uitvoering in de tijd toestaat. Het scheiden in de tijd van de uitvoering van een activiteit wordt ook wel preemptive scheduling genoemd. RCPSP met stochastische duurtijden Nog een andere variant stelt dat de duurtijden van activiteiten stochastisch verdeeld zijn, terwijl bij het basis RCPSP de duurtijden deterministisch zijn. Bij het berekenen van de optimale makespan (in zoverre dé optimale makespan dan nog kan bestaan) moet met de stochastische verdeling van de duurtijden van de activiteiten rekening gehouden worden. Multi-Skill Project Scheduling Problem Het Multi-Skill Project Scheduling Problem, of MSPSP, stelt resources voor als werknemers, elk met hun eigen eindige set aan skills. Deze werknemers kunnen dus slechts aan taken werken waarvoor ze gekwalificeerd zijn. Eens een taak is afgewerkt, kan de werknemer maar aan een andere taak beginnen waarvoor hij ook gekwalificeerd is. Maximum Time Lags De Maximum Time Lags variant voegt een extra voorwaarde toe aan het basis RCPSP. Een activiteit moet binnen een bepaald maximaal tijdsverschil (i.e. maximum time lag) van de start van zijn voorgangers ook een aanvang nemen. Resource Investment Problem Het Resource Investment Problem (RIP) is een iets minder verwant probleem aan het RCPSP. Het deelt het principe van volgorderelaties, het principe dat activiteiten resources nodig hebben voor hun uitvoering en waarbij de vraag ernaar nooit het aanbod mag overschrijden en het principe van niet preëmptief schedulen van activiteiten in de tijd. Het RIP kent echter een verschillende doelfunctie. Het RCPSP probleem tracht de totale makespan van het project te minimaliseren. Het RIP daarentegen, heeft een vooraf gekende deadline waarbinnen het project moet afgewerkt worden. Het RIP daarentegen tracht de nodige investeringen in resourcecapaciteit (een investering die geldt voor de gehele duurtijd van het project) te minimaliseren. Resource Levelling Problem Het Resource Levelling Problem (RLP), vervolgens, is gelijkaardig aan het RIP. Het heeft echter een afwijkende doelfunctie. Het RLP tracht de activiteiten dusdanig in te plannen dat de fluctuatie van de vraag naar resources

22 Hoofdstuk 1. Inleiding 5 over de gehele duurtijd van het project wordt geminimaliseerd. Immers, hoe constanter de vraag naar een bepaald type resource, hoe lager de investering in de capaciteit van dit type resource (i.e. het aanbod) kan zijn, hoe goedkoper het project kan uitgevoerd worden. Time-Constrained Project Scheduling Problem Deze thesis handelt over een laatste variant op het RCPSP: Het Time-Constrained Project Scheduling Problem (TCPSP). Een verdere uiteenzetting van dit specifiek probleem wordt gegeven in het volgende deel. Een uitgebreide uiteenzetting van de andere problemen kan gevonden worden in Klein (2000) en Artigues et al. (2008). 1.2 Het Time-Constrained Project Scheduling Problem Kadering Het Time-Constrained Project Scheduling Problem, of TCPSP, is een bijzonder type planningsprobleem. Zoals bij alle resource-constrained scheduling problems, bestaat het TCPSP uit n in te plannen activiteiten. Tussen deze activiteiten bestaan er volgorderelaties. Zo moet één activiteit gedaan zijn voor zijn gekende opvolgers kunnen beginnen. Bovendien vraagt elke activiteit gedurende diens uitvoering bepaalde resources. Het TCPSP voorziet K types resources en van elk type is op elk tijdstip van de gehele duurtijd van het project slechts een beperkte basiscapaciteit voorhanden. Het TCPSP is nauw verwant met het Resource Leveling Problem in die zin dat het ook een gekende deadline voor de voltooiing van het totale project hanteert. Echter, in tegenstelling tot het RLP wordt er geen beslissing genomen over de investering in de nodige resources van elk type voor de gehele duurtijd van het project. In het TCPSP is er, net als bij het RCPSP, voor elke tijdseenheid een eindige en beperkte basishoeveelheid resources voorradig. Omwille van een strikt toegekende deadline voor de voltooiing van het project kan het echter noodzakelijk zijn dat er op bepaalde tijdstippen extra resources moeten bijgehuurd worden om alle activiteiten correct binnen de deadline in te kunnen plannen. Het TCPSP tracht daarbij de totale huurkosten voor extra resources over het hele project te minimaliseren. Het Time-Constrained Project Scheduling Problem kent in de praktijk vele toepassingen. Enkele voorbeelden zijn: het met een beperkt team implementeren van Six-Sigma principes in een bedrijf, voor een door het management opgelegde deadline, de bewerking van een film met beperkt materieel voor de première op een filmfestival of het bouwen van een Olympisch dorp voor de aanvang van de Olympische Spelen.

23 Hoofdstuk 1. Inleiding 6 Het TCPSP is net als het RCPSP een combinatorieel probleem. Hoewel dit impliceert dat de optimale oplossing zich in een eindige set van mogelijke oplossingen bevindt, is het TCPSP volgens Neumann et al. (2002) een NP-hard probleem. Dit wil zeggen dat ondanks het feit dat een oplossing voor het probleem in polynomial time 1 geverifieerd kan worden, er geen efficiënte manier voor de constructie van de optimale oplossing voor het probleem gekend is. De tijd die nodig is voor het vinden van de optimale oplossing stijgt dan ook exponentieel met de toenemende complexiteit van het probleem. Het toepassen van exacte oplossingsmethoden op het TCPSP, zoals een branch and bound methode, is bijgevolg niet aan te raden, wil men in aanvaardbare tijdspanne tot een goede oplossing komen. Het enumereren van alle mogelijke oplossingen voor het probleem zou immers onaanvaardbaar veel tijd in beslag nemen (tot wel miljoenen jaren), zelfs met state of the art rekentechnologie. Omwille van deze karakteristiek van het TCPSP wordt in deze masterproef gewerkt met (meta-)heuristische oplossingsmethoden, die binnen een beperkte tijdspanne aanvaardbaar goede oplossingen trachten te vinden. Tot slot wordt het TCPSP gekenmerkt door een non-regular measure of performance of een niet-reguliere doelfunctie. Dat wil zeggen dat de doelfunctie van het TCPSP een dalende functie kan zijn van de eindtijden van de activiteiten, in de veronderstelling dat het om een minimalisatie probleem gaat. Het uitstellen van de start van een activiteit (deterministische duurtijd is verondersteld) kan dan leiden tot een verbetering van de doelfunctie. Bij een regular measure of performance is de doelfunctie een niet-dalende functie van de eindtijden van de activiteiten. Het RCPSP, bijvoorbeeld, heeft een regular measure of performance, i.e. de totale makespan van het project. Het uitstellen van eindtijden van activiteiten bij een RCPSprobleem kan immers alleen een negatieve impact hebben op de makespan van het project en dus de doelfunctie. In het beste geval heeft het uitstellen van activiteiten in de tijd helemaal geen impact. Voor het TCPSP daarentegen, kan het verlaten van bepaalde activiteiten betekenen dat huurkosten vermeden kunnen worden en bijgevolg dat de doelfunctie verbetert Mathematisch Model Het voorgestelde mathematisch model voor het TCPSP is gebaseerd op de mathematische formulering gegeven door Guldemond et al. (2008). Guldemond et al. maken echter gebruik van overuren en van verschillende modi waarin activiteiten gescheduled kunnen worden. Deze uitbreidingen worden in deze masterproef evenwel niet toegepast. Het oplossen van het TCPS-probleem bestaat uit het toekennen van starttijden r j aan een set van n activiteiten, {J 1,..., J n }, zodanig dat het gehele project voor de gekende deadline T voltooid is, mits het zo weinig mogelijk bijhuren van resources bovenop de gegeven basiscapaciteit. 1 De nodige tijd is een hogere graads functie van de inputfactoren van het probleem

24 Hoofdstuk 1. Inleiding 7 De tijdsspanne waarbinnen de activiteiten moeten gepland worden bestaat aldus uit T tijdseenheden. De geplande starttijd r j van activiteit J j is hierbij de eerste tijdseenheid waarop aan J j wordt gewerkt. Elke activiteit J j heeft tevens een bepaalde duurtijd p j. De deadline d j van activiteit J j wordt vervolgens gedefinieerd als de eerste tijdseenheid na het voltooien van J j, of in wiskundige termen: d j = r j + p j. De laatste tijdseenheid waar nog aan activiteit J j wordt gewerkt is dus d j 1. Eens een activiteit begonnen is, moet ze bovendien ook afgewerkt worden (i.e. de niet-preëmptieve eigenschap van de activiteiten). Figuur 1.1 toont de voorgaande begrippen op een tijdlijn r j d j Tijdseenheid T 1/05/2011 1/06/2011 1/07/2011 1/08/2011 1/09/2011 1/10/ /04/ /10/2011 Tijdstip T+1 p j Figuur 1.1: Voorstelling van de release time, de deadline en de duurtijd van activiteit j Om de activiteiten uit te kunnen voeren zijn bepaalde hoeveelheden resources nodig. Er zijn K types hernieuwbare resources aanwezig, {R 1,..., R K }, waarvoor telkens een basiscapaciteit Q kt per tijdseenheid t T voorzien is. Een specifieke activiteit J j heeft vervolgens voor zijn hele duurtijd, q jk resources van type k nodig. Indien de totale vraag naar resources van type k op tijdseenheid t de voorziene capaciteit Q kt overschrijdt, moeten er dus resources bijgehuurd worden tegen een kost c H kt per extra resource eenheid (per tijdseenheid). De totale hoeveelheid bij te huren resources van type k op tijdstip t wordt gegeven door H kt. Bovendien bestaan er tussen de verschillende activiteiten volgorderelaties die in het projectplan gerespecteerd dienen te worden. De set van activiteiten P j bevat alle activiteiten die direct voorafgaand aan activiteit J j moeten ingepland worden en die aldus voor het aanvangen van J j voltooid moeten zijn. Om het Integer Linear Programming (ILP) model verder te construeren introduceren we 2 types binaire variabelen die optreden als beslissingsvariabelen in het model. Vermits het TC- PSP beslist over de starttijden van de te plannen activiteiten, moeten de beslissingsvariabelen

25 Hoofdstuk 1. Inleiding 8 de starttijden van de activiteiten eenduidig vastleggen. Binaire variabele x jt hoort 1 te zijn als er op tijdstip t aan activiteit J j wordt gewerkt en 0 indien dit niet het geval is. tweede type binaire variabele s jt wordt 1 op de eerste tijdseenheid t waarop aan activiteit J j wordt gewerkt en 0 op elk ander tijdstip. In het mathematische model geeft dit de volgende vergelijkingen: Het onderworpen aan: Minimaliseer K T c H kt H kt k=1 t=0 (1.1a) d i p i t=r i d j 1 x jt = p j j (1.1b) t=r j n q jk x jt Q kt + H kt k, t (1.1c) j=1 d j p j t=r j s jt = 1 j (1.1d) x j,0 = s j,0 j (1.1e) x jt x j,t 1 + s jt j, t > 0 (1.1f) t s it + p i d j p j t=r j t s jt j, J i P j (1.1g) s jt = 0 t / {r j,..., d j p j } (1.1h) x jt = 0 t / {r j,..., d j 1} (1.1i) x jt {0, 1} j, t (1.1j) s jt {0, 1} j, t (1.1k) H jt 0 k, t (1.1l) De doelfunctie (1.1a) tracht de totale huurkosten voor het uitvoeren van het project te minimaliseren. Constraint (1.1b) zorgt ervoor dat binaire variabele x jt 1 is voor de gehele duurtijd van de activiteit, i.e. van geplande starttijd r j tot de laatste tijdseenheid voor deadline d j. Constraint (1.1c) zorgt er voor dat er op elk tijdstip t genoeg resources van elk type k voor handen zijn om de geplande activiteiten op dit tijdstip uit te kunnen voeren. Indien de daarvoor noodzakelijke resources de reguliere capaciteit Q kt overschrijden, zullen er H kt resources moeten bijgehuurd worden. Constraints (1.1d), (1.1e) en (1.1f) zorgen er voor dat activiteiten niet-preëmptief worden gescheduled (x jt kan pas 1 worden als er ook in de vorige tijdseenheid aan J j wordt gewerkt, met uitzondering van de start van de activiteit). Bovendien zorgen ze voor een correcte relatie tussen binaire variabelen x jt en s jt (i.e. s jt is 1 als ook x jt voor de

26 Hoofdstuk 1. Inleiding 9 eerste maal 1 is). Constraint (1.1g) zorgt voor een correcte implementatie van de volgorderelaties. Het stipuleert dat alle directe voorgangers van activiteit J j, verzameld in P j, voltooid moeten zijn eer binaire variabele s jt van J j 1 mag worden en de activiteit dus zijn aanvang kan nemen. Verder zorgen constraints (1.1h) en (1.1i) dat op alle irrelevante tijdstippen de waarde van de binaire variabelen vast ligt op 0. Tenslotte bepalen constraints (1.1j), (1.1k) en (1.1l) de relevante domeinen van de variabelen Voorbeeld en Voorstelling Ter illustratie van het TCPSP wordt gebruik gemaakt van een numeriek voorbeeld zoals vermeld in Ranjbar & F. (2009). Hoewel hier gebruikt als voorbeeld voor een RCPSP, kan het nagenoeg naadloos worden overgenomen ter illustratie van een TCPSP, wat hun verwantschap nogmaals duidelijk maakt. Figuur 1.2: Een voorbeeldproject met 12 activiteiten, waarvan 0 en 11 dummy activiteiten zijn die de start en het einde van het project aanduiden. De getallen boven de activiteiten zijn respectievelijk hun duurtijd en hun vraag naar resource R 1. Voor de eenvoud wordt in dit project slechts met 1 type resource gewerkt, hoewel er evengoed meerdere types resources in het TCPSP kunnen voorkomen. We veronderstellen dat de basiscapaciteit Q 1t van resource R 1 4 eenheden per tijdseenheid t bedraagt, zoals ook te zien is in figuur 1.3. Als er geen rekening gehouden wordt met deze basiscapaciteit leert de Critical Path Method (CPM) ons dat de vroegste deadline T die we aan dit project kunnen stellen 9 is 2. Als daarentegen gesteld wordt dat de vraag naar R 1 op geen enkel tijdstip t het 2 Het gevolgde pad van activiteiten is daarbij

27 Hoofdstuk 1. Inleiding 10 aanbod Q 1t mag overschrijden, en er dus eigenlijk een RCPSP opgelost wordt, is de optimale makespan 18, zoals te zien in figuur 1.3. Figuur 1.3: De optimale oplossing voor de RCPSP-variant van het probleem. Gesteld wordt dat de deadline op tijdstip 16 is vastgelegd. Deze deadline is haalbaar voor het TCPS-probleem omdat we gebruik kunnen maken van extra ingehuurde resources H 1t. Het oplossen van het TCPSP tracht de daartoe nodige huurkosten te minimaliseren. Een mogelijk schedule wordt getoond in figuur 1.4. Op tijdstippen 0, 1, 2, 7, 8 en 9 moet er telkens 1 resource bijgehuurd worden, i.e. H 1t = 1 met t [0, 1, 2, 7, 8, 9], want dan overstijgt de vraag naar resource R 1 het reguliere aanbod Q 1t. Bij een huurkost c 1t van 1 op elk tijdstip t geeft de doelfunctie een totale kost van Figuur 1.4: Een mogelijke oplossing voor het voorbeeldprobleem. Figuur 1.5 toont de optimale oplossing voor het probleem. Gedurende de achtste en negende tijdseenheid worden er telkens 2 resources bijgehuurd, waardoor de deadline van 16 gehaald wordt. De doelfunctie geeft bij een huurkost c 1t van 1 een kost van 4. Figuur 1.6 toont een andere oplossing met een zelfde totale huurkost. Er bestaan dus vaak meerdere optimale

28 Hoofdstuk 1. Inleiding 11 oplossingen voor hetzelfde TCPS-probleem. Figuur 1.5: De optimale oplossing voor een deadline van 16 tijdseenheden Figuur 1.6: Een andere optimale oplossing voor een deadline van 16 tijdseenheden Overzicht van de literatuur Het TCPSP is in de literatuur niet zo uitvoerig beschreven als het RCPSP. De eerste gemengdgeheeltallige mathematische formulering werd gegeven door Deckro & Hebert (1989). Neumann et al. (2002) formuleert verscheidene branch and bound technieken voor het oplossen van het TCPSP. Ook worden er uitbreidingen geformuleerd op het TCPSP. Zo wordt er een Net Present Value variant besproken, dewelke het probleem een regular measure of performance geeft. Guldemond et al. (2008) introduceert verscheidene vormen van niet-reguliere resource capaciteit in het TCPSP. Teneinde de vooropgestelde deadline te halen, kunnen er in de probleemomschrijving van Guldemond et al. ook overuren gewerkt worden en kunnen er tijdens deze overuren bovendien resources bovenop de reguliere capaciteit gehuurd worden. Uiteraard is bijhuren van resources tijdens reguliere tijdseenheden ook toegestaan.

29 Hoofdstuk 1. Inleiding 12 Guldemond et al. stelt daarbij een tweedelige heuristiek voor 3. Hurink et al. (ongepubliceerd) voegt twee extra uitbreidingen toe aan het probleem. Een eerste uitbreiding bestaat uit de introductie van adjacent resources (aangrenzende resources) in het TCPSP. In de gegeven probleemomschrijving wordt een adjacent resource gekenmerkt door de volgende 2 eigenschappen: ˆ De resource eenheden binnen een aangrenzende resource hebben een strikte volgorde. Dus, types en hoeveelheden resources toegekend aan een activiteit moeten deze specifieke volgorde volgen. In de praktijk komt dit soort situaties vaak voor, zoals bijvoorbeeld bij een assemblagelijn. ˆ Tevens gemotiveerd door situaties uit de praktijk, stellen de auteurs dat niet één activiteit de sequentie van een aangrenzende resource moet volgen, maar een groep van activiteiten. Verderbouwend op het voorbeeld van een assemblagelijn, wordt dus verondersteld dat een serie producten in batch wordt geproduceerd en dat deze batch gedurende productie niet onderbroken mag worden. Hurink et al. stelt vervolgens een decompositiemethode voor als aanzet tot het oplossen van dit specifieke probleem 4. Hurink et al. (ongepubliceerd) specifieert het voorgaande probleem verder met de introductie van spatial resources. Spatial resources zijn hulpmiddelen zoals fysieke ruimtes waarin gewerkt moet worden. Een groep van activiteiten vraagt buiten hun reguliere resourcevraagpatroon ook één of meerdere specifieke spatial resources. Nemen we een scheepswerf als voorbeeld, dan is het duidelijk dat de constructie van de romp van een schip niet alleen arbeiders en kranen vergt (omschreven als reguliere resources ), maar ook een vrij droogdok (een spatial resource). Bovendien blijft het droogdok bezet tot alle constructieactiviteiten aan het schip gedaan zijn en het schip te water gelaten wordt. Alle constructieactiviteiten zijn bijgevolg impliciet gegroepeerd tot een set van activiteiten die eenzelfde spatial resource vragen. Deze laatste kan dus ook niet vrijgegeven worden totdat alle activiteiten binnen deze activiteitenset voltooid zijn. Bovendien zijn ze, net als de reguliere resources, beperkt in voorraad, maar kunnen ze volgens de gegeven probleemomschrijving niet bijgehuurd worden. Net als bij de aangrenzende resources, stellen Hurink et al. een decompositiemethode 5 voor als aanzet tot het oplossen van dit probleem. 3 Omwille van de hoge specificiteit van de heuristiek aan de bijzondere probleemomschrijving, is het weinig relevant dieper in te gaan op deze oplossingsmethode 4 idem aan voetnoot 3 5 In de decompositiemethode worden eerst de activiteitensets toegewezen aan de spatial resources. Wanneer de volgorde van de bezetting van deze resources door de activiteitensets is bepaald, worden de individuele activiteiten ingepland rekening houdend met de gewone resources.

30 Hoofdstuk 1. Inleiding Onderzoeksdoelstelling Voorgaande uiteenzetting toont aan dat wetenschappers binnen het TCPSP domein vooral gezocht hebben naar uitbreidingen op het basis TCPS-probleem met het oog op praktisch toepasbaarheid 6. De meeste tot nu toe verschenen oplossingsmethoden zijn bijgevolg toegespitst op specifieke problemen met hoge praktische toepasbaarheid en hoewel zij hun verdienste voor deze problemen zeker hebben bewezen, missen de gepresenteerde oplossingsmethoden veralgemeenbaarheid. Guldemond et al. (2008) stelt dat de meeste oplossingsmethoden voor het RCPSP niet toepasbaar zijn op het TCPSP omwille van de non-regular measure of performance van het TCPSP. Deze masterproef wil echter aantonen dat het basis TCPS-probleem 7, behoudens enkele noodzakelijke wijzigingen, wel efficiënt kan worden benaderd met bestaande methoden voor het RCPSP. 1.4 Oplossingsmethoden Het doel van deze masterproef is het toepassen van (meta-)heuristische oplossingsmethoden op het basis TCPS-probleem. Methoden gebruikt voor het RCPS-problemen zijn het best toepasbaar op het TCPSP. Het TCPSP en het RCPSP delen immers veel projectkarakteristieken. Mits enkele aanpassingen moet het aldus mogelijk zijn met succes RCPSP-specifieke methoden toe te passen op het TCPS-probleem. In onderstaand overzicht worden dergelijke kandidaatmethoden toegelicht. Daarbij worden ze opgedeeld in 3 categorieën: (1.4.1) Exacte oplossingsmethoden, (1.4.2) heuristische oplossingsmethoden en (1.4.3) metaheuristische oplossingsmethoden Exacte oplossingsmethoden In de literatuur bestaat er een grote verzameling aan oplossingsmethoden voor het RCPSP. Een eerste deel concentreert zich op exacte oplossingsmethoden. Zij gaan op zoek naar de optimale oplossing, maar hebben als groot nadeel dat de daartoe benodigde tijd meestal niet aanvaardbaar is (de rekentijd stijgt exponentieel met de complexiteit). Eén van de meest onderzochte en uitgewerkte methodes is het branch and bound algoritme. Dit soort algoritme doorzoekt de gehele oplossingsruimte door het construeren van een search tree. Op elk knooppunt (i.e. begin van een vertakking) wordt een bepaalde starttijd aan een activiteit meegegeven. Hierdoor wordt een partieel schedule geconstrueerd (de starttijd van die activiteit ligt nu immers vast). Op een vertakking in een lager niveau krijgt een volgende 6 Zo stelt Hurink et al. (2011) dat hun gepresenteerde uitbreiding en bijhorende oplossingsmethode ontwikkeld werd in opdracht een Nederlandse consulting firma, die meermaals met een dergelijk probleem werd geconfronteerd 7 Daaronder worden een strikte deadline voor het project en reguliere hernieuwbare resources met beperkte capaciteit verstaan, zonder overuren of aangrenzende of spatial resources

31 Hoofdstuk 1. Inleiding 14 activiteit een mogelijke starttijd toegekend, waarna er een uitgebreider gedeeltelijk schedule wordt gevormd. Deze procedure herhaalt zich tot alle activiteiten een starttijd gekregen hebben en dus een compleet schedule is gevormd. In de meest uitgebreide zoekprocedure en dito search tree krijgt elke activiteit binnen het planningsprobleem elke mogelijke starttijd toegewezen, in elke mogelijke combinatie van starttijden van andere activiteiten. Bij elke knoop (node) van de search tree kunnen er echter 2 situaties voorvallen, die de procedure efficiënter en dus sneller kunnen doen verlopen: ˆ In een eerste situatie wordt een knooppunt bereikt. Dit wil zeggen dat één van de activiteiten een mogelijke starttijd heeft gekregen in het partiële schedule, waarbij (gedeeltelijke) evaluatie van de oplossing mogelijk is. ˆ In een daaropvolgende situatie wordt na (gedeeltelijke) evaluatie, een lower- of upperbound berekend of enig andere tijdsgebonden bound (grens). Laat deze bound een verdere zoektocht naar andere oplossingen met hetzelfde partiële schedule niet meer toe 8, dan wordt dit gebied uit het zoekgebied geweerd. Is er wel nog ruimte voor een mogelijk betere oplossing, wordt dit zoekgebied weer verder opgedeeld (branching), waarna het zoek-en evaluatieproces zich herhaalt. In de literatuur worden er veel varianten op deze basisprocedure beschreven. Omdat exacte oplossingsmethoden evenwel niet behoren tot de scope van deze masterproef, wordt voor een breder overzicht verwezen naar Artigues et al. (2008). Er dient wel vermeld te worden dat branch and bound technieken ook als heuristieken kunnen toegepast worden, door bijvoorbeeld sterkere heuristische bounds te berekenen en aan te wenden om het zoekgebied snel te verkleinen waardoor de noodzakelijke rekentijd sterk kan worden gereduceerd. Er is in dit geval echter géén garantie meer op het vinden van een optimale oplossing Heuristische oplossingsmethoden Een andere deel van de oplossingsmethoden beschreven in de literatuur concentreert zich op heuristische oplossingsmethoden. Heuristieken worden gebruikt om zeer snel een initïele oplossing te genereren en dienen vaak als vertrekpunt voor metaheuristieken, die hierna worden beschreven. De basis voor een heuristische benadering van een RCPSP (of enig ander probleem met een regular measure of performance) is een schedule generation scheme (SGS). Dit bepaalt de volgorde waarin activiteiten in een reeds bestaand gedeeltelijke schedule worden ingepland. Door de regular measure of performance wordt steeds de vroegst mogelijke positie gekozen 8 De bound wijst er bijvoorbeeld op dat met de corresponderende starttijden van de activiteiten op de bovenliggende nodes (i.e. partiële schedule), elke mogelijk te genereren oplossing met die starttijden slechter zal presteren dan de huidige beste oplossing

32 Hoofdstuk 1. Inleiding 15 om de activiteit in te plannen en is de relatie tussen het SGS en het uiteindelijke schedule eenduidig. Door de non-regular measure of performance, is dit niet mogelijk voor het TCPSP. Wanneer men van een optimaal TCPSP schedule een SGS zou opstellen en daarna op basis van dat SGS het oorspronkelijk schedule terug zou construeren, bekomt men mogelijks een ander schedule, omdat in het TCPSP het inplannen van een activiteit op de vroegst mogelijke starttijd niet noodzakelijk optimaal is. Toch kan een heuristische benadering, gebaseerd op een SGS, als component voor een heuristiek voor het TCPSP aangewend worden, zoals in hoofdstuk 3 gedaan wordt. Een non-regular measure of performance sluit immers oplossingen volgens een variant met een regular measure of performance niet uit. Toch kan in dat geval optimaliteit niet gegarandeerd worden. Seriële en parallele Schedule Generation Schemes (SGS) zijn twee typische basisvormen. Beiden plannen activiteiten in volgens een gegeven priority list, die een prioriteitswaarde geeft aan elke activiteit. ˆ Bij een seriële SGS, wordt elke activiteit, één voor één, in de volgorde aangeduid door de priority list, zo vroeg mogelijk ingepland in het partiële schedule, rekening houdend met de resource beperkingen en volgorderelaties. ˆ Bij een parallele SGS, wordt op elk mogelijk tijdstip gekeken naar alle activiteiten die, rekening houdend met resource beperkingen en volgorderelaties, op dat tijdstip kunnen worden ingepland. De activiteit met de hoogste prioriteit wordt vervolgens ingepland, waarna het proces zich herhaalt. Zolang er nog activiteiten op dat tijdstip gescheduled kunnen worden, wordt er niet naar een volgend tijdstip overgegaan. Een verdere opdeling binnen de categorie van heuristieken kan gebeuren naar single-pass en multi-pass heuristieken. ˆ Bij een single-pass heuristiek, wordt hetzelfde SGS slechts éénmaal toegepast. Hieruit ontstaat dus slechts 1 oplossing. ˆ Bij een multi-pass heuristiek, wordt hetzelfde SGS meerdere malen toegepast op het probleem. Er worden daarbij telkens andere prioriteitswaarden gegenereerd voor het gebruikte SGS, teneinde diverse oplossingen te bekomen. Een andere manier om diverse oplossingen te bekomen is het toepassen van verschillende soorten Schedule Generation Schemes op hetzelfde probleem. Daardoor presteert een multi-pass heuristiek over het algemeen beter dan een single-pass variant, maar vraagt uiteraard meer rekencapaciteit. Het is dus duidelijk dat aanpassingen noodzakelijk zijn om deze procedures succesvol toe te kunnen passen op het TCPSP: Het RCPSP is strikt gebonden aan de resourcecapaciteiten, terwijl het TCPSP tijdelijk capaciteit kan bijhuren. Het vroegste tijdstip waarop een activiteit kan worden ingepland is in het TCPSP dus enkel gebonden aan volgorderelaties. Het is

33 Hoofdstuk 1. Inleiding 16 evenwel duidelijk dat een daarop gebaseerd schedule bijzonder slecht zal presteren volgens de doelfunctie. Hoofdstuk 3 stelt een methode voor die dit euvel efficiënt tracht te omzeilen. Voor meer geëlaboreerde vormen van Schedule Generation Schemes en priority lists voor het RCPSP wordt de geïnteresseerde lezer doorverwezen naar Artigues et al., 2008, hoofdstuk Metaheuristische oplossingsmethoden Metaheuristieken hebben als doel binnen aanvaardbare tijd een zo goed mogelijke (maar niet noodzakelijk optimale) oplossing te bereiken. Aldus trachten zij het grootste probleem waarmee exacte oplossingsmethoden te kampen hebben, i.e. de gevraagde rekentijd, te verhelpen, mogelijks ten koste van optimaliteit. Net als voor de exacte oplossingsmethoden is het aanbod aan metaheuristische oplossingsmethoden in de literatuur erg groot. Een kort, niet exhaustief overzicht wordt hieronder gegeven. Artigues et al. (2008) en Glover & Kochenberger (2003) geven hierover een completer overzicht. ˆ Populatie-gebaseerde metaheuristieken: Deze categorie van metaheuristieken tracht reeds bestaande oplossingen aan te passen volgens de principes van Darwins evolutietheorie. Daarbij wordt eerst een initïele verzameling (een populatie) van oplossingen gegenereerd die zich vervolgens doorheen hun evolutie, zoals de natuur, aanpast aan -toevallig- verworven positieve eigenschappen, om zo tot een steeds beter resultaat te komen. Hieronder worden zes populatie-gebaseerde metaheuristieken kort toegelicht. Genetic Algorithm (GA): In iedere iteratie van dit algoritme worden de representatieschemas 9 van individuen uit de populatie onderworpen aan biologische principes zoals crossover en mutatie. Bij crossover combineren twee of meer individuen hun genetisch materiaal, zoals bij de voortplanting, tot de creatie van een aantal kinderen. Deze kinderen bezitten bepaalde chromosomen die gelijk zijn aan de chromosomen van één van de ouders. Voor het RCPSP stellen deze chromosomen de starttijden van activiteiten voor. Deze kinderen kunnen vervolgens onderhevig zijn aan mutaties op hun nieuw verkregen chromosomen. Afhankelijk van de fitness van het kind (bepaald door de doelfunctie) vergroot of verkleint hun kans op overleven. Op deze manier wordt de kans op het doorgeven van hun genetisch materiaal (inclusief goede en slechte eigenschappen) naar de daaropvolgende generatie beïnvloed. Voor de toepassing van Genetic Algorithms op het TCPSP, zie Verbeeck (2011) en Vercruyssen (2011). Ant Colony Optimization (ACO): Iedere iteratie construeren m ants (mieren) een oplossing. De wijze waarop ze hun oplossing construeren wordt beïnvloed door de feedback die ze krijgen over de geconstrueerde oplossingen van hun voorgangers (cfr. de sterkte van het achtergelaten feromoon in een gangenstelsel van mieren). 9 De voorstelling van de starttijden van de activiteiten van het project. Zie sectie 1.5 voor de gebruikte representatieschema s voor het TCPSP.

34 Hoofdstuk 1. Inleiding 17 Electro Magnitism (EM): Deze methode is gebaseerd op de wet van Coulomb over geladen deeltjes. Er zwermen m partikels rond in de oplossingsruimte. Op basis van hun lading (hen toegekend door de doelfunctie) zullen zij elkaar aantrekken (goede oplossingen trekken aan) of afstoten (slechte oplossingen stoten af). Particle Swarm Optimization (PSO): Deze techniek is gebaseerd op het kuddegedrag van dieren. Als in een vlucht vogels, die op zoek is naar eten op de grond, één vogel plots lager vliegt (in de veronderstelling dat hij een mogelijke prooi heeft opgemerkt), dan zullen de vogels in diens buurt zijn gedrag volgen en ook lager vliegen. Toegepast op optimalisatieproblemen, zal een oplossing die volgens de doelfunctie lokaal of zelfs globaal best presteert dit communiceren naar de andere elementen in de bevolking en hen aantrekken naar zijn positie. Deze methode wordt in deze masterproef uitgewerkt voor het TCPSP, zie hoofdstuk 2. Scatter Search (SS): Uit poules van zowel goed presterende als diverse oplossingen wordt in iedere iteratie één of meerdere subsets gevormd. De oplossingen van een subset worden vervolgens met elkaar gecombineerd en hun resulterende oplossingen geëvalueerd. Op basis van deze evaluatie worden de poules goede en diverse oplossingen geüpdatet. Daarna begint de volgende iteratie opnieuw met de constructie van nieuwe subsets. Artificial Immune System (AIS): Na de creatie van een initiële populatie (de B-cellen) worden slechts een aantal oplossing weerhouden (zij die zich het best kunnen binden met ziektekiemen, oftewel de beste schedules volgens de doelfunctie). Op deze oplossingen wordt vervolgens een sterke vorm van mutatie toegepast ter creatie van een nieuwe populatie B-cellen, waarna de procedure zich herhaalt. Deze metaheuristiek wordt toegepast op het TCPSP door Verbeeck (2011). ˆ Metaheuristieken gebaseerd op één oplossing: Deze categorie van metaheuristieken tracht met één oplossing de gehele oplossingsruimte te doorzoeken. In tegenstelling tot populatie-gebaseerde metaheuristieken kan er geen sociale interactie tussen elementen optreden om de zoekprocedure te leiden. Metaheuristieken gebaseerd op één oplossing gebruiken daarentegen interactie met historisch bezochte posities. Hieronder worden drie metaheuristieken gebaseerd op één oplossing, kort toegelicht. Greedy Random Adaptive Search Procedures (GRASP): een multi-start heuristiek die bestaat uit twee fases: een constructiefase (cfr. heuristische oplossingsmethoden) en een verbeteringsfase, in welke getracht wordt de initieel gegenereerde oplossing met behulp van een local search procedure (i.e. iteratief kleine verbeteringen aanbrengen aan het schedule) te verbeteren tot een lokaal optimum. Een GRASP voor het TCPSP wordt in deze masterproef verder uitgewerkt in hoofdstuk 3. Tabu Search (TS): Deze methode is speciaal ontworpen om aan lokale optima te

35 Hoofdstuk 1. Inleiding 18 ontsnappen en gebruikt daarbij een geheugen van eerdere bewegingen en oplossingen (respectievelijk het korte- en langetermijngeheugen genoemd). Het algoritme gaat in elke stap op zoek naar een verbetering door bepaalde bewegingen in het schedule te forceren. Telkens de oplossing in een lokaal optimum dreigt te geraken, wordt er een nietverbeterende stap toegelaten. Daarbij vermijdt het kortetermijngeheugen dat men naar een positie zou terugkeren die reeds bezocht is. Het langetermijngeheugen bëinvloedt de bewegingen door goede eigenschappen van bepaalde goed presterende oplossingen te onthouden. Simulated Annealing (SA): Net als Tabu Search is SA een metaheuristiek ontworpen om aan lokale optima te ontsnappen. Gebaseerd op de vaststelling dat om staal van goede kwaliteit te krijgen, men na de verhitting het staal best langzaam afkoelt, zullen er bij het bereiken van een lokaal optimum, niet verbeterende bewegingen (temperatuur daalt) in het schedule toegelaten worden. Wanneer de temperatuur te snel daalt (en het staal te bros zou worden, of het schedule te slecht zou worden), wordt er weer expliciet naar verbeteringen gezocht (temperatuur stijgt opnieuw). Deze methode wordt op het TCPSP toegepast door Verbeeck (2011). 1.5 Representatie van een oplossing Het doel van het TCPSP is het minimaliseren van de totale huurkosten. Daartoe kan er enkel met de starttijden van de activiteiten geschoven worden. Een oplossing kan dus voorgesteld worden door aan elke activiteit een bepaalde waarde toe te kennen, waaruit volgens een bepaalde constructieregel eenduidig de starttijd kan worden afgeleid en de oplossing gereconstrueerd kan worden. Uit sectie blijkt dat het voorstellen van een oplossing van een TCPS-probleem niet eenduidig kan gebeuren op basis van priority lists. We opteren daarentegen voor een shift-based representatieschema voorgesteld door Sampson & Weiss (1993). Elke oplossing wordt daarbij omschreven als een vector, waarbij elk niet-negatief geheel getal op postie n in deze vector correspondeert met het aantal tijdseenheden dat activiteit n na diens vroegst mogelijke starttijd (earliest start time, EST) is gescheduled. Deze voorstelling laat toe eenduidig een relatie met het uiteindelijk schedule op te leggen, ondanks de non-regular measure of performance. Figuur 1.7 toont de shift van activiteit 6 uit het voorbeeldproject (zie sectie 1.2.3) in één van de optimale oplossingen. Deel (A) van de figuur geeft de voorstelling van het earliest start schedule van het project. Bemerk dat het kritische pad 9 tijdseenheden bedraagt. In dit earliest start schedule wordt de start van activiteit 6 op tijdseenheid 4 vastgelegd. Deel (B) van de figuur herhaalt één van de optimale oplossingen van het voorbeeld project. Daarin is de start van activiteit 6 vastgelegd op tijseenheid 11. De shift van activiteit ten opzichte van zijn earliest start bedraagt dus 7 tijdseenheden. Figuur 1.8 toont de 2 resulterende representatie-

36 Hoofdstuk 1. Inleiding 19 schema s voor (A) en (B). Het earliest start schedule heeft uiteraard een representatievector bestaande uit enkel nullen. Merk op dat een representatieschema met negatieve waarden per definitie tot een onmogelijk (infeasible) schedule leidt. Uit het representatieschema van (B) kan er nog meer interessante informatie gehaald worden. De activiteiten van het kritische pad uit (A) (zijnde activiteiten 0, 1, 6, 8 en 11) kunnen onmogelijk een shift groter hebben dan de laatste activiteit van het kritische pad, in dit geval dummy activiteit 11. Deze vaststelling wordt gebruikt voor de populatiegeneratie van het gepresenteerde Darwinian Particle Swarm Optimization algoritme in hoofdstuk (A) (B) Shift van activiteit 6: +7 Figuur 1.7: Voorstelling van een shift van een activiteit.

37 Hoofdstuk 1. Inleiding 20 activiteit shift activiteit shift Figuur 1.8: Voorstelling van shift-gebaseerde representatieschemas. 1.6 Overzicht van komende hoofdstukken In hoofdstukken 2, 3 en 4 worden drie onderzochte metaheuristieken toegelicht. In hoofdstuk 2 wordt de Darwinian Particle Swarm Optimizer met een Local Darwinian Particle Swarm Optimizer (DPSO-LDPSO) toegelicht. In hoofdstuk 3 wordt de ontworpen Greedy Random Adaptive Search Procedure (GRASP) uit de doeken gedaan. In hoofdstuk 4 wordt vervolgens een hybride metaheuristiek voorgesteld die gebaseerd is op zowel het gepresenteerde DPSO- LDPSO als op de gepresenteerde GRASP, de GRASP-LDPSO. In hoofdstuk 5 worden de verschillende gehanteerde testprocedures uitgelegd. Ook worden de parameterkalibraties en de kracht van de samenstellende delen van de drie algoritmen individueel toegelicht. Ten slotte worden in dat hoofdstuk de drie methodes naast elkaar gelegd en hun testresultaten op verschillende testopstellingen vergeleken. In hoofdstuk 6 wordt de best presterende ontworpen methode vergeleken met de best presterende methoden van twee andere thesisstudenten die rond hetzelfde onderwerp onderzoek hebben gevoerd. In hoofdstuk 7 wordt ten slotte een conclusie van het gevoerde onderzoek geformuleerd.

38 Hoofdstuk 2 Darwinian Particle Swarm Optimization 2.1 Inleiding In deze inleiding wordt de overgang van een klassieke Particle Swarm Optimizer naar de geïmplemteerde Darwinian Particle Swarm Optimizer uitgelegd Particle Swarm Optimization Het Particle Swarm Optimization (PSO 1 ) algoritme is een stochastische optimalisatietechniek geïntroduceerd door Eberhart & Kennedy (1995). Deze meta-heuristiek emuleert het gedrag binnen een vlucht van vogels of het kuddegedrag van dieren. Zoals de naam van het algoritme aangeeft wordt de basis het PSO gevormd door een zwerm partikels (swarm of particles). Elk van deze partikels stelt een oplossing van het onderzochte probleem voor. Gesteld dat er naar een optimale oplossing wordt gezocht in M dimensies, dan vliegen deze partikels als het ware door de M-dimensionele oplossingsruimte. Voor een project bestaande uit M activiteiten stelt elke dimensie m de starttijd van activiteit m voor. De opeenvolgende bewegingen van de partikels doorheen de oplossingsruimte worden beïnvloed door hun eigen historisch gedrag en het gedrag van de andere partikels in de oplossingsruimte. Daarbij zal veelbelovend gedrag andere partikels aantrekken, zodat de omgeving rond dit goed presterend partikel intensiever onderzocht wordt. Gegeven is een minimalisatieprobleem in M dimensies met een enkelvoudige doelfunctie: Minimaliseer f(x), x = [x 1,..., x M ] (2.1) In elke iteratie van de procedure wordt de snelheid V i en de positie X i van elk partikel langsheen elke dimensie geüpdatet. De oorspronkelijke PSO methode gebruikt formules PSO kan ook als afkorting voor Particle Swarm Optimizer gebruikt worden. 21

39 Hoofdstuk 2. Darwinian Particle Swarm Optimization 22 en 2.3 om de snelheid en de positie van een partikel aan te passen: A {}}{ Vi,t m = w V m i,t 1 + B {}}{{}}{ c 1 rand1 (pbest m i Xi,t 1) m + c 2 rand2 (gbest m Xi,t 1) m (2.2) X m i,t = X m i,t 1 + V m i,t (2.3) Met w, rand1, rand2 [0, 1] en c 1, c 2 R In vergelijking 2.2 zien we dat de nieuwe snelheid Vi,t m iteratie t, beïnvloed wordt door 3 factoren: C van partikel i in dimensie m, gedurende A Eigen historische snelheid: Een fractie w [0, 1] van de snelheid gedurende de vorige iteratie Vi,t 1 m wordt behouden. Factor w wordt daarom ook de inertiefactor genoemd. w bepaalt vooral de balans tussen de mogelijkheden het zoekgebied globaal of lokaal af te tasten. In sectie wordt er verder op deze inertiefactor ingegaan. B Eigen beste historische positie: Partikel i wordt aangetrokken door diens eigen beste historische positie pbest i = [ pbest 1 i,..., ] pbestm i. De mate waarin het partikel hiertoe aangetrokken wordt hangt af van 2 factoren: leerfactor c 1 en een willekeurig gegenereerd getal rand1 [0, 1]. Leerfactor c 1 is bepalend voor de invloed die de historisch beste positie van het partikel heeft op de huidige snelheid. Hoe hoger c 1, hoe meer het partikel naar pbest i zal worden aangetrokken. Omwille van deze invloed wordt c 1 ook wel de cognitieve versnellingscoëfficiënt genoemd. rand1 introduceert een stochastische factor in het algoritme. Het bepaalt de uiteindelijke invloed van pbest i op de huidige snelheid. De uiteindelijke ] aantrekking ligt met andere woorden uniform verdeeld binnen [0, c 1 (pbest m i Xi,t 1 m ) voor elke dimensie m van het probleem. C Beste historische positie van de gehele populatie: Partikel i wordt tevens aangetrokken door de beste positie die gelijk welk partikel in de populatie gedurende vorige iteraties heeft bereikt: gbest = [ gbest 1,..., gbest M]. De mate waarin het partikel hiertoe aangetrokken wordt hangt af van 2 factoren: leerfactor c 2 en een willekeurig gegenereerd getal rand2 [0, 1]. Leerfactor c 2 is bepalend voor de invloed die de historisch beste oplossing van de hele swarm heeft op de huidige snelheid van partikel i. Hoe hoger c 2 hoe meer het partikel naar gbest zal worden aangetrokken, dus hoe meer het partikel zal versnellen. Omwille van deze invloed wordt c 2 ook wel de sociale versnellingscoëfficiënt genoemd. Immers, deze versnelling ontstaat door communicatie tussen de elementen. Door te variëren op de waarden van c 1 en c 2 kan een wisselende invloed van de cognitieve en sociale component worden bekomen. rand2 introduceert een tweede stochastische factor in het algoritme. Het bepaalt de uiteindelijke invloed van gbest op de huidige snelheid. De uiteindelijke aantrekking ] ligt met andere woorden uniform verdeeld binnen [0, c 2 (gbest m Xi,t 1 m ) voor elke dimensie m van het probleem.

40 Hoofdstuk 2. Darwinian Particle Swarm Optimization 23 Figuur 2.1 geeft een grafische voorstelling van het swarmgedrag van partikels (witte bollen). Deze partikels zwermen in een 2-dimensionele ruimte. De achtergrondkleuren tonen de waarde van de doelfunctie voor de corresponderende waarden van de 2 variabelen. De ene variabele varieert tussen 0 en 1.4, de andere tussen 0 en 1.0. We zien dat de 2 partikels aangetrokken worden tot zowel hun eigen historisch meest fitte positie (lichtgroene bol) als de meest fitte positie gevonden door gelijk welk partikel in de swarm (gele bol). Global Best Huidige Positie Local Best Figuur 2.1: Grafische weergave van het swarmgedrag van partikels. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en 1. Eberhart & Shi (1998) vergelijken het swarmgedrag van de partikels in een PSO met mutatieoperaties bij evolutiegebaseerde algoritmes. Zij duiden er echter op dat de mutatie -operatie bij een Particle Swarm Optimizer gestuurd wordt door diens eigen ervaring en de ervaring van andere partikels in de swarm. Er is dus sprake van mutatie die met een geweten wordt uitgevoerd. Bij een basis Genetic Algorithm (GA), een typisch evolutiegebaseerd algoritme,

41 Hoofdstuk 2. Darwinian Particle Swarm Optimization 24 is er geen sprake van zulk geweten. Het is overigens ook belangrijk er op te wijzen dat het PSO niet gevoelig is voor de grootte van het project. Immers, de snelheid en positie van elk partikel wordt voor elke dimensie afzonderlijk bekeken. Kenmerkend voor het Particle Swarm Optimization algoritme is diens goede globale zoekcapaciteit. Partikels kunnen immers zeer snel het hele zoekgebied doorkruisen, voornamelijk bij hoge waarden van de inertiefactor w en de leerfactoren c 1 en c 2. Dit leidt tot een trage convergentie en zeer grote diversiteit binnen de populatie. Wanneer het algoritme voldoende schedules of runtime krijgt, mag men dus goede resultaten van het algoritme verwachten. Nadeel van de trage convergentie is natuurlijk de geïmpliceerde zwakke local search capaciteit. Echter, sinds de introductie van het PSO algoritme, zijn er in de literatuur uitbreidingen geformuleerd die deze tekortkoming trachten op te lossen, zie sectie De Particle Swarm Optimization is reeds succesvol toegepast op neurale netwerk problemen en functieminimalisaties. De toepassing ervan op projectplanning is eerder schaars. Voorbeelden zijn Rabbani et al. (2010), Fengshan et al. (2010) en Günther & Nissen (2009) Werking van het basis PSO algoritme Een beginpopulatie of beginswarm wordt random of heuristisch gegenereerd (beide methoden worden toegepast in deze masterproef, zie sectie en hoofdstuk 4). Vervolgens wordt er aan elk partikel een random snelheidsvector toegewezen, Vi,0 m R voor elke dimensie m van het probleem. Aan het begin van elke iteratie wordt de huidige positie van het partikel geëvalueerd door de doelfunctie en worden, indien toepasselijk, pbest i en gbest geüpdatet (i.e. bij het vinden van een meer fitte positie). Daarna kan het swarmproces beginnen met de eerste positie-update, zoals gegeven in vergelijking 2.3. Na het uitvoeren van de positie-update herhaalt zich het gehele proces, te beginnen met een nieuwe evaluatie en een snelheidsupdate zoals weergegeven in vergelijking 2.2. Het flowchart van de procedure wordt gegeven in figuur 2.2.

42 Hoofdstuk 2. Darwinian Particle Swarm Optimization 25 Figuur 2.2: Flowchart van het basis PSO algoritme Volgens de flowchart in figuur 2.2 stopt het algoritme bij het bereiken van een op voorhand gedefinieerd maximum aantal schedules. Er kunnen echter nog andere stopcriteria gebruikt worden zoals totale runtime of een minimale procentuele verbetering per iteratie Uitbreidingen op het basismodel In de loop der jaren zijn er op het basismodel tal van uitbreidingen verschenen in de literatuur. De grote meerderheid van deze uitbreidingen had tot doel een oplossing te bieden aan de zwakkere local search capaciteiten van de basisversie van het PSO. De uitbreidingen zijn ruwweg onder te verdelen in 3 categorieën: uitbreidingen gericht op het reduceren van de snelheid van de partikels, uitbreidingen gericht op het sofisticeren van omgevingstopologieën en uitbreidingen gericht op het creëren en werken met subpopulaties.

43 Hoofdstuk 2. Darwinian Particle Swarm Optimization 26 ˆ Snelheidsreductie: Door partikels minder snel door de zoekruimte te laten bewegen, zullen ze hun huidige omgeving intensiever exploreren. Zo kan men een snellere convergentie bekomen en een dito verhoogde local search capaciteit. Om een snellere convergentie te bekomen, kan men in de eerste plaats de inertiefactor w verlagen. Daardoor zal de snelheid van het partikel minder beïnvloed worden door diens historische snelheid en relatief meer door pbest i en gbest, wat convergentie in de hand werkt. Een tweede manier waarop de inertiefactor w een belangrijkere rol kan spelen is door deze afhankelijk te maken van de runtime van het algoritme of van de fitness van het partikel. In het eerste geval hangt de waarde van inertiefactor w af van iteratie t. Zo wordt vergelijking 2.2: V m i,t = w t V m i,t 1 + c 1 rand1 (pbest m i X m i,t 1) + c 2 rand2 (gbest m X m i,t 1) (2.4) Daarbij zullen in vroege iteraties grote waarden voor w worden genomen om globaal te zoeken, waarna de inertiefactor -al dan niet lineair- afneemt om veelbelovende zoekgebieden lokaal verder te exploreren. In het tweede geval kan de waarde van w een functie zijn van de (relatieve) fitness van het partikel. Een goed presterend partikel kan een lage inertiefactor toebedeeld krijgen om lokale exploratie te intensifiëren. Een slecht presterend partikel daarentegen kan een hoge inertiefactor krijgen, om exploratie naar een ander zoekgebied te faciliteren. Een soortgelijke benadering kan ook toegepast worden op leercoëfficiënten c 1 en c 2. Tijdsafhankelijke leercoëfficiënten c 1,t en c 2,t, ook wel TVAC (time-variant acceleration coefficients) genoemd, worden op een hoge waarde geïnitialiseerd (bijvoorbeeld 3.0) en nemen dan af naarmate het aantal iteraties toeneemt. Ook dit zorgt voor een shift van globaal zoeken naar lokaal zoeken. Bovenstaande uitbreidingen zorgen voor een afzonderlijke reductie van de invloed van elk van de 3 componenten van Vi,t m. Men kan echter ook gewoon een maximaal toelaatbare snelheid V max definiëren, en overdreven snelheid van het partikel hiertoe begrenzen. Snelheidsreductie zorgt er bovendien voor dat het toelaatbare zoekgebied niet snel verlaten wordt. Ongelimiteerde snelheid verhoogt immers het risico op snelheidsexplosies die maar moeilijk uitdeinen, waardoor de partikels geen zinvolle bewegingen meer uitvoeren, maar springen van het ene extremum naar het andere. Clerc & Kennedy (2002) bekijken de convergentiecriteria voor een partikel op een analytisch manier. Daarbij onderzoeken ze verscheidende constriction factors χ. Ze stellen de volgende snelheids- en positie-update functies voor, die tot convergentie moeten leiden:

44 Hoofdstuk 2. Darwinian Particle Swarm Optimization 27 Vi,t m = χ [w Vi,t 1 m + c 1 rand1 (pbest m i Xi,t 1) m +c 2 rand2 (gbest m Xi,t 1 m )] (2.5) Met: 2 χ = 2 ϕ ϕ 2 4ϕ en ϕ = c 1 + c 2, ϕ > 4. (2.6) Ratnaweera et al. (2004), ten slotte, introduceert 2 uitbreidingen die premature convergentie naar een lokaal optimum moeten tegengaan: In de Particle Swarm Optimizer met mutatie en Time-Varying Acceleration Coefficients (MPSO-TVAC) wordt er nagekeken of het globale optimum stagneert over een bepaald aantal iteraties. Indien dit het geval is wordt de snelheidsvector van een random gekozen partikel random gemuteerd, om nieuwe globale zoektochten te verkrijgen. In de Self-Organizing Hierarchical Particle Swarm Optimizer with Time-varying Acceleration Coefficients (HPSO-TVAC), gaat het algoritme bij elke iteratie na of het partikel een lokaal optimum heeft bereikt. Een indicatie daartoe is wanneer de geüpdate snelheidsvector 0 blijkt te zijn, i.e. complete convergentie. Om uit dit lokaal optimum te ontsnappen wordt de snelheidsvector random gemuteerd. ˆ Verandering van omgevingstopologie: De kracht van het PSO ligt in de informatieuitwisseling die tussen de partikels plaatsvindt. In de literatuur is getracht deze informatieuitwisseling te optimaliseren. van den Bergh & Engelbrecht (2004) delen het optimalisatieprobleem op in M subproblemen. Daarbij wordt een coöperatieve set van M swarms gecreëerd, waarbij elke swarm één enkele dimensie van het probleem tracht te optimaliseren. Mendes et al. (2004) stelt dat er in het oorspronkelijke PSO te weinig informatieuitwisseling plaatsvindt tussen de partikels. Enkel het best presterende partikel oefent een invloed uit op een willekeurig ander partikel. In het Fully Informed Particle Swarm (FIPS) algoritme, gepresenteerd door Mendes et al., oefent elk partikel in de omgeving van een willekeurig gekozen partikel invloed uit op diens beweging in de zoekruimte.

45 Hoofdstuk 2. Darwinian Particle Swarm Optimization 28 stel Vi,t m = w Vi,t 1 m + ϕ (Pi m Xi,t 1) m met ϕ = ϕ en ϕ = [ ϕ 1,..., ϕ N ] dan [ ϕ k = U 0, ϕ ] max k N (2.7) N k N P i = W (k) ϕ k P k k N W (k) ϕ (2.8) k met P [ i = P 0 1,..., P ] 1 M Daarbij kan ϕ k met C n rand n in vergelijking 2.2 vergeleken worden. N stelt het aantal naburige partikels voor die invloed uitoefenen op partikel i. Pk stelt de beste historische positie voor, gevonden door partikel k. W (k) is een wegingsfunctie die gelijk welk relevant aspect van partikel k beschrijft. Een goede kandidaat daartoe is bijvoorbeeld de fitness value van het partikel. Janson & Middendorf (2005) stelt nog een andere neighbourhood topology voor. In de Adaptive Hierarchical Particle Swarm Optimizer (AHPSO) worden alle partikels hiërarchisch geordend volgens hun fitness value in een boomstructuur. Een partikel wordt vervolgens beïnvloed door de beste historische positie van diens parent node. Bovendien wisselen ouder en kind van positie als de fitness value van het kind beter is dan die van de ouder. Door deze structuur wordt een partikel in zijn beweging doorheen de oplossingsruimte afwisselend door andere elementen beïnvloed. Het is ook duidelijk dat een partikel niet alleen rechtstreeks invloed uitoefent op diens directe kinderen, maar ook onrechtstreeks op de nodes in nog lagere niveaus van de hiërarchie. Het Charged Particle Swarm (CPSO), gepresenteerd door Blackwell (2007), brengt een lading aan op elk partikel of op bepaalde zones in het zoekgebied. Afstotende ladingen worden bijvoorbeeld aangebracht op slecht presterende partikels (om zodoende géén aantrekking op naburige partikels uit te oefenen) of op reeds gevonden lokale optima. Een soortgelijk algoritme, het ARPSO (Riget & Vesterstrom, 2002), wisselt iteraties van aantrekking af met iteraties van afstoting om geen diversiteit in de populatie te verliezen (ARPSO: attractive/repulsive PSO). Gedurende iteraties van aantrekking, wordt het gewone PSO algoritme gebruikt omdat deze over het algemeen de aantrekking tot goed presterende partikels bewerkstelligt. Iteraties van afstoting worden gebruikt wanneer er te weinig diversiteit in de populatie is ontdekt. Daarbij wordt de snelheidsfunctie simpelweg geïnverteerd.

46 Hoofdstuk 2. Darwinian Particle Swarm Optimization 29 ˆ Subpopulaties: Een laatste groep uitbreidingen laat meerdere swarms parallel aan elkaar opereren. Dit laat toe bepaalde zoekgebieden apart te exploreren waardoor een local search procedure efficiënter kan verlopen. Bovendien kunnen, door parallelle evaluatie van deze swarms, lokale optima gedetecteerd worden. Nadeel is wel dat de geassocieerde parameterset erg complex wordt (hoeveel swarms, aantal partikels in elke swarm, etc.). Zhao et al. (2010) stelt een Dynamic Multi-Swarm Particle Swarm Optimizer (DMS- PSO) voor. De auteurs stellen dat het dynamisch gebruik van meerdere swarms twee tekortkomingen van het origineel probleem kan tegengaan. Ten eerste, hoe complexer het probleem, hoe efficiënter zoekstrategieën moeten zijn, om goede regios te kunnen exploreren binnen het aantal opgegeven schedules of de opgegeven maximum runtime. Het opdelen van de gehele oplossingsruimte in subdelen en elk van deze subdelen toekennen aan een aparte swarm (een subswarm), moet zorgen voor een efficiënte zoekstrategie. Ten tweede dreigt het originele algoritme te convergeren naar en vast te blijven zitten in lokale optima. Wanneer een dergelijke stagnatie in een subswarm is ontdekt, zal de swarm uit de zoekprocedure geëlimineerd worden. Zo zal een weinig belovende regio snel uit het zoekproces verwijderd worden, wat de efficiëntie van een globale zoektocht bevorderd. Deze autoadaptatie aan het landschap laat vervolgens toe de zoektocht toe te spitsen op veelbelovende regio s. Tillett et al. breidt het bovenstaande concept uit met elementen uit de evolutietheorie. De auteurs hebben deze methode daarom een Darwinian Particle Swarm Optimization (DPSO) genoemd. Dit concept wordt in deze masterproef toegepast en een verdere uiteenzetting hierover kan hieronder gevonden worden Darwinian Particle Swarm Optimization Een Darwinian Particle Swarm Optimization maakt gebruik van een set parallelle swarms, die onderhevig zijn aan principes van de evolutietheorie. Daardoor is het DPSO niet alleen onderhevig aan sociale, maar ook aan evolutiegebaseerde leereffecten. De volgende elementen van natuurlijke selectie zijn overgenomen in het DPSO: ˆ Hoe langer een swarm leeft, hoe groter de kans dat de swarm nakomelingen genereerd. Elke iteratie waarbij de swarm in leven blijft, heeft deze immers een kleine kans om een kind -swarm te genereren die kenmerken meedraagt van de ouder -swarm. ˆ De levensduur van een swarm wordt verlengd indien de swarm zich naar meer fitte posities begeeft. Concreet zal een swarm wiens gbest in deze iteratie wordt geüpdatet, beloond worden met een extra partikel in de swarm. ˆ Indien stagnatie in de swarm wordt gedetecteerd, worden de slechtst presterende partikels systematisch uit de swarm verwijderd. Als het aantal partikels onder een minimum

47 Hoofdstuk 2. Darwinian Particle Swarm Optimization 30 zakt, verdwijnt de gehele swarm uit de zoekprocedure. De concrete toepassing van het Darwinian Particle Swarm Optimization (en andere nevenuitbreidingen) op het TCPSP wordt hieronder in detail beschreven. 2.2 Oplossingsmethode In deze masterproef wordt een Darwinian Particle Swarm Optimizer met een Local Darwinian Particle Swarm Optimizer (DPSO-LDPSO) ontwikkeld. Deze bestaat uit 3 subdelen: (1) De populatie generatie methode, (2) de global search methode en (3) de local search methode Populatie generatie In deze fase worden initiële oplossingen (i.e. schedules) gegenereerd om de swarms te bevolken. Om het Darwinian Particle Swarm Optimization algoritme efficiënt aan te wenden wordt elke swarm bevolkt door partikels die zich in een apart deel van de oplossingsruimte bevinden. De collectie van parallelle swarms beslaat dus het hele zoekgebied. Elke swarm apart heeft immers als doel een bepaald gedeelte van het totale zoekgebied te exploreren. Om de oplossingsruimte van het TCPSP op te delen en te verdelen onder de swarms werd een nieuwe methode ontworpen. De ontworpen methode vertrekt van de vaststelling dat bij het TCPSP, in tegenstelling tot het RCPSP, voor elke activiteit, bij een gekende deadline, de maximale shift (i.e. de Latest Start Time (LST)) a priori gekend is. Deze is voor elke activiteit n op het kritische pad hetzelfde, namelijk het verschil tussen deadline en CriticalP ath (deadline CriticalP ath) met CriticalP ath de lengte van het kritische pad, i.e. de kortst mogelijke feasible makespan (zie sectie 1.5). Immers, het kritisch pad wordt berekend door elke activiteit zo vroeg mogelijk te schedulen, wat exact overeenkomt met de basis van onze representatie (verschuiving ten opzichte van de Earliest Start Time (EST)). Bovendien zijn de activiteiten op het kritisch pad determinerend voor de basiskwaliteit van het schedule. Zij hebben immers het kleinste aantal mogelijke initiële shifts in de populatie generatie methode. Zij worden dan ook gebruikt om zoekgebieden af te bakenen. Aan dummy activiteiten 0 en N wordt in de eerste plaats respectievelijk een shift van 0 en (deadline CriticalP ath) (i.e. activiteit 0 wordt zo vroeg mogelijk gescheduled en activiteit N zo laat mogelijk, dit geeft immers maximale kans op optimaliteit). De andere activiteiten op het kritische pad (laat C daarbij het aantal activiteiten op dit kritisch pad zijn) kunnen dan een verschuiving tussen deze twee uitersten krijgen. De methode maakt een onderscheid tussen zoekgebieden op basis het aantal gegeven shifts aan alle activiteiten op het kritische pad 2. Het minimale totaal aantal toegekende shifts is (deadline CriticalP ath) (i.e. enkel 2 Een gegeven shift wil zeggen dat één van de activiteiten 1 tijdseenheid opgeschoven is, verder weg van

48 Hoofdstuk 2. Darwinian Particle Swarm Optimization 31 activiteit N krijgt een verschuiving, die maximaal is). Het maximaal aantal toegekende shifts is dan (C 1) (deadline CriticalP ath) (i.e. alle activiteiten op het kritische pad buiten dummy activiteit 0 krijgt een maximale shift en worden dus op hun Latest Start Time gescheduled). Alle combinaties daartussen zijn in principe mogelijk, maar er moet wel rekening gehouden worden met volgorderelaties. Immers, als activiteit j P i een shift krijgt, dan moet activiteit i deze ook krijgen om de volgorderelaties te respecteren. Stel vervolgens dat er vertrokken wordt van M swarms dan is het zoekgebied van swarm m M, m > 0 gedefinieerd door een minimaal en maximaal aantal shifts toe te kennen aan de activiteiten op het kritisch pad. Deze minima en maxima voor swarm m worden getoond in vergelijkingen 2.9 en (C 1) (deadline CriticalP ath) Min: (m 1) + (deadline CriticalP ath) M (2.9) (C 1) (deadline CriticalP ath) Max: m + (deadline CriticalP ath) M (2.10) De methode zal vervolgens op random wijze activiteiten op het kritisch pad kiezen en vervolgens deze activiteit én diens successors op het kritisch pad shifts toekennen (indien nog mogelijk), tot wanneer het toegekende aantal shifts binnen de vooropgestelde grenzen valt. Als voorbeeld toont figuur 2.3 een mogelijke opbouw van een schedule voor het voorbeeld probleem (zie sectie 1.2.3). Het kritisch pad bestaat uit activiteiten 0, 1, 6, 8 en 11 en duurt 9 tijdseenheden. Deel (A) van de figuur toont het Earliest Start Schedule voor de activiteiten op het kritisch pad. Dummy activiteiten 0 en 11 zijn niet afgebeeld. Hun shifts liggen vast op 0 en 7 (deadline CriticalP ath = 16 9 = 7). Stel vervolgens dat er 4 parallelle swarms worden gecreëerd. Dan krijgen de activiteiten op het kritische pad voor de partikels in de eerste swarm in totaal minimaal 7 en maximaal 14 shifts toegekend (zie vergelijkingen 2.9 en 2.10). Figuur 2.3 (B) toont echter de opbouw van een schedule bevat in een partikel van de 2de swarm. Immers, het totaal aantal toegekende shifts bedraagt 16 ( voor activiteiten 0, 1, 6, 8 en 11). De figuur toont overigens ook het opdringen van shifts aan opvolgers van activiteiten. Stel bijvoorbeeld dat de populatie generatie methode activiteit 1 als eerste kiest en die bijgevolg een shift in de tijd van 1 geeft. Dan is het duidelijk dat op dat moment het schedule infeasible is. Immers activiteit 1 zal nog niet voltooid zijn als activiteit 6 (met een voorlopige shift van 0) wordt aangevangen. Daarom zal de methode de shifts van alle successors van de geselecteerde activiteit ook incrementeren, wat in deel (B) van de figuur te zien is. De figuur toont verder dat daarna activiteit 8 nog 6 keer random is gekozen (+1 door de selectie van activiteit 1 en 6 maal +1 door de selectie van activiteit 8 geeft een totale shift van 7, zoals te zien in deel (B) van de figuur). diens EST.

49 Hoofdstuk 2. Darwinian Particle Swarm Optimization 32 4 (A) (B) Shift van activiteit 6: +1 Figuur 2.3: Illustratie van de populatie generatie methode. Het is duidelijk dat partikels uit swarms met een laag indexnummer m de activiteiten van het kritisch pad vroeg zullen inplannen. Late inplanningen van deze activiteiten gebeurt door partikels uit swarms met een indexnummer m dicht tegen M. Tenslotte kent de methode voor de activiteiten die niet op het kritisch pad liggen een verschuiving ten opzichte van hun EST toe. Activiteiten worden in random volgorde gekozen, waarbij hun kans op selectie toeneemt naarmate de activiteit minder shiftmogelijkheden heeft (door bijvoorbeeld reeds toegekende shifts aan voorgangers of opvolgers). Daarmee wordt gepoogd maximale diversiteit in de beginpopulatie te introduceren. We kunnen nu immers meer gecontroleerd grote en kleine verschuivingen aan deze activiteiten toekennen. Na het toekennen van een verschuiving aan een activiteit worden de shiftmogelijkheden van nog niet geschedulede voorgangers en opvolgers geüpdatet en herhaalt de toekenningsprocedure zich, tot alle activiteiten een starttijd toebedeeld hebben gekregen en het hele schedule eenduidig ingepland is.

50 Hoofdstuk 2. Darwinian Particle Swarm Optimization 33 Ten slotte worden deze schedules een eerste maal geëvalueerd en worden de corresponderende starttijden van de beste schedules binnen elke swarm de startwaarden voor gbest van die swarm. Figuur 2.4 geeft een grafische voorstelling van de generatie van 4 swarms op het optimalisatieprobleem met 2 variabelen. Elke swarm bestaat uit 7 elementen, waarvan telkens het best presterende element reeds als gbest is aangeduid. Global Best Huidige Positie Figuur 2.4: Grafische weergave van de populatie generatie. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en Global Search In deze fase starten de partikels met hun exploratie van de oplossingsruimte. Daartoe wordt binnen elke swarm vertrokken van de standaardprocedure van de Particle Swarm Optimizer zoals te zien in figuur 2.2, pagina 25. De wijzigingen ten opzichte van deze procedure worden

51 Hoofdstuk 2. Darwinian Particle Swarm Optimization 34 hieronder opgelijst. Snelheids- en positie-update De snelheid van een partikel wordt geüpdatet volgens formule 2.2. Wel wordt er, om een iets snellere convergentie te bewerkstelligen en explosies te vermijden, een reductie op zowel de inertiefactor w, de maximale snelheid V max als de leerfactor c 2 geplaatst, telkens wanneer de swarm zijn gbest heeft geüpdatet. De maximaal toegelaten snelheid van een partikel wordt als volgt berekend: V max = γ V max (2.11) Met V max = (LST 1 EST 1 ) (LST N 1 EST N 1 ) 2 en γ [0, 1] (2.12) V max laat met andere woorden slechts een gedeelte γ van de totale mogelijke verschuiving van een partikel toe. De huidige snelheid van een partikel i gedurende iteratie t wordt als volgt berekend (voor een probleem in M dimensies): ( V ) 2 ( ) 2 V i,t = 1 i,t V M i,t (2.13) Wanneer de huidige snelheid te hoog blijkt te zijn, wordt de snelheid gereduceerd tot V max door op random wijze snelheid weg te nemen over alle mogelijke dimensies. Wanneer de huidige snelheid echter te laag is (in dit algoritme wanneer het partikel geen snelheid meer heeft), en stagnatie dreigt, wordt in navolging van Ratnaweera et al. (2004) (zie pagina 27), de snelheidsvector random gemuteerd, waarbij de kans op mutatie in elke dimensie een te optimaliseren parameter is. De positie van een partikel wordt tenslotte geüpdatet zoals gegeven in formule 2.3. Reparatie van een oplossing Het limiteren van de totale snelheid verhindert echter niet dat de snelheid over één enkele dimensie te hoog kan worden en dat na de positie-update het schedule onmogelijk (infeasible) blijkt te zijn. Daartoe wordt na elke positie-update van een partikel een controle op feasibility uitgevoerd en indien nodig het schedule aangepast tot een feasible schedule is bereikt. Er zijn 2 reparatiefuncties geïmplementeerd in het algoritme, een voorwaartse reparatie en een achterwaartse. De intrinsieke werking van beide functies is echter identiek. Het verschil is dat de voorwaartse reparatiefunctie begint te controleren bij activiteit 0 en opschuift naar

52 Hoofdstuk 2. Darwinian Particle Swarm Optimization 35 activiteit N, terwijl het achterwaartse begint bij activiteit N en zich zo naar activiteit 0 toewerkt. Welke van beide functies wordt gebruikt, wisselt elke iteratie op een random manier af. De intrinsieke werking gaat als volgt (uitgelegd voor de voorwaartse reparatiefunctie): Van elke activiteit j [1, N 1] wordt de maximaal toelaatbare verschuiving S max j berekend: S max j = min i Successorsj (EST i + X i,t ) DUR j EST j (2.14) Blijkt Sj max kleiner te zijn dan de huidige verschuiving X j,t, is het schedule infeasible en moet er een reparatie uitgevoerd worden. De reparatie zelf bestaat uit 2 opties: ˆ Opvolgers opschuiven: In de eerste poging wordt gepoogd de opvolgers naar achter te schuiven (vergroten van X i,t waarbij activiteit i de vroegst startende successor is) totdat EST j + X j,t + DUR j = min i Successorsj (EST i + X i,t ). Het is goed mogelijk dat een verschuiving van de successor een nieuwe infeasibility met diens successor oplevert. Daarom wordt de hele keten van successors bij verschuiving gecontroleerd op nieuwe conflicten en indien deze gedecteerd worden, worden zij op een gelijke manier opgelost. ˆ Voorgangers terugschuiven: In de tweede poging wordt getracht activiteit j zelf naar een vroeger tijdstip te schuiven door vermindering van X j,t tot EST j + X j,t + DUR j = min i Successorsj (EST i + X i,t ). Het is goed mogelijk dat een verschuiving van activiteit j een nieuwe infeasibility oplevert met diens predecessors. Daarom wordt de hele keten van predecessors bij verschuiving gecontroleerd op nieuwe conflicten en indien deze gedecteerd zijn geworden, worden zij op een gelijke manier opgelost. Er zijn vervolgens 4 mogelijkheden: ˆ Het opschuiven van opvolgers is nog steeds infeasible (de verschuiving van j viel bijvoorbeeld buiten het toelaatbare domein), maar het terugschuiven van voorgangers is feasible: voer de tweede optie uit. ˆ Het opschuiven van opvolgers is feasible, maar het terugschuiven van voorgangers is infeasible: voer de eerste optie uit. ˆ Zowel het opschuiven van opvolgers als terugschuiven van voorgangers is feasible: kies de optie met de beste fitness value. ˆ Zowel het opschuiven van opvolgers als terugschuiven van voorgangers is infeasible: Het reparatiealgoritme heeft gefaald. Deze situatie mag bijgevolg niet voorkomen.

53 Hoofdstuk 2. Darwinian Particle Swarm Optimization 36 Local Search submethode Binnen het feasible schedule wordt vervolgens naar verbeteringen gezocht. Een Local Search submethode gebaseerd op Verbeeck (2011), is hiervoor opgenomen in de procedure. algoritme gaat tussen de vroegst mogelijke starttijd voor activiteit j, STj min, rekening houdend met de planning van zijn voorgangers (zie vergelijking 2.15) en de laatst mogelijke starttijd, STj max, rekening houdend met de planning van zijn opvolgers (zie vergelijking 2.16) kijken of er een betere positie voor activiteit j kan gevonden worden. Dit ST min j = max i Pj (EST i + X i,t + DUR i ) (2.15) ST max j = min i Successorsj (EST i + X i,t ) DUR j (2.16) Het algoritme zal activiteit j op elke mogelijke startpositie ST tussen STj min en STj max plaatsen. Wanneer er op een bepaalde positie een volgens de doelfunctie betere fitness value dan de huidige gevonden wordt, wordt de activiteit daar geplaatst en worden ST min van diens opvolgers en ST max van diens voorgangers met de nieuwe positie geüpdatet. Beloning en bestraffing van swarms In navolging van Tillett et al. zijn de verschillende swarms onderhevig aan principes van natuurlijke selectie. De geïmplementeerde selectiemechanismen zijn: het toevoegen van een partikel aan een swarm, het verwijderen van een partikel uit een swarm, het onstaan van een kind -swarm gebaseerd op een ouder -swarm en het verwijderen van een gehele swarm uit de zoekprocedure. ˆ Het toevoegen van een partikel aan een swarm: Telkens wanneer een swarm zijn gbest updatet (wel gelimiteerd tot één maal per iteratie), wordt de swarm beloond met de toevoeging van één nieuw partikel, welke dezelfde kenmerken draagt als de andere elementen uit de swarm (i.e. met dezelfde kenmerken random gegenereerd zoals beschreven in sectie 2.2.1). ˆ Het verwijderen van een partikel uit een swarm: Wanneer een swarm faalt een betere positie te vinden over verschillende iteraties heen, dan vormt dit een indicatie dat een lokaal optimum is bereikt. Om rekenkracht vrij te maken voor andere swarms, waarvoor er nog geen indicatie bestaat dat deze een lokaal optimum hebben bereikt, worden er systematisch partikels uit de swarm verwijderd, zolang er geen betere positie door de overgebleven partikels wordt gevonden. Het aantal iteraties waarin geen verbetering is gevonden door swarm s wordt bijgehouden door search counter s. Wanneer search counter s een vooraf bepaalde zoeklimiet Max search counter heeft bereikt, wordt de slechtst presterende partikel uit de swarm verwijderd.

54 Hoofdstuk 2. Darwinian Particle Swarm Optimization 37 Om nog meer rekenkracht naar betere of meer belovende zoekgebieden te sturen, wordt bovendien het aantal iteraties tot de volgende verwijdering van een partikel keer op keer beperkt. Daartoe introduceren we een nieuwe variabele NKill s. NKill s houdt bij hoeveel partikels er al opeenvolgend verwijderd zijn, zonder dat er in swarm s een globale verbetering is gevonden. Wanneer de volgende partikel uit de swarm wordt verwijderd, wordt search [ counter s niet ] terug op 0 gezet, maar neemt deze de 1 waarde Max search counter 1 NKill s+1 aan. Hoe hoger NKill s wordt, hoe hoger search counter s opnieuw geïnitialiseerd wordt, hoe sneller het volgende partikel verwijderd zal worden. ˆ Het onstaan van een kind -swarm: Goed presterende swarms krijgen de kans zich voort te planten. Wanneer een swarm s zich in een iteratie globaal verbeterd heeft, heeft het een kleine kans een kind -swarm voort te brengen met kenmerken van zichzelf. De kans p op het voortbrengen van een kind-swarm wordt als volgt gedefinieerd: p = rand [0, 1] 2 N s (2.17) met N s het huidige aantal swarms. De nieuwe swarm bezit evenveel partikels als het startaantal partikels in een swarm bij aanvang van het algoritme (populatie generatiefase). De helft van de partikels wordt ingenomen door de beste partikels van de ouder-swarm. De andere helft bestaat uit random gegenereerde partikels met dezelfde basiskenmerken als de ouder swarm (cfr. sectie 2.2.1). Deze nieuwe swarm laat toe het zoekgebied rond de ouder-swarm nog intensiever te exploreren, terwijl ook nieuwe diversiteit in de swarm wordt geïntroduceerd. ˆ Het verwijderen van een swarm: Wanneer een swarm stagneert worden er systematisch (en steeds sneller) elementen uit de swarm verwijderd (cfr. punt 2). Wanneer er zich echter minder partikels in een swarm bevinden dan een vooropgesteld minimum aantal m min, dan wordt de hele swarm uit de zoekprocedure verwijderd. De best presterende swarm echter, kan niet worden verwijderd, omdat deze het vermoeden draagt een globaal optimum te kunnen zijn. Bovendien, wanneer enkel de best presterende swarm overblijft, worden er nieuwe swarms gecreëerd, onder dezelfde modaliteiten als in sectie 2.2.1, met uitzondering van gbest, dewelke voor elke swarm nu gbest van de enig overgebleven swarm wordt. Einde van de global search De global search stopt wanneer een voorgedefinieerd stopcriterium is bereikt. Dit kan het aantal door de global search gegenereerde schedules zijn of de totale runtime van de global search. Tot slot stopt het algoritme ook wanneer een a priori gekende optimale

55 Hoofdstuk 2. Darwinian Particle Swarm Optimization 38 oplossing bereikt is. De volgende pagina toont de werking van de gepresenteerde global search fase van het DPSO- LDPSO in pseudo-code. Dezelfde werking wordt ook grafisch afgebeeld in het flowchart op figuur 2.5. Initialiseer beginpopulatie over k swarms Initialiseer snelheidsvectoren Initialiseer w, c 2, V max, search counter, NKill en nrofparticles voor elke swarm repeat for swarms particle spawned = false for partikels in de swarm evalueer fitness F(x) van het partikel if F(x) < lbest van het partikel then update lbest van het partikel if F(x) < gbest van de swarm then update gbest van de swarm verlaag w, c 2 en V max reset search counter en NKill van de swarm if particle spawned = false then voeg partikel toe aan de swarm incrementeer nrof particles van de swarm particle spawned = true update de snelheid en positie van het partikel repareer de oplossing voer local search uit if particle spawned = false then incrementeer search counter van de swarm if search counter = Max search counter then verwijder slechtste partikel uit de swarm incrementeer N Kill van de swarm herinitialiseer search counter ifv N Kill decrementeer nrof particles if nrofparticles in de swarm < minimum nr of particles and swarm heeft niet de beste gbest over de k swarms then verwijder de swarm decrementeer k

56 Hoofdstuk 2. Darwinian Particle Swarm Optimization 39 if k = 1 then herinitialiseer beginpopulatie over k swarms herinitialiseer snelheidsvectoren herinitialiseer w, c 2, V max, search counter, NKill en nrofparticles voor elke swarm gebruik gbest van enig overgebleven swarm als gbest voor de k nieuwe swarms until stopcriterium is bereikt

57 Hoofdstuk 2. Darwinian Particle Swarm Optimization 40 Darwinian Particle Swarm Optimization Initialisatie Swarming F(x) < lbest? Nee Incrementeer search_counter Search_counter = max_search_counter? Initialisatie van k swarms in het k- de zoekgebied Ja Update lbest F(x)<gbest? Nee Verwijder swarm Ja Snelheidsvector initialisatie Populatie-evaluatie Ja Voeg nieuw partikel toe Nee Nee Creatie van kindswarm? Ja Kopieer beste helft van ouder swarm Random initialisatie van de andere helft < Max_schedules Aantal schedules? >=Max_schedules Output resultaat Figuur 2.5: Flowchart van het DPSO. Ja Verwijder Partikel Aantal partikels < minimum aantal partikels? Nee Snelheidsupdate Positie-update

58 Hoofdstuk 2. Darwinian Particle Swarm Optimization Local DPSO In een tweede fase van het gepresenteerde DPSO-LDPSO, worden de omgevingen rond de beste oplossingen uit de eerste fase intensief onderzocht. Het construeren van zeer lokale neighbourhoods voor het PSO is niet nieuw in de literatuur. Kennedy (2000) citeert een PSO variant waarbij zeer lokale neighbourhoods worden geconstrueerd door de k dichtste oplossingen tussen n gegenereerde oplossingen te klusteren tot subswarms. Deze methode is echter zeer rekenintensief. De gepresenteerde variant in deze masterproef omzeilt dit probleem door doelbewust dichte buren rond een kern -oplossing te genereren. Blackwell (2007) volgt een gelijkaardige methode door rond lokale pieken een swarm te genereren met patrouillerende partikels rond deze pieken. De verschillende gbest van de (nog) actieve swarms uit de eerste fase vormen in deze fase de kernen van lokale swarms die zich rond hen zullen begeven. Deze swarms worden geconstrueerd door een gbest van een gegeven swarm uit de eerste fase P articles in temporary swarm keer te muteren, ter constructie van P articles in temporary swarm partikels in een lokale swarm. De mate waarin gbest wordt gemuteerd wordt gecontroleerd door de parameter mutation rate. Deze bepaalt per activiteit (i.e. per dimensie van de oplossingsvector) de kans dat de starttijd van deze activiteit gemuteerd wordt. Een hoge mutation rate zorgt voor grote lokale zoekgebieden terwijl een lage mutation rate zorgt voor een lokale swarm met partikels op zeer korte afstand in de oplossingsruimte. Indien mutatie wordt toegelaten dan krijgt die activiteit een nieuwe shift tussen diens EST en LST. Nadien moet deze gemuteerde oplossing mogelijks opnieuw hersteld worden om een feasible schedule te verkrijgen. De procedure daarvoor is gelijkaardig aan de reparatiemethode beschreven in sectie De swarmprocedure loopt vervolgens gelijk aan die gepresenteerd in de eerste fase. Echter, in deze tweede fase wordt nooit een swarm verwijderd, tenzij er geen partikels meer in de swarm overblijven. Wanneer alle swarms uitgeswarmd zijn, herneemt de procedure zich met de creatie van nieuwe swarms gevuld met gemuteerde gbest oplossingen. Een gelijkaardige methode is reeds beschreven in de literatuur. Zhao et al. (2010) introduceert een Harmony Search als local search procedure in een Dynamic Multi-Swarm PSO voor het RCPSP. In de Harmony Search worden een bepaald aantal oplossingen waaronder de gbest van elke swarm opgeslagen in de Harmony Memory (HM). Met kans HMCR (Harmony Memory Consideration Rate) wordt een oplossing uit de HM lichtjes aangepast. Deze lichte aanpassing (pitching) wordt gecontroleerd door de Pitch Adjustment Rate (PAR). De Pitch Adjustment Rate bepaalt de kans dat een waarde in de oplossingsvector wordt aangepast. De Distance Bandwith controleert de grootte van de aanpassingen bij het pitchen. Met kans 1 HMCR wordt een geheel nieuwe oplossing ingevoegd op de onderzochte positie. In tegenstelling tot het algoritme gepresenteerd in deze masterproef, past Zhao et al. deze Harmony

59 Hoofdstuk 2. Darwinian Particle Swarm Optimization 42 Search echter toe na elke iteratie van het PSO. Indien de Harmony Search procedure een betere oplossing vindt, wordt de gbest van de desbetreffende swarm geüpdatet, waarna de PSO procedure zich herneemt. Einde van het lokale DPSO Het lokale DPSO stopt wanneer een voorgedefinieerd stopcriterium is bereikt. Dit kan het aantal door het lokale DPSO gegenereerde schedules zijn of de totale runtime van het lokale DPSO. Tot slot stopt het algoritme ook wanneer een a priori gekende optimale oplossing bereikt is. Figuur 2.6 geeft een grafische voorstelling van de generatie van lokale swarms in het voorbeeldoptimalisatieprobleem in 2 dimensies. Elke lokale swarm telt 5 elementen. De Global Best (gbest, kern van de lokale swarm) komt immers niet als beginelement voor in de lokale swarm. Op de volgende pagina ten slotte, wordt een overzicht in pseudo-code gegeven van de LDPSO fase. Global Best Huidige Positie Figuur 2.6: Grafische weergave van lokale swarms. De variabele op de x-as varieert tussen 0 en 1.4, de tweede variabele, op de y-as, varieert tussen 0 en 1.

60 Hoofdstuk 2. Darwinian Particle Swarm Optimization 43 voeg gemuteerde gbest k partikels toe aan k lokale swarms Initialiseer snelheidsvectoren Initialiseer w, c 2, V max, search counter, NKill, nrofparticles en gbest voor elke swarm repeat for swarms particle spawned = false for partikels in de swarm evalueer fitness F(x) van het partikel if F(x) < lbest van het partikel then update lbest van het partikel if F(x) < gbest van de swarm then update gbest van de swarm verlaag w, c 2 en V max reset search counter en NKill van de swarm if particle spawned = false then voeg partikel toe aan de swarm incrementeer nrof particles van de swarm particle spawned = true update de snelheid en de positie van het partikel repareer de oplossing voer local search uit if particle spawned = false then incrementeer search counter van de swarm if search counter = Max search counter then verwijder slechtste partikel uit de swarm incrementeer N Kill van de swarm herinitialiseer search counter ifv N Kill decrementeer nrof particles if nrofparticles = 0 bij elke swarm then voeg opnieuw gemuteerde gbest k partikels toe aan k swarms herinitialiseer snelheidsvectoren herinitialiseer w, c 2, V max, search counter, NKill, nrofparticles voor elke swarm gebruik historische gbest voor elke swarm until stopcriterium is bereikt

61 Hoofdstuk 3 Greedy Random Adaptive Search Procedure 3.1 Inleiding De Greedy Random Adaptive Search Procedure (GRASP) is een multi-start heuristische methode die in zijn basisvorm bestaat uit 2 fases: De constructie van een initiële oplossing en een verbeteringsfase. Elke iteratie doorloopt beide fases waarbij getracht wordt een lokaal optimum te bereiken. De procedure eindigt wanneer een vooraf gekende optimale oplossing wordt bereikt of bij het bereiken van één of meerdere door de gebruiker gedefinieerde stopcriteria. Met het implementeren van dit algoritme wordt gepoogd meer intelligentie in de opbouw van oplossingen te verkrijgen (zie ook sectie 3.2). Het grootste nadeel van een GRASP is dat alle iteraties (bestaande uit een constructie- en verbeteringsfase) los van elkaar staan en dat er dus geen communicatie met andere, reeds gegenereerde oplossingen plaatsvindt. Er bestaan echter strategieën die communicatie trachten te bevorderen, zie Resende & Ribeiro (2003). In hoofdstuk 4, wordt er echter een nieuwe methode van communicatie tussen de oplossingen gepresenteerd. GRASP algoritmen worden in een hele waaier aan toepassingen gebruikt (zie Resende & Ribeiro (2003, pg 240)). Het eerste GRASP algoritme werd door Chvatal (1979) gepresenteerd. Het is een wiskundige benadering voor het Set-Covering Problem. De eerste toepassing echter, werd geïntroduceerd door Feo & Resende (1989). In hun paper wordt een toepassing geformuleerd voor hetzelfde Set-Covering Problem. Feo et al. (1996) past de GRASP toe op het Single Machine Scheduling (SMS) probleem. In het SMS moeten N activiteiten op één machine gescheduled worden en tussen deze activiteiten bestaan er volgorde-afhankelijke setup kosten en tijdsvertragingen. Het SMS tracht de totale tijdsvertragingen en kosten te mi- 44

62 Hoofdstuk 3. Greedy Random Adaptive Search Procedure 45 nimaliseren. Akrout et al. (2010) tracht ook een GRASP benadering te vinden voor het SMS. Rios-Mercado & Bard (1998) presenteren een GRASP voor het flow-line probleem. In het flow-line probleem moeten N activiteiten op M identieke machines worden gescheduled, ter minimalisatie van de totale makespan. Alvarez-Valdes et al. (2008) presenteert een GRASP voor het project scheduling met gedeeltelijk hernieuwbare resources. Dit zijn niet hernieuwbare hulpmiddelen die met een beperkte capaciteit slechts gedurende bepaalde tijdseenheden voorradig zijn. Activiteiten gebruiken dan ook enkel deze hulpmiddelen als ze gedurende zulke tijdseenheden gepland worden. Weekendwerk kan op deze manier gemodelleerd worden (bijvoorbeeld, er mag slechts 2 weekends op 3 gewerkt worden). De GRASP wordt over het algemeen beschouwd als een heel eenvoudige methode waarbij slechts weinig parameters gekalibreerd dienen te worden. De basiswerking van een GRASP wordt getoond in figuur 3.1. Figuur 3.1: Flowchart van het basis GRASP

63 Hoofdstuk 3. Greedy Random Adaptive Search Procedure Oplossingsmethode Constructie van een initiële oplossing De eerste fase van een GRASP bestaat uit de constructie van een haalbare oplossing (feasible solution). Vermits het TCPSP een combinatorieel probleem is, kan de constructie van deze feasible solution gezien worden als een steekproef uit de oplossingsverzameling. Deze feasible solutions worden bovendien niet geconstrueerd met het oog op (lokale) optimaliteit. De zoektocht naar een (lokaal) optimum is het doel van de volgende fasen, zoals later wordt beschreven. De initiële oplossingen dienen daarentegen wel zo divers mogelijk te zijn, teneinde het hele zoekgebied af te tasten. Om deze diversiteit te bekomen wordt er heel wat willekeurigheid geïntroduceerd in de constructie van de initiële oplossingen. De constructiefase bestaat uit een iteratieve procedure waarbij een schedule stap voor stap wordt opgebouwd. In elke stap wordt een willekeurige activiteit toegevoegd aan het reeds partieel geconstrueerde schedule. Om een feasible schedule te verkrijgen wordt de willekeurigheid in de eerste plaats beperkt door de precedence relationships in rekening te brengen: Een activiteit kan maar willekeurig gekozen worden als reeds al zijn predecessors volgens het partiële schedule voltooid zijn. Met de doelfunctie wordt nog niet expliciet rekening gehouden 1. De constructie van een initiële oplossing start met een leeg schedule. Met behulp van een pointer wordt het punt in de tijd gedefinieerd waarop gekeken wordt of en welke activiteit op het tijdstip van de pointer zal aanvangen. Om een feasible schedule te bekomen worden op dit tijdstip enkel de activiteiten bekeken die mogelijks kunnen aanvangen, met andere woorden, wiens predecessors ten laatste voltooid zijn op het tijdstip van de pointer. Logischerwijs wordt deze pointer geïnitialiseerd op tijdseenheid 0. Deze activiteiten worden vervolgens geëvalueerd met behulp van een incrementele kostfunctie. Deze gaat na hoeveel resources er moeten bijgehuurd worden indien de activiteit start op het tijdstip van de pointer. Op basis van deze kostfunctie wordt de volgende te schedulen activiteit gekozen. De keuzeset van mogelijks te schedulen activiteiten wordt eerst op basis van de incrementele kostfunctie verkleind. Daartoe worden c min en c max gedefinieerd als respectievelijk de laagste en hoogste incrementele kost van de mogelijks te schedulen activiteiten. Met behulp van een eerste parameter α wordt een Restricted Candidate List (RCL) geconstrueerd. In het algemeen bevat de RCL de beste k alternatieven van de gehele keuzeset. Een andere, vaak gebruikte definiëring van de RCL is de verzameling van alle oplossingen binnen een bepaald percentage van het beste alternatief. Echter, de constructie van de RCL is probleem- en toepassingsafhankelijk en vraagt inzicht in het probleem. Dit inzicht is belangrijk, omdat 1 Via parameterkalibratie in de constructieprocedure kan er in deze fase evenwel al enige invloed op de doelfunctie worden uitgeoefend, zie verder.

64 Hoofdstuk 3. Greedy Random Adaptive Search Procedure 47 een te lakse toelating tot de RCL kan leiden tot inferieure oplossingen, terwijl te strikte toelating de diversiteit van de gegenereerde oplossingen in de kiem smoort. Voor het TCPSP is geopteerd voor een RCL waarin alle activiteiten van de oorspronkelijke keuzeset zitten waarvan de incrementele kost kleiner dan of gelijk is aan c min + α(c max c min ) met α [0, 1] (3.1) waarbij α een te optimaliseren parameter is, die aangepast moet worden aan de karakteristieken van het TCPSP. Vervolgens wordt er uit de RCL een willekeurige activiteit gekozen. Door de aard van het onderzochte probleem is het evenwel noodzakelijk op dit punt veranderingen ten opzichte van een traditionele GRASP methode voor het RCPSP aan te brengen. Indien bij een RCPS-probleem de RCL niet leeg is op een bepaalde pointerpositie, is het altijd beter één van de activiteiten uit de RCL op die positie te schedulen, door de regular measure of performance van het RCPSP. Bij eenzelfde situatie voor het TCPS-probleem kan het soms beter zijn geen activiteit te schedulen (Het TCPSP probleem heeft immers een non-regular measure of performance). Zolang c min 0 bedraagt (i.e. er bestaat minstens één activiteit die kosteloos een starttijd gelijk aan de positie van de pointer kan toegekend worden) is het raadzaam om één van de activiteiten uit de RCL daar te schedulen. De α-parameter beïnvloedt vervolgens de keuzeset en de geassocieerde incrementele kosten van de uiteindelijk gekozen activiteit (Indien α 0 is, zal bijvoorbeeld een kosteloze activiteit worden gekozen). Indien de minimale kost c min echter groter dan 0 is, wordt een parameter β geïntroduceerd die de keuze of er nog een activiteit op die plaats gescheduled wordt beïnvloed. Er moet immers in elk geval gehuurd worden, de te beantwoorden vraag is dus of er op dit tijdstip doelbewust extra huurkosten worden opgenomen of niet. Of dat noodzakelijk is hangt af van de karakteristieken van het probleem, en kan pas bij de volledige constructie van een schedule beantwoord worden. De beslissing in de gepresenteerde GRASP werkt als volgt: random gekozen activiteit e RCL met incrementele kost(e) > 0 wordt gescheduled als rand [0, 1] β incrementele kost(e) met β R (3.2) Hoe groter de incrementele kost van e is, hoe kleiner de kans dat e gescheduled wordt. Nadat activiteit e al dan niet gescheduled werd, wordt de pointer geüpdatet. Voor zolang c min 0 bedraagt en de RCL niet leeg is, blijft de pointer op dezelfde positie. Het is immers mogelijk dat er dan nog een activiteit kostenloos op die plaats kan gescheduled worden. Indien de RCL leeg is of c min > is, 0 wordt de pointer voorwaarts verplaatst naar het einde van de eerstvolgend eindigende, geschedulede activiteit, omdat er enkel dan resources vrijkomen. Dit proces loopt door tot alle activiteiten gescheduled zijn. Het kan echter gebeuren dat de pointer de latest start time van ongeschedulede activiteiten voorbij steekt, waardoor het schedule hoe dan ook infeasible wordt. Om dit tegen te gaan worden deze activiteiten dan op

65 Hoofdstuk 3. Greedy Random Adaptive Search Procedure 48 hun latest start time gescheduled, ongeacht de daartoe noodzakelijke huurkosten. Het doel van deze fase is immers het construeren van een feasible schedule, eerder dan een optimaal schedule. De flowchart van het constructieproces wordt gegeven in figuur 3.2 Begin Constructiefase Leeg schedule t=0 Construeer keuzeset Evalueer incrementele kost elementen bereken Cmin & Cmax Construeer RCL Selecteer een element s uit RCL Cmin > 0? Nee Voeg s toe op tijdstip t Ja Nee Rand < bèta/ incrementele_kost(s)? ja Voeg s toe op tijdstip t Nee Incrementeer t tot volgende completion time van reeds geschedulede activiteiten t > LST van element f uit ongeschedulede act? Ja Schedule f op LST Nee Schedule volledig? Ja Einde constructiefase Figuur 3.2: Flowchart van de constructiefase van de GRASP Verbetering van een oplossing Door het manipuleren van de parameters α en β, kunnen huurkosten vroeger of later in het schedule worden opgenomen. Hoge α- en β-waarden zorgen voor vroege opname, terwijl lage

66 Hoofdstuk 3. Greedy Random Adaptive Search Procedure 49 α- en β-waarden zorgen voor late opname. In de constructiefase wordt het schedule voorwaarts opgebouwd. Daarom is het raadzaam in deze fase huurkosten vroeg in het schedule op te nemen, omdat dit op een meer gecontroleerde manier kan gebeuren dan dat ze op het einde opgenomen worden. Op het einde bestaat er immers een groter risico dat activiteiten geforceerd op hun Latest Start Time (LST) gescheduled worden omdat de pointer reeds hun LST gepasseerd is. Bij hoge α- en β-waarden bestaat op het einde van het schedule dus een grotere kans op vrije ruimtes. De verbeteringsprocedure zal trachten activiteiten die op een tijdstip gescheduled staan waarop er gehuurd moet worden, een latere starttijd toe te kennen, in de vrije ruimte. De procedure werkt als volgt: gegeven is een activiteit, gescheduled op een tijdstip waarop er gehuurd moet worden. Vervolgens wordt een lijst aangemaakt van al zijn successors, direct en indirect. Dan wordt er één voor één, van de laatste tot de eerste activiteit in die lijst (i.e. van de eind dummy activiteit tot de oorspronkelijke activiteit), gekeken of de onderzochte activiteit later kan gescheduled worden, zonder de precedence relationships te verbreken. In de eerste plaats wordt er naar de goedkoopste starttijd gekeken. Indien er meerdere mogelijke starttijden met de laagste kost zijn, wordt de laatste starttijd gekozen. Het feit dat precedence relationships niet verbroken worden (i.e. een activiteit zal niet voorbij de starttijd van één van diens successors gescheduled worden) verklaart waarom de successor lijst achterwaarts wordt afgelopen. Door hoge α- en β-waarden is er immers bewegingsruimte op het einde van het schedule voorzien waardoor de bewegingsvrijheid van de laatste successor (dus ook de laatst geschedulede activiteit uit de successorlijst, de eind dummy activiteit buiten beschouwing gelaten) het grootst is. Het verplaatsen van deze activiteit naar een later tijdstip vergroot vervolgens de bewegingsvrijheid van diens directe predecessors. Het mogelijks vergroten van de bewegingsvrijheden van predecessors loopt dan zo door tot de eerste activiteit. Het gehele schedule wordt éénmaal achterwaarts doorlopen, van de laatste positie met een huurkost, tot de eerste. De verbeteringsprocedure wordt achterwaarts uitgevoerd om de bewegingsruimte in het middenveld nog te vergroten. Bovendien wordt elke activiteit maar één keer onderzocht op een mogelijke verbetering van diens starttijd Local search Na de verbeteringsfase wordt het gehele schedule nog éénmaal doorlopen met een local search procedure, zoals beschreven in sectie Door de verschuivingen die in de vorige fase plaatsvonden of door lage α en β waarden in de constructiefase, kunnen er immers nog andere vrije ruimten dan de voorziene ruimte op het einde van het schedule bestaan, of ontstaan zijn. De local search procedure probeert deze vrije ruimten alsnog op te vullen. Het schedule wordt door de local search procedure voorwaarts doorlopen. Immers, na de verbeteringsfase (en het

67 Hoofdstuk 3. Greedy Random Adaptive Search Procedure 50 zo laat mogelijk schedulen van activiteiten) is er meer bewegingsruimte te verwachten in het begin en het midden van de relevante tijdshorizon. Er zijn twee belangrijke verschillen met de verbeteringsfase: ˆ Het local search algoritme zoekt de hele feasible range af, gegeven in vergelijkingen 2.15 en 2.16 op pagina 36. In de verbeteringsfase worden enkel latere starttijden dan de huidige onderzocht. ˆ In de local search fase wordt er geen predecessor lijst opgebouwd en in volgorde onderzocht. Dit was noodzakelijk in de verbeteringsfase, om grote noodzakelijke verschuivingen in het schedule te bewerkstelligen. In local search fase gaan we slechts op zoek naar lokale verbeteringen. Einde van de GRASP De GRASP stopt wanneer een voorgedefinieerd stopcriterium is bereikt. Dit kan het aantal door de GRASP gegenereerde schedules zijn of de totale runtime van de GRASP. Tot slot stopt het algoritme ook wanneer een a priori gekende optimale oplossing bereikt is.

68 Hoofdstuk 4 Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer 4.1 Inleiding De derde en laatste methode die in deze masterproef wordt gepresenteerd, is een Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer (GRASP-LDPSO). Het is een hybride algoritme bestaande uit de GRASP, beschreven in hoofdstuk 3 en de lokale variant van de DPSO, beschreven in hoofdstuk 2. De motivatie voor deze hybridisering is tweeledig: ˆ Ten eerste tonen empirische resultaten, beschreven in hoofdstuk 5, aan dat zowel de eerste fase van het DPSO als de GRASP niet over genoeg local search capaciteiten beschikken om tot een echt lokaal optimum te convergeren. GRASP slaagt er door de ingebouwde intelligentie in de schedule-opbouw, daarentegen wel in sneller tot aanvaardbaar goede oplossingen te komen dan de eerste fase van het DPSO-LDPSO. De performantie van de lokale variant van het DPSO uit hoofdstuk 2 (LDPSO), toont echter aan dat lokale swarms over de nodige local search capaciteiten beschikt. ˆ Ten tweede, duidt Feo et al. (1996) op de observatie dat de snelheid waarmee local search methoden convergeren significant toeneemt naarmate vertrokken wordt van een verbeterde oplossing. Gegeven de beperkte rekentijd die aan metaheuristieken wordt gegeven is dit een interessante observatie: er moet bijgevolg gepoogd worden goede oplossingen als input aan de local search methode te geven. Er dient alvast opgemerkt worden dat de zwakkere local search capaciteiten van zowel de DPSO als de GRASP gedeeltelijk kunnen verklaard worden door de non-regular measure of 51

69 Hoofdstuk 4. Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer 52 performance van het TCPSP. Er moet dus gezocht worden naar een local search techniek die beter omkan met dit type measure of performance. De lokale variant van de DPSO (LDPSO, zie sectie 2.2.3) komt hiervoor in aanmerking. De partikels swarmen immers over de gehele set toegelaten starttijden van de activiteiten. Om de snelheid van convergentie tot een lokaal optimum op te drijven gebruiken we de b beste oplossingen die de GRASP methode binnen zijn toegelaten aantal iteraties heeft gegenereerd, als input voor de LDPSO. De GRASP heeft immers als kenmerk snel goede -doch niet optimale- oplossingen te genereren. 4.2 Oplossingsmethode Fase 1: GRASP In de eerste fase van dit hybride algoritme zorgt de GRASP voor relatief goede oplossingen. De ingebouwde intelligentie in de constructie zorgt steeds voor aanvaardbaar goede oplossingen per generatie van een schedule. Echter, een verdere zoektocht naar een betere oplossing, i.e. een lokaal optimum, is niet efficiënt binnen de GRASP omgeving, omdat er bijvoorbeeld geen communicatie bestaat tussen de huidig geconstrueerde oplossing en historisch relatief betere oplossingen. Dit euvel kan worden verholpen door de beste gegenereerde oplossingen van de GRASP door te verwijzen naar de volgende fase, waarin sociale interactie tussen elementen wél bestaat. Deze goede oplossingen zullen bijgevolg in de tweede fase de kernen van lokale swarms vormen. Gesteld dat het algoritme Max schedules mag opbouwen dan bepaalt parameter f [0, 1] hoeveel schedules de eerste fase mag construeren, i.e. f Max schedules. Van deze f Max schedules worden de b beste, niet gelijke oplossingen bijgehouden als input voor de tweede fase Fase 2: LDPSO In de tweede fase worden de b beste oplossingen uit de eerste fase de kernen van lokale swarms, net zoals de gbest van de verschillende swarms dat zijn voor het LDPSO uit het DPSO- LDPSO in hoofdstuk 2. In essentie worden dus de populatiegeneratie (zie sectie 2.2.1) en de Global Search (zie sectie 2.2.2) van de DPSO vervangen door de GRASP. De swarmprocedure is vervolgens gelijkaardig aan die beschreven in sectie Het gebruik van lokale varianten van het DPSO biedt de volgende voordelen: ˆ Zoals reeds vermeld zwermen de partikels in een klassieke Particle Swarm Optimizer over het hele oplossingsgebied rond de centrale beste oplossing. Deze manier van zoeken is optimaler bij een probleemomschrijving met een non-regular measure of performance. De

70 Hoofdstuk 4. Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer 53 beschreven GRASP methode stelt immers dat de activiteiten eerst voorwaarts worden gescheduled, op een zo vroeg mogelijke positie (afhankelijk van de parametersettings, zie sectie 3.2.1). Daarna worden de kostdrijvers zo laat mogelijk gescheduled (zie sectie 3.2.2). Deze 2 submethoden zijn inderdaad eerder geschikt voor regular measures of performance. Maar omwille van de observatie dat in een optimaal schedule slechts de ene activiteit kan beginnen als er een vorige gedaan is (tijdseenheid 0 buiten beschouwen gelaten) brengt een voorwaartse of achterwaartse constructie intelligentie in de opbouw en zorgen ze dus voor goede oplossingen. Het is pas in de laatste submethode, de local search fase van de GRASP (zie sectie 3.2.3) dat activiteiten doelbewust niet op vroeg (constructiefase) of laat (verbeteringsfase) worden gescheduled. Deze local search submethode is echter gericht op het vinden van kleine verbeteringen en zal het schedule niet grondig hertekenen. De LDPSO kan dit wel, omdat er zowel gemuteerd als geswarmd wordt. ˆ Door het lokale karakter van de swarms wordt er efficiënt gezocht naar lokale optima rond veelbelovende oplossingen. Het laten vallen van een globale zoektocht geeft de lokale swarms hierbij de nodige rekencapaciteit (i.e. het nodige aantal schedules of de nodige runtime) die noodzakelijk is om te convergeren naar deze lokale optima. ˆ Zoals reeds vermeld, vindt er in deze fase wel sociale interactie tussen oplossingen plaats en zal de swarm zich dynamisch doorheen de lokale zoekgebieden bewegen. Niet veelbelovende lokale zoekgebieden worden tevens inactief, wat ook meer rekencapaciteit voor betere zoekgebieden vrijmaakt. Einde van het GRASP-LDPSO De tweede fase stopt wanneer een voorgedefinieerd stopcriterium is bereikt. Dit kan het aantal door het lokale DPSO gegenereerde schedules zijn (i.e. (1 f) Max schedules) of de totale runtime van de tweede fase. Tot slot stopt het algoritme ook wanneer een a priori gekende optimale oplossing bereikt is.

71 Hoofdstuk 5 Performantie van de methoden De gepresenteerde algoritmes uit hoofdstukken 2, 3 en 4 werden gecodeerd in de C++ programmeertaal. Vervolgens zijn de implementaties van de algoritmen onderworpen aan verschillende tests. Verschillende testopstellingen moeten helpen besluiten te trekken rond de kracht van de verschillende algoritmen op verschillende aspecten van performantie. De basis voor de testprocedures zijn een standaard set aan projecten, die in de literatuur vaak wordt gebruikt om algoritmen te benchmarken. Een toelichting rond deze projectsets wordt gegeven in sectie 5.1. In sectie 5.2 worden vervolgens de verschillende performantiemaatstaven verder toegelicht. In de daaropvolgende secties 5.4, 5.5 en 5.6 worden de verschillende parameters en hun kalibraties voor de drie methoden toegelicht. Ook wordt de sterkte van de deelcomponenten in de algoritmen toegelicht. De performantie van de geïmplemteerde algoritmen voor de verschillende testopstellingen worden vergeleken in sectie 5.7. In sectie 5.8 wordt ten slotte de robuustheid van de algoritmen besproken. 5.1 Test datasets Om de drie gepresenteerde algoritmen te testen maken we gebruik van testdatabanken. Deze testdatabanken bestaan uit een verzameling projecten die random gegenereerd zijn. Zij voldoen wel aan bepaalde gekende karakteristieken, teneinde ontwikkelde algoritmen zinvol te kunnen testen. Voor deze masterproef maken we gebruik van de PSPLIB databanken, opgebouwd door Kolisch & Sprecher (1996), op basis van hun Project Generator ProGen (Kolisch et al., 1995) 1. Voor het testen van algoritmen ontworpen voor TCPSP worden de testdatabanken voor het RCPSP gebruikt. Deze projectenbibliotheek bestaat uit 3 grote delen: de j30, j60 en j120 projectsets met respectievelijk 30, 60 en 120 activiteiten per project. Binnen elke set gebruikt elk project maximaal 4 soorten resources. Elke set bestaat bovendien uit 480 testprojecten, ook wel instances genoemd. Deze instances hebben allen specifieke kenmerken rond netwerkcomplexiteit, frequentie van resourcegebruik en sterkte van resourcegebruik. 1 De PSPLIB testdatabanken zijn te vinden op 54

72 Hoofdstuk 5. Performantie van de methoden 55 Van elke combinatie van netwerkcomplexiteit, frequentie van resourcegebruik en sterkte van resourcegebruik bestaan er in de j30 projectset 10 voorbeeldprojecten. ˆ Netwerkcomplexiteit (NC): bepaalt het aantal niet-overbodige verbindingen tussen activiteiten binnen een project (i.e. het aantal precedence relationships): aantal verbindingen [J NC (1 ɛ NET ), J NC (1 + ɛ NET )] (5.1) Daarbij stelt J het aantal activiteiten binnen het project voor. N C varieert in PSPLIB tussen de 1.5 en 2.1. ɛ NET [0, 1] controlleert de afwijking in het aantal niet-overbodige verbindingen tussen activiteiten bij projecten met dezelfde netwerkcomplexiteit en is doorgaans een kleine procentuele waarde. ˆ Frequentie van het resourcegebruik (RF): stelt hoe vaak het gebruik van een type resource noodzakelijk is voor de uitvoering van een activiteit, onafhankelijk van de grootte van die vraag. RF = 1 J 1 R J 1 als q jk > 0 0 als q jk = 0 j=1 k R (5.2) In de PSPLIB variëren de waarden van RF tussen 0.25 en 1.0. Om de exacte vraag naar de verschillende types resources in een gegeven project te begrenzen, wordt ook hier een controlerende variabele ɛ ingevoerd, cfr. vergelijking 5.1 voor NC. ˆ Sterkte van resourcegebruik (RS): bepaalt hoe sterk de resource constraint van de R resources is, met andere woorden, hoe hoog de basiscapaciteit van de verschillende resourcetypes is. De gegeven capaciteit Q k van resource k R wordt gegeven in vergelijking 5.3. Q k = Q min k + RS (Q max k Q min ) k (5.3) is de minimale capaciteit die nodig is om elke activiteit in het project individueel in te kunnen plannen zonder huurkost: Q min k = max J 1 j=1 (q jk). J is het aantal activiteiten Q min k binnen het project, waarbij activiteiten 0 en J dummy activiteiten voorstellen. Q max k is de resourcecapaciteit die nodig is om het EST-schedule uit te kunnen voeren zonder huurkosten. Het is dus de piekvraag naar resource k als alle activiteiten zo vroeg mogelijk gescheduled worden. In PSPLIB varieert de waarde van RS tussen 0.2 en 1.0. Om de RCPSP instances van het PSPLIB als benchmark voor het TCPS-probleem te gebruiken, moeten we aan elke instance een deadline toekennen. Het PSPlib voorziet de optimale

73 Hoofdstuk 5. Performantie van de methoden 56 makespans voor het RCPS-probleem. Gebruiken we deze waarden als deadline, dan kunnen we de resultaten van de drie methoden vergelijken met de optimale oplossing, dewelke uiteraard 0 is (Het RCPSP laat immers het huren van extra resources niet toe). Voor het vergelijken van de methodes maken we in hoofdzaak gebruik van de j30 projectset. Deze specifieke kenmerken van de projecten in de j30 projectset zijn terug te vinden in bijlage A. 5.2 Measures of Performance De doelfunctie van het TCPSP is het minimaliseren van de totale huurkosten. Wanneer we een methode testen laten we de methode de gehele j30 projectset doorlopen en krijgen we dus 480 maal een totale huurkost. Hieruit kunnen verscheidene measures of performance worden berekend: ˆ Percentage optimale oplossingen: Wanneer de deadline van de projecten op de optimale makespan wordt geplaatst kennen we de optimale oplossing. Deze is namelijk 0. Het percentage optimale oplossingen wordt bijgevolg gegeven door vergelijking 5.4. # gevonden projecten zonder huurkost % (5.4) ˆ Gemiddelde huurkost: Deze measure of performance kan bij gelijk welke deadline zinvol gebruikt worden en wordt als volgt berekend: Gemiddelde huurkost = 480 i=1 F (x i) 480 (5.5) Waarbij x i de meest fitte oplossingsvector voor project i voorstelt, gevonden door het algoritme. ˆ Maximale huurkost: Een minder belangrijke, maar toch interessante measure of performance is de maximale huurkost gevonden binnen de projectset: Maximale huurkost = max 480 i=1 (F (x i )) (5.6) Waarbij x i de meest fitte oplossingsvector voor project i voorstelt, gevonden door het algoritme. Net als de gemiddelde huurkost kan de maximale huurkost altijd, ongeacht de gebruikte deadline, zinvol berekend worden. 5.3 Stopcriterium Alle onderstaande tests werden uitgevoerd bij een stopcriterium van 5000 te genereren schedules, tenzij anders vermeld. Hierbij is het evenwel van belang mee te geven hoe het aantal gegeneerde schedules wordt berekend:

74 Hoofdstuk 5. Performantie van de methoden 57 Basis telregel Gegeven een project met n activiteiten, zullen er bij initialisatie en per gecontroleerde verschuiving van de starttijd van een activiteit 1/n schedules worden bijgeteld. Gecontroleerde verschuiving van een starttijd Er is sprake van een gecontroleerde verschuiving van een starttijd wanneer de impact van de verschuiving op de doelfunctie wordt gecontroleerd. 5.4 DPSO-LDPSO In deze sectie worden eerst de parameters van het DPSO-LDPSO voorgesteld. Daarna worden deze parameters gekalibreerd voor optimale performantie Parameters Het gepresenteerde DPSO-LDPSO heeft volgende parameters : ˆ fase1: Parameter fase1 [0, 1] bepaalt hoeveel van de toegelaten schedules aan de populatiegeneratie 2 en de global search fase van de DPSO-LDPSO worden toegekend. Stel dat we het algoritme 5000 schedules laten bouwen dan worden er fase schedules aan de eerste fase toegekend. De overige schedules worden gebruikt voor het LDPSO. ˆ Max search counter: Parameter Max search counter bepaalt het aantal iteraties zonder verbetering van gbest alvorens een partikel uit de swarm wordt verwijderd. ˆ Particles in temporary swarm: Parameter Particles in temporary swarm bepaalt het aantal gemuteerde partikels die rond gbest worden gegenereerd in de tweede fase. ˆ mutation rate: Parameter mutation rate bepaalt de kans dat de starttijd van een activiteit binnen een oplossing gemuteerd wordt. Mutaties vinden plaats op 2 momenten in het algoritme: Wanneer de snelheid van een partikel 0 wordt. Door de starttijd van een activiteit te muteren, wordt de snelheid van het partikel geherinitialiseerd. Bij het genereren van lokale swarms in de 2de fase, zie sectie op pagina 41. ˆ nrofswarms: procedure begint. Parameter nrofswarms bepaalt met hoeveel swarms de global search ˆ pop: Parameter pop bepaalt met hoeveel partikels de global search procedure start. Het aantal partikels per swarm ligt bijgevolg vast op: pop nrofswarms. 2 De populatiegeneratie methode gebruikt steeds een vast aantal schedules, namelijk het totaal aantal te genereren partikels.

75 Hoofdstuk 5. Performantie van de methoden 58 ˆ inertiaweight: Parameter inertiaweight is de inertiefactor w. ˆ inertiaweight reduction: Parameter inertiaweight reduction bepaalt de lineaire reductie van de inertiefactor telkens wanneer er een nieuwe gbest gevonden wordt: w t = (1 inertiaweight reduction) w t 1. ˆ c1: Parameter c 1 is de learning rate geassocieerd met de pbest i van oplossing i, zie vergelijking 2.2 op pagina 22. ˆ c2: Parameter c 2 is de learning rate geassocieerd met de gbest van de swarm, zie vergelijking 2.2 op pagina 22. ˆ γ: Parameter γ bepaalt de maximale toegelaten snelheid van een partikel en is een fractie van de maximaal mogelijke snelheid, zie vergelijking Parameterkalibratie De bovenstaande parameters voor het DPSO-LDPSO dienen vervolgens gekalibreerd te worden om een optimale performantie van het algoritme te verkrijgen. Het trainen van deze parameters gebeurt door iteratief het algoritme een andere parameterset aan te reiken, en vervolgens de performantie ervan op de j30 projectset na te kijken. Omdat bepaalde parameters niet onafhankelijk van elkaar kunnen worden verondersteld, werden in een eerste fase omvangrijke sets van diverse parameterwaarden toegepast op het DPSO- LDPSO. Dit resulteerde in een parameterset die globaal bekeken het meest optimaal presteert. Daarbij werd prioriteit gegeven aan een lagere gemiddelde kost, omdat deze measure of performance minder gevoelig is voor random variatie. Er werd wel rekening gehouden met grote variaties in het percentage optimale oplossingen, dewelke door diens binaire karakter (of optimaal of niet) veel gevoeliger is voor random variatie. Met maximale kost, ten slotte, werd geen rekening gehouden en deze wordt louter ter informatie meegegeven in de gepresenteerde tabellen.

76 Hoofdstuk 5. Performantie van de methoden 59 De gevonden standaard parameters zijn te zien in tabel 5.1. Tabel 5.1: Standaard parameterwaarden voor het DPSO-LDPSO fase1 0,25 Max search counter 7 Particles in temporary swarm 5 mutation rate 0,4 nrofswarms 5 pop 60 inertiaweight (w) 0,8 inertiaweight reduction 0,1 c 1 1,5 c 2 1,5 γ 0,6 Vervolgens wordt de robuustheid van het algoritme nagekeken door elke parameter over een zinvolle bandbreedte te laten variëren en de impact van deze wijzigingen op de performantie van het algoritme na te gaan. Tabel 5.2: Kalibratie van parameter f ase1 fase1 % optimaal Gemiddelde kost Maximale kost 0,2 73,21% 2,48 49,80 0,4 72,54% 2,52 52,20 0,6 71,92% 2,92 60,00 0,8 72,71% 3,09 62,20 Tabel 5.2 toont de performantie van het DPSO-LDPSO waarbij er variatie over parameter fase1 optreedt. Een kleine portie (20%) van het totaal aantal toegekende schedules toewijzen aan de global search fase zorgt voor een betere performantie zowel in termen van percentage optimale oplossingen als van gemiddelde kost. Dit toont aan dat de local search fase van het DPSO-LDPSO een belangrijk onderdeel vormt van het algoritme en dat lang globaal blijven zoeken en vervolgens snel proberen convergeren naar lokale optima, een suboptimale strategie is. Variatie over parameter Max Search Counter (zie tabel 5.3) toont aan dat het niet té snel ver-

77 Hoofdstuk 5. Performantie van de methoden 60 Tabel 5.3: Kalibratie van parameter Max Search Counter (msc) msc % optimaal Gemiddelde kost Maximale kost 1 71,84% 2,53 50,4 3 73,15% 2,41 51, ,45% 2,35 51, ,41% 2,34 50,7 9 73,71% 2,40 50, ,75% 2,44 50, ,52% 2,43 50,9 wijderen van partikels betere resultaten oplevert. Een gematigd streng selectiemechanisme voor slecht presterende swarms is bijgevolg een goede optimalisatiestrategie. Minder goed presterende partikels moeten dus voldoende de kans krijgen zich naar betere gebieden te begeven. Aan de andere kant zorgt een te lakse uitzuivering van slecht presterende swarms voor teveel overbodige zoekpogingen in slechte regio s. Tabel 5.4: Kalibratie van parameter Particles in Temporary Swarm nr % optimaal Gemiddelde kost Maximale kost 5 73,38% 2,43 47, ,46% 2,61 48, ,71% 2,73 54,8 Tabel 5.4 toont dat een kleiner aantal partikels in de swarms van de tweede fase een betere performantie van het algoritme in termen van gemiddelde kost oplevert dan een groter aantal. Het percentage optimale oplossingen stijgt daarentegen licht met het aantal partikels in een lokale swarm, maar dit percentage is erg vatbaar voor random variatie ten opzichte van de gemiddelde kost. De vaststelling dat een beperkt aantal partikels in een lokale swarm goed presteert is in lijn met de bevindingen van Zhao et al. (2010), die stelt dat in vergelijking met evolutionaire algoritmes, de PSO een relatief kleinere populatie nodig heeft om goede resultaten te bekomen. Een Particle Swarm Optimization muteert immers met een geweten, in tegenstelling tot evolutionaire algoritmen, waardoor in een PSO ook met een relatief kleinere populatie goede resultaten kunnen gehaald worden, zie ook sectie op pagina 21. Mutatie treedt in het gepresenteerde algoritme op in twee situaties: (1) Wanneer de snelheid van een partikel 0 is en (2) wanneer er in de tweede fase lokale swarms worden gegenereerd.

78 Hoofdstuk 5. Performantie van de methoden 61 Tabel 5.5: Kalibratie van parameter Mutation Rate (mur) mur % optimaal Gemiddelde kost Maximale kost 0,1 73,29% 2,50 53,2 0,2 73,42% 2,42 52,4 0,3 73,50% 2,38 47,6 0,4 73,75% 2,28 42,8 0,5 73,75% 2,36 47,8 0,6 73,58% 2,37 50,2 0,7 73,96% 2,38 52,2 0,8 73,96% 2,38 52,6 0,9 73,63% 2,41 46,4 1 73,21% 2,41 56,2 De resultaten van de variatie op de mutatiekans (zie tabel 5.5) tonen aan dat de performantie van het algoritme in termen van percentage optimale oplossingen erg ongevoelig is voor veranderingen in deze mutatiekans. De gemiddelde kost in tabel 5.5 toont echter dat een mutatiekans van 40% de beste resultaten geeft. Dit bewijst enerzijds dat de snelheidsherinitialisatie in de global search niet te beperkt maar ook niet te hevig mag zijn om de globale zoektocht te bevorderen. Anderzijds toont dit resultaat aan dat er nog ruimere zoekgebieden nodig zijn voor de LDPSO. Voor het gepresenteerde GRASP-LDPSO (zie hoofdstuk 4) levert een mutatiekans van 10% voor de LDPSO fase de beste resultaten op. Dit betekent dat voor GRASP-LDPSO veel kleinere zoekruimten beter zijn voor de tweede fase. Tabel 5.6: Kalibratie van parameter pop pop % optimaal Gemiddelde kost Maximale kost 60 73,38% 2,43 47, ,29% 2,44 48, ,21% 2,57 49, ,13% 2,69 51, ,58% 2,78 50, ,75% 2, ,21% 2,72 56,4 Tabel 5.6 toont de resultaten van het DPSO-LDPSO bij een verschillend totaal aantal elementen in de beginpopulatie. Dit aantal elementen wordt vervolgens gelijkmatig verdeeld over

79 Hoofdstuk 5. Performantie van de methoden 62 het aantal swarms (in deze testopstelling 5 swarms). De resultaten tonen een zeer robuuste performantie in termen van percentage optimale oplossingen. De gemiddelde kost toont echter een stijgende trend bij een toenemend aantal beginelementen in de populatie. Dit toont aan dat partikels voldoende kans moeten krijgen om het complexe oplossingsgebied grondig te exploreren, wat bij een streng vooropgesteld stopcriterium en een grote beginpopulatie minder goed mogelijk is. Deze bevindingen lopen parallel aan de bevindingen bij de kalibratie van de parameter Particles in Temporary Swarm, die het aantal elementen in de lokale swarms van het LDPSO controlleert, zie ook tabel 5.4. Tabel 5.7: Kalibratie van parameter nrofswarms nr % optimaal Gemiddelde kost Maximale kost 5 73,60% 2,39 48, ,96% 2,44 49, ,97% 2,60 50,7 Tabel 5.7 toont dat het percentage optimale oplossingen licht toeneemt met het aantal initiële swarms in de global search fase. De gemiddelde projectkost toont daarentegen een inverse trend (de gemiddelde projectkost stijgt bij een groter aantal beginswarms). Met een kleiner aantal beginswarms zijn de initiële zoekgebieden weliswaar groter, maar kunnen ze intensiever geëxploreerd worden, en bezit de LDPSO dus zelf de mogelijkheid het beste subgebied van het toegewezen zoekgebied dieper te exploreren (swarmen rond de gbest). Dit verklaart de lagere gemiddelde kost. Voor een groter aantal beginswarms wordt het hele zoekgebied van bij het begin opgedeeld in kleinere delen. Veel van deze delen zullen leiden naar lokale optima en door de kenmerken van het DPSO (zie M ax search counter) zullen nog onnodige schedules in de swarm worden geïnvesteerd alvorens de swarm uit de zoekprocedure wordt geweerd. Een diepere exploratie is dus minder goed mogelijk voor veelbelovende zoekgebieden. Anderzijds worden, door het grote aantal beginswarms, zoekgebieden expliciet bevolkt die anders niet aangedaan worden, maar die wel de optimale oplossing kunnen bevatten (De omgeving rond deze oplossing is bijvoorbeeld heel slecht). De stijging in het percentage optimale oplossingen is echter verwaarloosbaar in vergelijking met de stijging in gemiddelde projectkost, dewelke bovendien een robuustere maatstaf van performantie is dan het percentage optimale oplossingen 3. Dit verklaart de keuze voor het kleinste aantal swarms in de standaard parameterwaarden. 3 Het percentage optimale oplossing is immers een binaire classificatie (ofwel optimaal, ofwel niet optimaal) en is dus niet erg genuanceerd.

80 Hoofdstuk 5. Performantie van de methoden 63 Door het feit dat het beginaantal partikels in een swarm rechtstreeks wordt bepaald uit het aantal beginswarms en de totale beginpopulatie zijn beide paramaters ook tezamen gekalibreerd. De resultaten van deze kalibratie zijn te vinden in tabel 5.8 en figuur 5.1. Tabel 5.8 toont aan dat het beginaantal partikels in een swarm weinig invloed uitoefent op het percentage optimale oplossingen gevonden door DPSO-LDPSO. Figuur 5.1 toont een dalende gemiddelde kost naarmate er een kleiner aantal beginswarms en een kleinere beginpopulatie wordt geïnitialiseerd. Het laten leiden van een beperkt aantal partikels door vrij grote zoekgebieden heeft dus een positieve impact op de gemiddelde projectkost. Tabel 5.8: Gezamenlijke kalibratie van parameters nrofswarms en pop % optimaal nrofswarms pop ,33% 73,83% 73,59% 90 73,78% 73,54% 73,26% ,54% 73,88% 73,62% ,78% 73,41% 73,05% ,46% 73,54% 73,20% 3,40 3,20 3,00 2,80 2,60 2,40 2,20 2, ,20-3,40 3,00-3,20 2,80-3,00 2,60-2,80 2,40-2,60 2,20-2,40 2,00-2,20 Figuur 5.1: Gemiddelde projectkost voor DPSO-LDPSO voor variatie over parameters nrofswarms en pop. De lengte-as varieert over pop, de diepte-as over nrofswarms.

81 Hoofdstuk 5. Performantie van de methoden 64 Kalibratie van de inertiefactor w toont aan dat zowel in termen van percentage optimale oplossingen als van gemiddelde kost een inertiefactor rond 0.7 tot de beste resultaten leidt (zie tabel 5.9). Dit toont aan dat het recente gedrag van het partikel een aanzienlijke sturende functie heeft voor een betere positiebepaling van het partikel in komende iteraties. Tabel 5.9: Kalibratie van parameter w w % optimaal Gemiddelde kost Maximale kost 0,1 71,88% 2,79 53,6 0,3 72,33% 2,61 53,4 0,5 73,71% 2,35 50,8 0,7 74,00% 2,33 45,4 0,9 73,58% 2,41 52,2 Parameter inertiaweight reduction bepaalt hoe snel de snelheidsinertie afneemt bij het vinden van een betere gbest, waardoor lokale exploratie wordt aangemoedigd. De resultaten in tabel 5.10 suggereren een reductie van 10 tot 20 % als optimale reductiestrategie. Géén reductie (i.e. inertiaweight reduction = 0) blijkt tot suboptimale resultaten te leiden, net als een te hoge reductie. Tabel 5.10: Kalibratie van parameter inertiaweight reduction (iwr) iwr % optimaal Gemiddelde kost Maximale kost 0 73,21% 2,69 56,4 0,1 73,46% 2,44 52,2 0,2 73,88% 2,48 47,8 0,3 73,58% 2,62 50,6 0,4 73,17% 2,67 54,2 0,5 73,17% 2,70 56,2 Kalibratie van parameter γ, gegeven in tabel 5.11, leert dat een te strikte reductie van de maximale snelheid V max tot suboptimale resultaten leidt zowel in termen van percentage optimale oplossingen als de gemiddelde kost. De partikels kunnen immers niet snel genoeg slechte gebieden verlagen en, in hun global search, geen betere subgebieden opzoeken. Voor γ-waarden groter dan 0.1 is de performantie in termen van percentage optimale oplossingen erg robuust. Voor de gemiddelde kost merken we echter een optimale bandbreedte voor parameter γ tussen 0.4 en 0.6. Voor hogere waarden stijgt immers de gemiddelde kost opnieuw,

82 Hoofdstuk 5. Performantie van de methoden 65 omdat de partikels lokale zoekcapaciteiten zullen ontberen. bepaalde gebieden heen vliegen. Ze zullen immers te snel over Tabel 5.11: Kalibratie van parameter γ gamma % optimaal Gemiddelde kost Maximale kost 0,1 70,75% 3,77 66,6 0,2 73,29% 2,76 52,4 0,3 73,77% 2,47 49,75 0,4 73,98% 2,32 47,55 0,5 73,77% 2,36 48,85 0,6 73,74% 2,36 49,8 0,7 73,72% 2,40 52,15 0,8 73,24% 2,51 51,7 0,9 73,34% 2,42 51,7 1 73,08% 2,46 51,6 Kruistabel 5.12 en bijhorende figuur 5.2 tonen het percentage optimale oplossingen gevonden door het DPSO-LDPSO voor verschillende combinaties van leerfactoren c 1 en c 2. Zowel de percentages als de figuur tonen aan de invloed van pbest i op de snelheid van partikel i (gecontroleerd door c 1 ) een zo goed als verwaarloosbare impact heeft op de performantie van het algoritme. Voor een hoog percentage optimale oplossingen is echter wel een minimale invloed van gbest van de swarm (gecontroleerd door c 2 ) bij het bepalen van de snelheid van de partikels noodzakelijk. Wanneer c 2 groter dan 0.5 bedraagt is de performantie vrij robuust, waardoor het precieze belang van gbest voor deze measure of performance moeilijk te achterhalen valt.

83 Hoofdstuk 5. Performantie van de methoden 66 Tabel 5.12: Kalibratie van parameters c 1 en c 2 naar percentage optimale oplossingen % optimaal c 2 c 1 0 0,5 1 1,5 2 2,5 Eindtotaal 0 69,08% 73,25% 73,96% 73,79% 73,96% 74,04% 73,01% 0,5 69,23% 73,73% 73,81% 73,44% 73,50% 74,10% 72,97% 1 68,85% 73,35% 73,46% 73,75% 73,21% 73,35% 72,66% 1,5 69,27% 73,50% 73,67% 73,73% 73,56% 73,71% 72,91% 2 69,13% 73,83% 73,62% 73,81% 73,71% 73,90% 73,00% 2,5 69,38% 72,94% 73,52% 73,48% 73,69% 74,25% 72,87% Eindtotaal 69,16% 73,43% 73,67% 73,67% 73,60% 73,89% 72,90% 75,00% 74,00% 73,00% 72,00% 71,00% 70,00% 69,00% 68,00% 67,00% 1,5 2 2,5 74,00%-75,00% 73,00%-74,00% 72,00%-73,00% 71,00%-72,00% 70,00%-71,00% 69,00%-70,00% 68,00%-69,00% 67,00%-68,00% 66,00%-67,00% 66,00% 0 0,5 1 1, ,5 0,5 1 Figuur 5.2: Percentage optimale oplossingen in functie van parameters c 1 en c 2. De lengte-as varieert over c 1, de diepte-as over c 2. Kruistabel 5.13 en bijhorende figuur 5.3 tonen de gemiddelde projectkost gevonden door het DPSO-LDPSO voor verschillende combinaties van leerfactoren c 1 en c 2. Net als bij de percentages optimale oplossingen tonen de kruistabel en de figuur aan dat de grootte van de impact van pbest i op de snelheid van partikel i (gecontroleerd door c 1 ) een zo goed als verwaarloos-

84 Hoofdstuk 5. Performantie van de methoden 67 bare invloed heeft op de performantie van het algoritme. In tegenstelling tot de percentages optimale oplossingen, is een opmerkelijke daling in gemiddelde projectkost te zien bij een stijgende impact van gbest op de snelheidsbepaling van de partikels in de swarm. Het is slechts bij een c 2 -waarde van 1.5 of groter dat deze daling stagneert en er robuuste waarden voor gemiddelde kosten te noteren vallen. Dit laat ons toe het belang van gbest op de snelheidsbepaling beter in te schatten. We kunnen nu immers concluderen dat aantrekking tot de globaal best gevonden positie in de swarm een belangrijke voorwaarde tot goede performantie van het algoritme is, in tegenstelling tot de eigen beste positie van het partikel. Tabel 5.13: Kalibratie van parameters c 1 en c 2 naar gemiddelde projectkost Gemiddelde kost c 1 c 2 0 0,5 1 1,5 2 2,5 Eindtotaal 0 3,23 3,26 3,18 3,23 3,25 3,21 3,23 0,5 2,67 2,64 2,69 2,71 2,71 2,68 2,68 1 2,43 2,47 2,42 2,42 2,43 2,44 2,43 1,5 2,40 2,37 2,37 2,33 2,34 2,38 2,37 2 2,33 2,39 2,37 2,38 2,31 2,33 2,35 2,5 2,34 2,37 2,36 2,40 2,36 2,33 2,36 Eindtotaal 2,57 2,59 2,56 2,58 2,57 2,56 2,57

85 Hoofdstuk 5. Performantie van de methoden 68 3,40 3,20 3,00 2,80 2,60 2,40 2,20 1,5 2 2,5 3,20-3,40 3,00-3,20 2,80-3,00 2,60-2,80 2,40-2,60 2,20-2,40 2,00-2,20 2,00 0 0,5 1 1, ,5 0,5 1 Figuur 5.3: Gemiddelde projectkost in functie van parameters c 1 en c 2. De lengte-as varieert over c 2, de diepte-as over c Performantie van de verschillende componenten In dit deel gaan we de sterkte van de verschillende componenten binnen het DPSO-LDPSO na. Zoals gegeven in sectie 2.2, bestaat het gepresenteerde Darwinian PSO uit 3 grote delen: populatie-initialisatie, global search en local search (LDPSO). We schakelen bepaalde componenten systematisch uit en presenteren de resultaten op 5000 schedules met standaard parameterwaarden. In de eerste plaats wordt de kracht van de populatiegeneratie methode nagegaan. Bij een beginpopulatie van 180, vindt het algoritme na de populatie generatie reeds bij 47,3% van de projecten de optimale oplossingen. Vervolgens schakelen we de LDPSO fase uit, om de kracht van de populatiegeneratie en de global search fase na te gaan: ˆ Tabel 5.14 toont de resultaten van de populatie generatie en de global search fase na f ase schedules, waarbij f ase1 gekalibreerd is op de standaard parameterwaarde

86 Hoofdstuk 5. Performantie van de methoden Deze resultaten worden volgens vergeleken met de resultaten na 5000 schedules van het complete algoritme. We bemerken een stijging van 16.69% optimale oplossingen door de Local DPSO fase. De daling in de gemiddelde kost is echter spectaculairder, tot meer dan 68%. Deze resultaten tonen aan dat de eerste fase van het algoritme er vlot in slaagt een aanvaardbaar percentage optimale oplossingen te vinden, ondanks een erg hoge gemiddelde projectkost. Dit komt voornamelijk door een vast percentage gemakkelijk te optimaliseren projecten in de j30 projectset. De tweede fase, het LDPSO, slaagt er vervolgens in een forse reductie in de huurkost van de moeilijk te optimaliseren projecten te verkrijgen, door de beste lokale zoekgebieden intensiever te exploreren. ˆ Tabel 5.15 toont de resultaten van de DPSO variant die voor de gehele duurtijd (i.e schedules) een global search uitvoert. De resultaten suggereren dat de lokale DPSO variant slechts een kleine verbetering in percentage optimale oplossingen kan verkrijgen. Slechts in termen van gemiddelde projectkost wordt een degelijke reductie door LDPSO gevonden (-26.5%). Dit toont aan dat na verloop van tijd de global search fase zichzelf naar de veelbelovende lokale gebieden leidt. Tabel 5.16 toont de resultaten van DPSO-LDPSO waarbij de rekenintensieve local search submethode (zie sectie op pagina 36) is uitgeschakeld. De resultaten tonen aan dat, ondanks hetzelfde maximum van 5000 te genereren schedules, de investering in schedules voor de rekenintensieve local search submethode leidt tot betere performantie van het algoritme. Tabel 5.14: Performantie van DPSO-LDPSO na de global search en de local search fase. % optimaal Gemiddelde kost Maximale kost Na DPSO 63,10% 7,35 93,75 Na DPSO-LDPSO 73,63% 2,35 50,46 verschil 16,69% -68,06% -46,18% Tabel 5.15: Verschil in performantie tussen DPSO en DPSO-LDPSO. % optimaal Gemiddelde kost Maximale kost DPSO 71,69% 3,20 58,00 DPSO-LDPSO 73,63% 2,35 50,46 verschil 2,70% -26,58% -13,00%

87 Hoofdstuk 5. Performantie van de methoden 70 Tabel 5.16: Verschil in performantie tussen DPSO-LDPSO met of zonder local search methode. % optimaal Gemiddelde kost Maximale kost zonder LS 65,08% 6,55 87,75 met LS 73,63% 2,35 50,46 verschil 13,14% -64,18% -42,50% 5.5 GRASP Parameters In hoofdstuk 3 werd aangetoond dat één van de voordelen van de GRASP methode het lage aantal te kalibreren parameters is. Voor de toepassing op het TCPSP zijn er slechts 2 parameters te optimaliseren: ˆ α: Parameter α bepaalt het deterministisch karakter van de GRASP. Bij waarde 0 is de selectiemethode voor mogelijks in te plannen activiteiten deterministisch. Bij waarde 1 is deze geheel random, cfr. vergelijking 3.1 op pagina 47. ˆ β: Parameter β bepaalt de kans dat op een bepaalde tijdseenheid gehuurd mag worden om nog een extra activiteit op die positie te plannen, cfr. vergelijking 3.2 op pagina Parameterkalibratie De bovenstaande parameters voor GRASP dienen vervolgens gekalibreerd te worden om een optimale performantie van het algoritme te verkrijgen. Het trainen van deze parameters gebeurt door iteratief het algoritme een andere parameterset mee te geven en vervolgens de performantie ervan op de j30 projectset na te gaan. Vermits er weinig parameters te optimaliseren zijn kan een volledige analyse van het parameterspectrum opgenomen worden. Kruistabel 5.17 toont de resultaten van de verschillende opgenomen parametersets in termen van percentage projectplannen optimaal opgelost door de GRASP.

88 Hoofdstuk 5. Performantie van de methoden 71 Tabel 5.17: Kalibratie van parameters α en β naar percentage optimaal opgeloste projecten. % optimaal α β 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 Eindtotaal 0 69,9% 70,0% 69,9% 69,2% 68,9% 69,1% 68,6% 68,6% 68,5% 68,8% 69,0% 69,1% 0,2 76,1% 76,3% 75,7% 75,0% 74,2% 73,9% 73,4% 73,5% 73,0% 73,5% 72,8% 74,3% 0,4 75,4% 75,9% 75,2% 75,3% 74,3% 73,9% 74,3% 73,2% 73,2% 73,5% 73,6% 74,3% 0,6 75,3% 75,2% 74,7% 75,0% 73,8% 73,8% 73,5% 72,8% 73,6% 73,8% 73,3% 74,1% 0,8 74,5% 74,7% 74,0% 74,5% 73,2% 73,3% 73,5% 72,7% 72,8% 73,0% 73,0% 73,6% 1 71,5% 71,3% 71,7% 71,4% 71,2% 71,0% 71,3% 70,6% 70,5% 71,1% 71,5% 71,2% 1,2 70,8% 70,8% 71,7% 71,4% 71,0% 70,6% 71,3% 70,4% 70,3% 70,5% 71,0% 70,9% 1,4 70,4% 70,7% 71,0% 70,7% 70,3% 71,0% 70,8% 70,7% 70,6% 70,6% 70,7% 70,7% Eindtotaal 73,0% 73,1% 73,0% 72,8% 72,1% 72,1% 72,1% 71,6% 71,6% 71,9% 71,8% 72,3%

89 Hoofdstuk 5. Performantie van de methoden 72 Tabel 5.17 wordt grafisch weergegeven in figuur 5.4. Daarbij varieert parameter β van 0 tot 1.4 (lengte-as) en parameter α van 0 tot 1 (diepte-as). Zowel de tabel als de figuur tonen aan dat een β-waarde tussen 0.2 en 0.8 tot de beste resultaten leidt. Binnen dit interval zijn de resultaten vrij robuust. De ruime breedte van dit interval toont aan dat het algoritme niet erg gevoelig is aan de plaats waar er huurkosten worden opgenomen, zolang het opnemen van kosten maar toegelaten wordt. Voor β = 0 haalt het algoritme immers gevoelig de mindere resultaten. Voor deze β-waarde mogen er nooit extra kosten opgenomen worden, tenzij infeasibility dreigt, en dus zullen de kosten zich allemaal op het einde opstapelen. Anderzijds mogen huurkosten in het begin ook niet te laks worden opgenomen (cfr. de verslechterende resultaten voor grote β-waarden). De discussie illustreert overigens het feit dat het TCPSP over een non-regular measure of performance beschikt. Immers, bij een dergelijke doelfunctie speelt de locatie waar de kosten in de planningshorizon opgenomen worden geen rol voor de waarde van de doelfunctie. Breiden we het basisprobleem bijvoorbeeld uit naar een TCPSPvariant met een Net Present Value benadering voor de huurkosten, dan zou de locatie van de opgenomen kosten wél een invloed hebben op de doelfunctie, dewelke dan regular is geworden (zie overigens hoofdstuk 7 voor de aanbeveling rond uitbreiding van het TCPSP met een NPV-variant).

90 Hoofdstuk 5. Performantie van de methoden 73 78,00% 76,00% 74,00% 76,00%-78,00% 74,00%-76,00% 72,00% 72,00%-74,00% 70,00%-72,00% 70,00% 68,00%-70,00% 66,00%-68,00% 68,00% 66,00% 64,00% 0 0,2 0,4 0,6 0,8 1 1,2 0 1,4 0,9 1 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 64,00%-66,00% Figuur 5.4: Kalibratie van parameters α en β naar percentage optimaal opgeloste projecten. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as. Voor parameter α tonen tabel 5.17 en figuur 5.4 aan dat waarden tussen 0 en 0.3 tot de beste resultaten leiden. Dit betekent dat er streng geselecteerd mag worden welke elementen uit de keuzeset uiteindelijk in de Restricted Candidate List terecht komen. De goede resultaten voor een strenge selectie kunnen verklaard worden uit het feit dat de test loopt op de j30 projectset, waar de deadline op de gekende optimale makespans voor de RCPSP-variant (i.e. zonder huurkosten) is geplaatst. Er valt dus a priori te verwachten dat het optimaler is steeds de goedkoopst in te plannen activiteiten te kiezen uit de gehele keuzeset om deze toe te laten in de Restricted Candidate List. Met het oog op het verscherpen van de deadline en dus het sneller moeten opnemen van huurkosten (zie sectie op pagina 93), verklaart dit de keuze voor standaard α-waarde van 0.5. Tabel 5.18 en figuur 5.5 tonen de gemiddelde projectkost bij variërende waarden voor α en β. De resultaten bevestigen de conclusies die hiervoor werden gepresenteerd: parameter β zorgt voor een robuuste performantie tussen 0.2 en 0.8, terwijl door de specifieke deadline, parameter α gemiddeld de laagste kost geeft voor waarden tussen 0 en 0.3.

91 Hoofdstuk 5. Performantie van de methoden 74 Tabel 5.18: Kalibratie van parameters α en β naar gemiddelde projectkost Gemiddelde α β 0 0,1 0,2 0,3 0,4 0,5 0,6 0,7 0,8 0,9 1 Eindtotaal 0 2,17 2,16 2,12 2,15 2,15 2,30 2,32 2,47 2,46 2,51 2,52 2,30 0,2 1,47 1,53 1,56 1,61 1,70 1,79 1,88 1,91 1,98 2,00 1,97 1,76 0,4 1,49 1,52 1,50 1,59 1,66 1,76 1,82 1,86 1,89 1,99 1,92 1,73 0,6 1,45 1,51 1,58 1,54 1,65 1,79 1,80 1,83 1,89 1,87 1,92 1,71 0,8 1,53 1,51 1,60 1,59 1,66 1,72 1,73 1,83 1,84 1,86 1,88 1,70 1 1,65 1,65 1,63 1,70 1,76 1,80 1,78 1,84 1,86 1,96 1,86 1,77 1,2 1,66 1,74 1,68 1,69 1,74 1,74 1,81 1,88 1,89 1,93 1,95 1,79 1,4 1,68 1,72 1,67 1,79 1,78 1,79 1,83 1,86 1,99 1,96 1,96 1,82 Eindtotaal 1,64 1,67 1,67 1,71 1,76 1,84 1,87 1,93 1,97 2,01 2,00 1,82

92 Hoofdstuk 5. Performantie van de methoden 75 3,00 2,50 2,00 2,50-3,00 2,00-2,50 1,50 1,50-2,00 1,00-1,50 0,50-1,00 1,00 0,50 0,00 0 0,2 0,4 0,6 0,8 1 1,2 0 1,4 0,1 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,00-0,50 Figuur 5.5: Kalibratie van parameters α en β naar gemiddelde projectkost. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as. Ten slotte tonen tabel B.1 en figuur B.1, te vinden in bijlage op pagina s 117 en 116, aan dat de maximale projectkost vrij robuust is over alle parametersets behalve voor gecombineerde lage waarden voor α en β. Doordat slechts één projectresultaat de maximale projectkost bepaalt per iteratie, zijn de geobserveerde variaties vooral te wijten aan random schommelingen tussen de testiteraties van de projectset voor dezelfde parameterwaarden Performantie van de verschillende componenten Het gepresenteerde Greedy Random Adaptive Search Procedure bestaat in essentie uit 3 onderdelen, zie hoofdstuk 3: (1) de initiële constructie van een oplossing, (2) de verbetering van een oplossing en (3) de local search procedure. Wanneer we systematisch componenten (2) en/of (3) uitschakelen kunnen we de kracht van elk onderdeel nagaan. Tabel 5.19 toont de resultaten van de GRASP waarbij componenten (2) en (3) zijn uitgeschakeld. In dit geval construeert de GRASP 5000 basisschedules, zonder enige vorm van verbetering (i.e. eens de activiteiten een initiële starttijd hebben gekregen, worden deze niet meer gewijzigd). Daarbij haalt het algoritme in 51.44% van de onderzochte

93 Hoofdstuk 5. Performantie van de methoden 76 projecten de optimale oplossing, tegen een gemiddelde kost van Dit toont aan dat de GRASP inderdaad een behoorlijke graad van intelligentie in de constructiefase meedraagt. Fasen (2) en (3) slagen er samen in deze initieel geconstrueerde oplossingen gevoelig verder te verbeteren (stijging van ruim 43% in het percentage optimale oplossingen, een daling van bijna 53% en ongeveer 28% in respectievelijk gemiddelde en maximale kost). Tabel 5.19: Performantie van GRASP zonder oplossingsverbetering (2) en local search (3) % optimaal Gemiddelde kost Maximale kost zonder (2) & (3) 51,44% 3,67 47,20 met (2) & (3) 73,76% 1,73 33,94 verschil 43,39% -52,79% -28,09% Vervolgens wordt de oplossingingsverbeteringsmethode terug ingeschakeld en blijft enkel de local search methode non-actief. De resultaten van deze testopstelling worden gepresenteerd in tabel Het performantieverschil tussen de twee testopstellingen is erg beperkt (ongeveer 3 %). Dit kan verklaard worden door het feit dat de local search methode heel schedule-intensief is. Immers, elke mogelijke verschuiving wordt in deze methode gecontroleerd, en vraagt telkens 1/n schedules (met n = aantal activiteiten in het project). Hierdoor kan GRASP relatief minder complete schedules afwerken. Ondanks dit nadeel, stijgt de performantie van het algoritme, wat de effectiviteit van de local search methode onderstreept. Tabel 5.20: Performantie van GRASP zonder local search % optimaal Gemiddelde kost Maximale kost zonder (3) 71,56% 1,88 37,00 met (3) 73,76% 1,73 33,94 verschil 3,07% -7,83% -8,27% 5.6 GRASP-LDPSO Parameters Het gepresenteerde Greedy Random Adaptive Search procedure met een Darwinian Particle Swarm Optimization heeft volgende parameters : ˆ α: Parameter α bepaalt het deterministisch karakter van de GRASP. Bij waarde 0 is de selectiemethode voor in te plannen activiteiten deterministisch. Bij een waarde 1 is de selectie geheel random, cfr vergelijking 3.1 op pagina 47.

94 Hoofdstuk 5. Performantie van de methoden 77 ˆ β: Parameter α bepaalt de kans dat op een bepaalde tijdseenheid gehuurd mag worden om nog een extra activiteit daar te plannen, cfr vergelijking 3.2 op pagina 47. ˆ fase1: Parameter fase1 bepaalt hoeveel van de toegelaten schedules aan de GRASP worden toegekend. Stel dat we het algoritme 5000 schedules laten bouwen, dan worden er f ase schedules aan de GRASP toegekend. De overige schedules worden gebruikt door de LDPSO fase. ˆ b: Parameter b bepaalt het aantal beste, diverse oplossingen, gevonden door de GRASP in de eerste fase, die onthouden worden en later gebruikt worden als basis voor het LDPSO. Het bepaalt dus hoeveel swarms er in de tweede fase initieel geconstrueerd zullen worden. ˆ Max search counter: Parameter Max search counter bepaalt het aantal iteraties zonder verbetering van gbest alvorens een partikel uit de swarm wordt verwijderd in de LDPSO fase. ˆ Particles in temporary swarm: Parameter Particles in temporary swarm bepaalt het aantal gemuteerde partikels die rond gbest worden gegenereerd in de LDPSO. ˆ mutation rate: Parameter mutation rate bepaalt de kans dat een activiteit binnen een oplossing wordt gemuteerd. Mutaties vinden plaats op 2 momenten in het algoritme. Wanneer in de LDPSO fase de snelheid van een partikel 0 wordt. Mutatie van de starttijden van bepaalde activiteiten zorgt dan voor een snelheidsherinitialisatie. Bij het genereren van lokale swarms in LDPSO. Hierdoor ontstaan er oplossingen in de dichte omgeving van een goede oplossing. Door het swarmgedrag van de partikels zal deze omgeving intensief doorzocht worden. ˆ inertiaweight: Parameter inertiaweight is de inertiefactor w, zie vergelijking 2.2 op pagina 22. ˆ inertiaweight reduction: Parameter inertiaweight reduction bepaalt de lineaire reductie van de inertiefactor telkens wanneer er een nieuwe gbest gevonden wordt: w t = (1 inertiaweight reduction) w t 1, zie vergelijking 2.4 op pagina 26. ˆ c 1 : Parameter c 1 is de learning rate geassocieerd met de pbest i van oplossing i, zie vergelijking 2.2 op pagina 22. ˆ c 2 : Parameter c 2 is de learning rate geassocieerd met de gbest van de swarm, zie vergelijking 2.2 op pagina 22. ˆ γ: Parameter γ bepaalt de maximale snelheid een partikel mag vliegen en is een fractie van de maximaal mogelijke snelheid, zie vergelijking 2.12 op pagina 34.

95 Hoofdstuk 5. Performantie van de methoden Parameterkalibratie De parameters van het algoritme dienen vervolgens gekalibreerd te worden voor optimale performantie. Door het hybride karakter van het GRASP-LDPSO, kunnen voor parameters eigen aan ofwel de GRASP methode of de LDPSO methode kalibraties uit voorgaande delen gebruikt worden. De twee delen werken immers onafhankelijk van elkaar en worden slechts gelinkt door 2 parameters f ase1 en b. Deze 2 parameters worden hieronder gekalibreerd. Parameters γ en Mutation rate kennen echter wel een andere standaardwaarde dan in DPSO- LDPSO. Immers, kalibratietesten wezen uit dat zowel γ als M utation rate ingesteld op 0.1 de beste performantie geven. Dit is een gevolg van het feit dat de global search fase is vervangen door de GRASP. In het DPSO-LDPSO zijn voor een effectieve global search hoge toegelaten snelheden (hoge γ-waarden) en een hogere snelheidsherinitialisatie (hoge M utation rate) bij het stilvallen van een partikel noodzakelijk. Voor een lokale zoektocht in de buurt van een goede oplossing, moeten partikels echter heel traag rondzweven (lage γ-waarden) in de buurt van die goede oplossing (lage M utation rate). Tabel 5.21 toont de standaardparameterwaarden voor beide te kalibreren parameters. Deze waarden werden gevonden door een uitgebreide set parameterwaarden toe te passen op het hybride algoritme, waarna de best presterende parameterset werd onthouden. Tabel 5.21: Standaard parameterwaarden voor het GRASP-LDPSO parameter waarde b 7 fase1 0,5 Tabel 5.22 toont de performantie van het GRASP-LDPSO voor verschillende waarden van fase1. Hoe hoger de waarde van fase1 hoe meer schedules van het maximum aantal toegelaten schedules (voor deze test 5000) er aan de GRASP fase worden toegekend. Zowel in termen van percentage optimale oplossingen als gemiddelde projectkost zien we een zeer robuuste performantie van het algoritme wanneer 20 tot 70% van het maximum te genereren schedules aan de GRASP worden toegekend. Dit duidt er op dat zowel de GRASP als de lokale DPSO een minimum aan schedules nodig hebben om tot optimale performantie te komen. Over een groot interval (50% van het maximum aantal toegelaten schedules) loopt de performantie echter vrij gelijk. Wanneer we naar de performantie van GRASP kijken over een variërend stopcriterium, zie sectie op pagina 93, dan zien we dat GRASP op 1000 schedules (= ) voor net geen 70% van de projecten een optimale oplossing bekomt. Voor 3500 schedules (= ) extrapoleren we de resultaten van 3000 en 4000 schedules en vinden we een percentage optimale oplossingen dicht tegen 73%. Dat wil zeggen dat in

96 Hoofdstuk 5. Performantie van de methoden 79 het interval 0.2 tot 0.7 van f ase1 de GRASP procedure stelselmatig betere oplossingen blijft vindt, maar dat deze voordelen in het GRASP-LDPSO a rato gecompenseerd worden door een minder presterende lokale DPSO, die bij een toenemende waarde van f ase1 over steeds minder te construeren schedules beschikt. Tabel 5.22: Kalibratie van parameter fase1 fase1 % optimaal Gemiddelde kost Maximum kost 0,1 83,13% 1,36 35,80 0,2 83,96% 1,25 34,60 0,3 84,00% 1,24 40,80 0,4 83,88% 1,23 35,20 0,5 83,75% 1,22 35,40 0,6 83,71% 1,22 35,60 0,7 83,00% 1,23 34,20 0,8 82,21% 1,32 36,20 0,9 81,21% 1,50 39,60 De kalibratie van parameter b, die bepaalt hoeveel lokale swarms er worden gecreëerd in de LDPSO fase, is te zien in tabel Uit de gepresenteerde resultaten valt geen eenduidige conclusie te trekken wat het optimale aantal beste oplossingen voor de tweede fase betreft. De performantie is, behoudens beperkte random variatie, ongevoelig voor het aantal doorgegeven oplossingen. Deze vaststelling bewijst dat uit de allerbeste oplossing van de GRASP fase, in de meeste gevallen, in de lokale DPSO fase de beste oplossing gevonden wordt. Tabel 5.23: Kalibratie van parameter b b % optimaal Gemiddelde kost Maximum kost 1 83,02% 1,23 34, ,61% 1,21 34, ,57% 1,15 33, ,83% 1,21 35, ,81% 1,20 32, ,82% 1,18 32, ,72% 1,19 33, ,85% 1,19 32,67

97 Hoofdstuk 5. Performantie van de methoden Performantie van de verschillende componenten In deze sectie wordt nagegaan in welke mate de 2 fasen van het GRASP-LDPSO, de GRASP fase en de lokale DPSO fase, bijdragen tot de performantie van het totale algoritme. Tabel 5.24 toont de gemiddelde kost en het percentage optimale oplossingen gevonden na de eerste en tweede fase. De verbetering in gemiddelde kost, gevonden gedurende de tweede fase, loopt op tot gemiddeld net geen 55%. De verbetering in percentage optimaal opgeloste projecten na fase 2 bedraagt gemiddeld net geen 15%. Dit toont aan de sociale interactie die tussen de partikels in de lokale DPSO plaatsgrijpt en het vernauwen van de totale zoekruimte tot lokale gebieden, een significant positieve impact heeft op de performantie van het algoritme. Tabel 5.24: Verschil in performantie tussen eerste en tweede fase van de GRASP-LDPSO Gemiddelde kost % optimaal 1ste fase 2de fase 1ste fase 2de fase 2,80 1,26 72,08% 82,71% % verbetering: 54,87% % verbetering: 14,74% Vervolgens wordt de rekenintensieve local search subprocedure uitgeschakeld. Deze procedure zoekt zeer lokaal naar verbetering (met een veel kleiner zoekgebied dan de lokale swarms gevormd bij de DPSO, waar immers nog starttijden gemuteerd worden), maar vraagt door het iteratief evalueren van opties veel schedules. We gaan dus na of het investeren in extra schedules in de local search procedure effectief een meerwaarde biedt aan het algoritme. Tabel 5.25 toont duidelijk aan dat het gebruiken van de local search procedure tot verbetering van de resultaten leidt. De daling van de gemiddelde kost in fase 1 loopt op tot meer dan 47%, terwijl ze in de 2de fase oplopen tot bijna 75%. Hoewel de trend dezelfde is, valt het inverse patroon bij het percentage optimale oplossingen op. De procentuele verbetering in fase 1 met local search loopt op tot meer dan 30%, terwijl dit na de 2de fase gereduceerd is tot net geen 22%. Dit toont aan dat de local search subprocedure voornamelijk een grote impact heeft op de gemiddelde projectkost en dat het algoritme zelf, het LDPSO in het bijzonder, een grotere drijver is voor het vinden van optimale oplossingen. Tabel 5.25: Verschil in performantie tussen eerste en tweede fase zonder Local Search methode Gemiddelde kost % optimaal 1ste fase 2de fase 1ste fase 2de fase zonder LS 4,13 2,21 50,21% 64,58% met LS 2,80 1,26 72,08% 82,71% % verschil 47,43% 74,46% -30,35% -21,91%

98 Hoofdstuk 5. Performantie van de methoden Vergelijking van de performantie tussen de methoden In dit deel wordt de performantie van de algoritmen getoetst aan verschillende karakteristieken van de projecten binnen projectset j30. In sectie 5.1 op pagina 54 werden reeds projectkarakteristieken als Netwerk Complexiteit (Network Compexity, NC), Resource Frequentie (Resource Frequency, RF) en Resource Sterkte (Resource Strength, RS) toegelicht. In kruistabel 5.26 worden de resultaten getoond van de variatie over NC, RS en RF voor het DPSO-LDPSO. Gelijke overzichtstabellen voor GRASP en GRASP-LDPSO worden gegeven in tabellen 5.27 en De gegeven performantiewaarden zijn de gemiddelde kosten van projecten die aan de corresponderende NC, RF en RS voldoen. Dezelfde resultaten worden ook grafisch weergegeven in figuren B.2, B.3 en B.4, te vinden in bijlage op pagina 118 en volgende. In komende paragrafen wordt de impact van elke karakteristiek op de performantie van de algoritmen apart toegelicht. Tabel 5.26: Overzicht kostperformantie DPSO-LDPSO Gemiddelde kost per project NC RS RF Eindtotaal ,63 0,73 0,20 1, ,70 3,35 4,23 13, ,88 11,63 10,50 32, ,83 21,05 16,30 62,18 Totaal ,03 36,75 31,23 109, ,00 0,00 0,00 0, ,25 0,13 0,25 0, ,53 0,38 0,40 1, ,58 1,90 1,50 4,98 Totaal ,35 2,40 2,15 6, ,00 0,00 0,00 0, ,03 0,00 0,03 0, ,18 0,00 0,48 0, ,25 0,18 0,00 0,43 Totaal ,45 0,18 0,50 1, ,00 0,00 0,00 0, ,00 0,00 0,00 0, ,00 0,00 0,00 0, ,00 0,00 0,00 0,00 Totaal ,00 0,00 0,00 0,00 Eindtotaal 43,83 39,33 33,88 117,03

99 Hoofdstuk 5. Performantie van de methoden 82 Tabel 5.27: Overzicht kostperformantie GRASP Gemiddelde kost per project NC RS RF Eindtotaal , , ,325 2,45 2,075 8, ,45 9,95 5,1 22, ,95 9,2 41,15 Totaal ,425 27,35 16,375 73, , , ,95 0,575 0,15 1, ,45 0,725 0,425 1, ,5 2,55 1,65 5,7 Totaal ,85 2,225 9, , ,525 0, ,125 0,4 0 0,525 Totaal ,55 0,4 0,525 1, Totaal Eindtotaal 32,975 31,6 19,125 83,7

100 Hoofdstuk 5. Performantie van de methoden 83 Tabel 5.28: Overzicht kostperformantie GRASP-LDPSO Gemiddelde kost per project NC RS RF Eindtotaal ,45 0,55 0,075 2, ,525 6,85 2,425 14, ,4 14,55 7,325 36,275 Totaal ,375 21,95 9,825 53, , , ,1 0,275 0,075 0, ,725 0,85 1,55 3,125 Totaal ,05 1,125 1,625 3, , , ,225 0, ,25 Totaal ,4 0, , Totaal Eindtotaal 22,825 23,1 11,45 57,375

101 Gemiddelde projectkost Hoofdstuk 5. Performantie van de methoden 84 De impact van Resource Frequency op de performantie wordt getoond in figuur 5.6. De grafiek toont duidelijk aan dat hoe vaker er vraag is naar een bepaald resourcetype, hoe hoger de gemiddelde kost per project uitvalt. Voor een lage RF presteren de verschillende algoritmen vrij gelijk. Voor hogere RF s presteert het DPSO-LDPSO relatief het slechts, GRASP-LDPSO het best. Een verdere analyse heeft echter pas zin als we daarbij ook de Resource Strength in ogenschouw nemen. Tabellen 5.26, 5.27 en 5.28 tonen immers dat er grote verschillen optreden tussen de gemiddelde kost van projecten die gekenmerkt worden door eenzelfde hoge Resource Frequency, maar met een verschillende Resource Strength. Hoe lager de capaciteit van de resources (i.e. een lage Resource Strength), hoe hoger de gemiddelde kost van het beste schedule gevonden door de verschillende methoden. In deze gevallen is het immers heel moeilijk om de activiteiten, elk met een frequente vraag naar de verschillende types resources, optimaal in te plannen bij een beperkte basis resourcecapaciteit. Er moet daarbij voor elke activiteit met bijna elk type resource rekening gehouden worden voor de doelfunctie. Met andere woorden, er moet bij elke activiteit vaker voor elke resource nagekeken worden of er tijdelijk capaciteit van deze resource moet bijgehuurd worden. Gemiddelde projectkost in functie van resourcefrequentie 6,00 5,00 4,00 3,00 2,00 1,00 0, DPSO-LDPSO 0,13 1,16 2,83 5,63 GRASP 0,06 0,88 2,09 3,95 GRASP-LDPSO 0,00 0,19 1,29 3,30 Figuur 5.6: Gemiddelde kost per project in functie van Resource Frequentie.

102 Gemiddelde projectkost Hoofdstuk 5. Performantie van de methoden 85 Figuur 5.7 toont de impact van de hoogte basisinvestering (i.e. de capaciteit) in de 4 resources. Hoe meer resources er per tijdseenheid voorradig zijn zonder extra huurkosten, hoe beter de oplossingen gevonden door de algoritmen. Wanneer de Resource Strength het schedulen op de Earliest Start Time van de activiteiten toelaat (i.e. bij RS = 1) wordt de optimale oplossing altijd gevonden. Voor heel lage RS-waarden lopen de performanties van de algoritmen erg uit elkaar. Voor RS = 0.2 haalt DPSO-LDPSO een dubbel zo hoge gemiddelde kost ten opzichte van GRASP-LDPSO. Dit duidt er op dat het gebrek aan intelligentie in de opbouw van schedules nefast is voor de performantie van het DPSO-LDPSO algoritme wanneer de basisresourcecapaciteit Q k van resource k erg laag is. Door deze lage basiscapaciteit ligt de optimale makespan van het corresponderende RCPS-probleem erg ver in de tijd, wat de oplossingsruimte voor het TCPSP erg vergroot. Voor grote oplossingsruimten blijkt de performantie van DPSO-LDPSO relatief gezien dus zwak te zijn. Gemiddelde projectkost in functie van resourcesterkte 10,00 9,00 8,00 7,00 6,00 5,00 4,00 3,00 2,00 1,00 0, DPSO-LDPSO 9,08 0,58 0,09 0,00 GRASP 6,10 0,76 0,12 0,00 GRASP-LDPSO 4,43 0,32 0,04 0,00 Figuur 5.7: Gemiddelde kost per project in functie van Resource Sterkte.

103 Gemiddelde projectkost Hoofdstuk 5. Performantie van de methoden 86 Wanneer we vervolgens naar de Netwerk Complexiteit (NC) kijken (zie figuur 5.8), merken we een dalende gemiddelde kost op bij een toenemende netwerkcomplexiteit. Dit kan verklaard worden door het feit dat een hoge complexiteit de bewegingsvrijheid van elke activiteit beperkt en dus de feasible oplossingsruimte erg verkleint, waardoor er gemakkelijker een goede oplossing kan gevonden worden. Ondanks het feit dat de feasible oplossingsruimte verkleint, en we dus een relatief betere performantie van DPSO-LDPSO zouden verwachten (zie conclusie bij figuur 5.7), toont figuur 5.8 dat dit niet het geval is. Dit komt omdat niet de totale oplossingsruimte verkleint, doch enkel de feasible oplossingsruimte. Bij de snelheidsupdate van de partikels in het DPSO-LDPSO wordt immers geen rekening gehouden met de huidige planning van het partikel, noch met diens voorgangers en opvolgers. Na de positie-update moet het schedule immers nog hersteld worden om de volgorderelaties opnieuw te respecteren, wat de diversiteit van de oplossingen negatief beinvloedt. Bij GRASP en GRASP-LDPSO worden in de opbouw van de oplossingen de volgorderelaties expliciet in ogenschouw genomen. Daardoor kunnen zij bij hogere netwerkcomplexiteit profiteren van de kleinere feasible oplossingsruimte, zoals de resultaten in de figuur ook aantonen. Gemiddelde projectkost in functie van netwerkcomplexiteit 3,00 2,50 2,00 1,50 1,00 0,50 0, DPSO-LDPSO 2,74 2,46 2,12 GRASP 2,06 1,98 1,20 GRASP-LDPSO 1,43 1,44 0,72 Figuur 5.8: Gemiddelde kost per project in functie van Netwerkcomplexiteit.

104 Hoofdstuk 5. Performantie van de methoden 87 Figuur 5.9 toont de beïnvloeding van de verschillende projectkarakteristieken op de gemiddelde projectkost gevonden door de drie algoritmen. Wanneer er geen invloed van een bepaalde projectkarakteristiek wordt verondersteld en deze projectkarakteristiek varieert over N waarden, dan kan men verwachten dat (1/N 100) % van de totale kosten worden veroorzaakt door projecten gekenmerkt door 1 van deze N waarden. Indien er weldegelijk beïnvloeding door de projectkarakteristiek optreedt, zal de procentuele waarde afwijken van (1/N 100) %. De gebruikte maatstaf voor de sterkte van de beïnvloeding is de gemiddelde kwadratische afwijking van het te verwachten percentage voor elke waarde van de onderzochte projectkarakteristiek. De berekening van deze gemiddelde kwadratische afwijking D gem voor een bepaalde projectkarakteristiek is terug te vinden in vergelijking (5.7). Daarbij stelt P n het effectieve procentuele aandeel voor van de projecten met projectkenmerkwaarde n N in de totale kost, of het totale percentage niet gevonden optimale oplossingen. D gem = 1 N N n=1 ( ) 1 2 N P n (5.7) Figuur 5.9 toont dat resourcesterkte (RS) voor de drie algoritmen de grootste bron van beïnvloeding is in hun performantie. Het veranderen van de basiscapaciteit Q k van resource k is dus de grootste moeilijkheid waarmee de algoritmen te kampen hebben om hun performantie te behouden. Netwerkcomplexiteit (NC) heeft daarentegen het minst invloed op de performantie van de algoritmen. Bij een vergelijking tussen de algoritmen, toont de GRASP methode zich het meest ongevoelig voor variatie van de projectkarakteristieken. 0,18 0,16 0,14 0,12 Gemiddelde kwadratische afwijking volgens verschillende projectkenmerken 0,10 0,08 0,06 DPSO-LDPSO GRASP GRASP-LDPSO 0,04 0,02 0,00 RF RS NC Figuur 5.9: Gemiddelde kwadratische afwijking van de gemiddelde projectkost ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken.

105 Hoofdstuk 5. Performantie van de methoden 88 In bijlage B geven tabellen B.2, B.3 en B.4, op pagina s 121 en volgende, en bijhorende grafische overzichten B.5, B.6 en B.7, tot slot, het percentage projecten dat door de methoden optimaal opgelost is voor verschillende projectkarakteristieken. Figuren B.8, B.9 en B.10 tonen, zoals verwacht, dat meer projecten optimaal opgelost worden voor karakteristieken die tevens een gemiddelde lage kost opleveren, zoals hierboven gegeven. Het GRASP-LDPSO scoort voor elke variatie op elke onderzochte projectkarakteristiek relatief het best. De resultaten voor DPSO-LDPSO en GRASP zijn daarentegen erg concurrerend op de verschillende projectkenmerken. Door het te strikte binaire karakter van deze measure of performance (ofwel optimaal, ofwel niet) is het evenwel niet zinvol een diepere analyse uit te voeren op basis van het percentage optimale oplossingen, omdat uit deze strikte classificatie geen nuttige nieuwe conclusies getrokken kunnen worden. Op dit besluit wordt één uitzondering gemaakt. In figuur 5.10 wordt de beïnvloeding voorgesteld van variatie over de projectkarakteristieken op het percentage optimale oplossingen gevonden door de drie geïmplementeerde algoritmen. Ook voor het percentage optimale oplossingen blijkt de resourcesterkte (RS) de belangrijkste factor voor performantieverschillen te zijn. De conclusies voor de verschillen tussen de algoritmen op basis van deze measure of performance lopen echter niet gelijk met deze voor de gemiddelde kost. DPSO-LDPSO is immers het meest gevoelig voor variatie op resourcesterkte bij het vinden van optimale oplossingen. De invloed van resourcefrequentie en netwerkcomplexiteit zijn voor deze measure of performance bovendien minder uitgesproken. 0,0120 Gemiddelde kwadratische afwijking volgens verschillende projectkenmerken 0,0100 0,0080 0,0060 0,0040 DPSO-LDPSO GRASP GRASP-LDPSO 0,0020 0,0000 RF RS NC Figuur 5.10: Gemiddelde kwadratische afwijking van de niet-beïnvloede situatie voor het percentage gevonden optimale oplossingen voor de verschillende projectkenmerken.

106 % optimale oplossingen Hoofdstuk 5. Performantie van de methoden Robuustheid van de methoden In dit deel gaan we de robuustheid van de verschillende algoritmen na. Hierbij variëren we over het maximum aantal te genereren schedules, de projectdeadline en tenslotte passen we de methoden ook toe op de andere projectsets (j60 en j120 ) uit de PSPLib Variatie op het stopcriterium Bij een eerste robuustheidstest laten we de algoritmen een toenemend maximum aantal schedules genereren. Immers, hoe meer schedules het algoritme mag genereren, hoe groter de kans dat er een nog betere oplossing gevonden wordt. We beginnen bij een zeer beperkt stopcriterium van 1000 schedules en variëren tot schedules. In sectie 5.3 op pagina 56 werd de gebruikte telling reeds toegelicht. Figuur 5.11 toont de evolutie van het percentage optimale oplossingen gevonden door de algoritmen, voor een soepeler wordend stopcriterium. De stijgende curven duiden erop dat de algoritmen effectief ontsnappen aan lokale optima. Een eerste teken van stagnatie valt wel te merken bij het DPSO-LDPSO tussen en schedules, waar het percentage optimale oplossingen met nauwelijks een percent toeneemt, ondanks een verdubbeling van het aantal schedules. De figuur toont aan dat de GRASP- LDPSO methode veruit superieur is aan de anderen voor deze measure of performance. De GRASP methode toont voor een klein aantal schedules zijn capaciteit om zeer snel tot goede oplossingen te komen. Het procentuele verschil met GRASP-LDPSO is immers nooit kleiner dan bij een maximum van 1000 te genereren schedules. Bovendien slaagt de GRASP er in bij minder dan 5000 te genereren schedules de DPSO-LDPSO methode achter zich te laten. Percentage optimale oplossingen in functie van het aantal schedules 95,00% 90,00% 85,00% 80,00% 75,00% 70,00% 65,00% 60,00% DPSO-LDPSO 63,59% 68,47% 71,20% 72,51% 73,63% 75,90% 77,55% 78,61% GRASP 69,33% 71,13% 72,33% 73,24% 73,76% 75,84% 77,75% 79,73% GRASP-LDPSO 75,91% 79,38% 81,24% 82,67% 83,92% 86,62% 89,25% 91,29% Figuur 5.11: Vergelijking tussen het percentage optimale oplossingen gevonden door de methoden voor verschillend aantal schedules.

107 % bijna optimale oplossingen Hoofdstuk 5. Performantie van de methoden 90 Hoewel DPSO-LDPSO en GRASP-LDPSO dezelfde lokale zoekmethode (LDPSO) met elkaar delen, tonen de cijfers duidelijk aan dat de goede oplossingen, aangeleverd door GRASP in GRASP-LDPSO, een hogere kans op het vinden van een optimale oplossing bieden. Dit bevestigt de bevindingen van Feo et al. (1996), die stelt dat de snelheid waarmee een local search methode naar een lokaal optimum convergeert gevoelig toeneemt naarmate vertrokken wordt van goede startoplossingen. Deze snelle convergentie is voor strikte stopcriteria bijgevolg erg wenselijk. Figuur 5.12 toont vervolgens het percentage bijna optimale oplossingen van de gepresenteerde methoden voor verschillende aantallen te creëren schedules. Net zoals bij het percentage optimale oplossingen ligt het resultaat van GRASP-LDPSO ver boven de resultaten van beide andere methoden. Voor een maximum te genereren schedules lager dan 5000, is de GRASP methode superieur aan DPSO-LDPSO, waarna beide methoden een zeer concurrentieel verloop kennen. Percentage bijna optimale oplossingen in functie van het aantal schedules 100,00% 95,00% 90,00% 85,00% 80,00% 75,00% 70,00% DPSO-LDPSO 71,74% 76,28% 79,05% 80,47% 81,46% 84,15% 86,04% 87,74% GRASP 77,26% 79,31% 80,63% 81,54% 82,13% 84,12% 85,96% 87,58% GRASP-LDPSO 81,76% 84,95% 86,61% 87,77% 88,72% 91,06% 93,08% 94,33% Figuur 5.12: Vergelijking tussen het percentage bijna optimale oplossingen gevonden door de methoden voor verschillend aantal schedules.

108 Hoofdstuk 5. Performantie van de methoden 91 Tabel 5.29 toont het percentage strikt bijna optimale oplossingen gevonden door de verschillende methoden voor een variatie op het stopcriterium. Strikt bijna optimale oplossingen De verzameling van strikt bijna optimale oplossingen bestaat enkel uit het percentage projecten met beste projectoplossingen gekenmerkt door een huurkost van 1 of 2 voor een c H k = 1 ( k R) (i.e. zeer dicht tegen optimaliteit). De hoge percentages opgemeten voor zowel GRASP als DPSO-LDPSO ten opzichte van GRASP-LDPSO, leggen de respectievelijke zwakheden van GRASP en DPSO-LDPSO bloot. GRASP slaagt er inderdaad in goede oplossingen te vinden, zelfs bij een laag aantal maximum toegelaten schedules. De local search procedure voor één enkele oplossing is echter beperkt en, door het gebrek aan sociale interactie, worden oplossingen in de GRASP-iteraties erna niet doelgericht doorheen de omgeving van deze oplossing geleid voor verdere exploratie. Dit gebrek is één van de grote motivaties tot het gebruik van het hybride GRASP-DPSO algoritme. Het DPSO-LDPSO daarentegen, vindt niet snel genoeg goede oplossingen, waardoor de lokale zoekgebieden in de LDPSO fase van het DPSO-LDPSO een te groot gebied moeten beslaan, wat het vinden van de optimale oplossing niet in de hand werkt. Tabel 5.29: Vergelijking tussen het percentage strikt bijna optimale oplossingen gevonden door de methoden voor verschillend aantal schedules. GRASP DPSO-LDPSO GRASP-LDPSO ,93% 8,15% 5,85% ,18% 7,80% 5,58% ,29% 7,85% 5,37% ,30% 7,95% 5,09% ,38% 7,83% 4,79% ,28% 8,25% 4,45% ,22% 8,49% 3,83% ,85% 9,13% 3,04%

109 Gemiddelde projectkost Hoofdstuk 5. Performantie van de methoden 92 Figuur 5.13 toont vervolgens het verloop van de gemiddelde projectkost, wanneer de algoritmen meer schedules mogen genereren. De relatief slechte performantie van DPSO-LDPSO voor heel strikte stopcriteria springt daarbij direct in het oog. Leggen we deze resultaten samen met het percentage optimale oplossingen gevonden door deze methode voor eenzelfde aantal schedules (zie figuur 5.11 op pagina 89), dan moeten we concluderen dat op de heel moeilijk op te lossen schedules de partikels onvoldoende tijd krijgen om het zoekgebied af te tasten. Dit duidt weerom op het gebrek aan doelgerichte intelligentie in DPSO-LDPSO. Naarmate de partikels meer tijd krijgen om de complexe oplossingsruimte te exploreren, zien we de gemiddelde kost spectaculair dalen. Voor zeer grote aantallen maximaal te genereren schedules convergeren tenslotte de resultaten van GRASP en DPSO-LDPSO. De GRASP methode haalt een zeer concurrentiële gemiddelde kost bij 1000 te genereren schedules ten opzichte van GRASP-LDPSO, maar moet de laatstgenoemde voor grotere aantallen duidelijk laten gaan. De uiteindelijk verzwakkende relatieve resultaten van de GRASP kunnen er op duiden dat, zeker voor lage waarden van parameter α en bijgevolg een zeer deterministische constructiefase, de meeste constructiemogelijkheden uitgeput zijn, en er bijgevolg maar heel weinig mogelijkheden meer overblijven tot verdere exploratie en dus verbetering. Gemiddelde kost in functie van het aantal schedules 9,00 8,00 7,00 6,00 5,00 4,00 3,00 2,00 1,00 0, DPSO-LDPSO 7,74 4,37 3,31 2,76 2,35 1,68 1,31 1,06 GRASP 2,66 2,22 1,98 1,84 1,73 1,45 1,23 1,03 GRASP-LDPSO 2,52 1,82 1,51 1,32 1,20 0,89 0,64 0,47 Figuur 5.13: Vergelijking tussen de gemiddelde projectkost voor de methoden voor verschillend aantal schedules.

110 Maximale projectkost Hoofdstuk 5. Performantie van de methoden 93 Figuur 5.14 toont tenslotte de maximale projectkost per iteratie van de j30 projectset voor de verschillende methoden bij een stijgend aantal maximum te genereren schedules. Voor DPSO- LDPSO stellen we een gelijkaardig evolutiepatroon vast als bij de gemiddelde projectkost: De maximale projectkost bij 1000 schedules is tot wel 3 keer zo slecht als die van GRASP. Voor een toenemend aantal schedules daalt de maximale kost spectaculair om bij schedules aansluiting te maken met de GRASP methode. Deze GRASP methode slaagt er bovendien in om voor heel weinig te genereren schedules een lagere maximale kost te bekomen dan GRASP- LDPSO, wat nogmaals de kwaliteit van GRASP bij heel strikte stopcriteria onderstreept Maximale kost in functie van het aantal schedules DPSO-LDPSO 128,1 72,6 61,36 54,92 50,46 37,98 30,9 26,82 GRASP 45,79 38,98 37,33 35,45 33,94 30,54 26,41 23,32 GRASP-LDPSO 53,40 43,05 37,63 36,76 34,50 28,37 23,16 18,72 Figuur 5.14: Vergelijking tussen de maximale projectkost voor de methoden voor verschillend aantal schedules Variatie op de deadline In deze sectie wordt de performantie van de verschillende voorgestelde algoritmen voor wisselende deadlines met elkaar vergeleken. De minimale deadline die we voor elk project kunnen vooropstellen is het kritisch pad van het project (CriticalPath). Een kortere deadline zou immers onmogelijk tot een feasible schedule kunnen leiden. Verder voorziet PSPLib voor elk project in de j30 projectset de optimale duurtijd van de RCPSP-variant, optimal makespan. Definiëren we vervolgens parameter α [0, 1.4] zodanig dat deadline = CriticalP ath + α (optimal makespan CriticalP ath) (5.8) dan kunnen we de performantie van de verschillende algoritmen meten voor verschillende waarden van α, zonder erg afhankelijk te zijn van de karakteristieken van de testprojecten (Bij-

111 Gemiddelde kost Hoofdstuk 5. Performantie van de methoden 94 voorbeeld, van grote of kleine absolute verschillen tussen CriticalP ath en optimal makespan). Figuur 5.15 toont de gemiddelde projectkost gevonden door de drie algoritmen voor α-waarden tussen 0 (i.e. deadline = kritisch pad) en 1.4 (i.e. deadline ligt verder dan de gekende optimale makespan voor de RCPSP-variant). De figuur toont aan dat voor α 0.6 de laagste gemiddelde kost door DPSO-LDPSO gevonden wordt. Het verschil met de gemiddelde kost gevonden door GRASP-LDPSO is echter minimaal. GRASP presteert tot een α-waarde van 0.8 het slechtst in termen van gemiddelde kost. Voor grotere α-waarden benadert de gemiddelde kost gevonden door GRASP de gemiddelden van GRASP-LDPSO. Voor kleine oplossingsruimten, zoals het geval is bij lage α-waarden, presteert het DPSO- LDPSO dus het best. In deze situatie moet de global search in de eerste fase van het DPSO- LDPSO slechts een kleine ruimte aftasten, waardoor het intrinsiek een groter local search karakter krijgt. Voor lokale zoektochten, zoals in het LDPSO, is de goede performantie van swarmende partikels reeds bevestigd (zie sectie op pagina 68). Voor grotere oplossingsruimten, geïmpliceerd door grote α-waarden, presteert de GRASP beter ten opzichte van het DPSO-LDPSO. De ingebouwde intelligentie in de GRASP zorgt voor een automatische spreiding van de activiteiten over de uitgebreidere planningshorizon. Bovendien zijn er nu meer schuifmogelijkheden met de starttijden bij het voorwaarts/achterwaarts schedulen van de activiteiten. De lokale zoekcapaciteiten van het LDPSO zorgen ervoor dat de performantie van GRASP-LDPSO voor elke α-waarde beter doet dan de performantie van GRASP, dewelke door het gebrek aan sociale interactie tussen verschillende oplossingen, goede lokale zoekcapaciteiten ontbeert. Gemiddelde kost in functie van alpha 90,00 80,00 70,00 60,00 50,00 40,00 30,00 20,00 10,00 0,00 0 0,2 0,4 0,6 0,8 1 1,2 1,4 DPSO-LDPSO 84,00 50,08 27,85 14,45 6,47 2,39 0,82 0,24 GRASP 87,43 56,76 33,41 17,31 7,13 1,73 0,27 0,08 GRASP-LDPSO 85,38 52,61 29,66 14,75 5,68 1,20 0,12 0,02 Figuur 5.15: Vergelijking tussen de gemiddelde projectkost voor de methoden voor verschillende waarden van α.

112 Maximale kost Hoofdstuk 5. Performantie van de methoden 95 Figuur 5.16 toont de maximale projectkost per iteratie van de j30 projectset gevonden door de verschillende methoden. Het vormt een indicatie van de performantie van de algoritmen op de moeilijkst te optimaliseren projectsets. De maximale projectkost daalt in absolute termen spectaculair, voornamelijk omdat de maximale kost een momentopname is (slechts 1 projectoplossing per oplossingsiteratie) en omdat projecten met hoge Resource Frequentie en een lage Resource Sterkte en Netwerk Complexiteit (i.e. kenmerken van de duurste projecten, zie tabellen 5.26, 5.27 en 5.28 op pagina s 81 en volgende) zeer snel voordeel kunnen halen uit een langere planningshorizon Maximale kost in functie van alpha ,2 0,4 0,6 0,8 1 1,2 1,4 DPSO-LDPSO GRASP GRASP-LDPSO Figuur 5.16: Vergelijking tussen de maximale projectkost voor de methoden voor verschillende waarden van α. Wat minder relevante, doch wel interessante grafieken zijn te vinden in figuren 5.17 en Deze tonen de evolutie van het percentage optimale en bijna optimale oplossingen in functie van α. Voor waarden van α onder 1, zijn de percentages weinig relevant. De optimale oplossing hoeft dan immers niet 0 te zijn, wat pas gegarandeerd is voor α = 1. Het feit dat er optimale oplossingen worden gevonden voor α-waarden kleiner dan 1 heeft te maken met de resource sterkte-karakteristieken van bepaalde projecten. Indien RS 1 is, dan kan een project optimaal gescheduled worden op de Earliest Start Time van de activiteiten, oftewel

113 % optimale oplossingen Hoofdstuk 5. Performantie van de methoden 96 voor een makespan gelijk aan het kritisch pad, omdat de voorziene resourcecapaciteit voor de verschillende resourcetypes dit expliciet voorziet. Voor gelijk welke waarde van α presteert het GRASP-LDPSO veruit het best. Echter, zoals reeds aangehaald, kan een zinvolle conclusie maar genomen worden voor α 1. Voor deze waarden zien we het percentage optimale oplossingen logischerwijs spectaculair stijgen. Voor α = 1.4 bereikt GRASP-LDPSO bijna 100% optimaliteit. De resultaten van DPSO-LDPSO en GRASP lopen parallel voor α-waarden kleiner of gelijk aan 1. Slechts voor de grootste zoekruimten (α > 1) presteert GRASP gevoelig beter dan DPSO-LDPSO. De reden hiervoor is dezelfde als deze aangehaald bij de verklaring voor het verschil in gemiddelde kost tussen GRASP en DPSO-LDPSO voor grotere waarden van α, zie pagina ,00% % optimale oplossingen in functie van alpha 100,00% 80,00% 60,00% 40,00% 20,00% 0,00% 0 0,2 0,4 0,6 0,8 1 1,2 1,4 DPSO-LDPSO 44,71% 44,70% 44,76% 48,91% 53,97% 73,60% 83,73% 92,54% GRASP 44,24% 44,28% 44,25% 48,52% 53,19% 73,76% 90,52% 96,54% GRASP-LDPSO 46,05% 46,43% 47,78% 54,82% 63,29% 83,92% 95,42% 99,03% Figuur 5.17: Vergelijking tussen het percentage optimale oplossingen gevonden door de methoden voor verschillende waarden van α. Figuur 5.18 toont een gelijkaardige relatieve performantie tussen de verschillende methoden voor het gevonden percentage bijna optimale oplossingen. Om de performantie van de verschillende methoden beter te kunnen vergelijken in termen van bijna optimale oplossingen worden de percentages strikt bijna optimale oplossingen berekend. Deze percentages zijn terug te vinden in tabel Voor α < 1 zijn er weinig nuttige conclusies aan de cijfers te koppelen. Voor α = 1 echter, vindt GRASP het hoogste percentage strikt bijna optimale

114 % optimale oplossingen Hoofdstuk 5. Performantie van de methoden 97 oplossingen, wat er effectief op wijst dat de lokale zoekcapaciteiten van GRASP erg beperkt zijn. Verder valt ook het permanent hoge percentage strikt bijna optimale oplossingen voor het DPSO-LDPSO op. Blijkbaar slaagt de LDPSO methode van de DPSO-LDPSO er niet in even effectief de optimale oplossing te vinden als de LDPSO methode van de GRASP- LDPSO. De belangrijkste reden hiertoe is het verschil in de kalibratie van parameter γ en mutation rate in beide algoritmen. Deze bedragen voor DPSO-LDPSO respectievelijk 0.6 en 0.4, wat veel grotere lokale zoekgebieden en toegelaten snelheden impliceert in vergelijking met de 0.1 parameterkalibratie voor zowel γ als mutation rate in het GRASP-LDPSO. De hoge waarden voor beide factoren in het DPSO-LDPSO moeten leiden tot een betere globale exploratie maar zorgen tegelijkertijd voor een verminderde local search capaciteit van het algoritme. 120,00% % bijna optimale oplossingen in functie van alpha 100,00% 80,00% 60,00% 40,00% 20,00% 0,00% 0 0,2 0,4 0,6 0,8 1 1,2 1,4 DPSO-LDPSO 49,28% 50,18% 52,73% 58,59% 68,49% 81,50% 89,48% 96,51% GRASP 49,11% 49,94% 51,87% 57,27% 65,70% 82,13% 95,84% 99,15% GRASP-LDPSO 50,17% 52,14% 56,28% 64,39% 74,00% 88,72% 98,24% 99,88% Figuur 5.18: Vergelijking tussen het percentage bijna optimale oplossingen gevonden door de methoden voor verschillende waarden van α.

115 Hoofdstuk 5. Performantie van de methoden 98 Tabel 5.30: Percentage strikt bijna optimale oplossingen gevonden door de verschillende methoden voor verschillende waarden van α. α DPSO-LDPSO GRASP GRASP-LDPSO 0 4,57% 4,88% 4,12% 0,2 5,48% 5,65% 5,72% 0,4 7,97% 7,61% 8,50% 0,6 9,68% 8,75% 9,56% 0,8 14,52% 12,52% 10,71% 1 7,90% 8,38% 4,79% 1,2 5,75% 5,32% 2,82% 1,4 3,97% 2,60% 0,85% Variatie op de datasets Ten slotte wordt de performantie van de methoden nagegaan voor de andere projectsets uit de PSPLib. De drie methoden worden gebenchmarkt voor de j30, j60 en j120 projectsets bij een stopcriterium van 5000 schedules. Voor de j30 projectset zijn de optimale makespans gekend. Door de grote complexiteit van de j60 en j120 projectsets zijn de optimale makespans voor de projecten in deze projectsets nog niet gekend. De PSPLib voorziet echter de beste makespans die door verschillende onderzoekers tot op dit moment zijn gevonden en gerapporteerd. We gebruiken deze beste heuristische oplossingen voor het RCPSP bijgevolg als deadline voor het TCPSP. Tabel 5.31 toont dat de drie algoritmen aanvaardbaar presteren op de j60 projectset, ondanks de toegenomen complexiteit. Tabel 5.33 toont aan dat de verslechtering in resultaten zich vooral manifesteert in de gemiddelde projectkost. Net als op de j30 projectset presteert GRASP-LDPSO relatief het best op de j60 projectset (zie tabel 5.31), ondanks de grootste relatieve terugval in performantie van de drie algoritmen. Tabel 5.31: Performantie van de methoden op de j60 projectset. % optimaal Gemiddelde kost Maximale kost DPSO-LDPSO 68,39% 15,78 211,23 GRASP 66,91% 15,92 174,35 GRASP-LDPSO 73,04% 13,98 181,85

116 Hoofdstuk 5. Performantie van de methoden 99 Tabel 5.32 toont dat de drie algoritmen echter falen op de j120 projectset. Voor zowel het percentage optimale oplossingen als de gemiddelde kost lopen de relatieve vervallen van de resultaten immers hoog op. Tabel 5.33 toont ook aan dat de terugval in resultaten zich ditmaal het minst doorzetten voor GRASP-LDPSO. De resultaten wijzen er globaal genomen op dat bij grote complexe projecten, onder beperkte runtime, de gepresenteerde algoritmen in hun huidige vorm niet performant zijn. Voor GRASP-LDPSO werd een additonele test ondernomen om na te gaan of de parameterkalibraties, gedaan op basis van de j30 projectset, een mogelijke oorzaak van de waargenomen achteruitgang kunnen zijn. Voor complexe projecten kan bijvoorbeeld in de lokale DPSO fase het zoeken naar verbeteringen in een te beperkte omgeving nefast zijn voor de performantie van het algoritme. Initiële bijkomende testen tonen echter aan dat het vergroten van het zoekgebied van de lokale swarms geen positieve impact heeft op de performantie van het algoritme. Tabel 5.32: Performantie van de methoden op de j120 projectset. % optimaal Gemiddelde kost Maximale kost DPSO-LDPSO 24,55% 185, GRASP 21,61% 160,44 654,95 GRASP-LDPSO 27,79% 151,11 660,45 Tabel 5.33: Evolutie van de performantie van de drie algoritmen op de verschillende projectsets. % optimaal Gemiddelde kost j30-j60 DPSO-LDPSO -7,12% 571,49% GRASP -9,29% 820,23% GRASP-LDPSO -12,96% 1065,00% j60-j120 DPSO-LDPSO -64,10% 1076,24% GRASP -67,70% 907,79% GRASP-LDPSO -61,95% 980,90%

117 Hoofdstuk 6 Vergelijking met externe methoden Dit thesisonderwerp werd gedeeld met twee medestudenten, elk van hen ontwierp één of meerdere metaheuristieken. Het is daarom interessant, om in dit hoofdstuk 1, de performantie van de eigen ontworpen oplossingsmethoden te vergelijken met de door hen ontworpen metaheuristieken. Om het overzicht evenwel te bewaren zal enkel de meest performante techniek van elke persoon vergeleken worden. Zoals reeds bleek uit hoofdstuk 5 is GRASP-LDPSO globaal genomen het meest performante zelf ontworpen algoritme. Een korte omschrijving van de twee andere metaheuristieken ontworpen door de medestudenten zal in het volgend onderdeel gegeven worden. 6.1 Introductie tot de twee andere metaheuristieken Verbeeck (2011) ontwierp meerdere algoritmen voor het oplossen van het TCPSP. Uit de resultaten bleek dat het Artificial Immune System (AIS) over het algemeen het best presteerde. In het gepresenteerde AIS worden na de creatie van een initiële populatie slechts de beste oplossingen weerhouden. Op deze oplossingen wordt vervolgens een sterke vorm van mutatie toegepast ter creatie van een nieuwe populatie, waarna de procedure zich herhaalt. Vercruyssen (2011) ontwikkelde een Genetisch Algoritme (GA) waarbij de populatie opnieuw wordt ververst na een aantal iteraties. Dit houdt in dat de oude populatie-elementen worden vervangen door nieuwe, willekeurig gegenereerde projectplannen. Verder kan een aantal oude elementen worden overgenomen via een elitarisme methode. 1 Dit hoofdstuk werd grotendeels samen met de twee andere thesisstudenten geschreven. 100

118 Hoofdstuk 6. Vergelijking met externe methoden Vergelijking van de performantie bij een een oplopend aantal schedules Totale kost De vergelijking van de verschillende methoden loopt als volgt: In een eerste analyse wordt de impact op de totale kost van het aantal maximum aantal te genereren schedules nagegaan. Als deadline nemen we de optimale makespan van de RCPSP-variant. Figuur 6.1 geeft een overzicht van de totale kost voor tot en met gegenereerde projectplannen voor elk van de 3 weerhouden methoden. De verhouding tussen de verschillende methoden verschuift naarmate het aantal projectplannen toeneemt. Het genetisch algoritme onderscheidt zich hierbij met een lagere kost bij een hoog aantal gegenereerde projectplannen. Het artificial immune system doet het initieel vrij goed (op de test voor 1000 schedules na), maar naarmate het aantal projectplannen toeneemt, daalt de kost minder snel als bij de 2 andere methoden. Dit alles wijst op een verschil in de verbeteringspercentages tussen de verschillende methoden. Figuur 6.2 geeft de verbeteringspercentages van de verschillende methoden weer. Het AIS heeft daarbij een duidelijk dalend verbeteringspercentage, dat zich bij een hoog aantal gegenereerde projectplannen lijkt te stabiliseren tussen de 10% en de 15%. De verbeteringspercentages van GA en GRASP-LDPSO zijn initieel lager dan bij het AIS, maar dalen over de hele lijn gezien veel minder en stabiliseren tussen de 25% en de 30%. Figuur 6.1: Vergelijking van de gemiddelde kost bij projecten met de minimal makespan als deadline

119 Hoofdstuk 6. Vergelijking met externe methoden 102 Figuur 6.2: Procentuele verbetering van de gemiddelde kost bij projecten met de minimal makespan als deadline Percentage optimaal opgeloste projecten Op het gebied van het percentage optimaal opgeloste projecten is de hybride metaheuristiek GRASP-LDPSO de meest performante van de drie, zoals weergegeven in figuur 6.3. Vervolgens noteren we dat de verschillen met het GA veel kleiner zijn dan die met het AIS. Deze laatste techniek scoort gemiddeld 9% minder goed dan het GRASP-LDPSO. Dit euvel wordt veroorzaakt doordat het AIS veel projecten oplost met een bijna optimale huurkost terwijl de andere twee metaheuristieken deze situaties wel succesvol weten te vermijden. Betreffende de procentuele verbetering (figuur 6.4) gelden dezelfde conclusies als bij de totale kost. Het AIS start met een heel hoog verbeteringspercentage van 9,64% maar eindigt met een percentage van 1,13%. De andere metaheuristieken starten aanvankelijk met een lager percentage van 5% maar weten dit niveau min of meer vol te houden bij een toenemend aantal schedules.

120 Hoofdstuk 6. Vergelijking met externe methoden 103 Figuur 6.3: Vergelijking van het percentage correct opgeloste projecten met de minimal makespan als deadline Figuur 6.4: Procentuele verbetering van het percentage correct opgeloste projecten met de minimal makespan als deadline

121 Hoofdstuk 6. Vergelijking met externe methoden Vergelijking van de performantie op basis van wisselende deadlines Figuur 6.5 geeft de impact van de α-waarde weer op elk van de drie methoden (zie ook vergelijking 5.8 op pagina 93). Daarbij volgen de drie algoritmen een duidelijk zeer gelijklopende trend. Een meer gedetailleerde vergelijking kan gebeuren aan de hand van figuur 6.6. Hierin wordt de kost van AIS als 100% gedefinieerd en de andere methoden als een percentage ten opzichte van die kost uitgedrukt. Deze grafiek toont een duidelijke evolutie aan: voor zeer lage α-waarden zijn de 3 methoden aan elkaar gewaagd. De oorzaak hiervoor moet waarschijnlijk gezocht worden in het lage aantal mogelijke oplossingen. Het beperkt aantal elementen in de oplossingsruimte beperkt de verschillen in totale kost. Voor gemiddelde waarden van α (40% - 100%) presteert de AIS heuristiek relatief het best. Dit houdt in dat de methode betere resultaten oplevert voor deadlines die een beetje korter zijn dat de RCPSP deadline, maar toch voldoende groot zijn ten opzichte van het kritische pad waardoor er voldoende spelingsruimte voorhanden is. Deze deadlines zijn belangrijk omdat ze de voornaamste groep vormen waarin het TCPSP wordt ingezet in de praktijk 2. Voor waarden van α die groter zijn dan 100% levert de AIS dan weer veel slechtere waarden op dan het GA en GRASP-LDPSO. Bij een α-waarde van 140% bedraagt de kost voor de set van projecten bij het AIS meer dan het dubbel van de kost van GRASP-LDPSO en 3 maal zoveel als de kost van het GA. Figuur 6.5: Gemiddelde kost bij toenemende waarden van α 2 De aandachtige lezer merkt dat de performantie van GRASP-LDPSO voor deze α-waarden relatief het minst goed presteert. Uit sectie bleek reeds dat deze methode niet de best ontworpen methode was voor deze α s, wel DPSO-LDPSO.

122 Hoofdstuk 6. Vergelijking met externe methoden 105 Figuur 6.6: Verbetering van de gemiddelde kost bij toenemende waarden van α 6.4 Vergelijken van de performantie op basis van projectkarakteristieken In deze sectie wordt er gekeken hoe de verschillende algoritmen presteren voor projecten met verschillende karakteristieken. De testprocedure verloopt als volgt: van de verschillende methoden worden zowel de percentages niet optimale oplossingen als de gemiddelde projectkost verzameld voor projecten met verschillende netwerkcomplexiteit, resourcefrequentie en resourcesterkte. Vervolgens wordt voor de verschillende types projectkarakteristieken de procentuele impact van een bepaalde netwerkcomplexiteit, resourcefrequentie of resourcesterkte op de totale gemiddelde kost of het totale percentage niet gevonden optimale oplossingen berekend. De procentuele resultaten voor de verschillende projectkenmerken op basis van de gemiddelde kost zijn terug te vinden in figuren 6.7, 6.8 en 6.9. In figuur 6.9 maken de gevonden huurkosten voor projecten met een netwerkcomplexiteit van 2.1 bijvoorbeeld 23% uit van de totale huurkosten gevonden door het GA. Het aandeel van de kost van projecten in de totale kost over alle projecten neemt systematisch toe naarmate de projecten gekenmerkt worden door een hogere resourcefrequentie, een lagere resourcesterkte of -in iets mindere mate- een lagere netwerkcomplexiteit. Voor de drie projectkenmerken toont de AIS methode een meer gelijkaardige verdeling van de gemiddelde kosten overheen de verschillende waarden van een projectkarakteristiek.

123 Hoofdstuk 6. Vergelijking met externe methoden % 70% 60% 50% 40% 30% 20% 10% 0% 29% 63% 1% 3% 14% 4% 7% 0% 32% 51% 27% GA AIS GRASP-LDPSO % Figuur 6.7: Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde resourcefrequentie. 100% 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 94% 0% 1% 5% 0% 2% 10% 0% 1% 7% 88% GA AIS GRASP-LDPSO % Figuur 6.8: Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde resourcesterkte.

124 Hoofdstuk 6. Vergelijking met externe methoden % 40% 35% 30% 25% 20% 15% 10% 23% 41% 36% 35% 30% 35% 20% 40% 40% 5% 0% GA AIS GRASP-LDPSO Figuur 6.9: Procentueel aandeel in de totale kost van projecten gekenmerkt door een bepaalde netwerkcomplexiteit. Gelijkaardige vergelijkende percentages voor het percentage niet gevonden optimale oplossingen worden gepresenteerd in figuren 6.10, 6.11 en Het procentuele aandeel van projecten waarvoor geen optimale oplossing werd gevonden in het totale percentage niet gevonden optimale oplossingen, loopt op naarmate de projecten gekenmerkt worden door een hogere resourcefrequentie, een lagere resourcesterkte of - in de meeste gevallen- een lagere netwerkcomplexiteit. Ook hier valt de gelijkere verdeling van het percentage niet gevonden optimale oplossingen over verschillende waarden van een projectkenmerk voor het Artificial Immune System op.

125 Hoofdstuk 6. Vergelijking met externe methoden % 50% 40% 30% 20% 10% 0% 43% 37% 34% 38% 37% 22% 17% 3% 6% 0% 11% GA AIS GRASP-LDPSO % Figuur 6.10: Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde resourcefrequentie. 90% 80% 70% 60% 50% 40% 30% 20% 10% 0% 81% 73% 77% 0% 2% 17% 22% 20% 0% 5% 0% 3% GA AIS GRASP-LDPSO Figuur 6.11: Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde resourcesterkte.

126 Hoofdstuk 6. Vergelijking met externe methoden % 40% 35% 30% 25% 20% 15% 10% 5% 0% 31% 33% 36% 33% 36% 35% 31% 25% GA AIS GRASP-LDPSO % Figuur 6.12: Procentueel aandeel in het percentage niet gevonden optimale oplossingen van projecten gekenmerkt door een bepaalde netwerkcomplexiteit. Vervolgens wordt er gekeken welke van de drie algoritmen in zijn performantie het meest beïnvloed wordt door de verschillende projectkarakteristieken. Wanneer er geen invloed van een bepaalde projectkarakteristiek wordt verondersteld en deze projectkarakteristiek varieert over N waarden, kan men verwachten dat (1/N 100) % van de totale kosten wordt veroorzaakt door projecten gekenmerkt door 1 van deze N waarden. Indien er weldegelijk beïnvloeding door de projectkarakteristiek optreedt, zal de procentuele waarde afwijken van (1/N 100) %. De gebruikte maatstaf voor de sterkte van de beïnvloeding is de gemiddelde kwadratische afwijking van het te verwachten percentage voor elke waarde van de onderzochte projectkarakteristiek. De berekening van deze gemiddelde kwadratische afwijking D gem voor een bepaalde projectkarakteristiek is terug te vinden in vergelijking (6.1). Daarbij stelt P n het effectieve procentuele aandeel voor van de projecten met projectkenmerkwaarde n N in de totale kost of het totale percentage niet gevonden optimale oplossingen. D gem = 1 n N n=1 ( ) 1 2 N P n (6.1) Figuren 6.13 en 6.14 tonen de gemiddelde kwadratische afwijkingen voor de verschillende projectkarakteristieken. Resourcesterkte (RS) blijkt voor alle algoritmen de grootste bron van beïnvloeding op hun performantie. Het veranderen van de basiscapaciteit Q k van resource k is dus de grootste moeilijkheid waarmee de algoritmen te kampen hebben om hun performantie te behouden. Netwerkcomplexiteit (NC) heeft daarentegen het minst invloed op de performantie van de algoritmen. Bij een vergelijking tussen de algoritmen, merken we dat zowel voor de gemiddelde kost als het percentage niet gevonden optimale oplossingen het AIS algoritme het minst beïnvloed wordt door variatie van de projectkarakteristieken.

127 Hoofdstuk 6. Vergelijking met externe methoden % 16% 14% 12% 10% 8% 6% 16% 13% 15% 4% 2% 0% 6% 8% 3% 0,60% 0,07% RF RS NC 0,90% GA AIS GRASP-LDPSO Figuur 6.13: Gemiddelde kwadratische afwijking van de gemiddelde projectkost ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken. 12% 10% 8% 6% 4% 11% 8% 10% 2% 0% 3% 4% 2% 0,04% 0,04% RF RS NC 0,34% GA AIS GRASP-LDPSO Figuur 6.14: Gemiddelde kwadratische afwijking van het percentage niet gevonden optimale oplossingen ten opzichte van de situatie zonder beïnvloeding door de verschillende projectkenmerken. 6.5 Conclusie Uit voorgaande discussie is het moeilijk op te maken welke van de drie methoden het best presteert op het basis TCPS-probleem. Het Artificial Immune System haalt goede resultaten bij strikte deadlines en is het meest ongevoelig aan schommelingen in projectkarakteristieken.

128 Hoofdstuk 6. Vergelijking met externe methoden 111 Het presteert daarentegen het minst goed bij een zeer strikt stopcriterium en vindt het laagste aantal optimale oplossingen. GRASP-LDPSO haalt relatief gezien het hoogste aantal optimale oplossingen onder de verschillende onderzochte omstandigheden. Dit hoge percentage kan verklaard worden door het doelbewust diep exploreren van de omgevingen rond goede oplossingen in de tweede fase van het hybride algoritme. Bij zeer strikte deadlines presteert het algoritme dan weer relatief het zwakst. Het Genetisch Algoritme blinkt op geen enkel testonderdeel echt uit, behalve bij een hoge limiet voor het stopcriterium. Het presteert echter globaal gezien het vaakst op hoog niveau.

129 Hoofdstuk 7 Algemeen besluit 7.1 Gevoerd onderzoek In deze masterproef werd een onderzoek gevoerd naar meta-heuristische oplossingsmethoden voor het Time-Constrained Project Scheduling Problem (TCPSP). Het basis probleem binnen het TCPSP omvat een project bestaande uit een aantal activiteiten met een vaste duurtijd. In het TCPSP kent het project bovendien een strikte deadline. Tussen de activiteiten bestaan er volgorderelaties. Bovendien vragen de activiteiten bepaalde resources voor hun uitvoering. Deze resources zijn voor elke tijdseenheid binnen de deadline slechts beperkt voorradig. Om de deadline te halen is het mogelijk tijdelijk resources bij te huren. Door het verschuiven van de starttijden van de activiteiten trachten oplossingsmethoden de totale huurkosten gedurende de uitvoering van het project te minimaliseren. Voor het oplossen van het TCPS-probleem werden twee gekende metaheuristieken voor het Resource-Constrained Project Scheduling Problem aangepast aan de specfieke karakteristieken van het TCPSP. Het Darwinian Particle Swarm Optimization met een Local Darwinian Particle Swarm Optimizer (DPSO-LDPSO) laat partikels (mogelijke oplossingen) binnen verschillende swarms in de M-dimensionele oplossingsruimte rondvliegen. Daarbij wordt hun snelheid en positie bepaald door hun snelheid uit de vorige iteratie, hun historisch beste positie en de beste positie gevonden door de hele swarm in vorige iteraties. In de eerste fase (DPSO) wordt het hele zoekgebied oppervlakkig geëxploreerd. In de tweede fase (LDPSO) worden de meest veelbelovende subgebieden verder onderzocht. Door de non-regular measure of performance van het TCPSP is het immers noodzakelijk de omgevingen van goede oplossingen grondig te exploreren (LDPSO). De Greedy Random Adaptive Search Procedure tracht in elke iteratie stapsgewijs een projectplan op te bouwen. Daarbij kent het in elke stap een starttijd toe aan een volgende activiteit op basis van het huidige gedeeltelijke schedule. Vervolgens wordt er gepoogd de activiteiten 112

130 Hoofdstuk 7. Algemeen besluit 113 die op tijdstippen gescheduled staan waarop resources bijgehuurd worden, naar een andere starttijd te verhuizen, teneinde deze huurkosten te vermijden. Een derde geïmplementeerd algoritme is een hybride Greedy Random Adaptive Search Procedure met een Local Darwinian Particle Swarm Optimizer (GRASP-LDPSO). In de eerste fase zal de GRASP methode initiële oplossingen construeren. Rond de beste oplossingen uit de eerste fase, worden in de tweede fase lokale swarms geconstrueerd om de oplossingsruimte in de omgeving van deze beste oplossingen verder te onderzoeken. Vervolgens werden de drie geïmplementeerde algoritmen onderworpen aan verscheidene tests. Daaruit is gebleken dat GRASP voor een zeer strikt stopcriterium relatief goede oplossingen vindt. Echter, door het gebrek aan interactie met andere en historische oplossingen, slaagt de methode er in vergelijking met de andere methoden minder goed in verbeteringen te vinden bij een langere runtime. DPSO-LDPSO vertoont een invers patroon. Voor een strikt stopcriterium presteert het algoritme niet goed, omdat een initiële verkenning van het oplossingsgebied voor dit algoritme noodzakelijk is. Voor langere runtimes, echter, zal door de interactie tussen de elementen, de performantie stelselmatig verbeteren. Voor heel strikte deadlines en een gemiddelde runtime, toont DPSO-LDPSO zich overigens superieur ten opzichte van de andere methoden, omdat in dit geval de oplosssingsruimte kleiner is en de aftastingsfase bijgevolg korter is. Het hybride GRASP-LDPSO presteert over het algemeen het best. Het percentage optimale oplossingen binnen de onderzochte projectset gevonden door het algoritme is in het bijzonder opvallend, zowel voor een variatie over de deadline als voor verschillende stopcriteria. Dit blijkt ook uit een vergelijk met andere oplossingsmethoden ontworpen door andere thesisstudenten. In termen van gemiddelde projectkost presteert het GRASP-LDPSO ook steeds relatief het best ten opzichte van de andere zelf ontworpen methoden, met uitzondering van projecten met strikte deadlines, waar het DPSO-LDPSO iets beter presteert. Deze globale goede performantie kan verklaard worden uit het feit dat GRASP-LDPSO de goede eigenschappen van beide algoritmen waarop het gebaseerd is, combineert. Door in een eerste fase het GRASP algoritme te gebruiken kan het snel goede oplossingen bekomen. Door de lokale DPSO kunnen vervolgens de omgevingen rond deze oplossingen op dynamische wijze dieper onderzocht worden. 7.2 Beperkingen van het onderzoek Het doel van dit onderzoek was het aantonen van de toepasbaarheid van metaheuristische oplossingswijzen, gebruikt voor het RCPSP, op het TCPSP. Daarbij werden enkele metaheuristieken voor de eerste maal toegepast op het basis TCPS-probleem. In dit verband kunnen er drie beperkingen geformuleerd worden: 1. Dit onderzoek is, voor zover gevonden in de literatuur, een eerste in zijn soort. Nooit

131 Hoofdstuk 7. Algemeen besluit 114 eerder werden metaheuristieken, gebruikt voor het RCPSP, toegepast op het TCPSP. Dit betekent dat de aanpassingen aan de bestaande metaheuristieken, om ze toepasbaar te maken op het TCPSP, niet kunnen getoetst worden aan eerder gevoerd onderzoek, net als hun performantie. 2. Dit onderzoek maakt gebruik van het basis TCPS-probleem. Door het gebruik van het basis TCPS-probleem is de toepasbaarheid van metaheuristieken voor het RCPSP toegenomen. Aan de andere kant is de toepasbaarheid van het basis TCPS-probleem in de praktijk terecht in vraag te stellen. 3. De gepresenteerde algoritmen zijn geoptimaliseerd naar de prestaties op eenvoudige projecten. De gepresenteerde algoritmen werden immers gekalibreerd naar hun performantie op de j30 projectset van de PSPLib. De resultaten van de toepassing op het j60 en j120 projectset, die grotere en complexere projecten omvatten, tonen aan dat de gepresenteerde algoritmen niet goed meer presteren bij toegenomen projectgrootte en -complexiteit. 7.3 Suggesties tot verder onderzoek In de vorige sectie werd reeds de praktische toepasbaarheid van de basisversie van het TC- PSP in vraag gesteld. Deze basisversie en de erop toegepaste oplossingsmethoden zijn echter slechts een vertrekpunt van waaruit oplossingsmethoden voor TCPSP-varianten met een hogere praktische toepasbaarheid kunnen worden afgeleid. Eén van de mogelijke varianten is de uitbreiding van het basisprobleem met een Net Present Value (NPV) benadering. Het tijdstip van het inhuren van extra resources wordt dan immers gereflecteerd in de doelfunctie. Dit geeft de NPV-variant van het TCPSP overigens een regular measure of performance, waardoor ook weer andere oplossingsmethoden met succes kunnen worden toegepast. Ook kan er naar metaheuristische oplossingsmethoden gezocht worden voor de TCPSP-variant met overuren, zoals beschreven door Guldemond et al. (2008). De grote uitdaging daarbij is het vinden van een adequate representatie van een oplossing. Tevens tonen de resultaten van de gepresenteerde algoritmen aan dat er nog ruimte voor verbetering te vinden is voor de toepassing van metaheuristieken op het basis RCPSP probleem. Eén mogelijkheid daartoe is de waarden van parameters α en β in de Greedy Random Adaptive Search Procedure autoadaptief te maken aan de kenmerken van het te optimaliseren project.

132 Bijlage A Kenmerken van de j30 projectset Tabel A.1: Kenmerken van de j30 projectset. projectgroep NC RF RS projectgroep NC RF RS

133 Bijlage B Bijlagen bij performantie van de methoden 50,00 45,00 40,00 45,00-50,00 35,00 40,00-45,00 35,00-40,00 30,00 25,00 30,00-35,00 25,00-30,00 20,00-25,00 20,00 15,00 10,00 5,00 0,00 0 0,2 0,4 0,6 0,8 1 1,2 0 1,4 1 0,9 0,8 0,7 0,6 0,5 0,4 0,3 0,2 0,1 15,00-20,00 10,00-15,00 5,00-10,00 0,00-5,00 Figuur B.1: Kalibratie van parameters α en β naar maximale projectkost. Variatie over α vindt plaats op de diepte-as, variatie over β op de lengte-as. 116