A local search algorithm with repair procedure for the Roadef 2010 challenge

Lauri Ahlroth, André Schumacher, Henri Tokola3.5.2010

Outline

• Group• Algorithm• Implementation process• Results

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.

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

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

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

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

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

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.

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

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%

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

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.

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

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

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

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

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

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

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

Thank you!