Solvers

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


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


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


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


Rich VRP

 Vehicle routing in practice

 Attributes of several generic problems



Complex “cost” functions

8


The Journey of Milk

…..

9


10


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


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


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


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


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



(3)

 VRPTW (Berger & Barkaoui, 2004)

 Evolved two populations

 Minimize total travel time

 Minimize temporal violations

16


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


Controlled Direct Exchange Mechanisms

Search r

Search j

Search k

Search i

Search h

18


Search l

Direct Exchange Mechanisms: Diffusion

Search j

Search r

Search k

Search i

Search h

19


Search l

Indirect, Memory-based Exchange Mechanisms

Search j

Search i

Search k

Memory, Pool

Reference Set

Elite Set

Data Warehouse

20


Search l

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



(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



(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


ICS Fundamental Ideas & Concepts

 Decomposition by attribute

 Concurrent population evolution

 Solver specialization

 Cooperation with self-adjusting and guidance features

24


Shared-Memory ICS

Integrator Integrator

Partial

Solutions

(set A)

Partial

Solutions

(set B)

Complete

Solutions

Partial

Solvers (set A)

Partial

Solver (set A)

Partial

Solvers (set B)

Partial

Solver (set B)

25


Global

Search

Coordinator

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



(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



(3)

 Issues and challenges

 Homogeneous vs. heterogeneous population

 Purposeful evolution of partial solutions

 Reconstruction & improvement of complete solutions

28


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


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


Integrative Crossover population

P’ of elite partial solutions

Partial solution selection operators

Integrative crossover operators

Mutation/

Education

Admissible selection operators population

P of complete solutions

31


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


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


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


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


Global Search Coordinator – Monitoring

 Pools / populations

 Complete solutions (direct)

 Partial solutions (& integrators) (direct or indirect)

 Exchanges / communications (possibly)

36



(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



(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


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


ICS Concurrent Evolution set S

1 of partial solvers population

P

1 of partial solutions set S

2 of partial solvers set S

3 of partial solvers population

P

2 of partial solutions population

P

3 of partial solutions population

P’ of elite partial solutions

Selective migration Guiding migration

Evolution Integrative evolution set S of solvers global monitoring

& guidance set I of integrators global evolution guiding-migration operators

40

© Teodor Gabriel Crainic 2009 population

P of complete solutions

Zoom on Partial Solver Organization

GA

1 partial solver

Legend

Selective migration

Evolution

Guiding migration

GA

2 partial solver population

P i of partial solutions

TS

1 partial solver

TS

2 partial solver

41


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


Rich VRP: Supply Side Extensions

 Heterogeneous fleet

 Variable travel times

 Multiple routes

 Multiple depots

 Location-routing

 Multi-compartment

 Complex cost structure

 Loading constraints


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


MDPVRP and MDPVRPTW

 Multiple depots

 With given number of homogeneous vehicles at each depot

 Periodic problem

 Planning horizon of t

“days” (periods)



For 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.


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).


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)!


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.


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)


Solution Representation

 For each customer:

 Depot assignment

 Pattern assignment

 For each depot and each day:

 The routes that are performed

 Some solvers (HAPGA) also use a different representation at some stages of the solution process


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, but penalized with self-adjusting penalties

 Critical for a good performance!

 Handles time windows

 Can be generalized easily to deal with MDPVRP(TW)


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


 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


Illustration of

Prins’ Approach


54

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)


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!


HAPGA: Selection

 Each parent is selected through a binary tournament

 Select two individuals at random

 Keep the best one

 Poor individuals have a very low probability of reproducing


HAPGA: The PIX Crossover

 PIX: Periodic crossover with Insertions

 Creates a single offspring C from two parents P 1 and P 2

 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 P

1 into C

 Copy a substring of customer visits of day t from P

1 into C



 Parent P 2 is then scanned sequentially and visits to customers are added:

 On days where all visits from P 1 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



60


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


HAPGA: Repair Phase

 Before education 30% of children (chosen randomly) are

“repaired” :

 By setting their penalty weights very high

 Pushes them back to feasibility


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


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%.


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


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


Initial Results

(20 instances out of 40)

No.

GUTS

Best

ICS % pr01b 2536,76 2457,47 -3,13 pr02b 4622,78 4513,31 -2,37 pr03b 5882,97 5822 -1,04 pr04b 7085,11 7025,64 -0,84 pr05b 8133,62 7823,75 -3,81 pr06b pr07b

9384,1 9155,83 -2,43

5352,7 5334,61 -0,34 pr08b 7890,22 7747,16 -1,81 pr09b 11426,3 11264,9 -1,41 pr10b 13555,6 13196,2 -2,65 pr11b 2210,16 2166,16 -1,99 pr12b 3949,45 3846,21 -2,61 pr13b 5129,08 5077,59 -1,00 pr14b 5652,3 5671,24 0,34 pr15b 6115,84 6029,28 -1,42 pr16b 7436,69 7354,08 -1,11 pr17b 5153,61 4954,64 -3,86 pr18b 6906,79 6755,75 -2,19 pr19b 9494,45 9389,05 -1,11 pr20b 11331,1 11351,1 0,18

GUTS

Average

ICS %

2667,168 2487,084 -6,75

4723,013 4560,94 -3,43

6113,291 5889,186 -3,67

7518,133 7052,701 -6,19

8415,249 7984,21 -5,12

9545,122 9216,941 -3,44

5866,998 5346,14 -8,88

8057,079 7815,076 -3,00

11545,58 11342,5 -1,76

14102,9 13358,84 -5,28

2500,293 2203,722 -11,86

4113,193 3904,369 -5,08

5275,06 5102,555 -3,27

5834,044 5703,701 -2,23

6373,293 6100,656 -4,28

8233,508 7410,981 -9,99

5323,459 5090,012 -4,39

7148,461 6837,984 -4,34

10039,86 9493,532 -5,44

12529,28 11466,16 -8,49


Initial Results

(20 instances out of 40) (2)

No.

P-GUTS

Best

ICS % pr01b 2451,55 2457,47 0,24 pr02b 4513,68 4513,31 -0,01 pr03b 5843,75 5822 -0,37 pr04b 7012,79 7025,64 0,18 pr05b 7842,2 7823,75 -0,24 pr06b 9119,34 9155,83 0,40 pr07b 5288,57 5334,61 0,87 pr08b 7737,29 7747,16 0,13 pr09b 11255,3 11264,9 0,09 pr10b 13292,7 13196,2 -0,73 pr11b 2104,55 2166,16 2,93 pr12b 3876,04 3846,21 -0,77 pr13b 5095,37 5077,59 -0,35 pr14b 5686,64 5671,24 -0,27 pr15b 6088,26 6029,28 -0,97 pr16b 7316,19 7354,08 0,52 pr17b 4853,46 4954,64 2,08 pr18b 6769,81 6755,75 -0,21 pr19b 9373,12 9389,05 0,17 pr20b 11403,2 11351,1 -0,46

P-GUTS

Average

ICS

2461,344 2487,084

4531,748 4560,94

5866,98 5889,186

7035,81 7052,701

7890,094 7984,21

9156,675 9216,941

5320,15 5346,14

7765,598 7815,076

11296,2 11342,5

13342,58 13358,84

2128,174 2203,722

3890,99 3904,369

5103,53 5102,555

5704,57 5703,701

6113,942 6100,656

7421,524 7410,981

4915,364 5090,012

6848,514 6837,984

9471,418 9493,532

11470,54 11466,16

%

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


An Evolutionary ICS MDPVRP Illustration

(2)

 Two Integrators: Random select in 25% best

1.

2.

2 parents

 extract depot and period patterns

 generate population

 evolve

 send best valid

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


Test Instances

 Derived from the set of instances used in the

MDPVRPTW implementation.

6

7

4

5

Inst

1

2

3

8

9

10

3

1

2

3 m

1

1

2

1

2

3

192

240

288

72 n

48

96

144

144

216

288

4

6

4

4 d

4

4

4

6

6

6

4

6

4

4 t

4

4

4

6

6

6

71


Preliminary Results

Gaps with respect to best known solutions:

1h00

1,61%

5 min

1,22%

HAPGA

3h00

0,92%

ICS no UTS

15 min

0,77%

P-HAPGA

3 x 1h00

0,83%

30 min

0,60%

5 min

1,30%

5 min

1,20%

ICS

15 min

1,01%

ICS no Guidance

15 min

0,79%

30 min

0,82%

30 min

0,66%

72


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


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


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


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



(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



(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


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


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



(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



(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


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



(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


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


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


Solvers

Related documents

Products

Support

Solvers

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib