Multi-Thread Integrative Cooperative
Optimization for Rich VRP
Teodor Gabriel Crainic, Gloria Cerasela Crişan,
Nadia Lahrichi, Michel Gendreau,
Walter Rei, Thibaut Vidal
DOMinant 2009, Molde, Norway
Multi-Thread Integrative Cooperative
Optimization for Rich VRP
Teodor Gabriel Crainic, Gloria Cerasela Crişan,
Nadia Lahrichi, Michel Gendreau,
Walter Rei, Thibaut Vidal
DOMinant 2009, Molde, Norway
Plan
Our research program: Addressing comprehensively rich
(combinatorial optimization) (planning) problems
 Goals, objectives, inspiration / fundamental ideas
 The Integrative Cooperative Search approach
 Rich VRP: Concept and literature review
 Applying ICS to rich VRP
 The current application: MDPVRP
 Planning and uncertainty
 Perspectives

3
© Teodor Gabriel Crainic 2009
Our Research Program
Planning and management of complex systems
 Transportation, logistics, telecommunications, …
 Design, scheduling, routing, …
 Combinatorial optimization problems
 Mix-integer formulations
 Formally hard problems
 Large instances
 Plan now, repetitively execute later: uncertainty
 More complex modeling and algorithmic issues

4
© Teodor Gabriel Crainic 2009
Our Research Program (2)
Need “good” solutions in “reasonable” computing times
 Exact methods for reduced complexity/dimensions
 Decomposition, enumeration, bounds, cuts, …
 Heuristics and meta-heuristics
 Parallel computation
 Cooperative search
 The problem-solving paradigms evolve, however

5
© Teodor Gabriel Crainic 2009
Rich Problem Setting
Large number of interacting attributes (characteristics)
 Larger than in “classical” (“academic”) settings
 Problem characterization
 Objectives
 Uncertainty
 That one desires to (must ) address simultaneously

6
© Teodor Gabriel Crainic 2009
Design of Wireless Networks
Simultaneously
 Determine the appropriate number of base stations
 Location
 Height & power
 Number of antennas/station
 Tilt & orientation of each antenna
 Optimize cost, coverage & exposure to electrosmog

7
© Teodor Gabriel Crainic 2009
Rich VRP
Vehicle routing in practice
 Attributes of several generic problems
 Complex “cost” functions

8
© Teodor Gabriel Crainic 2009
The Journey of Milk
…..
9
© Teodor Gabriel Crainic 2009
10
© Teodor Gabriel Crainic 2009
Actual Rich VRP Applications at FPLQ
Coalition of all dairy farmers
 A number of processing plants
 Transportation centrally
negotiated and managed
 Carrier contracting:
assign farms to carriers and plants
+ route construction
(strategic/tactic)
 Operational route adjustments

11
© Teodor Gabriel Crainic 2009
Multiple Routing Attributes
Time windows
Vehicle capacities
Route duration & length
Topology of routes
Multi-compartment
Multi-depot
Multiple periods
Complex cost functions
Pick up at farmers
 Deliveries at plants (very
different in capacities)
 Mixing pickups and
deliveries (sometimes)
 Multiple tours
…
 Planning now by FDLQ,
execute repetitively later
by carriers

12
© Teodor Gabriel Crainic 2009
Object and Goals of the Research Program
Models and methods for addressing “rich” problems
 Combinatorial optimization
 Planning
 Uncertainty
 Operations management and plan adjustment
 Applications to routing and (service) design

13
© Teodor Gabriel Crainic 2009
What Methodology for Rich Problems?
Simplify (!!)
 Series of simpler problems
 Simultaneous handling of multiple attributes
 A more complex problem to address!
 Propose a “new” approach

14
© Teodor Gabriel Crainic 2009
Sources of Inspiration
Decomposition
 Major methodological tool in optimization
 Domain decomposition in parallel computation
 Solution reconstruction? “Partition” modification?
 Simplification
 Fixing part of a rich problem may yield a case easier
