1. A local search algorithm with repair procedure for the Roadef 2010 challenge Lauri Ahlroth, André Schumacher, Henri Tokola 3.5.2010

2. Outline Group Algorithm Implementation process Results

3. Group Our group consists of three people from two different departments of Aalto University: –Department of Information and Computer Science André Schumacher, post-graduate student Lauri Ahlroth, post-graduate student –Department of Mechanical engineering Henri Tokola, post-graduate student.

4. The problem Two types of plants –Plants of type 1 generate energy by given time-variant cost –Plants of type 2 consume fuel and they need to be shut down for refueling by scheduled outage  We have assumed that plants of type 2 are cheaper than type 1 and thus we try to achieve maximal production of type 2 Many constraints –CT1-CT12 are constraints for energy production –CT13-CT21 are constraints for outage schedule  We find feasible outage schedule and after that try to find the feasible energy production schedule Multiple scenarios  We create a solution where production of type 2 plants is the same for all scenarios

5. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

6. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

7. Initial solution Initial outage schedule is constructed using limited- depth backtrack method using constraint propagation for the outage scheduling constraints Production is calculated by using min refuels and full power for type 2 plants (unless demand is smaller) Gives feasible solution for B6,B7,B9 and B10. For B8, we use infeasible solutions until we find the first feasible solution

8. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

9. Outage generation We have two possible neighborhood strategies: –Select all plants of type 2 –Select a single plant of type 2 For each selected plant, we move outage with 0.1 probability. –We move outages randomly between lbound and ubound, that are calculated by taking into account scheduling and refueling constraints –We sometimes add new and remove outages More than 50% of the all schedules that are generated are infeasible.

11. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

12. Outage repair Min conflict heuristic –We test all possible moves and select the move that minimizes the conflicts –This is repeated until there are no conflicts or we cannot repair the conflicts any more –Tabulist contains initially the changed outages, which cannot be moved in the first few repair steps –The repair can not produce a move to the initial outage date Only the conflicts where a move affects are checked! Repair rate is typically about 98%

13. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

14. Feasible production check We try to find out quickly if there is a feasible production schedule –First we try to fix the refueling of outages that cause problems Fuel stock before and after refueling (CT11) Refuel limit (CT7) –If it is not possible we try minimal refueling. If it is not possible we reject the solution. In a 1000 seconds run for B6 instance, about 2% of the generated solutions are rejected by feasible production check.

15. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

16. Refuel levels and production Refuels are increased by using trial and error –Increasing stops when type 2 plants enter decreasing power profiles in the same time they enter the next outage. Fuel: –produce as much power as possible with plants of type 2 do not exceed the minimum demand –The remaining production is satisfied using plants of type 1

17. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

18. Simulated annealing We use a simulated annealing based method to accept or reject the solution We use LBOUND variable to scale the difference between the solution candidates. –LBOUND is optimistic cost estimate based on a relaxation of the problem. The final algorithm is quite near simple hill climbing, because there were few moves toward the worse solution

19. Algorithm Initial solution New outage generation Outage repair (Constraints CT13-CT21) Feasible refuel levels check (Constraints CT1-CT12) Increase fuel levels by using trial and error Accept or reject the solution Production levels If we have time

20. Changes in the program during qualification and final round Qualification round: –Initial solution using backtracking –New solution - SA – simple repair – min refuel –3-6 weeks work per group member Final round: –Fixing solution for new instances, there were notable problems: We assumed that sum of productions of type 2 plants were allways smaller than minimum demand Initial solution failed because of Ct13bis Problems with memory as the new instances were quite large –Optimized for speed by introducing incremental updates and constraint checking –3-6 weeks work per group member There were some modifications that were not added to final solution because we ran out of time –Scenario-specific optimization –Better neighborhood strategy

21. Results of 4000 seconds runs (final test before submit) dataB6.txt:85 665 255 440 dataB7.txt:83 651 277 007 dataB8.txt:359 914 701 565 dataB9.txt:214 930 128 904 dataB10.txt:95 203 702 217

22. Thank you!