CrewGroups Recent Development and Plans for the Future

1. CrewGroupsRecent Development and Plans for the Future Presentation at SweConsNet´03 Tomas Lidén Carmen Consulting AB tomas.liden@carmenconsulting.com

2. Outline • Introduction • Constraints and costs • Program flow, search algorithm • Discussion, future plans

3. Background Normal scheduling (rostering) - Each flight has different crew + Greater flexibility Group scheduling (rostering) + Same crew fly together for a month - Less flexibility

4. CrewGroups on One Page • Problem: Construct homogenous groups (flight cabin crew) • Characteristics: Assignment, non-additive costs • Developed during 2001 for IberiaIn production since spring 2002Further developed regarding December functionality in fall 2002 • Currently a CP application using ILOG Solver with set variables, one customized constraint, global & local search • Thesis work on alternative techniques. Column generation yields better performance and slightly better solution quality. Porting currently discussed (without CP).

5. One Group per purser • cost function and most constraints defined here • accessors used to collect data from SubGroup duringsolution search Set variables SubGroup One per buddy bid, single purser and cabin attendant - aggregated data, checks on bids Crew Input data Structure Group Days handled with set variables. Historic values handled with integer variables. Cost and constraints applied on the above variables. Normally construct min nr of groups, but in December construct all possible

6. Assignment Constraints • Crew in buddy bid always assigned to a group • Crew in buddy bid always kept together • Exception in December • Do not combine certain crew (“anti bids”)

7. Simple Constraints • Max nr of inexperienced per group • Max nr of crew in transition course • etc

8. Inhomogenous Will give cost Can be limited with additional constraint Handling of Days • Consider size? Normally – no December – yes • Constraint for max nr of days off • Pattern constraint for days off ( _ _ _ x..x _ _ _ ) • Analogue handling of days with preassigned duties

9. Inhomogenous Will give cost Can be limited with additional constraint Handling of Historic Values • Size always considered

10. Inhomogenous Will give cost Handling of Work Reduction • Size not considered • Never higher than the purser (constraint)

11. Extremely bad! Will give high cost Special handling in December - 1 • Day 32 (Jan 1st) considered for fairness – work over Christmas and New Years Eve. • Buddy bids split due to day 32 • Much lower cost if split bids are rejoined in same group ( X = Y )

12. Favour matching days (through cost) Size considered Special handling in December - 2

13. Added in hierarchical order Removed again if no solution found Iterate to minimize total cost Add cost constraints for expensive groups Pick groups pairwisePerform complete enumeration Program flow - Solve problem Add hard constraints and find solution Add/remove all additional constraints and find solution Global search for cheaper solution Local search for cheaper solution Print and analyze results

14. Search heuristic, Global search Select a group (variable) • Already used and buddy bids • Factor x affecting difficulty and cost • … Select a subgroup (value) to assign • Size and buddy bids • Factor y affecting difficulty and cost • … • Depth first • Many factors to consider • tradeoff between low cost (=quality) and difficulty (=solvability) • Each new factor affects the search algorithm! • Not clear how sensible algorithm is for different weights

15. More problems in December • All groups must be produced – longer execution times. • Special search algorithm needed! • Handling of rejoined bids hard. Too greedy search will not find possible solutions. Ungreedy search will miss good rejoinings (=worse solution quality) • A pure CP application should have a better local search. Tabu?

16. Generate (CP?) Duals Columns Solve LP Solve IP Column generation • Benefits • faster (4-6 times for large problems) • better (5-10% lower cost, even more in December) • more stable (less sensitive for weights and new factors) • CP not needed for generation… • Constraints = column legality • Cost straightforward to calculate • Domain reduction (for quicker generation) can easily be implemented • Porting/rewriting considered…

17. Yes, but can be treated as legality and column cost Discussion, CP suitable or not? • Initial arguments • tricky constraints • non-additive, non-linear cost • unclear problem • few possible solutions • Current opinion • Works ok, but not the best • ColGen better, hybrid solver perhaps optimal • Challenging problem for CP+local search? Yes, good during modelling and development No!

18. END Thank you for your attention! Questions?