to address
 Cooperative (parallel) meta-heuristics successful in
harnessing the power of different algorithms
 Guidance mechanisms

15
© Teodor Gabriel Crainic 2009
Sources of Inspiration (3)

VRPTW (Berger & Barkaoui, 2004)
 Evolved two populations
Minimize total travel time
Minimize temporal violations
16
© Teodor Gabriel Crainic 2009
Cooperative Multi-search
Several independent ([meta-]heuristic or “exact”) search
threads work simultaneously on several processors &
exchange information with the common goal of solving
a given problem instance
 Exchange meaningful information in a timely manner
 What information?
 Between what processes? When & how?
 What does one do with imported/exchanged data?
 Most successful: asynchronous direct/indirect exchanges

17
© Teodor Gabriel Crainic 2009
Controlled Direct Exchange Mechanisms
Search
r
Search
k
Search
j
Search
i
Search
l
Search
h
18
© Teodor Gabriel Crainic 2009
Direct Exchange Mechanisms: Diffusion
Search
j
Search
i
Search
r
Search
k
Search
l
Search
h
19
© Teodor Gabriel Crainic 2009
Indirect, Memory-based Exchange Mechanisms
Search
j
Search
k
Memory, Pool
Reference Set
Elite Set
Data Warehouse
Search
l
Search
i
20
© Teodor Gabriel Crainic 2009
Memory-based Mechanisms
No direct exchanges among searches
 Data is deposited and extracted from the common
repository structure according to each method’s own
logic
 Asynchronous operations and process independence
easy to enforce
 Easy to keep track of exchanged data
 Dynamic and adaptive structure
 Exchanged information may be manipulated to build
new/global data and search directions = guidance

21
© Teodor Gabriel Crainic 2009
Sources of Inspiration (4)

VRPTW (Le Bouthiller et al. 2005)
 Parallel cooperative guided meta-heuristic
 Two different tabu searches
 Two GA (simple) crossover
 Education through post-optimisation
 Communications though a central memory (pool)
 Patterns of arcs in good/average/bad solutions in
memory and their evolution
 Particular phases and guidance based on patterns
22
© Teodor Gabriel Crainic 2009
Sources of Inspiration (5)

Wireless network design (Crainic et al. 2006)
 Parallel cooperative guided meta-heuristic
 Several tabu searches work on parts of the search
space to optimize relative to certain attributes only
 A genetic algorithm to combine partial solutions
 Communications though a central memory (pool)
 Particular phases and guidance
23
© Teodor Gabriel Crainic 2009
ICS Fundamental Ideas & Concepts
Decomposition by attribute
 Concurrent population evolution
 Solver specialization
 Cooperation with self-adjusting and guidance features

24
© Teodor Gabriel Crainic 2009
Shared-Memory ICS
Integrator
Integrator
Partial
Solutions
(set A)
Partial
Solvers (set A)
Partial
Solver (set A)
Global
Search
Coordinator
Partial
Solutions
(set B)
Complete
Solutions
Partial
Solvers (set B)
Partial
Solver (set B)
25
© Teodor Gabriel Crainic 2009
Decomposition by Attribute
Simpler settings by fixing (ignoring) variables or
constraints
 “Eliminating” variables or constraints might yield the
same sub-problems but impair the reconstruction of
solutions
 Yields
 Well-addressed, “classical” variants with state-of-theart algorithms
 Formulations amenable to efficient algorithmic
developments
 Our idea: be opportunistic!

26
© Teodor Gabriel Crainic 2009
Decomposition by Attribute (2)
Each subproblem = Particular fixed attribute set
 Addressed using effective specialized methods
→ Partial Solvers
 Partial Solvers focus on the unfixed attributes
→ Partial Solutions
 Multiple search threads
 One or several methods for each subproblem
 Meta-heuristic or exact
 Central-memory cooperation

27
© Teodor Gabriel Crainic 2009
Decomposition by Attribute (3)

