Initial solution

A local search algorithm with repair
procedure for the Roadef 2010
challenge
Lauri Ahlroth, André Schumacher, Henri
Tokola
3.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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
Algorithm
Initial solution
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
Initial solution
• Initial outage schedule is constructed using limiteddepth 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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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
If we have time
Accept or reject
the solution
Production levels
New outage generation
Outage repair
(Constraints CT13-CT21)
Feasible refuel
levels check
(Constraints CT1-CT12)
Increase fuel levels by
using trial and error
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!