Issues and challenges
 Homogeneous vs. heterogeneous population
 Purposeful evolution of partial solutions
 Reconstruction & improvement of complete solutions
28
© Teodor Gabriel Crainic 2009
Reconstructing Complete Solutions
Recombining Partial Solutions to yield complete ones
 Search threads / operators → Integrators
 Select and forward
 Population-based, evolutionary methods:
GA & Path Relinking
 Mathematical programming-based models

29
© Teodor Gabriel Crainic 2009
Reconstructing Complete Solutions (2)
Issues and challenges
 Selection of partial solutions for combination
 Which subproblems?
 What quality?
 What diversity?
 Selection of complete solutions for inclusion in the
central-memory population
 What quality?
 What diversity?

30
© Teodor Gabriel Crainic 2009
31
© Teodor Gabriel Crainic 2009
solutions
Admissible
selection
operators
complete
solutions
Mutation/
Education
complete
solutions
Integrative
crossover
operators
complete
solutions
Partial
solution
selection
operators
partial
partial
population
P’ of
elite
partial
solutions
solutions
Integrative Crossover
population
P of
complete
solutions
Improving Complete Solutions
Search threads – Solvers
 Evolve & improve complete solution population
 These are difficult problems!
 If they were “easy”, we would not need ICS!
 Should modify solutions in ways partial solvers would
not do
 Post-optimization certainly interesting
 Large neighbourhoods for “few” iterations
 Select few solutions and solve and exact problem
 Local branching on variables from different attribute, …
sets
32

© Teodor Gabriel Crainic 2009
Purposeful Evolution
Current processes
 Partial Solvers work on particular subproblems defined
exogenously ↔
 Initial entering communication
 Intra Partial Solver exchanges & evolution through
central-memory cooperation
 Integrators extract & combine Partial Solutions ↔
 One-way communications
Partial solutions  Integrator  Complete-solution
pool

33
© Teodor Gabriel Crainic 2009
Purposeful Evolution – Current Processes
No communications among Partial Solvers on different
attribute sets
 No communications from Complete-solution pool to
Integrators and Partial Solvers
 No modifications to subproblem definition
(values of attributes in corresponding sets) 
no feed back

34
© Teodor Gabriel Crainic 2009
Purposeful Evolution – Issues
Reconstruct / approximate global status of the search
 Information exchange mechanisms
 Guidance for Partial Solvers & global search
 Evolve toward high-quality complete solutions
 In absence of a mathematical framework
 Apply cooperation principles
 Avoid “heavy-handed” process control
 A “richer” role for the Global Search Coordinator

35
© Teodor Gabriel Crainic 2009
Global Search Coordinator – Monitoring
Pools / populations
 Complete solutions (direct)
 Partial solutions (& integrators) (direct or indirect)
 Exchanges / communications (possibly)

36
© Teodor Gabriel Crainic 2009
Global Search Coordinator – Monitoring (2)
Classical (central) memory statistics
 A “richer” memory through analysis of solutions &
communications
 Quality of solution & evolution of population
 Impact on population (quality & diversity)
 Presence of solutions or solution elements in various
types/classes of solutions
Arcs, routes
Good, average, poor solutions
Solutions with particular attribute sets, …

37
© Teodor Gabriel Crainic 2009
Global Search Coordinator – Monitoring (3)
The process – Partial Solver, Integrator, Solver – that
produced the solution
 Search space covering
 Attribute values (combinations of) corresponding to
visited search space regions
(how often, quality measure)
…

38
© Teodor Gabriel Crainic 2009
Global Search Coordinator – Guidance
Partial Solvers cooperate and communicate according to
their own internal logic
 Based on monitoring results, “instructions” (solutions,
often) are sent GSC → Partial Solver (pool) or Integrator
 Enrich quality or diversity
 Modify the values of the fixed attributes 
Moving the search to a different region
 Modify the sets of attributes defining the partition
 Modify parameter values or method or replace method

39
© Teodor Gabriel Crainic 2009
ICS Concurrent Evolution
Selective migration
set S1
of partial
solvers
set S2
of partial
solvers
Evolution
set S3
of partial
solvers
Integrative evolution
set S
of
solvers
population
P1 of
partial
solutions
population
P2 of
partial
solutions
Guiding migration
population
P’ of
elite
partial
solutions
set I
of
integrators
population
P3 of
partial
solutions
global evolution
guiding-migration
operators
40
© Teodor Gabriel Crainic 2009
global
monitoring
& guidance
population
P of
complete
solutions
Zoom on Partial Solver Organization
Legend
GA1
partial
solver
Selective migration
Evolution
Guiding migration
GA2
partial
solver
population
Pi of
partial
solutions
TS1
partial
solver
TS2
partial
solver
41
© Teodor Gabriel Crainic 2009
Rich VRP

A concept that has emerged in the last decade or so
 To focus attention on problems that are closer to the
real problems encountered in practical settings

Some references:
 Two SINTEF working papers by Bräysy, Gendreau,
Hasle, and Løkketangen
 Special issue of CEJOR (2006) edited by Hartl, Hasle,
and Janssens
 Several recent papers dealing with specific Rich VRPs
© Teodor Gabriel Crainic 2009
Rich VRP: Supply Side Extensions

Heterogeneous fleet

Variable travel times

Multiple routes

Multiple depots

Location-routing

Multi-compartment

Complex cost structure

Loading constraints
© Teodor Gabriel Crainic 2009
Rich VRP: Demand Side Extensions

Presence of backhauls

Pickup and delivery

Split deliveries

Periodic problems

Inventory routing

Dynamic and stochastic problems

Compatibility issues

Loading constraints
© Teodor Gabriel Crainic 2009
MDPVRP and MDPVRPTW

Multiple depots
 With

given number of homogeneous vehicles at each depot
Periodic problem
 Planning
 For

horizon of t “days” (periods)
each customer: a list of acceptable visit day “patterns”
Each customer must be assigned to a single depot and a single
pattern and routes must be constructed for each depot/pattern,
in such a way that the total cost of all the resulting routes is
minimized.
© Teodor Gabriel Crainic 2009
MDPVRP and MDPVRPTW: Literature Review

Integrated approach (Parthanadee and Logendran, 2006)
 Complex
variant of MDPVRPTW
 Customers
may be served from different depots on
different days
 Tabu

Search in which depot and pattern changes are made
Much more extensive literature exists on the MDVRP and the
PVRP (and their variants with time windows).
© Teodor Gabriel Crainic 2009
An Important Property

Any instance of the MDVRP(TW) can be transformed into an
instance of the PVRP(TW)
 By
clever redefinition of the allowed patterns
 Distances

to customers, however, become day-dependent
Similarly, any instance of the MDPVRP(TW) can be
transformed into a (much) larger instance of the PVRP(TW)
→ One can use the same solution procedure to solve the
PVRP(TW), the MDVRP(TW) and the MDPVRP(TW)!
© Teodor Gabriel Crainic 2009
An Important Property (2)

The previous property leads to a natural decomposition of the
MDPVRP(TW) into two subproblems:
 PVRP(TW)
→ Fix depot assignments
 MDVRP(TW)

→ Fix pattern assignments
We can use the same solvers as Partial Solvers for the two
subproblems and as Global Solver.
© Teodor Gabriel Crainic 2009
Solvers

Currently, we use two solvers:
A
local search solver based on the Unified Tabu Search
(UTS) procedure of Cordeau et al. (2001)
This solver handles instances with or without time
windows
A
new population search solver (HAPGA)
This solver only handles instances without time
windows (for the time being)
© Teodor Gabriel Crainic 2009
Solution Representation

For each customer:
 Depot
assignment
 Pattern

For each depot and each day:
 The

assignment
routes that are performed
Some solvers (HAPGA) also use a different representation at
some stages of the solution process
© Teodor Gabriel Crainic 2009
Solvers: UTS

Proposed by Cordeau et al. (1997, 2001)

A fairly straightforward Tabu search procedure based on the
GENI insertion procedure (Gendreau et al., 1992)

Infeasible solutions w.r.t. capacity and route length:
 Allowed,
 Critical
but penalized with self-adjusting penalties
for a good performance!

Handles time windows

Can be generalized easily to deal with MDPVRP(TW)
© Teodor Gabriel Crainic 2009
Solvers: HAPGA

New solver under development

HAPGA: Hybrid Adaptive Penalties Genetic Algorithm

A solver for the PVRP (and “equivalent” problems)

Combines two threads of ideas:

Prins’ (2002) memetic approach for the VRP
Solution representation, population management, …

Allowing infeasible solutions with respect to capacity and route
length constraint violations
With self-adjusting penalties as in UTS
© Teodor Gabriel Crainic 2009
The chromosome representation of VRP solutions is as
giant TSP tour covering customers without delimiters!
 Solutions are
extracted from
chromosome
using a SPLIT
procedure (shortest path problem on an auxiliary graph)
 “Standard” crossover operators
 Solution enhancement through local search

53
© Teodor Gabriel Crainic 2009
Illustration of
Prins’ Approach
54
© Teodor Gabriel Crainic 2009
HAPGA: Solution Representation

To handle periods, HAPGA maintains two chromosomes for
each solution:
 Route
chromosome
As in Prins’ approach
Maintains for each “day” the sequence of customer visits
“Days” are listed sequentially (with delimiters)
 Pattern
chromosome
Maintains for each customer the pattern chosen
(redundant information)
© Teodor Gabriel Crainic 2009
HAPGA: Solution Evaluation


Prins and his co-authors:

Enforce strict capacity and route duration constraints

Allow to violate the fleet size constraint

Easy SPP for SPLITTING giant tours
In HAPGA:

Capacity and route duration constraints are relaxed

Fleet size is strict

SPLIT (for each day) becomes an SPP with resource constraints

Can be extended to effectively handle heterogeneous fleets!
© Teodor Gabriel Crainic 2009
HAPGA: Selection

Each parent is selected through a binary tournament
 Select
 Keep

two individuals at random
the best one
Poor individuals have a very low probability of
reproducing
© Teodor Gabriel Crainic 2009
HAPGA: The PIX Crossover

PIX: Periodic crossover with Insertions

Creates a single offspring C from two parents P1 and P2

For each day t in the planning horizon, we chose randomly to:
 Copy
no customer visits from P1 into C
 Copy
all customer visits of day t from P1 into C
 Copy
a substring of customer visits of day t from P1
into C
© Teodor Gabriel Crainic 2009
HAPGA: The PIX Crossover

Parent P2 is then scanned sequentially and visits to
customers are added:
 On
days where all visits from P1 were not copied
 If
they are allowed by some pattern for the customer
considered
 If

the total number of visits to a customer is not exceeded
If some customers are missing visits, these are inserted
in random order and at minimum cost after performing
the SPLIT procedure
© Teodor Gabriel Crainic 2009
HAPGA: The PIX Crossover
60
© Teodor Gabriel Crainic 2009
HAPGA: Education

After creation, all children go through education

Two local search procedures:
 Route
improvement (RI)
Applies separately to each day
8 different moves (insertions, swaps, 2-opt, 2-opt*)
 Pattern
improvement (PI)
Applied on an individual customer basis
 Simple

descents
Applied in RI, PI, RI sequence
© Teodor Gabriel Crainic 2009
HAPGA: Repair Phase

Before education 30% of children (chosen randomly) are
“repaired” :
 By
setting their penalty weights very high
 Pushes
them back to feasibility
© Teodor Gabriel Crainic 2009
HAPGA: Population Management

Small population (10,000/n)

A single child produced in each iteration

Should replace the least “interesting” individual of the
population
 Different
ideas tried
 Experiments

still under way
Diversification: After 10,000 iterations without
improvement, replace 90% of the population
© Teodor Gabriel Crainic 2009
HAPGA: Infeasibility Management

The proportion ξ of feasible individuals is monitored

Penalty coefficients are updated every 200 iterations
 If
ξ ≤ 0.2, both coefficients are increased by 20%.
 If
ξ ≥ 0.3, both coefficients are decreased by 15%.
© Teodor Gabriel Crainic 2009
A MDPVRPTW Implementation

Three-population scheme:
 P0: “Global” population
 P1: Fixed patterns
 P2: Fixed depots

UTS implementations for
 Integrator & Global Solver: MDPVRPTW
 The 2 Partial Solvers for “subproblems”

Three copies of UTS for each population
65
© Teodor Gabriel Crainic 2009
A MDPVRPTW Implementation (2)

Integrator: when idle
 Select random in best in each partial population
 Pairs → triplets (customer, depot, pattern) → build
best routes (no change in pairs !)

Guidance: send best on improvement

Tested on instances created from the MDVRPTW and
PVRPTW instances of Cordeau et al. (2001)
66
© Teodor Gabriel Crainic 2009
Initial Results (20 instances out of 40)
No.
pr01b
pr02b
pr03b
pr04b
pr05b
pr06b
pr07b
pr08b
pr09b
pr10b
pr11b
pr12b
pr13b
pr14b
pr15b
pr16b
pr17b
pr18b
pr19b
pr20b
GUTS
2536,76
4622,78
5882,97
7085,11
8133,62
9384,1
5352,7
7890,22
11426,3
13555,6
2210,16
3949,45
5129,08
5652,3
6115,84
7436,69
5153,61
6906,79
9494,45
11331,1
Best
ICS
2457,47
4513,31
5822
7025,64
7823,75
9155,83
5334,61
7747,16
11264,9
13196,2
2166,16
3846,21
5077,59
5671,24
6029,28
7354,08
4954,64
6755,75
9389,05
11351,1
%
-3,13
-2,37
-1,04
-0,84
-3,81
-2,43
-0,34
-1,81
-1,41
-2,65
-1,99
-2,61
-1,00
0,34
-1,42
-1,11
-3,86
-2,19
-1,11
0,18
GUTS
2667,168
4723,013
6113,291
7518,133
8415,249
9545,122
5866,998
8057,079
11545,58
14102,9
2500,293
4113,193
5275,06
5834,044
6373,293
8233,508
5323,459
7148,461
10039,86
12529,28
Average
ICS
2487,084
4560,94
5889,186
7052,701
7984,21
9216,941
5346,14
7815,076
11342,5
13358,84
2203,722
3904,369
5102,555
5703,701
6100,656
7410,981
5090,012
6837,984
9493,532
11466,16
%
-6,75
-3,43
-3,67
-6,19
-5,12
-3,44
-8,88
-3,00
-1,76
-5,28
-11,86
-5,08
-3,27
-2,23
-4,28
-9,99
-4,39
-4,34
-5,44
-8,49
© Teodor Gabriel Crainic 2009
Initial Results (20 instances out of 40) (2)
No.
pr01b
pr02b
pr03b
pr04b
pr05b
pr06b
pr07b
pr08b
pr09b
pr10b
pr11b
pr12b
pr13b
pr14b
pr15b
pr16b
pr17b
pr18b
pr19b
pr20b
P-GUTS
2451,55
4513,68
5843,75
7012,79
7842,2
9119,34
5288,57
7737,29
11255,3
13292,7
2104,55
3876,04
5095,37
5686,64
6088,26
7316,19
4853,46
6769,81
9373,12
11403,2
Best
ICS
2457,47
4513,31
5822
7025,64
7823,75
9155,83
5334,61
7747,16
11264,9
13196,2
2166,16
3846,21
5077,59
5671,24
6029,28
7354,08
4954,64
6755,75
9389,05
11351,1
%
0,24
-0,01
-0,37
0,18
-0,24
0,40
0,87
0,13
0,09
-0,73
2,93
-0,77
-0,35
-0,27
-0,97
0,52
2,08
-0,21
0,17
-0,46
P-GUTS
2461,344
4531,748
5866,98
7035,81
7890,094
9156,675
5320,15
7765,598
11296,2
13342,58
2128,174
3890,99
5103,53
5704,57
6113,942
7421,524
4915,364
6848,514
9471,418
11470,54
Average
ICS
2487,084
4560,94
5889,186
7052,701
7984,21
9216,941
5346,14
7815,076
11342,5
13358,84
2203,722
3904,369
5102,555
5703,701
6100,656
7410,981
5090,012
6837,984
9493,532
11466,16
© Teodor Gabriel Crainic 2009
%
1,05
0,64
0,38
0,24
1,19
0,66
0,49
0,64
0,41
0,12
3,55
0,34
-0,02
-0,02
-0,22
-0,14
3,55
-0,15
0,23
-0,04
An Evolutionary ICS MDPVRP Illustration
3-population scheme as in other application
 HAPGA is used as Partial Solver, Global Solver and
Integrator
 For each population, 3 solvers:
 2 x HAPGA
 1 x UTS
 When HAPGA is used as Partial Solver, education does
not change the patterns corresponding to the “fixed”
attributes

69
© Teodor Gabriel Crainic 2009
An Evolutionary ICS MDPVRP Illustration (2)
Two Integrators: Random select in 25% best
1. 2 parents  extract depot and period patterns 
generate population  evolve  send best valid
2. 100 couples: crossover + educate & repair  send
best (valid)
 Guiding migration on partial population stalling
 Random generation of partial population +
 Random select & migrate 1 complete in 25% best

70
© Teodor Gabriel Crainic 2009
Test Instances

Derived from the set of instances used in the
MDPVRPTW implementation.
Inst
1
2
3
4
5
6
7
8
9
10
m
1
1
2
2
3
3
1
1
2
3
n
48
96
144
192
240
288
72
144
216
288
d
4
4
4
4
4
4
6
6
6
6
71
© Teodor Gabriel Crainic 2009
t
4
4
4
4
4
4
6
6
6
6
Preliminary Results
Gaps with respect to best known solutions:
HAPGA
1h00
1,61%
5 min
1,22%
3h00
0,92%
ICS no UTS
15 min
0,77%
P-HAPGA
3 x 1h00
0,83%
5 min
1,30%
30 min
0,60%
5 min
1,20%
ICS
15 min
1,01%
ICS no Guidance
15 min
0,79%
72
© Teodor Gabriel Crainic 2009
30 min
0,82%
30 min
0,66%
Planning and Uncertainty
Plan
 For a set of fixed routes that will be used repetitively
some time later for a given amount of time
 Within an environment where there is variability of
and uncertainty on future values of system
characteristics – demand – at planning time
 Important characteristics of desired plan:
 Flexibility: Planned routes can be adapted easily to
changes in the system environment (new information)
 Robustness: Planned routes do not need to be overly
adjusted given changes in the environment

73
© Teodor Gabriel Crainic 2009
A Case Study – the FPLQ
FPLQ assumes (by law) responsibility for the
transportation of milk from farms to processing plants,
producers assuming the costs
 FPLQ negotiates contracts with motor carriers within a
provincial convention
 3 main FPLQ processes
 Negotiation of contracts (year)
 Pickup photo (monthly adjustment)
 Assignment of routes (weekly adjustment)
 1 carrier process (!!): operate routes

74
© Teodor Gabriel Crainic 2009
Planning at FPLQ
Yearly negotiation of contracts with carriers
 On forecasts of milk production at farms and milk
demand at plants & last year plan
1. Assign farms to carriers, build routes, assign
routes to plants: depot  farms  plant
May be more complicated than that …
2. Price routes and negotiate rates with carriers
3. Mediate between FPLQ and carriers
 Contracts generated:
 97 carriers, 575 routes, 134 plants
 For a total of 77 050 rates (134 plants x 575 routes)

75
© Teodor Gabriel Crainic 2009
Adjusting the Plan

The “pickup” photo – monthly
 Select a 2-day period
 Observe
how routes are performed
 Obtain a detailed description of the quantity of milk
picked and delivered
 From these observation adjustments are defined for the
next month
 “Routing”, farm ↔ route/carrier
76
© Teodor Gabriel Crainic 2009
Adjusting the Plan (2)
Assignment of routes – weekly
 Plants send week requirements
 Adjust the plan for next week
 Routes ↔ Plants
 Distribute the milk supply through the various plants
in order to minimize transportation costs
 Balance (reconciliate) supply and demand

77
© Teodor Gabriel Crainic 2009
Adjusting the Plan (3)
The two adjustment processes not yet completely defined
 But they indicate the FPLQ follows the standard practice
of plan now and adjust later with revealed information
 The so-called a priori planning

Build an a priori plan:
Negotiation of contracts
Operate and adjust the
established a priori plan:
Pickup photo
Assignment of routes
Build a series of routes to be
assigned to carriers
tactical adjustments of
farms to routes
operational adjustments of
routes to plants
78
© Teodor Gabriel Crainic 2009
Planning Processes
A well-defined planning process
 Tools to build routes (with few attributes) “locally”
 No comprehensive planning methodology
 No capability for scenario/policy analysis
 No formal taking into account of future variability and
uncertainty

79
© Teodor Gabriel Crainic 2009
Planned Work to Address Uncertainty
Goals
 A “comprehensive” study of uncertainty and its
impact on planning
 Develop stochastic programming models and
methods to produce more flexible and robust plans
 Insight into form and characteristics of such plans
and, possibly, develop simpler but as efficient
solution approaches & policies
 For regular planning and strategic studies

80
© Teodor Gabriel Crainic 2009
Planned Work to Address Uncertainty (2)
Sources of uncertainty
 Farm production volumes
 Plant requirements
 Travel and service times
 Disruptions
 Information process(es)
 Farm and plant (regular, uncoordinated) updates
 Actual availability at farms

81
© Teodor Gabriel Crainic 2009
Planned Work to Address Uncertainty (3)
Recovery and adjustment practices = the recourse(s)
 The decision process(es)
 Independent participants – farms, plants
 Routes operated very independently – carriers
 Will the plan be permanently modified at some point
in the future (when?, how?)?
 Modeling – stochastic programming
 Recourse formulations
 Decision stages: two or multiple
 Probabilistic constraints to bound the risk
 Solution methods – stochastic programming

82
© Teodor Gabriel Crainic 2009
ICS for Planning Under Uncertainty
Adapting ICS: A rich research program 
 Decomposition strategy
 Functional (attributes) decomposition
 Domain decomposition
 Scenario decomposition
 Which problems for the partial solvers?
 Which problems for integrators?
 Evolution & guidance?

83
© Teodor Gabriel Crainic 2009
Planned Work to Address Uncertainty(4)
The value of explicit inclusion of uncertainty factor into
planning models
 Insight into form and characteristics of “stochastic”
solutions
 Deterministic solution methods building on this insight?
 “Solving” with a “few” appropriate scenarios? …

84
© Teodor Gabriel Crainic 2009
Conclusions & Perspectives
Rich (combinatorial optimization) problems present
interesting challenges and opportunities
 Parallel cooperation performs very well
 ICS appears promising when complexity grows
 Still a lot of work on all aspects of the approach and
applications

85
© Teodor Gabriel Crainic 2009
Questions from the field: Did you know…

One cow produces enough milk to satisfy the annual
milk and dairy product needs of 30 people

It takes 11 litres of milk to make 1 kilogram of cheese
86
© Teodor Gabriel Crainic 2009