Algorithms for Container Loading Problems

by

ZHU, Wenbin

A Thesis Submitted to
The Hong Kong University of Science and Technology
in Partial Fulfillment of the Requirements for
the Degree of Doctor of Philosophy
in Computer Science and Engineering

September 2012, Hong Kong

HKUST Library
Reproduction is prohibited without the author’s prior written consent
 Acknowledgements

First of all, I would like to express my gratitude to my advisor, Prof. Siu-Wing Cheng,
who changed my attitude towards research for the better. When I submitted the first
draft of my proposal (that was full of mistakes) to him, he literally edited it word by
word, sentence by sentence, and challenged almost every idea. I was shocked by his
stringent requirements and commitment to academic integrity. It was then that I realized
how important it is to be critical and careful in research, and this change in attitude has
benefitted me greatly ever since. He also provided very helpful feedback and pointed me
to the right references on the technical problems I encountered.
I am grateful to Prof. Papadias, Dr. Li, Dr. Qi and Dr. Yi for serving on my thesis
committee.
I would also like to express my gratitude to my former co-advisor, Prof. Andrew Lim.
He provided continued financial support for my research activities and allowed me to
participate in many real word projects that eventually led to this thesis. He also provided
valuable advice on research directions. On a few occasions, I almost gave up my research
after prolonged frustration, and it was his encouragement and support that enabled me
to persevere and eventually finish the tasks at hand.
Special thanks goes to one of my collaborators, Dr. Wee-Chong Oon. He was an
excellent collaborator, who is critical, thoughtful and very enthusiastic for the subjects
on which we collaborated. The many heated arguments with him inspired an array of
new ideas. He also has superb presentation skills and provided valuable advice on the
organization and presentation of this thesis.
I would like to thank my other collaborators Mr. Weili Huang, Mr. Lijun Wei, Mr.
Yujian Weng and Mr. Zhaoyi Zhang for their support in the various projects that I was
involved and their valuable feedback. I also would like to thank my co-authors Dr. Chan
Hou Che, Ms. Brenda Cheang, Mr. Xiang Gao, Mr. Qian Hu, Mr. Bo Jin, Mr. Zhixing
Luo, Dr. Hu Qin, Miss Ning Wang, Dr. Zhou Xu, and Mr. Zizhen Zhang. I would further
like to thank my colleagues and friends, Mr. Yibo Chen and Miss Tian Tian.
Finally, I would like to thank my beloved wife, Ms. Yu Chen. Her encouragement and
understanding is a continuous source of mental support that helped me through the bleak
moments.

iv
Contents

Title Page i

Authorization Page ii

Signature Page iii

Acknowledgements iv

Table of Contents v

List of Figures xii

List of Tables 1

Abstract 1

1 Introduction 2
1.1 Background and Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Important Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2.1 Dimensionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2.2 Guillotine-Cut Constraint . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3 Full Support Constraint . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2.4 Heterogeneity of Box Assortment . . . . . . . . . . . . . . . . . . . 8
1.2.5 Other Issues in Container Loading Problems . . . . . . . . . . . . . 11
1.3 Problem Definitions and Related Problems . . . . . . . . . . . . . . . . . . 12
1.3.1 Classification Under Standard Typology . . . . . . . . . . . . . . . 13
1.4 Existing Algorithms for SCLP, MCLCMP and 3D-BPP . . . . . . . . . . . 14
1.4.1 Existing Algorithms for SCLP . . . . . . . . . . . . . . . . . . . . . 14

v
 1.4.2 Existing Algorithms for MCLCMP . . . . . . . . . . . . . . . . . . 15
1.4.3 Existing Algorithms for 2D/3D BPP . . . . . . . . . . . . . . . . . 16

2 Algorithms for the Single Container Loading Problem 18

2.1 Iterative-Doubling Greedy Look Ahead (ID-GLA) Tree Search Algorithm . 19
2.1.1 Maximal Space Representation of Free Space . . . . . . . . . . . . . 19
2.1.2 Block Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.1.3 Greedy d-step Look Ahead Tree Search . . . . . . . . . . . . . . . . 24
2.1.4 Ranking Placements . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.5 Iterative Doubling of Search Effort . . . . . . . . . . . . . . . . . . 29
2.2 Handling the Full Support Constraint . . . . . . . . . . . . . . . . . . . . . 31
2.2.1 Generating Fully Supported Blocks . . . . . . . . . . . . . . . . . . 31
2.2.2 Generating Fully Supported Residual Spaces . . . . . . . . . . . . . 32
2.3 A Conceptual Model for Analyzing Block Building Approaches . . . . . . . 34
2.3.1 Free Space Representation and Management Techniques (E1) . . . . 36
2.3.2 Candidate Blocks Generation (E2) . . . . . . . . . . . . . . . . . . 40
2.3.3 Residual Space Selection (E3) . . . . . . . . . . . . . . . . . . . . . 44
2.3.4 Candidate Block Selection (E4) . . . . . . . . . . . . . . . . . . . . 45
2.3.5 Asymmetry in Space and Block Selection . . . . . . . . . . . . . . . 46
2.3.6 Search Strategy (E6) . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.4 Test Instances and Experimental Setup . . . . . . . . . . . . . . . . . . . . 50
2.5 Calibration of ID-GLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.5.1 Impact of Residual Space Representation and Management (E1,E5) 53
2.5.2 Impact of Using Various Block Types (E2) . . . . . . . . . . . . . . 55
2.5.3 Impact of Ranking Functions for Residual Space Selection (E3) . . 60
2.5.4 Impact of Fitness Measure for Block Selection (E4) . . . . . . . . . 61
2.5.5 Impact of Overarching Search Strategy (E6) . . . . . . . . . . . . . 62
2.5.6 Multi-Best-Space Scheme vs Single-Best-Space Scheme . . . . . . . 65
2.6 Computational Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 68
2.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73

3 Algorithms for the Multiple Container Loading Problem 75

3.1 Set Cover Formulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

vi
 3.1.1 Loading Factor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.2 Set Cover Based Binary Search (SCBS) Algorithm . . . . . . . . . . . . . . 79
3.2.1 Binary Search on Loading Factor . . . . . . . . . . . . . . . . . . . 80
3.2.2 Strategies for Generating Packing Patterns . . . . . . . . . . . . . . 82
3.3 Prototype Column Generation . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.1 Preliminaries on Column Generation Techniques . . . . . . . . . . . 89
3.3.2 Prototype Column Generation Algorithm . . . . . . . . . . . . . . . 91
3.3.3 Generating Candidate Prototypes . . . . . . . . . . . . . . . . . . . 96
3.3.4 Realizing Prototypes . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.4 Goal-driven Prototype Column Generation . . . . . . . . . . . . . . . . . . 97
3.4.1 Goal-driven Search . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5 Handling the Full Support Constraint and Limited Supply of Containers . 101
3.5.1 Full Support Constraint . . . . . . . . . . . . . . . . . . . . . . . . 101
3.5.2 Limited Supply of Containers . . . . . . . . . . . . . . . . . . . . . 102
3.6 Test Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.6.1 The 47 IMM 3D Bin Packing Instances . . . . . . . . . . . . . . . . 104
3.6.2 350 New MTC Instances with Known Optimal Solutions . . . . . . 105
3.6.3 190 GP Instances Based on Real Orders . . . . . . . . . . . . . . . 111
3.7 Computational Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.7.1 Calibration of SCBS . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.7.2 Calibration of GD-PCG . . . . . . . . . . . . . . . . . . . . . . . . 116
3.7.3 Calibration of PCG . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.7.4 Comparisons on IMM 3D Bin-Packing Instances . . . . . . . . . . . 125
3.7.5 Results of SCBS on MTC Instances . . . . . . . . . . . . . . . . . . 127
3.7.6 Comparison between SCBS, PCG and GD-PCG on MTC Instances 129
3.7.7 GD-PCG results on 190 GP instances . . . . . . . . . . . . . . . . . 131
3.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131

4 Algorithms for 2D/3D Bin Packing Problems 134

4.1 Space Defragmentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.2 A Constructive Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.1 The Extreme Point Insertion Heuristic . . . . . . . . . . . . . . . . 140
4.2.2 Two Enhancements to Extreme Point Insertion . . . . . . . . . . . 141

vii
 4.3 Bin Shuffling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.4 Space Defragmentation by Visibility Graphs . . . . . . . . . . . . . . . . . 147
4.5 Test Instances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.5.1 Standard Bin Packing Instances . . . . . . . . . . . . . . . . . . . . 149
4.5.2 New Bin Packing Instances . . . . . . . . . . . . . . . . . . . . . . 150
4.6 Computational Experiments . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.6.1 Effectiveness of Space Defragmentation . . . . . . . . . . . . . . . . 152
4.6.2 Component Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.6.3 Convergence Over Time . . . . . . . . . . . . . . . . . . . . . . . . 154
4.6.4 Comparison with Existing Algorithms on Standard Instances . . . . 154
4.6.5 Comparison with Hybrid GRASP/VND on New Instances . . . . . 163
4.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164

5 Conclusion 166
5.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.2 Future Research . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168

Bibliography 170

viii
List of Figures

1.1 Floor loading; Pallet Loading (image from Internet) . . . . . . . . . . . . . 3

1.2 Empty pallet; loaded pallet (image from Internet) . . . . . . . . . . . . . . 3
1.3 An example of 2-stage guillotine-cut . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Divider sheets; straps; wrapping (image from Internet) . . . . . . . . . . . 7
1.5 Air bags; void filler (image from the Internet) . . . . . . . . . . . . . . . . 8

2.1 Three residual spaces that form a cover of the free space . . . . . . . . . . 20
2.2 A placed block b overlaps with residual space r . . . . . . . . . . . . . . . . 20
2.3 Classes of blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.4 Combining two blocks along the length direction of the container . . . . . . 24
2.5 Two-step look ahead with branching factor m = 3 . . . . . . . . . . . . . . 25
2.6 Anchor distances between a residual space and the container . . . . . . . . 28
2.7 Combining two fully supported blocks along the length direction . . . . . . 32
2.8 Combining two fully supported blocks along the height direction . . . . . . 33
2.9 r0 is the residual space corresponding to the top face of block b . . . . . . . 33
2.10 A single block placed in the container . . . . . . . . . . . . . . . . . . . . . 37
2.11 Six possible partitions of the residual space . . . . . . . . . . . . . . . . . . 37
2.12 Columns and layers are special subsets of simple blocks . . . . . . . . . . . 41
2.13 G4 Heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.14 Calculating best fit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.15 An example of PCTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.16 Volume utilization of best solutions by ID-GLA using various residual space
representations, averaged over the first 10 instances of test sets BR1-15 . . 55
2.17 Average block count over the first 10 instances of test sets BR0-BR15 . . . 57
2.18 Average box count per block averaged over the first 10 instances of test
sets BR0-BR15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58

ix
2.19 Volume utilization of best solutions by ID-GLA using different types of
candidate blocks, averaged over the first 10 instances of test sets BR1-15 . 59
2.20 ID-GLA base version (SB GB) vs ID-GLA using SB or GB alone: volume
utilization of best solutions, averaged over the first 10 instances of test sets
BR1-15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.21 Volume utilization of best solutions by ID-GLA using various space selec-
tion strategies, averaged over the first 10 instances of test sets BR1-15 . . . 62
2.22 Volume utilization of best solutions by ID-GLA using various volume-fit
block selection strategies, averaged over the first 10 instances of test sets
BR1-15 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
2.23 Volume utilization of best solutions by various search strategies, averaged
over the first 10 instances of test sets BR1-15 . . . . . . . . . . . . . . . . 65
2.24 Volume utilization of best solutions found by ID-GLA using various search
depths, averaged over the first 10 instances of test sets BR1-15 . . . . . . . 65
2.25 Convergency behavior of the different space selection strategies . . . . . . . 69

3.1 A possible arrangement of 5 boxes where the removal of the middle box
(shaded) leads to partial support of box 4. Since this is the only possible
arrangment (up to symmetry) of boxes 1 - 4, there is no full support solution. 78
3.2 G4-heuristic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.3 A wall is a vertical layer of boxes against W × H face . . . . . . . . . . . . 84
3.4 Two ways of generating residual spaces . . . . . . . . . . . . . . . . . . . . 85
3.5 Partitions for two containers . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.6 Performance of various search strategies on loading factor α. Average gap
to optimal is reported for each iteration of the middle loop of GD-PCG . . 119
3.7 Performance of various settings of γ. Average gap to optimal is reported
for each iteration of the middle loop of GD-PCG . . . . . . . . . . . . . . . 120
3.8 Impact of GoalDrivenSearch on overall performance. Average gap to
optimal is reported for each iteration of the middle loop of GD-PCG . . . . 121
3.9 Performance of various settings for CPLEX time limit. Average gap to
optimal is reported for each iteration of the middle loop of GD-PCG . . . . 122
3.10 Performance of various settings for SCLP time limit. Average gap to opti-
mal is reported for each iteration of the middle loop of GD-PCG . . . . . . 124

x
4.1 Example of space defragmentation . . . . . . . . . . . . . . . . . . . . . . . 135
4.2 A packing pattern and its X-comparability graph . . . . . . . . . . . . . . 136
4.3 Extreme points . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.4 Inflate-and-Replace Operator . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.5 Motivation for Bin Shuffling Strategy . . . . . . . . . . . . . . . . . . . . . 145
4.6 Conservativeness of comparability graph . . . . . . . . . . . . . . . . . . . 148
4.7 Visibility graph representation . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.8 Constructing 3D visibility graphs takes Ω(n2 ) time . . . . . . . . . . . . . 149
4.9 4 categories of item sizes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.10 Improvement of solution quality over time . . . . . . . . . . . . . . . . . . 155

xi
List of Tables

2.1 Chracteristics of 1600 BR test instances . . . . . . . . . . . . . . . . . . . 52

2.2 Volume utilization of best solutions by ID-GLA using various residual space
representations, averaged over the first 10 instances of test sets BR0-15 . . 54
2.3 Average block count over the first 10 instances of test sets BR0-BR15 . . . 56
2.4 Average box count per block over first 10 instances of test sets BR0-15 . . 57
2.5 Volume utilization of best solutions by ID-GLA using various types of can-
didate blocks, averaged over the first 10 instances of test sets BR0-15 . . . 58
2.6 Volume utilization of best solutions by ID-GLA using various space selec-
tion strategies, averaged over the first 10 instances of test sets BR0-15 . . . 61
2.7 Volume utilization of best solutions by ID-GLA using various block selec-
tion strategies, averaged over the first 10 instances of test sets BR0-15 . . . 63
2.8 Volume utilization of best solutions by various search strategies, averaged
over the first 10 instances of test sets BR0-15 . . . . . . . . . . . . . . . . 64
2.9 Volume utilization of best solutions by ID-GLA using various search depths,
averaged over the first 10 instances of test sets BR0-15 . . . . . . . . . . . 66
2.10 Comparison of space selection strategies on 160 BR instances . . . . . . . . 67
2.11 Comparison on 1600 BR instances, without full support constraint . . . . . 71
2.12 Comparison on 1600 BR instances with full support constraint . . . . . . . 72

3.1 Probability of combination selection . . . . . . . . . . . . . . . . . . . . . . 86

3.2 The bin packing problems IMM01-47 . . . . . . . . . . . . . . . . . . . . . 106
3.3 Container types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.4 Valid combinations of K400 and K400 h to ensure optimality of known solution110
3.5 Valid combinations of K200 , K400 and K400 h to ensure optimality of known
solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.6 Summary of MTC Instances . . . . . . . . . . . . . . . . . . . . . . . . . . 111

xii
3.7 Average gap to optimal for various strategies under different random seeds 114
3.8 Overall performance of various combinations of R and α0 . . . . . . . . . . 115
3.9 Effect of R and α0 broken down by random seed . . . . . . . . . . . . . . . 116
3.10 Gap to optimal obtained by R = 5, α0 = 0.01 using various random seeds . 117
3.11 Impact of GoalDrivenSearch on overall performance . . . . . . . . . . 121
3.12 Impact of CPLEX time limit on overall performance . . . . . . . . . . . . . 122
3.13 Impact of SCLP time limit on overall performance . . . . . . . . . . . . . . 124
3.14 Results on bin packing problems IMM01-47 without full support constraint;
SCBS uses seed 11; new best solutions are in bold; worse solutions are in
italics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.15 Results on bin packing problems IMM01-47 with full support constraint;
new best solutions are in bold. . . . . . . . . . . . . . . . . . . . . . . . . . 128
3.16 Results of SCBS on MTC instances . . . . . . . . . . . . . . . . . . . . . . 129
3.17 Computational results on MTC instances (without full support constraint) 130
3.18 Computational results on MTC instances (with full support constraint) . . 131
3.19 Computational results on GP instances (based on real data) . . . . . . . . 132

4.1 EP-Insert-SD vs EP-FFD using various sorting rules . . . . . . . . . . . 153

4.2 Effect of components of BS-EPSD . . . . . . . . . . . . . . . . . . . . . . 154
4.3 Computational environments of various bin packing algorithms . . . . . . . 155
4.4 Comparison at class level with existing approaches on 2D and 3D instances 156
4.5 Comparison at group level on the 6 classes of 2D instances by [1] . . . . . . 158
4.6 Comparison at group level on the 4 classes of 2D instances by [2] . . . . . . 159
4.7 Comparsion at group level on 8 classes of 3D instances by [3] . . . . . . . . 160
4.8 Comparison at class level with hybrid GRASP/VND on 2D instances . . . 162
4.9 Comparison at class level with hybrid GRASP/VND on 3D instances . . . 162
4.10 Summarized results for Type 1 and Type 2 instances . . . . . . . . . . . . 163
4.11 Summarized results for Type 3 instances . . . . . . . . . . . . . . . . . . . 164

xiii
 Algorithms for Container Loading Problems

by ZHU, Wenbin
Department of Computer Science and Engineering
The Hong Kong University of Science and Technology

Abstract

The problems examined originate from industrial projects. In one project, our team was
contracted by a buying agent for a large multi-national retailer to investigate better ways
to formulate packing plans for the loading of goods into multiple containers. Typically,
the goods come in the form of 3D rectangular carton boxes, which are to be loaded into
3D rectangular containers of various standard sizes. Each type of container has a different
associated cost of shipping. The task is to select a set of containers that can contain all
items while minimizing this shipping cost. We call this problem the Multiple Container
Loading Cost Minimization Problem (MCLCMP).
If a set of boxes can be loaded into a container, we call the set of boxes and the
associated container a loading pattern. MCLCMP can be naturally formulated as a
set cover problem, where the set to be covered is the set of all boxes and a loading
pattern “covers” a subset of boxes. We would like to select loading patterns from a set of
candidates to cover all boxes while minimizing the total cost of the associated containers.
Our approaches to the MCLCMP are essentially two-level approaches. The burden of
finding feasible loading patterns is left to the algorithms for the Single Container Loading
Problem (SCLP).
We first develop efficient algorithms for the SCLP, and then proceed to devise three
set cover based algorithms for the MCLCMP in increasing order of sophistication and
effectiveness. The special case of the MCLCMP where all containers are identical is the
well-known 3D bin packing problem (3D-BPP); we propose a new algorithm that exploits
specific features of the 3D-BPP. Computational experiments on benchmark data suggest
that our new algorithms for the SCLP, MCLCMP and 3D-BPP outperform all prior
approaches.

1
Chapter 1

Introduction

1.1 Background and Motivation

The problems examined in this thesis originate from industrial projects awarded to our
research team by various companies in Hong Kong and mainland China. In one project,
our team was contracted by a buying agent for a large multi-national retailer to investigate
better ways to formulate packing plans for the loading of goods into multiple containers.
The agent’s procurement department is responsible for ordering products from manufac-
turers located in Asia, inspecting the products to ensure quality, and finally shipping the
products to retail stores spread across Europe. As a result, one of the procurement de-
partment’s tasks is to arrange the products for shipping. Typically, the goods come in the
form of 3D rectangular carton boxes. They are loaded into 3D rectangular containers of
various standard sizes. Each type of container has a different associated cost of shipping.
The task is to select a set of containers that can contain all items while minimizing this
shipping cost. Products are loaded with faces parallel to the faces of the container, often
known as orthogonal packing in literature.
There are two loading modes: floor loading and pallet loading. In floor loading, carton
boxes are loaded directly onto the floor of the container, typically by hand (see Figure
1.1(a) 1 ). It is modeled as the multiple container loading cost minimization problem
(MCLCMP) and it is the subject of study in Chapter 3.
In pallet loading, cartons are first loaded onto pallets (Figure 1.2(a) 2 ), and the pallets
are then loaded into containers by folklift (see Figure 1.1(b) 3 ). Figure 1.2(b) 4 shows
a pallet loaded with carton boxes. A few types of pallets (with slightly different base
areas) are commonly employed in the shipping industry, but usually only one type of
pallet is used in a single shipment. The base area of standard pallets have been designed
to efficiently cover the floor of the container. The optimal way of loading pallets into
1
http://image.made-in-china.com/6f3j00uMFEstgmgabI/Container-Loading.jpg
2
http://woodenpalletsforsale.com/2011/03/23/what-type-of-pallet-do-i-need-for-the-
products-i-ship/
3
http://www.containershipinfo.com/wp-content/uploads/2011/10/container-loading1.jpg
4
http://www.dreamstime.com/stock-image-cardboard-boxes-on-pallet-image17358351

2
 (a) Floor loading (b) Pallet loading

Figure 1.1: Floor loading; Pallet Loading (image from Internet)

(a) Empty pallet (b) Loaded pallet

Figure 1.2: Empty pallet; loaded pallet (image from Internet)

containers are known (or can be easily computed in advance); for example, 11 pallets
with base area 1m × 1.2m can be loaded onto the floor of a 20-foot container. Pallets are
often built either to occupy the entire height of the loading space of a container, or half
of the height so that two pallets stacked together occupy the entire height. In the latter
case, we will be able to load 22 pallets with base area 1m × 1.2m into a 20-foot container.
We call these two heights of pallets full height and half height pallets, respectively. Full
height and half height pallets are seldom combined in a single container for reasons of
efficiency of material handling.
If all pallets are of the same height, and all containers are of an appropriate size and
height (this is often the case since 20-foot and 40-foot containers are the most commonly
used container types in the industry), then the main challenge will be to determine the
minimum number of pallets required to load all cartons. Once this is done, we can easily
compute the number of containers of each type required to achieve the lowest cost. The
problem of loading a set of cartons into the minimum number of pallets of the same size is
the well-known 3D orthogonal bin packing problem (3D-BPP) and is the subject of study
in Chapter 4.
If we are allowed to mix pallets of full height and half height, we can think of a full
height pallet as one type of container and a half height pallet as another type of container,
whereupon the problem becomes very similar to floor loading and can be modeled as
MCLCMP. Note that we will need to impose additional restrictions on the number of full

3
height pallets for the following two reasons. Firstly, from an operational point of view,
tall pallets are harder to handle, i.e., they are not as stable when transported by forklift.
Secondly, without further restrictions we will always prefer to use a full height pallet,
since replacing two half height pallets with a full height pallet always results in a better
solution due to the overhead introduced by the thickness of the pallet itself.
The single container loading problem (SCLP), where the objective is to load as many
cartons as possible into a container to maximize the total volume of the loaded cartons,
arises in two scenarios. Firstly, it is a subproblem to MCLCMP. Most approaches to
MCLCMP (including those proposed in this thesis) are essentially two-phase approaches:
the first phase partitions the carton boxes into subsets, and the second phase attempts
to load as many carton boxes from a subset into a container as possible. Secondly, SCLP
may exist as a standalone application. For example, another of our team’s clients is a
Hong Kong based audio speaker manufacturer, who may process a typical order as follows.
The customer places a tentative order, and the salesman estimates whether the order can
be loaded into a single container. If the order is slightly larger than a container can
hold, the salesman will usually suggest to reduce the order quantity slightly, because the
leftover quantity will have to be shipped using either freight or courier service, which are
much more expensive than shipping a full container. On the other hand, if the order
quantity is slightly less than a container, the salesman will suggest to increase the order
quantity, which will increase the sales volume and also help the customer reduce the per
unit shipping cost. Although SCLP is well-studied, we devote Chapter 2 to developing
new effective algorithms for it, as algorithms for SCLP will become building blocks for
effective algorithms for MCLCMP.
Although many individual products are generally not rectangular in shape, (e.g.,
canned or bottled food), they are often first packaged into carton boxes or plastic contain-
ers for ease of handling and distribution. Hence, in the logistics industry many application
scenarios involve packing rectangular objects into rectangular spaces. Furthermore, the
boxes are usually placed orthogonally, i.e., with the carton edges parallel to the axes.
The three problems we study, namely SCLP, MCLCMP and 3D-BPP, can be classified as
three-dimensional orthogonal packing problems of rectangular objects.
In the remainder of this chapter, we first discuss a few important considerations and
constraints related to packing applications in Section 1.2. We then formally define our
problems and summarize related problems in Section 1.3. Finally, we survey existing
algorithms for SCLP, MCLCMP and 3D-BPP in Section 1.4.

1.2 Important Considerations

From a theoretical standpoint, cutting a set of small objects from large objects is identical
to packing a set of small objects into large objects. For example, in the 2D orthogonal bin

4
packing problem (2D-BPP), we want to pack a set of rectangles into identical rectangular
bins and minimize the total number of bins to accommodate all rectangles. In certain
loading application, items cannot stack over other items either because they are fragile
or their top faces are irregular. Such application can be modeled as 2D-BPP, where the
base area of a container is modeled as a bin and the base area of a cargo box is modeled
as an input rectangle. Similarly, 2D-BPP can also model cutting applications such as
cutting a set of rectangular pieces from a set of identical rectangular stock sheets, where
a stock sheet is modeled as a bin. Naturally the manufacturer would like to minimize the
total number of stock sheets while providing all the pieces in a customer’s order. We can
see that orthogonal packing problems and cutting problems have identical mathematical
formulations, when side constraints are ignored. Hence, we may expect cutting problems
and packing problems to share many commonalities, and many techniques can be applied
to both applications. We will therefore survey both the state-of-art cutting literature and
packing literature.
However, there are important differences between cutting and packing problems. Firstly,
cutting applications are usually one- or two-dimensional, whereas packing applications are
generally two- or three-dimensional; we discuss the issue of dimensionality in Section 1.2.1.
Secondly, there are important physical constraints that differentiate packing applications
from cutting applications. We examine two such constraints: the guillotine-cut constraint
in Section 1.2.2 and the full support constraint in Section 1.2.3.
The main difference between MCLCMP and 3D-BPP is the heterogeneity of the box
assortment, which has a very significant impact on the structure of the problem. Hence,
different approaches are required to solve these problems effectively, which we discuss in
Section 1.2.4.
Finally, we provide a summary of other practical issues and constraints from different
packing applications that have been studied in existing literature in Section 1.2.5.

1.2.1 Dimensionality
Cutting problems model the need to cut large pieces of stock into smaller pieces in many
industries. For example, glass is usually manufactured in large rectangular pieces, and
then cut into small rectangular pieces for various applications. In the garment industry,
cloth is cut into pieces and then assembled into various items of apparel such as shirts,
trousers, etc. Other two-dimensional examples include cutting steel plates and wooden
boards. One-dimensional cutting problems are also useful for modeling industrial appli-
cations, e.g., paper that is produced in a roll of fixed width off a production line is cut
into rolls of smaller width.
Packing problems model many applications in the logistics industry, e.g., loading car-
ton boxes, pallets or barrels into trucks or containers; or packaging individual products

5
such as cans or bottles into carton boxes. Objects in packing problems are generally
three-dimensional. However, in some applications, objects can only be placed in certain
orientations and/or cannot be stacked over each other, whereupon the problems are re-
duced to two-dimensional problems. For example, when carton boxes are loaded onto
pallets in a factory, oftentimes only a single type of product is loaded onto a pallet. Fur-
thermore, the pallets are loaded layer by layer, so it is required that the boxes in each
layer must have the same height, i.e., all products within a layer are placed with the same
dimension in the vertical direction, though they can be rotated by 90 degrees. Another
example would be the shipping of unstackable items such as sofas; since they cannot be
stacked on top of one another, the problem becomes finding the best layout of the base
areas of the sofas onto the floor of the container or truck.

1.2.2 Guillotine-Cut Constraint

In many cutting applications, e.g., cutting sheets of glass or wooden planks, it is difficult
or impossible to turn the blade in the middle of a cut. Hence, the cutting plan must be
formulated such that every cut divides the piece of material into two completely separate
smaller pieces. Some applications also require the cuts to be carried out in stages, and
such applications are often modeled as d-stage guillotine-cut problems. For example, in a
typical 2-stage guillotine cut application, the first stage involves cutting the large pieces
with a horizontally installed blade into horizontal strips. These strips then go through a
second stage, where they are cut vertically into pieces (Figure 1.3).

Trim Waste

Products

Movement on
conveyor belt

Figure 1.3: An example of 2-stage guillotine-cut

The guillotine-cut constraint makes little sense in packing applications. In fact, the
opposite requirement (i.e., the plan should be non-guillotine) is desirable in some situa-
tions. For example, consider the scenario of loading carton boxes onto pallets that are to
be subsequently transported by forklift. If no wrapping material is used, it is desirable to
increase the interlocking of boxes so that the packing is more stable during transportation
(see the stability consideration in Section 1.2.5)
Although the interlocking of boxes will increase stability, it will also make the loading

6
process more difficult and hence increase labor costs. When labor costs are expensive (with
respect to the value of the products shipped), alternative methods will be used to increase
stability, e.g., adding divider sheets every few layers (see Figure 1.4(a)1 ), using straps to
tie carton boxes together (see Figure 1.4(b)2 ) or wrapping the entire pallet (see Figure
1.4(c)3 ). In such cases, whether the packing plan follows the guillotine-cut constraint
is irrelevent. The guillotine-cut constraint can also be safely disregarded when loading
carton boxes into a space with supporting walls, such as standard shipping containers.

(a) Divider sheets (b) Loaded pallet with straps (c) Loaded pallet with wrap-
ping

Figure 1.4: Divider sheets; straps; wrapping (image from Internet)

The effect of the guillotine-cut constraint on the difficulty of a packing problem varies.
On the one hand, the guillotine-cut constraint is hard to incorporate into some integer
program based models. On the other hand, the guillotine-cut constraint restricts the
set of feasible packings, which may reduce the search space. Some packing problems
that include the guillotine-cut constraint can be naturally formulated as a recursion and
efficiently solved using a divide-and-conquer approach, i.e., the containers are recursively
divided into two subcontainers, and each is filled by carton boxes.

1.2.3 Full Support Constraint

Another significant difference between cutting and packing applications is the full support
constraint, which is usually not relevant in cutting applications but can be important for
certain packing applications. The full support constraint is often required to improve the
stability of the packing when the density of the products is high. A box is considered
fully supported if it is loaded directly onto the floor of the container, or if it is on top of
other boxes and its base area is fully covered by the top faces of the loaded boxes.
For low-density products, the full support constraint can be relaxed. Air bags (Figure
1
http://www.marvatexinc.com/divider.htm
2
http://www.geoffering-ceramic.com/glass-bricks/images/glass-block-pallet.jpg
3
http://www.oceanfreightusa.com/shipref_pon.php

7
1.5(a)1 ) and void fillers (Figure 1.5(b)2 ) are often used to fill the empty space between
cartons and increase the stability when necessary. In such scenarios, the main objective
is to maximize the volume utilization of the loading space.

(a) Air bags used to fill gaps (b) Void filler (indicated by green ar-
rows) in a packed container

Figure 1.5: Air bags; void filler (image from the Internet)

Since the full support constraint is hard to formulate into an integer program, existing
exact algorithms for 2D and 3D orthogonal packing problems often do not include the
full support constraint. For heuristic algorithms, the difficulty of handling this constraint
varies. Some approaches can be easily adapted to handle the full support constraint
[4], whereas incorporating the full support constraint into some algorithms would require
substantial modifications.

1.2.4 Heterogeneity of Box Assortment

The heterogeneity of the box assortment in packing problems differs depending on the
application scenario. Packing problem instances may be composed of many types of boxes
(strongly heterogeneous), which is a common scenario for courier services where products
of various sizes are collected from customers and packed into containers before being
shipped by truck or plane; a few types of boxes (weakly heterogeneous), for instance when
batches of goods from a warehouse are sent to retail stores; or entirely of one type of box
(homogeneous), a situation that is prevalent for goods coming off an assembly line in a
factory.
The heterogeneity of the box assortment has a large impact on the structure the
problem, and hence different techniques are required to handle instances with different
heterogeneity. For example, bin packing problems and cutting stock problems (with
identical stock size) are very similar, since both require arranging all items into bins (or
pieces of stock) such that the total number of bins (or pieces of stock) is minimized.
The main difference is that in bin packing problems, we assume each item is distinct,
1
http://www.globalspec.com/learnmore/material_handling_packaging_equipment/
packaging_labeling_equipment/protective_packaging
2
http://www.globalspec.com/learnmore/material_handling_packaging_equipment/
packaging_labeling_equipment/protective_packaging

8
so the characteristics of every item are separately defined in the input. In contrast, in
cutting stock problems we assume the customer’s order consists of a few product types
(typically a few to a few dozen), and for each product type many pieces are to be produced
(typically hundreds to thousands). Hence, the items are defined in the input according
to type, and for each type the dimensions and number of pieces demanded are specified.
Clearly, we can convert a bin packing instance to a cutting stock instance (with identical
stock size) and vice versa, and any algorithm that solves one problem can solve the other.
However, such a strategy is unpromising since reducing a cutting stock problem to a bin
packing problem usually results in an exponential number of items (with respect to the
input length), so the two problems are likely to require significantly different approaches
to solve efficiently.
If a set of items can be arranged onto a stock piece, we call it a cutting pattern. In
a sense, the heterogeneity of the box assortment measures the discreteness of the cutting
patterns needed to solve the problem, which can be seen from the set cover formulation
of the cutting stock problem: the set to be covered is the set of all items and a cutting
pattern “covers” a subset of items.
A cutting pattern can be represented by a vector where the j-th component is the
number of items of the j-th type in the pattern. Since there are a finite (though exponen-
tial) number of possible patterns, we can index them using integers. Let (ai1 , ai2 , ..., aiM )
denote the i-th cutting pattern, where M is the total number of item types. The cutting
stock problem can be modeled as:

|P|
X
SC : Minimize z = ci xi (1.1)
i=1
|P|
X
Subject to aji xi ≥ nj , j = 1, . . . , N (1.2)
i=1

xi ≥ 0 and integer, i = 1, . . . , |P| (1.3)

where P denotes the set of all possible cutting patterns, and the objective is to select
the minimum number of cutting patterns to cover the demand of each item type nj . The
decision variable xi indicates how many times the i-th pattern is used.
When the number of item types M is small and each type has a large number of pieces,
i.e., nj is much greater than aij , ∀i, we can expect xi to be generally much larger than
1. Compare this to bin packing, where nj = 1, ∀j, and xi will be either 0 or 1. Observe
that every solution is a point with integer coordinates in the space RM , and the space
RM can be divided into a grid where every solution is a grid point. Compared to the bin
packing problem, the solutions to the cutting stock problem will divide RM into a finer
grid in this manner. This implies that when we solve the LP relaxation of the set cover
model to produce a solution where some component is fractional, it is more likely in the

9
case of the cutting stock problem that there is an integer solution nearby than in the bin
packing problem. Therefore, when nj is much greater than aij , we would expect the gap
between the LP solution and the integer programming (IP) solution to be small, which
will greatly improve the effectiveness of algorithms based on IP.
Existing literature often formulates cutting stock problems as integer programming
models [5, 6], which are solved using standard techniques such as branch-and-price or
column generation. On the other hand, algorithms for 2D and 3D orthogonal bin packing
problems often work directly on the geometric layout of the packings to construct solutions
[7, 8]. The MCLCMP problem we investigate in Chapter 3 is more similar to the cutting
stock problem. Hence, our approach is to formulate it using a set cover model, and solve
the set cover model using a column generation technique with some enhancements. In
contrast, for the 3D-BPP problem investigated in Chapter 4, we attempt to construct
solutions directly based on the geometric layout of a solution, which we then attempt to
improve by inspecting the combinatorial structure of the items inside a bin.
The heterogeneity of the box assortment also impacts the solution technique for the
single container loading problem. The homogeneous SCLP is well-studied, and the most
successful techniques employ a divide-and-conquer strategy. Since there is only one box
type, a two-dimensional problem instance can be represented as a tuple (L, W, l, w), where
L × W is the size of the container and l × w is the size of the box. The problem can
be solved by partitioning the large bin into a few small bins, and then recursively filling
the small bins. A table is used to store the instances already solved in order to avoid
repeated computation. When certain restrictions are imposed (such as the guillotine-cut
constraint) such that there are only a finite number of ways to partition a large bin into
small bins, such methods will produce solutions that are optimal or very close to optimal.
For example, the G4-heuristic [9] for two-dimensional packing and the n-tet approach
[10] for multi-dimensional packing use this type of strategy. However, such an approach
will not work when there are multiple types of boxes and there are a limited number
of each box, because we have to record the number of boxes used for each box type for
a subproblem. The number of possible combinations of boxes grows exponentially, and
hence the size of the table used to record the best solution for computed instances will
also grow exponentially.
For weakly heterogeneous instances, it is possible to load boxes in batches, whereby
when boxes of one type are to be loaded, they are arranged in the same orientation to form
a layer. Such an approach often leads to good solutions [11, 12]. As the heterogeneity
increases, the probability of forming such layers is greatly reduced and the quality of
solutions produced using such a strategy deteriorates. A partial remedy is to allow boxes
of different sizes to form compact blocks and placing blocks instead of layers [4].

10
1.2.5 Other Issues in Container Loading Problems
Volume utilization is the most common primary objective for many real-world container
loading problems; a denser packing may result in the use of fewer containers or vehicles,
which also has the environmentally beneficial effect of reducing carbon emissions. Depends
on the specific applications, other considerations need also to be addressed.
Carpenter and Dowsland [13] has established three heuristic rules that often result in
a stable packing:

Every box must be in contact with at least two boxes from layers below. Boxes in
contact with less than X% of the base area are ignored.

The total contact area of the base of each box must be at least Y%

No straight or jagged (+/ − I mm) guillotine cuts traversing more than Z% of the
maximum length or width of the packing are allowed

These considerations are useful when loading carton boxes onto pallets and no wrapping
materials are used.
Bischoff and Ratcliff [14] mentioned the multi-drop consideration, where cargo boxes to
different destinations are loaded into the same container. In such situations, it is desirable
to arrange the cargo such that boxes to be unloaded at a destination are not blocked by
boxes meant for later destinations. Christensen and Rousøe [15] explicitly considered this
constraint in the context of the container loading problem. The multi-drop consideration
is often modeled as a last-in first-out constraint in the context of vehicle routing problems
with 3D loading considerations [16–21].
When loading products with high density (e.g. machinery), weight distribution within
the container needs to be considered. If the weight is very unevenly distributed, certain
handling operations will be very difficult or even impossible [14]. When the container is to
be transported by road (including the case of loading a truck), weight distribution across
the vehicle axles must be considered. Weight distribuiton has been studied by Ratcliff
and Bischoff [22] and Davies and Bischoff [23]. When loading high density products, the
load bearing strength of items must also be considered, i.e., we cannot stack too much
weight on top of an item. Bischoff [24] took load bearing strength into consideration
when producing 3D loading patterns.
In some applications, the shipment of certain items are more urgent than others. In
these cases, we would prioritize the loading of high priority items first. Shipment priorities
was first mentioned by Bischoff and Ratcliff [14] and subsequently studied by Ren et. al.
[25], who stipulated that all high priority items must be loaded before loading any low
priority items.
Bischoff and Ratcliff [14] also briefly mentioned a few other considerations such as
grouping of items, where it is considered desirable to load items for the same recipients

11
such that they are physically close to each other in order to facilitate unloading; and
separation of items, where certain types of items such as food and chemicals should not be
loaded into the same container. Separation of items in the context of the one-dimensional
bin packing problem is known as bin packing with conflicts, and has been intensively
studied. However, it is seldom considered in 3D.
Although many considerations have been mentioned in literature, very little work has
been dedicated to such considerations. They are normally handled as side constraints and
addressed in an ad-hoc manner by adapting an existing algorithm for 3D packing.
While the considerations discussed in this section are useful for specific applications,
they are not as important to the applications that motivated this study. Hence, we only
briefly mention them here for completeness and will not study them in detail in this work.
However, these factors are all potentially fruitful avenues of future research.

1.3 Problem Definitions and Related Problems

The multiple container loading cost minimization problem (MCLCMP) generalizes a few
well-studied problems. We will first formally define MCLCMP, and then summarize the
relationship between MCLCMP and its well-studied special cases.
The input of MCLCMP consists of

• M types of rectangular containers. Each type t = 1, . . . , M includes the following

attributes:

– Dimensions: Lt × Wt × Ht
– Cost of one container: Ct
– Number of available containers: mt

• N types of rectangular cargo boxes. Each type j = 1, . . . , N includes the following

attributes:

– Dimensions: lj × wj × hj
– Value of one cargo box: pj usually defined as volume pj = lj wj hj .
– Available cargo boxes: nj
– Allowed orientations for placement: Oj . An orientation of a box of type j is a
permutation of lj , wj , hj . It denotes how the sides of a box are aligned with the
sides of a container. There are at most six possible orientations. For example,
since a refrigerator must be placed upright, only two orientations are allowed.

The objective is to minimize the total cost of utilized containers, while satisfying the
following constraints:

12
 • Load All: all carton boxes are loaded. We assume the available containers are
sufficient to load all carton boxes.

• Orthogonal Packing: all carton boxes inside a container form a feasible orthogonal
packing. More precisely:

– Every box is fully inside a container

– Every box is placed with sides parallel to the sides of the container
– Any pair of boxes are interior-disjoint

• Full Support Constraint: every box is either placed directly on the floor of a
container, or on top of a set of boxes whose top faces cover the entire base area of
the box.

When there is only one type of container, i.e., M = 1, minimizing the total cost of the
containers is equivalent to minimizing the total number of containers used. This special
case is often known as the multiple container loading problem (MCLP). When the full
support constraint is ignored and the boxes are not rotatable (i.e., Oj = {(lj , wj , hj )}), it
is often known as the three-dimensional orthogonal bin packing problem (3D-BPP) [7].
In SCLP, there is only one container, i.e., M = 1 and m1 = 1, and the objective
becomes maximizing the total value of the loaded carton boxes. The Load All constraint
is dropped. When the boxes are not rotatable, this special case is the well-known three-
dimensional orthogonal knapsack problem (3OKP) [26–28].
The special case of SCLP where there is only one type of carton box is also well-studied
and is known as the manufacturer’s pallet loading problem. Very little literature models
this problem in the form of three-dimensional packing [29]. Instead, it is often modeled
as two-dimensional packing, since pallets are loaded layer by layer, and in each layer the
boxes are loaded with the same side in the vertical direction [9, 30–35].
The two-dimensional counterparts of MCLCMP, 3D-BPP and 3OKP are commonly
refered as the two-dimensional cutting stock problem, the two-dimensional orthogonal
bin packing problem and the two-dimensional orthogonal knapsack problem, respectively.
They are further divided into four subgroups depending on whether the guillotine-cut
constraint is enforced and whether the items are rotatable [36, 37].

1.3.1 Classification Under Standard Typology

Cutting problems and packing problems are the same from a modeling point of view, i.e.,
in both cases we are trying to arrange a set of small objects inside a set of large objects.
Dyckhoff and Finke [38, 39] introduced a typology on cutting and packing problems
and provided a reasonably comprehensive bibliography up to 1990. Wäscher et. al. [40]
improved the typology and covered the literature from 1980 to 2004. Cutting and packing

13
problems can be classified by objective function into minimizing an input value (e.g., in
3D-BPP, we would like to minimize the total number of bins) and maximizing an output
value (e.g., in SCLP, we would like to maximize the total volume of loaded carton boxes);
by dimensionality into 1-dimensional, 2-dimensional, 3-dimensional, multi-dimensional
and open dimension problems (one dimension is open and to be minimized); by the shape
of the objects into rectangular, circular or irregular (which is often modeled as polygons,
or polygons with arcs); by the assortment of small objects into homogeneous, weakly
heterogeneous and strongly heterogeneous; or by characteristics of the containers or stock
pieces (called the “large objects”) into a single large object, identical large objects, weakly
heterogeneous large objects and strongly heterogeneous large objects.
According to the improved typology [40], SCLP is classified under the three-dimensional
rectangular orthogonal SLOPP (Single Large Object Placement Problem) when the as-
sortment of carton boxes is weakly heterogeneous, and under the three-dimensional rect-
angular orthogonal SKP (Single Knapsack Problem) when the carton boxes are strongly
heterogeneous; MCLCMP is classified under the three-dimensional rectangular orthog-
onal MSSCSP (Multiple Stock-Size Cutting Stock Problem); and 3D-BPP is classified
under the three-dimensional rectangular orthogonal SBSBPP (Single Bin-Size Bin Pack-
ing Problem).

1.4 Existing Algorithms for SCLP, MCLCMP and

3D-BPP
1.4.1 Existing Algorithms for SCLP
SCLP is NP-hard in the strong sense [41]. As expected, exact algorithms can only solve
instances of limited size [42]. For many real world applications, it is therefore necessary
to resort to heuristics, metaheuristics and incomplete tree search based methods in order
to produce good solutions in reasonable time.
It is possible to classify existing algorithms for SCLP into three (not necessarily dis-
joint) classes. Constructive methods generate solutions by repeatedly loading boxes into
the container until no further boxes can be loaded. Divide-and-conquer methods instead
divide the container into sub-containers, and then recursively solve the resultant smaller
problems before recombining them into a complete solution [9, 10, 43–46]. Finally, lo-
cal search methods start with an existing solution, then repeatedly apply neighborhood
operators to generate new solutions [47, 48].
The best performing approaches in recent literature [4, 11, 12, 48, 49] share similar
algorithm structures and can be classified as block building approaches. Block building
approaches are constructive methods. A block is a subset of boxes that is placed compactly
inside its minimum bounding cuboid. Each step of a block building approach involves

14
placing a block into some free space in the container, and this is repeated until no more
blocks can fit into the container. Many earlier approaches for SCLP are also block building
in nature [50–53].
Among the block building approaches, we mention a few of the most successful ap-
paroaches. Parreño et. al. [11] introduced a maximal space algorithm that uses a two-phase
GRASP search. Parreño et. al. [48] later proposed a variable neighborhood search (VNS)
method. The current best single-threaded approach is the Container Loading by Tree
Search algorithm (CLTRS) by Fanslau and Bortfeldt [4] that uses a Partition-Controlled
Tree Search (PCTRS) to select the block to load in each iteration. Gonçalves and Re-
sende [12] devised a parallel Biased Random-Key Genetic Algorithm (BRKGA) for the
problem, which produced the best results (using a machine with 6 cores) on benchmark
data at the time of writing.
There have also been wall-building approaches [41, 54], where a container is filled by
vertical layers (called walls), and layer-building approaches [14, 55], where the container
is filled from the bottom up using horizontal layers. Both a wall and a horizontal layer
can been seen as special cases of a block, so these approaches can also be considered block
building approaches. All of these techniques only instantiate blocks when the combination
of boxes contained within is considered desirable by some measure (e.g., if the total volume
of the boxes take up at least 98% of the entire block volume).

1.4.2 Existing Algorithms for MCLCMP

Earlier literature often recommended ways to extend procedures for the SCLP to multiple
containers. Possible strategies include the sequential strategy, where single containers are
filled in turn using SCLP approaches [50, 56, 57]; the pre-assignment strategy, which
first assigns boxes to containers before loading [55]; and the simultaneous strategy, which
considers multiple containers during the loading of boxes [50].
There is little existing literature that examines multiple container loading problems
and its variants directly. Takahara and Miyamoto [58] studied a similar problem where
the objective was to minimize wasted volume, which is equivalent to minimizing the total
capacity of containers used. This may be regarded as a variant of MCLCMP where the
containers of various types have equal unit costs. An evolutionary approach was proposed,
where a pair of sequences (one for boxes and one for containers) is used as the genotype,
and a heuristic was used to determine the loading plan given the sequence of boxes and
containers. MCLCMP and some possible variants were also studied by Eley [59] who
proposed a bottleneck assignment approach. The author used a set cover formulation,
and generated packing patterns using a tree search based heuristic. Set cover based
heuristics have also been proposed for both 1D and 2D bin packing problems [60].
One strategy to solve MCLCMP is to formulate it as a set cover problem, and then

15
solve the set cover formulation using a technique similar to column generation (Section
3.3). The idea of column generation has its roots in the work by Ford and Fulkerson
[61], who suggested a scheme to implicitly enumerate the variables of a multi-commodity
flow problem. The idea was further developed by Dantzig and Wolfe [62] into a column
generation technique, which extends a linear program column-wise as needed. The column
generation technique was first implemented by Gilmore and Gomory [63, 64] as part of
an efficient heuristic algorithm for the cutting stock problem. It has since become a
prominent technique for solving linear programs with huge numbers of variables over the
past few decades.
Desrosiers et. al. [65] combined the column generation technique with the linear
programming based branch-and-bound framework for solving the m-TSP with time win-
dows; the resulting technique is commonly referred to as branch-and-price. Barnhart et.
al. [66] unified a number of specialized branch-and-price algorithms and proposed generic
algorithms for solving huge integer programs, which has positioned the branch-and-price
approach as a viable tool for solving integer programs with a huge number of variables.
Column generation and branch-and-price techniques have been successfully applied
to many hard combinatorial optimization problems. Examples include vehicle routing
problems [67], airline crew pairing [68], crew scheduling [69], and 2D bin packing [70].
More examples can be found in the survey by Lubbecke and Desrosiers [71].

1.4.3 Existing Algorithms for 2D/3D BPP

Existing approaches for 2D/3D bin packing problems can be broadly classified into two
categories, namely simple heuristics and meta-heuristics. Many simple heuristics are con-
structive in nature, whereby items are placed into containers based on some heuristic rule.
An important task for such constructive heuristics is to determine the set of candidate
positions at which an item can be loaded.
Martello et. al. [7] defined corner points as candidate positions, which are the points
where the horizontal and vertical line segments of the envelope of the items in the container
intersect in the 2D case; this concept can be generalized to higher dimensions. Crainic et.
al. [8] expanded on this idea by defining extreme points, which was employed in the best
current constructive heuristic for the 2D- and 3D-BPP; we describe this approach in detail
in Section 4.2.1. Normal positions, which are positions whereby items cannot be moved
along any axis towards the origin (blocked by other items or boundaries of the container),
are also commonly used for packing problems. For 2D packing, normal positions are also
known as bottom-left stable positions [72].
Once the candidate positions are identified, different strategies can be used to load
items into the container. Given a target item i, possible strategies include first fit, which
chooses the first valid position, and best fit, which selects the best position according to

16
some measure. For 2D packing, strategies such as bottommost leftmost [73] and maximum
touching perimeter [37] have been tried. These strategies were extended to 3D [16].
Meta-heuristics generally employ simple heuristics as subroutines. For the bin packing
problem, the use of meta-heuristics has been shown to outperform simple heuristics by
large margins. Examples include the Guided Local Search method by Faroe et. al. [74],
which iteratively improves an initial solution that is generated using a greedy heuristic
by employing a guided local search; the TS2 Pack algorithm by Crainic et. al. [75] that
improves on an initial solution using a tabu search; the approach by Perboli et. al.
[76] that improves on initial solutions using a greedy adaptive search procedure (GASP);
and the hybrid GRASP/VND approach by Parreño et. al. [77] that employs a variable
neighborhood descent technique in a GRASP framework.

17
Chapter 2

Algorithms for the Single Container

Loading Problem
In the Single Container Loading Problem (SCLP), the objective is to orthogonally load a
set of three-dimensional cargo boxes into a three-dimensional rectangular container so as
to maximize the volume utilization of the container. The full support constraint is often
imposed for container loading problems, which requires that all boxes are 100% supported
from below.
In this chapter, we first present our iterative-doubling greedy look ahead (ID-GLA) tree
search algorithm for SCLP that does not consider the full support constraint in Section
2.1. The algorithm loads one block (of cargo boxes) at a time using a greedy approach
until no more cargo boxes can be loaded into the container; a tree search is invoked to look
ahead a few steps to determine which block is to be loaded at each step. Our algorithm
consists of multiple iterations, and in each iteration the search effort of the tree search is
doubled. We then extend our algorithm to address the full support constraint in Section
2.2.
Our approach and the best performing approaches in recent literature [4, 11, 12, 48]
share similar structures and can be broadly classified as block building approaches. We
propose a conceptual model in Section 2.3 that captures the common structure of these
block building approaches. In this conceptual model, a block building approach is dis-
sected into six elements. Three of the six elements define the states and transitions in
the search space, two of the elements are heuristic rules that attempt to guide the search
to more promising search regions, and the last element is the overarching search strategy.
By dissecting block building approaches into six elements, we can compare and contrast
the various choices made by existing algorithms for each element through both theoretical
discussion and computational experiments. This conceptual model not only allows us to
better understand the impact of various choices for each element, it also allows us to
identify possible further research directions.
Finally, we conducted a number of computational experiments to understand the be-
havior of our algorithm and illustrate its effectiveness over existing algorithms, which we

18
describe in Sections 2.4 and 2.5.

2.1 Iterative-Doubling Greedy Look Ahead (ID-GLA)

Tree Search Algorithm
In a typical constructive method, a packing is obtained by loading one box at a time until
no further boxes can be loaded into the container. However, in a block building approach,
boxes are first arranged into blocks, and in each step a block of boxes is loaded instead
of a single box.
Our approach is a block building approach. We start with an empty container and
a list of candidate blocks. In the first step, we select a block and place it at one of the
corners of the container. The remaining free space in the container can be represented
as a list of cuboids, which we call residual spaces. In subsequent steps, we select one of
the residual spaces and one of the available blocks, and then place the selected block at
some corner of the selected space. Once the block is placed, we update the list of residual
spaces and available blocks. This process is repeated until the list of residual spaces is
empty, whereupon we have produced a complete packing. We use a tree search procedure
to generate several complete packings, and return the best packing found when the time
limit is reached.
In any step of our solution construction process, the state of the current partial packing
can be fully described by:

R: a list of cuboids (residual spaces) representing the free space in the container

B: a list of candidate blocks

PB: a list of placed blocks and their locations

We first show how we represent free space as a list of residual spaces in Section 2.1.1,
and then describe how boxes are combined into blocks in Section 2.1.2. We then explain
in Section 2.1.3 how we perform a d-step look ahead tree search that produces several
complete packings and returns the best one. Section 2.1.4 describes how we evaluate the
desirability of a placement (i.e., a block, a residual space, and a corner in that space),
which is used in our tree search. Finally, our overall approach is outlined in Section 2.1.5.

2.1.1 Maximal Space Representation of Free Space

We use the maximal space concept to represent the free space in the container. When
a single block is placed at a corner of the container, the remaining free space can be
represented by three overlapping cuboids, where each cuboid is a largest rectangular
box that is interior-disjoint with the placed block; such a cuboid is called a residual

19
space. Figure 2.1 shows the resultant residual spaces from placing such a block; since the
three cuboids overlap, they are illustrated in three separate diagrams (as semi-transparent
cuboids) for clarity of presentation.

(a) (b) (c)

Figure 2.1: Three residual spaces that form a cover of the free space

Due to the overlapping nature of the maximal space representation, when a block is
placed at some corner of a residual space, it may overlap with other residual spaces. After
a block is placed, these overlapped residual spaces must be updated. Figure 2.2 illustrates
a general case, where a placed block b overlaps with a residual space r. In this case, the
remaining free space in r can be represented using the maximal space concept, and the
resultant residual spaces can be computed as follows. For each plane that corresponds to
a face of the block b, if the plane intersects with r, then it will divide r into two parts,
where one part overlaps with b and the other part is a new residual space. In Figure 2.2,
the plane corresponding to the right face of b produces the residual space r0 . Therefore,
for any residual space that overlaps with a placed block b, its remaining free space can be
represented by up to six residual spaces corresponding to the six faces of b.

r
r'

Figure 2.2: A placed block b overlaps with residual space r

2.1.2 Block Generation

There are two types of blocks that have been employed in existing research. A simple
block consists of only one type of box, where all boxes are placed in the same orientation.
In contrast, a guillotine block may consist of multiple types of boxes and/or boxes that
are placed in different orientations. A guillotine block is recursively defined: 1) all simple

20
blocks are guillotine blocks; 2) two guillotine blocks that are combined along the length,
width or height direction (of the container) is a guillotine block.

(a) Simple block (b) Guillotine block

Figure 2.3: Classes of blocks

For the purpose of finding a solution to SCLP (without the full support constraint),
it is clear that two blocks with the same dimensions that consist of the same set of boxes
are equivalent, even if the internal configurations (i.e., relative locations of the boxes) are
different. Hence, a block can be fully described by the following attributes:

• l, w, h: the dimensions of the minimum bounding cuboid that encloses all boxes in
the block

• Boxes: the list of boxes in the block

For equivalent blocks, we only keep the first one generated and discard the rest.

Generating Simple Blocks

Our procedure for generating simple blocks is given by Algorithm 1, which returns a list
of approximately MaxSBCount simple blocks. A simple block by definition consists of
one or more boxes of the same type placed in the same orientation. A simple block can
be seen as a box replicated nl , nw , and nh times along the length, width and height
directions of the container, respectively. Since there are only nj boxes of type j, so
nl ≤ nj , nw ≤ nj , nh ≤ nj and the total number of boxes in the block nl · nw · nh ≤ nj .
Furthermore, a box of dimensions (lj , wj , hj ) can be placed in up to six orientations as
given by the set of allowed orientations Oj . Lines 2-10 enumerates all possible simple
blocks for each box type j in allowed orientations and places them into a list Bj .
If the total number of simple blocks generated is greater than MaxSBCount, the
algorithm retains only the num smallest blocks for each box type, where num is computed
based on the proportion of blocks of that type out of all blocks generated and is at least
one (line 14). This addresses the possibility that a very small box type results in a
disproportionate number of blocks in the resultant block list. Furthermore, by retaining
at least the smallest block for each box type (consisting of a single box), we ensure that
all boxes are represented in the block list.

21
Algorithm 1 Generating Simple Blocks

Generate-Simple-Blocks(MaxSBCount)
1 B =∅
2 for each box type j
3 Bj = ∅
4 for each allowed orientation (l, w, h) ∈ Oj
5 for nl = 1 to nj
6 for nw = 1 to nj
7 for nh = 1 to nj
8 if nl · nw · nh ≤ nj
9 Create a block b with dimensions
(nl · l, nw · w, nh · h) consisting of nl · nw · nh
boxes of type j
10 P Add b to Bj
11 totalBlocks = j |Bj |
12 if totalBlocks > MaxSBCount
13 for each box type j
|Bj |
14 num = max{b totalBlocks · MaxSBCountc, 1}
15 Sort Bj by increasing block volume
16 Add first num blocks from Bj to B
17 else
18 Add all blocks from Bj for all box types j to B
19 return B

22
Generating Guillotine Blocks

Algorithm 2 generates guillotine blocks by iteratively combining smaller blocks into larger
ones. We begin by generating up to MaxBlockCount/2 simple blocks (line 1). We maintain
three sets of blocks: the set of blocks generated so far is stored in B, the set of blocks
generated in the previous iteration is stored in PG, and the set of blocks generated in
the current iteration is stored in NG. The new blocks are generated by picking one block
b1 from B and another block b2 from PG, and then combining the two blocks along the
length, width or height direction of the container. It is possible that the generated block
b is equivalent to some existing block in B (of the same dimensions and consisting of the
same set of boxes) or infeasible (too big to be loaded into the container, or consisting of
more boxes of a type than are available); such blocks are discarded. After an iteration
is completed, the new generation of blocks NG is added to B and becomes the previous
generation PG for the next iteration. The process continues until we generate enough
blocks, or no new blocks are generated (line 3).

Algorithm 2 Generating Guillotine Blocks

Generate-Guillotine-Blocks(MinUtil , MaxBlockCount)
1 B = Generate-Simple-Blocks(MaxBlockCount/2)
2 PG = B
3 while |B| < MaxBlockCount and PG is not empty
4 NG = ∅
5 for each block b1 in P
6 for each block b2 in B
7 for each direction dir in {L, W, H}
8 b = combine b1 and b2 along the direction dir
9 if b is feasible and no equivalent block exists in B
10 Add b to NG
11 B = B ∪ NG and keep only the first MaxBlockCount blocks
12 PG = NG
13 return B

To combine two blocks b1 and b2 along the length direction:

1. Identify the block with the larger cross section, i.e., the block whose projection on
W × H has a larger area. Without loss of generality, assume block b1 is the block
with the larger cross section.

2. Place b1 at the origin, and append b2 to b1 along the length direction, i.e., set the
coordinates of the front-bottom-left corner of b2 to (b1 .l , 0, 0).

3. Find the minimum bounding cuboid that encloses both b1 and b2 . The dimensions

23
 of this minimum bounding cuboid is given by l = b1 .l + b2 .l , w = max{b1 .w , b2 .w },
and h = max{b1 .h, b2 .h}.

4. Create a new block b whose dimensions are (l, w, h), and b.Boxes = b1 .Boxes ∪
b2 .Boxes

Figure 2.4 illustrates the combination of two blocks along the length direction of the
container. Blocks can be combined in a similar manner along the width and height
directions.

30

20
b2
H
b1
60
10
40

60
20
W 40
0 20
0 0 L

Figure 2.4: Combining two blocks along the length direction of the container

2.1.3 Greedy d-step Look Ahead Tree Search

Whenever a block is placed into a residual space, it is always placed such that one of its
corners coincides with one of the corners of the residual space. Since any block can be
potentially placed at any of the eight corners of a residual space, given a state with |R|
residual spaces and |B| blocks, there are up to 8 · |R| · |B| possible placements. A common
strategy to determine the best placement for a given state is to use a tree search. At the
root of the tree, we consider the top m placements according to some fitness measure,
resulting in up to m depth one nodes. For each node at depth one, we again try the top
m placements, resulting in up to m2 depth two nodes. We expand the tree up to depth d.
For each node at depth d, we use a simple greedy method to obtain a complete packing
(i.e., we repeatedly perform the best placement according to the fitness measure until no
more blocks can be loaded).
Figure 2.5 illustrates a search tree with m = 3, d = 2. The first placement on the path
that leads to the best complete packing (i.e., the volume of the loaded boxes is maximized)
is considered to be the best placement for the root node. In Figure 2.5, since placement
p2 leads to the best complete solution, so p2 is the best placement for state S. We call
such a tree search d-step look ahead.
The tree search described above essentially looks d steps ahead in order to decide the
best placement for a given state. We denote this tree search by the notation LookAhead(S, d, m, Rank),

24
 S d = 0

p1 p2 p3

S1 S2 S3 d = 1

d = 2

Best

Complete the solution using the greedy algorithm

Figure 2.5: Two-step look ahead with branching factor m = 3

where S is the current state, d is the maximum depth of the tree search, m is the maximum
number of subtrees explored at each node of the tree search (also called the branching
factor), and Rank is a function that ranks all possible placements for the current state S.
More precisely, the function Rank(S, m) returns up to m placements out of all possible
placements for state S. The tree search procedure LookAhead(S, d, m, Rank) returns a
pair (p, CS ), where p is the best placement for the current state S , and CS is the best
complete solution found during the tree search.
Using the above tree search, we designed a greedy algorithm called
GreedyLookAhead (Algorithm 3). Starting from the initial state S corresponding to the
input SCLP instance, we invoke the tree search procedure LookAhead to find the best
placement p. We then move to the next state by performing the selected placement
using the procedure Place(S, p). We repeat the above process until there are no residual
spaces remaining. We record the best solution found using variable BestSol ; since each
invocation of the tree search procedure LookAhead also returns a complete solution CS
(line 6), we update the best known solution BestSol if CS is superior.
The procedure Place(S, p) updates state S according the selected placement p =
(r, b, c), which indicates that block b is placed at corner c of residual space r. Once
the selected block b is placed, the set of boxes in the block is loaded into the container.
Hence, the number of remaining boxes is reduced, and as a result some blocks in S.B may
become infeasible (they may consist of more boxes than are now available); such infeasible
blocks are deleted (line 2). Furthermore, the placed block may overlap with some residual
spaces in S.R (it will at least overlap with the residual space r in the selected placement);
these overlapped residual spaces are deleted from S.R (line 4). In general, these residual

25
Algorithm 3 Greedy d-Step Lookahead Tree Search Algorithm

GreedyLookAhead(B, d, m, Rank)
// B : a list of blocks
// d : maximum depth of the tree search
// m: maximum branching factor of the tree search
// Rank: a function that ranks all placements of a state
1 BestSol = NULL
2 Create an initial state S, where
S.R consists of a single free space corresponding to the entire container
S.B consists of all feasible blocks from the list B
3 while S.R is not empty
4 (p, CS ) = LookAhead(S, d, m, Rank)
5 Place(S, p)
6 update BestSol if CS is a better solution
7 Update BestSol if S is a better solution
8 return BestSol

Place(S, p)
// S : a state representing a partial packing
// p: a triplet (r, b, c) representing a placement
1 place block b at corner c of residual space r, add the placed block to S.PB
2 delete infeasible blocks from S.B
3 NewSpaceList = ∅
4 delete all residual spaces that overlap with the placed block b from S.R
5 for each space os that overlaps with the placed block b
6 compute the residual spaces in os
7 add the residual spaces into NewSpaceList
8 delete all spaces from NewSpaceList that are too small to accommodate
any block in S.B
9 delete all spaces from NewSpaceList that are subsumed by
some other space in NewSpaceList
10 for each space rs in NewSpaceList
11 if rs is not enclosed by any free space in S.R
12 insert rs to S.R

26
spaces may still contain some useful space, which can be represented as new residual
spaces as computed using the method described in Section 2.1.1. The list NewSpaceList
stores all the new residual spaces generated. Spaces that are too small to accommodate
any block in S.B are deleted (line 8). Due to the overlapping nature of the maximal
space representation, some residual spaces in NewSpaceList may be subsumed (i.e., fully
enclosed) by other spaces; such spaces are superfluous and are likewise deleted (lines 9
and 11). The remaining useful new residual spaces are inserted into S.R (line 12).

2.1.4 Ranking Placements

We now describe our placement ranking function, which selects up to m placements
out of all possible placements of the state S. Given two integers m1 and m2 such that
m1 · m2 ≤ m, the function selects up to m1 residual spaces from S.R. For each selected
residual space r, up to m2 blocks that “fit best” into r are chosen, resulting in up to m
placements.
We consider two schemes for deciding m1 and m2 . One simple scheme is to always
set m1 = 1 and m2 = m; this is the scheme used by Fanslau and Bortfeldt [4], which
we call the Single-Best-Space scheme. An alternative scheme is to set both m1 and m2
√
to about m for the root node of a search tree (at depth zero), and for all other nodes
in the search tree we set m1 = 1 and m2 = m; we call this the Multi-Best-Space scheme
(given in Algorithm 4).

Algorithm 4 Ranking Placements of a State using Multi-Best-Space Scheme

Rank-Placement-Multi-Space(S, m)
// S : a state representing a partial packing
// m: the maximum number of placements to be returned
1 if S corresponds to √ the root node
2 m1 = max{b mc, 1}
3 else m1 = 1
4 m2 = max{bm/m1 c, 1}
5 PlacementList = ∅
6 SpaceList = select the best m1 residual spaces in S.R
7 for each residual space r in SpaceList
8 for the m2 blocks b in S.B that fit best into space r
9 Add placement (r, b, c) to PlacementList
10 return PlacementList

It is well known that packing boxes from the corners of the container towards the
center tends to lead to better utilization of space, since free space is then collated at
the center and tends to be continuous [11, 78]. Hence, when selecting residual spaces,
we prefer to select residual spaces close to a corner of the container. Our residual space

27
selection strategy closely resembles that of Parreño et. al. [11] except for two aspects: (1)
we may select more than one residual space; (2) we use Manhattan distance instead of
lexicographic distance [11, last paragraph in the left column, page 414].
A residual space r has eight corners, and each corner has a corresponding corner
of the container. Figure 2.6 illustrates eight pairs of corresponding corners: (A1 , B1 ),
(A2 , B2 ), . . . , (A8 , B8 ). For each pair of corners, we compute the Manhattan distance,
i.e., if (x1 , y1 , z1 ) are the coordinates of A1 and (x2 , y2 , z2 ) are the coordinates of B1 , the
Manhattan distance is |x1 − x2 | + |y1 − y2 | + |z1 − z2 |. We call the corner of r with the
minimum Manhattan distance the anchor corner, and the distance between the anchor
corner and its corresponding corner of the container is the anchor distance; in Figure
2.6, A2 is the anchor corner. When selecting residual spaces, we prefer the space with the
smallest anchor distance, with ties broken by greater volume. If there is still a tie, we prefer
the space with smaller lexicographical order of (y1 , z1 , y2 , z2 , x1 , x2 ), where (x1 , y1 , z1 ) are
the coordinates of the corner closest to the origin, and (x2 , y2 , z2 ) correspond to the corner
farthest from the origin (the container is assumed to be placed with its length, width and
height aligned with the X-, Y -, and Z-axes, respectively).

B8 B7

B5 A8 A7 B6
A5 A6

B4 A4 A3
B3
A1 A2
B1 B2

Figure 2.6: Anchor distances between a residual space and the container

For each selected residual space, we select up to m2 blocks from S.B using a fitness
measure. The fitness of a block b with respect to a given residual space r is defined as

f (r, b) = V + α · (Vloss + Vwaste ) (2.1)

where V is the total volume of the boxes in the block, Vloss is the wasted space volume
after the block b is placed into r, Vwaste is the wasted block volume in block b (i.e., the
volume of the block minus the total volume of boxes in the block), and α is a coefficient
that controls the relative weight of V and (Vloss + Vwaste ).
The value of Vloss is computed as follows. Recall that after a block is placed at a corner

28
of a residual space r, the remaining space in r is represented by at most three cuboids
(Figure 2.1). Given such a cuboid and the set of available boxes, the maximum usable
space on each axis must be a linear combination of the dimensions of the boxes. If the
magnitude of a dimension of a cuboid is not a valid linear combination of box dimensions,
we can “trim” it to the largest linear combination. To compute the largest linear combi-
nation subject to the availability of boxes is equivalent to solving a knapsack problem; we
make use of the standard knapsack problem algorithm using dynamic programming (DP)
that runs in pseudopolynomial time [79] for this purpose. We compute Vloss as the total
amount of wasted space trimmed from the three cuboids as measured by this technique.
Let (lr , wr , hr ) be the dimensions of residual space r and (lb , wb , hb ) be the dimensions
of the block. The dimensions of the three cuboids representing the remaining space are
given by (lr − lb , wr , hr ), (lr , wr − wb , hr ) and (lr , wr , hr − hb ). Since not all boxes can
be fully rotated, the linear combinations of box dimensions along the length, width and
height directions of the container may be different. For the length (resp. width and height)
direction, let the array element MaxKnapL[x] (resp. MaxKnapW [x] and MaxKnapH [x])
denote the largest linear combination of box dimensions that does not exceed x, calculated
using the dynamic programming approach [79]. We compute the wasted space volume
in the three cuboids as ((lr − lb ) − MaxKnapL[lr − lb ]) × wr × hr , lr × ((wr − wb ) −
MaxKnapW [wr − wb ]) × hr and lr × wr × ((hr − hb ) − MaxKnapH [hr − hb ]), respectively.
Since the linear combinations of box dimensions will change when the set of available
boxes change, we must update the arrays MaxKnapL, MaxKnapW and MaxKnapH after
each block is placed. During the tree search
LookAhead(S, d, m, Rank), they are updated before a node is expanded. When we reach
a node at depth d, the partial solution represented by the node will be completed by a
greedy procedure that repeatedly performs the best placement at each step. However, in
this greedy procedure we do not update the arrays, since every update of the array will
require solving a knapsack problem, which is too costly in terms of computation time.

2.1.5 Iterative Doubling of Search Effort

The parameters d and m in GreedyLookAhead(B, d, m, Rank) control the size of the
search tree explored by the LookAhead(S, d, m, Rank) function, which is proportional to
w = md . The total computational effort by GreedyLookAhead is also approximately
proportional to w, although invoking GreedyLookAhead with a larger w value may not
always take more CPU time because the number of tree searches carried out is affected
by the selected placements.
Our overall approach uses a simple strategy that starts with computational effort
w = 1, and doubles the effort in subsequent iterations until all allocated CPU time is
used. Our resultant Iterative-Doubling Greedy Look Ahead (ID-GLA) approach is given

29
in Algorithm 5.

Algorithm 5 The Iterative-Doubling Greedy Look Ahead Algorithm

ID-GLA(d, Rank)
// d : maximum depth of tree search
// Rank: a function that ranks placements of a state
1 BestSol = NULL P
2 avgBoxPerType = k Nk /K
3 if avgBoxPerType > 6
4 B = Generate-Simple-Blocks(MaxBlockCount)
5 else B = Generate-Guillotine-Blocks(MinUtil , MaxBlockCount)
6 w=1
7 while time √ limit is not exceeded
8 m = b d wc
9 sol = GreedyLookAhead(B, d, m, Rank)
10 update BestSol if sol is a better solution
11 w =2·w
12 return BestSol

Remark on Computing Branching Factors

Note that early in the ID-GLA algorithm when the values of w are small, we may have
√ √
b d wc = b d 2 · wc. Hence, multiple invocations of
GreedyLookAhead(B, d, m, Rank) with the same m value would be performed. Since
GreedyLookAhead with a particular m value will always result in the same solution,
to avoid such redundant work, the actual logic for determining the branching factors is
√ √
slightly more complex than m = b d wc; our implementation is identical to m = b d wc
when w is large.
Let m(i) be the branching factor for the LookAhead tree search at depth i. For the
d-step look ahead search, we want m(0) × m(1) × · · · × m(d−1) = w such that the individual
m(i) values are as similar as possible. In order to avoid performing multiple redundant
searches early in our ID-GLA algorithm when the search effort w is small, our actual
implementation of the GreedyLookAhead function takes w as a parameter (instead of m)
and calculates m(i) , i = 0, · · · , d − 1 for the current state S, as follows:
( √
(i) b d wc : i > 0
m = w
d m(1) ×···×m(d−1) − 0.5e : i = 0
For the Multi-Best-Space scheme, recall that at the root node, we consider m1 residual
spaces and m2 blocks where m1 × m2 ≤ m(0) . The method given in lines 1-4 of Algorithm
4 produces the same values of m1 and m2 for m(0) = 1, 2, 3. To resolve this issue, our

30
actual implementation calculates m1 and m2 as follows:
(
m1 = m(0)
m(0) < 4 :
m2 = 1
( √
m1 = m(0)
m(0) ≥4 :
m2 = bm(0) /m1 c

2.2 Handling the Full Support Constraint

In order to adapt ID-GLA to handle SCLP with the full support constraint, we only
need to ensure that the following conditions hold throughout the course of our algorithm:

• FS1: All boxes in blocks are fully supported from below by boxes or by the base of
the block; such blocks are called fully supported blocks

• FS2: The bases of all residual spaces are fully covered by the top faces of some
placed boxes or the floor of the container; such spaces are called fully supported
residual spaces

• FS3: Blocks are placed only on the base of a fully supported residual space (i.e.,
one of the bottom four corners of the space)

When these conditions hold, the placement of a block will not violate the full support
constraint. Since the initial state (the empty container with no boxes) represents a fully
supported packing plan, so by induction all states reached from the initial state satisfying
these conditions represent fully supported packing plans.

2.2.1 Generating Fully Supported Blocks

A fully supported block (FSB) is a block where all boxes in the block are fully supported
from below by either other boxes or the base of the block. We associate each FSB with
a new attribute packing area, which is a rectangular region on the top face of the block
that is fully covered by the top faces of boxes in that block.
Clearly, any simple block is an FSB and its packing area is the entire top face. FSBs are
generated by iteratively combining two FSBs along the length, width or height direction
of the container. We use the same technique as Fanslau and Bortfeldt [4] to combine two
FSBs to generate a new FSB. Combining two FSBs along the length or width direction
will always result in an FSB since no overhanging boxes will be introduced. Figure 2.7
shows how two FSBs can be combined along the length direction.
In our approach, two FSBs b1 and b2 can be combined along the length (resp. width)
direction of the container only if:

1) the heights of the two blocks are the same;

31
 p2
p1
60 b2
40
20
b1 60
W
20 H 40
10

20
L
00
0

Figure 2.7: Combining two fully supported blocks along the length direction

2) the length (resp. width) of the packing area spans the entire length (resp. width) of
the corresponding block

3) the resultant block is feasible and has volume utilization no less than MinUtil

4) all other conditions required to combine two blocks are satisfied, i.e., the resultant
block must be able to fit into the container, the number of boxes in the resultant
block must not exceed the number of available boxes, and the volume utilization of
the resultant block is above a given threshold.

When two FSBs b1 and b2 with packing areas p1 and p2 , respectively, are combined
along the length direction, the packing area p of the resultant block is given by

p.length = p1 .length + p2 .length (2.2)

p.width = min{p1 .width, p2 .width} (2.3)

When two FSBs are combined along the height direction, we avoid introducing new
overhanging boxes by placing the top block inside the packing area of the bottom block.
Hence, two FSBs can be combined along the height direction only if the base area of
the top block can contained by the packing area of the bottom block (Figure 2.8). The
packing area of the resultant block is the packing area of the top block.

2.2.2 Generating Fully Supported Residual Spaces

We extend the concept of a residual space to a fully supported residual space. A fully
supported residual space is a residual space where its base area is fully covered by either
the floor of the container or the top faces of some placed boxes.
Recall that for SCLP without the full support constraint, when a placed block b
overlaps with a residual space r, the remaining free space in r can be represented by up

32
 r2

r1
40 b2

60

40
H
20
b1
60

W
40
20

20
L

00
0

Figure 2.8: Combining two fully supported blocks along the height direction

to six new residual spaces, each of which corresponds to a face of the placed block. In
the case of SCLP with the full support constraint, when a placed FSB overlaps with a
fully supported residual space, the four spaces corresponding to the left, right, front and
back faces of the block are automatically fully supported (we can easily verify that their
base areas are fully supported). No residual space corresponding to the bottom face of
the block will be generated due to the placement restriction FS3. Finally, the residual
space corresponding to the top face of the placed block will be fully supported if we use
the packing area of the block as its base. Figure 2.9 shows a fully supported block b that
overlaps with a fully supported residual space. The residual space corresponding to the
the top face of block b is r0 , and the base area of r0 is exactly the packing area p of block
b.

r¢
p
H
b

0
Figure 2.9: r is the residual space corresponding to the top face of block b

33
2.3 A Conceptual Model for Analyzing Block Build-
ing Approaches
Our ID-GLA algorithm and the best performing SCLP approaches in recent literature
[4, 11, 12, 48] share similar structures and can be broadly classified as block building
approaches.
In this section, we propose a conceptual model to capture the common structure of
these block building approaches. In this conceptual model, we attempt to dissect all block
bulding approaches into six common elements, which enables us to compare and contrast
the various choices made by existing algorithms for each element using both theoretical
discussion and computational experiments. This helps us to better understand the impact
of various choices for each element and identify possible further research directions.
The six elements in our conceptual model are:

E1: how to represent and manage free space in the container

E2: how to generate a list of candidate blocks

E3: how to select a candidate residual space

E4: how to select a candidate block

E5: where to place the selected block in the selected residual space

E6: what is the overarching search strategy

The elements E1, E2 and E5 define the search space, i.e., the choices made for E1, E2
and E5 define the set of states in the search space and the transitions between states. The
elements E3, E4 and E5 set a restriction on the set of transtions that will be considered by
a search and impose an order in which transitions are considered during the search. E3,
E4 and E5 also define the boundaries of the search space subregions that will be explored.
The last element E6 is the most complicated element, which specifies the overall strategy
of the search.
For example, in our ID-GLA algorithm, the search space has a single initial state S0 ,
which consists of one residual space (the entire loading space of the container), all blocks
generated by a particular procedure (either Generate-Simple-Blocks or Generate-
Guillotine-Blocks depending on the SCLP instance to be solved), and no placed
blocks. For each state S, there are at most 8 · |S.R| · |S.B | neighbors, each corresponding
to the state after placing a block b ∈ S.B at one of the eight corners of a residual space
r ∈ S.B . Whenever a block is placed, both the total volume of free space (the union of
S.R) and the number of unloaded boxes are reduced. Hence, we will eventually reach a
state where either all boxes are loaded or no residual space large enough to accommodate

34
any unloaded boxes exists; we call such states terminal states. Clearly, any path from
the initial state to one of the terminal states has finite length. Hence, the search space is
well-defined and consists of a finite set of states and transitions. In fact, the search space
of ID-GLA is a directed acyclic graph (DAG) with one intial state (a node with in-degree
0) and a set of terminal states (nodes with out-degree 0).
All block building approaches work by exploring a region in the search space to find a
path from the initial state to some terminal state, which corresponds to a loading plan.
The process of finding a loading plan can be described as follows:

step a) start from some initial state, where the list of free spaces consists of the
container, and the list of blocks is generated (explicitly or implicitly) according to
some strategy.

step b) move to the next state by selecting a free space cuboid and a block of cargo
boxes, and placing the selected block into the selected cuboid.

step c) repeat step b) until we reach a terminal state, where there is no available
next state.

This process is usually repeated multiple times and the best loading plan found is reported
as the final solution.
Elements E1, E2 and E5 affect the number of states and transitions in the search space.
For example, consider a particular SCLP instance without the full support constraint and
two possible implementations of the ID-GLA algorithm: ID-GLA(SB) uses only simple
blocks and ID-GLA(GB) uses guillotine blocks; these two implementations differ only in
element E2. Since all simple blocks are also guillotine blocks, the search space of ID-
GLA(SB) is a subgraph of the search space of ID-GLA(GB). As another example, assume
only simple blocks are used, and consider two implementations of ID-GLA where the
first implementation tries to place blocks at the bottom four corners of a residual space
and the second implementation tries all eight corners (i.e., they use different methods for
element E5). Clearly, the search space of the first implementation is smaller than that of
the second.
The elements E3, E4 and E5 together impose an order on the transitions that are
considered in a search. E3 and E4 often appear as heuristic rules that attempt to guide
the search to promsing subregions. For example, for E3, our ID-GLA algorithm ranks
space by anchor distance, which prefer transitions that first fill residual spaces at the
corner of the container. Such a ranking function will tend to produce a continuous empty
space in the middle of the container, which is easier to utilize than small scattered residual
spaces.
The elements E3, E4 and E5 also restrict the set of transitions considered by a search.
In the search space of ID-GLA, a state S has up to 8 · |S.R| · |S.B | transitions. When

35
the Single-Best-Space scheme is used, the residual space with minimum anchor distance
is selected for the current state S. For the selected residual space, multple blocks are
considered (the exact number of blocks considered is determined by the search effort). In
this case, E3 acts like a filter that selects only a subset of transitions by residual space.
We now present the various techniques employed by the most successful existing block
building approaches for each element. Where appropriate, we will also discuss new possi-
bilities for the various elements. The techniques for E1 are summarized in Section 2.3.1
together with the options for E5 (since E5 is tightly coupled with E1). Options for gen-
erating candidate blocks are presented in Section 2.3.2. Options for selecting candidate
spaces and blocks are presented together in Section 2.3.3 since they are closely related
to each other. A few search strategies are summarized in Section 2.3.6 for E6. The em-
pirical effectiveness of the various options will be presented by means of computational
experiments in Sections 2.4 and 2.5.

2.3.1 Free Space Representation and Management Techniques

(E1)
In general, free space in the container can be represented by a set of cuboids, where each
cuboid is called a residual space. Clearly, this is true when no boxes have been loaded
into the container. As we proceed to place blocks into residual spaces, the residual spaces
that overlap with placed blocks are replaced by smaller residual spaces that represent the
remaining space. Two such representations are commonly employed by block building
approaches, namely cover representations and partition representations.
The main purpose of storing a set of residual spaces is to allow us to quickly decide
whether a block can be placed at some position inside the container. We can also store a
list of candidate positions (instead of residual spaces) as long as we devise a method to
check whether a block can be placed at a position, although block building approaches
to SCLP seldom employ such representations. In fact, the extreme point representation
of candidate positions has been commonly employed by algorithms for other variants of
2D and 3D packing problems and has been proven effective. This may be a fruitful new
direction for research.
Alternatively, the free space in the container need not be explicitly represented at all
since the locations and dimensions of the placed blocks in a state are sufficient for the
purpose of finding all possible positions where unloaded blocks can be placed. We call
this an implicit representation.

Cover Representation

In our ID-GLA algorithm, smaller residual spaces form a cover of the remaining space,
hence we call it a cover representation. In ID-GLA, when a block is placed inside a residual

36
space r, the remaining space is covered by up to six overlapping cuboids called maximal
spaces, which are the largest cuboids inside r that are interior-disjoint with the placed
block. The maximal space concept was employed by Lai and Chan [80] and subsequently
employed by Lim et. al. [81] and Parreño et. al. [11, 48]. It was also employed by the Fit
Degree algorithm by He and Huang [49] where it was referred to as action space.
In existing literature that adopts the maximal space representation of free space, blocks
are always placed at one of the eight corners of a residual space (element E5).

Partition Representation

Another common strategy is to represent the free space as a list of interior-disjoint cuboids,
which we call a partition representation. In the intial state when no boxes have been
loaded, the list consists of a single cuboid (the entire space in the container). Consider
the situation when a block is loaded into a free space. Figure 2.10 shows a single block
(the solid rectangular cuboid) that is placed in a corner of the container. The remaining
free space is partitioned into three interior-disjoint cuboids.

Figure 2.10: A single block placed in the container

(a) (b) (c)

(d) (e) (f)

Figure 2.11: Six possible partitions of the residual space

37
 There are a total of six possible partitions (see Figure 2.11). Such a partition repre-
sentation of free space was employed by the Container Loading by Tree Search (CLTRS)
algorithm [4] and commonly adopted in block building approaches [12, 51, 82]. When
this representation is used, additional rules are needed to select one out of the six possi-
ble partitions. A common heuristic is to select the partition that maximizes the largest
residual space. This is because larger spaces are easier to fill up than smaller spaces and
often result in denser packings.
This heuristic rule may be implemented in different forms. For example, we can select
the partition that maximizes the volume of the largest residual space and minimizes the
volume of new residual spaces that are too small to accommodate any box, which we call
rejected space. Let V (r) denote the volume of residual space r, and (r1, r2, r3) be the
three new residual spaces in a partition. We can rank partitions by:
X
f (r1, r2, r3) = max{V (r1 ), V (r2 ), V (r3 )} − V (r) (2.4)
rejected space r

The CLTRS algorithm employed a more complex logic, which can be described as
follows. The three residual spaces in the partition in Figure 2.11(a) are the result of
applying three cuts: the first cut is applied on the height axis and produces a residual
space on top of the placed block, the second cut on the length axis creates a residual
space to the right of the placed block, and the third cut on the width axis results in a
residual space behind the placed block. Similarly, the residual spaces in the other five
partitions are produced by applying the three cuts in different orders. Let r.L and b.L
be the dimension of the residual space r and the placed block b along the length axis,
respectively; r.L − b.L is called the reduced size (of r) along the length axis. The reduced
size along the width and height axes are similarly defined. The CLTRS algorithm sorts
the axes in descending order of reduced size and applies the cuts in that order to obtain
the residual spaces. Loosely speaking, this implementation prioritizes the axes with larger
reduced sizes to produce residual spaces with larger cross sections.
In summary, we have presented two partition representations:

Part-Eval: selects the partition that maximizes the volume of the largest residual
space and minimizes rejected volume

Part-Fanslau: selects the partition produced by applying cuts on the axes in de-
scending order of reduced size

When a partition representation is employed by existing literature, attempts are often

made to merge adjacent residual spaces. For example, in the algorithms by Fanslau
and Bortfeldt [4] and Moura and Oliveira [82], residual spaces that are too small to
accommodate any boxes (i.e., rejected spaces) are not immediately discarded. Instead,

38
when a residual space is processed, it is merged with adjacent rejected spaces if such a
merge would result in a larger space.
When this representation is used, a block is usually placed at the corner of the residual
space that is closest to the origin (element E5). In fact, if the full support constraint is not
enforced and adjacent residual spaces are not merged, placing a block at any corner will
be equivalent since the residual spaces are disjoint. When merging of adjacent residual
spaces is implemented, choosing any specific corner of the container as the origin will
result in equivalent packings.

Comparison between Cover and Partition Representations

A packing plan P is said to follow the guillotine-cut constraint if it can be divided by a

plane into two disjoint subsets P1 , P2 such that P1 and P2 are on opposite sides of the
plane, and this division can be carried out recursively until both P1 and P2 consist of
only one box. Partition representations of free space follow the guillotine-cut constraint,
but cover representations do not. Consequently, if all candidate blocks also follow the
guillotine-cut constraint, the packing plan produced by a block building algorithm that
uses a partition representation of residual spaces will likewise satisfy the guillotine-cut
constraint. In contrast, when a cover representation is used, the resulting packing plan
often does not follow the guillotine-cut constraint due to the interlocking of boxes.
In some cutting applications where a large piece of material is cut into smaller pieces,
the physical limitations of the cutting machine may prevent the blade from turning in the
middle of a cut. In such applications, it would be desirable if the packing plan satisfies
the guillotine-cut constraint, so using a partition representation is appropriate. On the
other hand, packing patterns that follow the guillotine-cut constraint are usually less
stable and hence less suitable when the application involves loading cargo into a loading
space without confining walls. For example, when loading boxes onto a pallet that is
to be transported by forklift, it is desirable to create packing patterns where the boxes
interlock.
In some applications, the primary objective is volume utilization, and neither the
guillotine-cut constraint nor stability considerations are important. In such situations,
a cover representation is often a better choice than a partition representation. This is
because there are SCLP instances where the optimal loading plans do not satisfy the
guillotine-cut constraint, and using a partition representation would eliminate certain
(possibly optimal) packing plans from the search space.
If we allow blocks to be placed in the interior of residual spaces (in addition to the
eight corners) and the candidate blocks include all single-box blocks corresponding to
every allowed orientation of each type of box, then there is a state for every valid packing
plan in the search space using a cover representation. Therefore, the search space of cover
representations are more complete than partition representations. If the search strategy

39
can take advantage of this increased completeness of the search space, higher quality
solutions can be found. Computational experiments show that ID-GLA using a cover
representation outperforms ID-GLA using a partition representation on the majority of
test sets (Section 2.5.1).
Although using a cover representation results in a more complete search space, it also
increases the complexity of space management. When a partition representation is used,
there are at most 2n + 1 residual spaces in a state S, where n is the number of blocks that
are already placed in the state, since placing one block will always consume one residual
space and introduce at most 3 new residual spaces. When a cover representation is used,
in the worst case the number of residual spaces in a state S is at most O(n6 ), since each
face of a maximal space coincides with one of the 6 faces of a placed block. Also in the
worst case, the number of residual spaces is at least Ω(n3 ) because the corner of each
residual space closest to the origin is a normal position; a box placed at a normal position
cannot be pushed towards the origin without also pushing other boxes, and there are at
least Ω(n3 ) such positions in the worst case. Although these worst case scenarios seldom
occur, there are considerably more residual spaces on average when a cover representation
is used. Hence, it requires more CPU time to process the residual spaces, which means
fewer states can be explored for a fixed amount of CPU time. Therefore, the search
strategy must be able to overcome this disadvantage in order harness the benefits of the
completeness of the search space offered by a cover representation.

Other Possible Representations

In position-based representations, a list of candidate positions where blocks can be placed

are recorded in a state instead of residual spaces. Such representations are commonly
employed in packing literature [7, 8, 83, 84], but they are seldom employed in block
building approaches. The set of positions considered may vary. For example, Crainic et.
al. [8] uses extreme points. The list of candidate positions for the initial state consists
of only the origin. Once a new box is placed at an extreme point, the extreme point is
consumed and up to six new extreme points are created in the case of 3D packing, and
up to two new extreme points are introduced in the case of 2D packing. We will describe
this representation in detail in Section 4.2.1 (page 140).

2.3.2 Candidate Blocks Generation (E2)

In both our ID-GLA algorithm and the tree search algorithm by Fanslau and Bortfeldt [4],
both simple blocks and guillotine blocks are employed, where simple blocks are a subset of
guillotine blocks. Block building approaches in earlier literature tend to use only special
subsets of simple blocks, e.g., columns and layers. Figure 2.12(a) shows the three ways
that multiple boxes (of the same type) can be arranged into columns. Since each box

40
type can be placed in up to six orientations, there are up to 18 types of columns. For
each possible type of column, there are 2 ways in which it can be expanded into layers,
as shown in Figure 2.12(b). Hence, there are 36 types of layers per box type. By this
definition, every column is a layer and every layer is a simple block.

(a) 3 ways to form columns (b) 2 ways to form layers

Figure 2.12: Columns and layers are special subsets of simple blocks

Blocks with a more complex structure than guillotine blocks can be defined. For
example, the G4-heuristic [9], which recursively divides a rectangle into 4 sub-rectangles
as shown in Figure 2.13, produces high quality solutions for two-dimensional rectangle
packing. This algorithm can be used to produce layers that are not guillotine blocks.
Although such blocks have not yet been employed by block building approaches, we
include it here for completeness of discussion.

4
2

3
1

Figure 2.13: G4 Heuristic

Finally, we define a trivial block as a block that is composed of a single box. In

summary, we have defined six types of blocks:

• simple blocks: multiple boxes of the same type arranged in the same orientation,
and can be uniquely identified by the following five attributes:

– j : the box type

– o: the orientation in which boxes are placed

41
 – nl , nw , nh: the size of the block in terms of box count along the length, width
and height directions of the container

• trivial blocks: simple blocks with nl , nw , nh equal to 1

• columns: simple blocks with at most one of nl , nw , nh greater than one

• layers: simple blocks with at most two of nl , nw , nh greater than one

• guillotine blocks: all simple blocks and resultant blocks after combining two guil-
lotine blocks along the length, width or height direction of the container

• non-guillotine blocks: blocks that cannot be obtained by combining two guillotine

blocks, e.g., some layers produced by the G4-heuristic

Candidate blocks can be either generated in advance, such as in our ID-GLA algorithm
and the container loading by tree search (CLTRS) algorithm by Fanslau and Bortfeldt
[4]; or generated on demand, such as in the reactive GRASP algorithm by Parreño et. al.
[11]. The latter is conceptually equivalent to the former. We use the reactive GRASP
algorithm to illustrate the equivalence.
The reactive GRASP algorithm first selects a residual space r. Next, for each box
type and allowed orientation, it will produce the three largest columns as shown in Figure
2.12(a) that can fit into r (subject to the availability of the remaining boxes). If there
are still more boxes available, it will then try to expand each column as much as possible
to obtain two layers as illustrated by Figure 2.12(b). Therefore, for each box type and
orientation, up to 6 layers are produced. This can be equivalently implemented as follows.
We first generate all possible columns that can fit into the container (subject to the
availability of boxes in the input), i.e., we do not only generate the largest columns. For
each column, we expand it in the two directions to generate all possible layers that can fit
into the container; once again, we do not only generate the largest layers. After a residual
space r is selected, we first filter the layers to keep only those that can fit into r and
consist of boxes not exceeding the remaining boxes. For each box type j and orientation
o, we keep six layers that are selected as follows:

• L1: the layer that maximizes nl and then maximizes nw

• L2: the layer that maximizes nw and then maximizes nh

• L3: the layer that maximizes nl and then maximizes nh

• L4: the layer that maximizes nh and then maximizes nl

• L5: the layer that maximizes nw and then maximizes nh

• L6: the layer that maximizes nh and then maximizes nw

42
 Of course, generating all blocks in advance will have a different effect on execution
time compared to generating blocks on demand. Since residual spaces with exactly the
same dimensions but at different locations will be produced during the search, generating
all blocks in advance avoids redundant computation due to such repetitions. On the
other hand, generating blocks on demand will avoid generating blocks that will never be
used. For simple blocks, these two approaches may not produce a significant difference
in execution time. However, for more complex blocks such as non-guillotine blocks, the
difference in execution time may be substantial.

Impact of using Larger Blocks

The main effect of using larger blocks is to introduce shortcuts in the search space. For
example, in our ID-GLA algorithm, as long as all trivial blocks are included in the list
of candidate blocks, adding larger blocks such as simple blocks and guillotine blocks will
not change the number of states in the search space. However, adding large blocks will
allow us to navigate from one state to a “distant” state in a single move that would
otherwise require several moves. The net effect of introducing large blocks with high
volume utilization is to compress the average height of the search trees. Its effectiveness
can be explained by the following example. Placing a guillotine block consisting of k simple
blocks is equivalent to placing the k simple blocks sequentially, provided the placements
corresponding to reconstructing the guillotine block are made at each of the k steps.
However, there are many different ways in which the k simple blocks can be placed, and
the probability of making k consecutive placements that lead to a state where the boxes
are compactly packed diminishes quickly as k grows. Hence, introducing large blocks with
high volume utilization greatly increases the odds of navigating from a promising state to
another promising state, and results in search trees with much smaller heights on average.
Introducing more transitions into the search space is a double-edged sword. Since the
search space of a typical SCLP instance is extremely large, we are only able to explore a
very small portion of the search space in a reasonable amount of computation time. No
matter what search strategy is used, we are only able to explore a few transitions per
state on average (although it is possible to explore many transitions for a few states).
Introducing too many transitions to every state may increase the probability of guiding
the search towards a wrong direction in the early stages, which would ultimately result
in a poor solution. The right balance can only be determined through computational
experiments. Our experiment in Section 2.5.2 has shown that simple blocks are more
effective for weakly heterogeneous SCLP instances (where there are few box types and
many boxes per type) and guillotine blocks are more effective for strongly heterogeneous
SCLP instances (where there are many box types with few boxes per type).
The use of larger blocks also helps to mitigate the difficulty of designing a good heuris-
tic function. The landscape of the search space of SCLP is extremely flat, so it is a very

43
challenging task to design a good heuristic function that can determine a good search
direction. For every loading plan, there is an equivalent gapless loading plan, where the
start coordinates of a box is either 0 or the end coordinates of another box for each axis
[85]. The projection of a loading plan with n boxes on an axis is a set of n intervals,
which can be represented by an interval graph, where every node represents an inter-
val, and there exists an edge between two nodes if their corresponding intervals overlap.
Therefore, every gapless loading plan corresponds to three interval graphs (one for each
axis). There are about n! interval graphs with n nodes up to isomorphism [86] (i.e., if
we permute the labels of the nodes in a graph to obtain another graph, these two graphs
are considered identical). With three dimensions there could be as many as (n!)3 possible
interval graph representations, and since there are n! ways to assign boxes to nodes in
the interval graphs, there could be up to n! × (n!)3 = (n!)4 loading plans. However, the
number of possible volume utilization values is at most 2n since every box must either be
in the container or not. Hence, the number of possible loading plans dwarfs the number
of possible evaluations, which suggests a very flat search landscape. This type of search
topology means that hill-climbing or gradient descent methods are unpromising since it is
difficult to find clearly superior solutions in a localized search. However, the introduction
of blocks with high volume utilization allows search algorithms to examine promising lo-
cales at more distant areas of the search landscape in each step, and therefore potentially
makes search techniques more effective.

2.3.3 Residual Space Selection (E3)

The space selection method for all existing block building algorithms is similar to the one
used by our ID-GLA algorithm, i.e., we select the top m1 spaces according to some ranking
function. The differences lies in how m1 is determined and how the ranking function is
defined. In ID-GLA, if the Multi-Best-Space scheme is used, m1 is determined by the
search effort w. If the Single-Best-Space scheme is used, m1 is always 1. For existing
block building approaches, m1 is always 1.
In ID-GLA, the ranking function prefers to fill residual spaces that are close to the
corners, which tends to leave empty space in the middle. This heuristic rule is commonly
adopted by algorithms that employ the maximal space representation of residual space [11,
49, 78, 87, 88], although the exact implementations differ. In our ID-GLA algorithm, we
used anchor distance (see Figure 2.6) to measure the distance between a residual space and
the closest corner of the container, where the distance between two points is measured by
Manhattan distance. Parreño et. al. [11] tried two alternative implementations of anchor
distance, where Manhattan distance is replaced by Euclidean distance and lexicographic
distance, respectively. The lexicographic distance between two points (x1 , y1 , z1 ) and
(x2 , y2 , z2 ) is defined as a vector consisting of three components which are |x1 − x2 |,

44
|y1 − y2 | and |z1 − z2 | sorted in ascending order. For each corner of a residual space,
the nearest corner of the container is found, and the lexicographic distance is computed
between these two corners, resulting in a total of eight lexicographic distance vectors. The
minimum distance in lexicographical order is taken as the anchor distance. In summary,
there are three implementations of anchor distance:

• ADM: anchor distance using Manhattan distance between two points

• ADE: anchor distance using Euclidean distance between two points

• ADL: anchor distance using lexicographic distance between two points

When a partition representation is employed, residual spaces are often processed in

a specific order. We describe the scheme used by the CLTRS algorithm by Fanslau and
Bortfeldt [4] as an example. When a block is placed in a residual space, three new residual
spaces are generated by three cuts. The residual spaces generated by the first, second
and third cut are called the max, med and min space, respectively. The spaces are pushed
onto a stack in the following order: min space, max space, med space. At any state, the
space at the top of the stack is popped out and processed. This particular push order
aims to serve two purposes [4, first paragraph, left column, page 230]: 1. if the max or
med space is too small to accommodate any box, part of them can be merged with the
min space when the min space is processed, which will enlarge the small space; and 2.
medium spaces are filled before large spaces since large spaces are generally easier to fill.
The stack implements the ranking function; if we interpret the position of a residual space
in the stack (ordered from top to bottom) as a rank for the residual space, CLTRS selects
the residual space that minimizes this rank.

2.3.4 Candidate Block Selection (E4)

All existing block building approaches first select a residual space, and then select a few
blocks for the selected residual space according to some fitness measure (only blocks that
can fit into the residual space are considered). In our ID-GLA algorithm, the fitness mea-
sure consists of three components: 1. the volume V of the block, which is the immediate
gain if we place the block; 2. an estimation of potential loss Vloss that might occur later
in the search; and 3. the wasted space Vwaste inside the block. We prefer blocks with
large immediate gain, and small potential loss and wasted space, i.e., our fitness measure
is f (r, b) = V + α · (Vloss + Vwaste ), where α controls the relative emphasis on immediate
gain compared to potential loss. In the CLTRS algorithm, the fitness measure is simply
the volume of the block, which is equivalent to our fitness measure with α = 0.
Parreño et. al. [11] studied two fitness measures. The first is largest-volume, which
prefers blocks with larger volume (equivalent to our fitness measure with α = 0). The

45
 dy

dx
dz

Figure 2.14: Calculating best fit

second is called best-fit, which first takes the distances along the three axes dx, dy and dz
between the block and the residual space as shown in Figure 2.14. These distances are then
sorted in ascending order into a fitness-triplet (d1 , d2 , d3 ). A block with a lexicographically
smaller fitness-triplet is considered a better fit since a block with fitness-triplet (0, 0, 0)
will occupy the entire residual space, and a block with fitness-triplet (0, 0, d3 ) will fully
occupy two dimensions of the residual space, etc. When two blocks have the same fitness
measure, the block that consists of a smaller number of boxes is preferred.

2.3.5 Asymmetry in Space and Block Selection

Existing block building approaches place a greater emphasis on block selection (E4) than
residual space selection (E3). In existing block building approaches, only one residual
space is selected for the current state using some fixed rule (or, equivalently, using some
ranking function). Once a residual space is selected, one of the eight corners is automati-
cally designated as the position to place a block. A few blocks are then selected according
to a fitness measure and tried in the search process. Recall that a transition from a state s
is a triplet (r, b, p) representing placing the block b at position p inside a residual space r.
The set of all possible transitions from a state are dots distributed in a two-dimensional
space (since p fully depends on r), which we call the transition space. All existing block
building approaches only try a few transitions that lie on the same line in this transition
space.
The residual spaces and candidate blocks play symmetric roles from the transition
space point of view. This symmetry opens up new research directions, which may lead to
new and more effective algorithms for SCLP.
From the transition space point of view, all existing block building approaches carry
out search in the dimension corresponding to candidate blocks. Conceptually, we could
instead select a block first, and then carry out a search along the dimension corresponding
to residual spaces. For example, a technique that selects, say, the largest block in each
iteration, and then searches for the best residual space (and corresponding corner) to
place the block would follow this strategy.
In fact, many simple constructive heuristics in earlier literature (that loads one box at
a time) uses this technique. A typical bottom left fill heuristic for 2D rectangular packing

46
[89] works as follows. Boxes are sorted in descending order of volume and loaded one at a
time. When a box is loaded, we try to place it at the bottommost leftmost valid position.
A typical best-fit heuristic [8] tries to place the current box at a position that maximizes
a certain fitness measure. Since such heuristics process one box at a time according to a
loading sequence, we call them sequence based constructive heuristics.
Sequence based constructive heuristics can be easily converted into a tree search pro-
cedure if we try the top k positions instead. They can also be embedded into an iterative
local search framework, where in each iteration a new loading sequence is produced based
on the loading sequence in the previous iteration, and the loading sequence is converted
into a packing plan by invoking constructive heuristics. Such a strategy often produces
high quality solutions for 2D and 3D bin packing problems (Section 4.2). If we can adapt
such algorithms to place one block at a time, we may obtain a more effective algorithm
for certain applications.
It is also logical to carry out the search in both dimensions of the transition space
simultaneously. For example, in our ID-GLA algorithm, the Multi-Best-Space scheme
tries multiple residual spaces, and for each residual space multiple candidate blocks will
be tried. Although ID-GLA with the Multi-Best-Space scheme does not outperform ID-
GLA with the Single-Best-Space scheme, allocating half the CPU time to each scheme
and taking the better solution outperforms either scheme alone (Section 2.5.6).

2.3.6 Search Strategy (E6)

Iterative-Doubling Greedy Look Ahead

The overall search strategy in our ID-GLA algorithm is called iterative-doubling greedy
look ahead. In each iteration, a loading plan is created by a greedy look ahead tree search,
i.e., a two-step look ahead tree search is invoked to determine the best transitions for a
state, and the loading plan is created by greedily following the best transitions suggested
by the two-step look ahead tree search at each step starting from the initial solution.
Multiple iterations of this greedy look ahead tree search are performed with the search
effort doubled in each succeeding iteration.

Container Loading by Tree Search

The Container Loading by Tree Search (CLTRS) algorithm by Fanslau and Bortfeldt
[4] is similar to ID-GLA, except that the two-step look ahead tree search is replaced
by Partition Controlled Tree Search (PCTS). Furthermore, CLTRS is performed in two
stages, where the first stage uses simple blocks and the second stage uses guillotine blocks;
the two stages are otherwise identical.
PCTS selects the best transition for a state s as follows. Assuming at least minChildCount
successors are generated at each node of the search tree, and the total number of nodes

47
in the search is limited by search effort w, then the maximal depth of search maxDepth
is given by:

maxDepth = max{1, blogminChildCount wc} (2.5)

The authors set minChildCount = 3. For example, when w = 32, then maxDepth = 3
based on Equation (2.5). The set of all ordered partitions of the integer maxDepth is
given by

π = {(d1 , d2 , . . . , dk ) | d1 + d2 + · · · + dk = maxDepth, di ∈ Z+ } (2.6)

In this example, π = {(3), (2, 1), (1, 2), (1, 1, 1)}. For every partition, a separate search
is carried out (See Figure 2.15(a)) to select the best trantitions for s and compute an
associated score. The transition with highest score is then selected as the best transition
for s.
For a partition that consists of k elements (d1 , d2 , ..., dk ), the search has k phases,
where the i-th phase is a tree search with depth di . The branching factor in the i-th
phase is given by:
√
mi = max{minChildCount, b di wc} (2.7)

The best node at depth di of the i-th phase becomes the root node of the (i + 1)-th phase.
For example, the search corresponding to the partition (2, 1) is shown in Figure 2.15(b).
The tree search in the first phase is of depth 2, and the second phase is of depth 1. The
branching factors for phases 1 and 2 are calculated to be 5 and 32, respectively. The 25
nodes at depth d1 = 2 in the first phase are extended using a greedy heuristic, resulting
in 25 complete solutions. The greedy heuristic repeatedly chooses the largest block and
∗
places it into the residual space on top of the stack. Assuming S3,12 is the packing with
highest volume utilization among the 25 completed packing solutions, then S3,12 becomes
the root node in the second phase of the tree search. The 32 nodes at depth d2 = 1 in the
second phase are extended to form 32 complete solutions using the same greedy heuristic.
∗
Assuming S4,4 is the best complete solution in the second phase, then the transition from
S1,1 to S2,3 is selected as the best transition for the partition (2, 1), where the volume
∗
utilization of S4,4 serves as the score.

Reactive Greedy Randomized Adaptive Search Procedure (RGRASP)

The Reactive Greedy Randomized Adaptive Search Procedure (RGRASP) by Parreño

et. al. [11, section 3, page 415] is an iterative procedure where each iteration consists
of a construction phase and an improvement phase. The behavior of the construction
phase is controlled by a parameter δ that is selected randomly from a set of candidates.
The probability of selecting each candidate is updated every 500 iterations based on past

48
 td=3

(3) (2,1) (1,2) (1,1,1)

d1 = 1 d1 = 1
m1 = 32 m1 = 32
d1 = 2
m1 = 5 d2 = 1
d1 = 3 m2 = 32
m1 = 3 d2 = 2
d2 = 1 m2 = 5 d3 = 1
m2 = 32 m3 = 32

(a) PCTS with w = 32

S1,1

S2,1 S2,2 S2,3 S2,4 S2,5

S3,1 ... ... ... ... S3,25

S3,12 d1 = 2
m1 = 5
S*3,1 S*3,12 S*3,25
S3,12

…... …... d2 = 1
S4,1 S4,4 S4,32
m2 = 32
S*4,1 S*4,4 S*4,32

(b) Search tree for partition (2, 1)

Figure 2.15: An example of PCTS

49
performance, which is the reactive aspect of RGRASP. The details of RGRASP are given
in Algorithm 6.
Both the construction phase and the improvement phase make use of a greedy ran-
domized construction (GRC) procedure. In GRC, the solution is constructed step by step.
In each step, the residual space that minimizes ADL (anchor distance using lexicographic
distance between two points, Section 2.3.3) is selected. Blocks that can fit into the se-
lected residual space are ranked by either largest-volume or best-fit in descending order.
The top 100δ% blocks (at least one) are selected to form a set of restricted candidates.
One block is then selected uniformly randomly from the restricted candidates, and the
selected block is placed at the anchor corner of the selected residual space. The parameter
δ ∈ [0, 1] controls the randomness of the GRC procedure; when δ = 0 GRC becomes a
hill-climbing greedy algorithm, and when δ = 1 GRC becomes a purely random walk.
The improvement phase is activated if a promising soluiton is found by the construction
phase (line 12). In the improvement phase, the last 50% of the placed blocks in the
solution are unloaded. The partial solution is then converted into two complete solutions
by a greedy method (i.e., invoking GRC with δ = 0). In the first invocation, the block
with largest volume is selected in each step; in the second invocation, the block with
best-fit is selected in each step.

2.4 Test Instances and Experimental Setup

There are 16 sets of test cases (BR0-BR15) that are commonly employed by existing
SCLP literature as a test bed. BR1-BR7 were generated by Bischoff and Ratcliff [14],
while BR0 and BR8-BR15 were generated by Davies and Bischoff [23]. Each set consists
of 100 instances. The 16 sets of instances are ordered by increasing heterogeneity of box
assortment, i.e., from BR0 to BR15 the number of box types increases. All of the test
sets also impose a variety of restrictions on the possible orientations for individual boxes,
which may be different for different boxes in the same test instance.
Table 2.1 summarizes the characteristics of the test data. The column avg box# gives
the average number of boxes in each instance in the set, box type# gives the number of
box types, and avg box# per type is the ratio of the previous two columns. The test sets
are broadly classified into three categories in existing literature: BR0 consists of only one
type of box (homogeneous), BR1-7 consists of a few types of boxes per instance (weakly
heterogeneous), and BR8-BR15 consists of up to 100 types of boxes per instance (strongly
heterogeneous). It is well known that strongly heterogeneous instances are considerably
more challenging than weakly heterogeneous instances. In addition, earlier algorithms
were only tested on sets BR1-7. Hence, we report the averages over test sets BR1-7,
BR8-15 and BR1-15 in addition to the average for each test set.
According to our conceptual model, ID-GLA can be dissected into six elements. We

50
Algorithm 6 Reactive Greedy Randomized Adaptive Search Procedure

ReactiveGRASP(maxIter )
1 D = {0.1, 0.2, ..., 0.9} // the set of candidates for δ
2 Vb = 0, Vw = ∞ // the box volume in the best and worst solution found
3 nδ = 0, ∀δ ∈ D // number of invocations of GRC using δ
4 Vδ = 0, ∀δ ∈ D // total volume of boxes in solutions obtained with δ
5 pδ = 1/|D|, ∀δ ∈ D // probability of choosing δ
6 iter = 0
7 bestSol = NULL
8 while iter < maxIter
// Construction Phase
9 Choose δ from D with probability pδ
10 S = Invoke GRC with δ and rank blocks by largest-volume
11 V = volume of loaded boxes in S

// Improvement Phase
12 if V ≥ Vw + 0.5(Vb − Vw )
13 Remove last 50% of blocks from S to obtain PS
14 Invoke GRC with δ = 0 and rank blocks by largest-volume on PS
to obtain S 0 with volume V 0
15 if V 0 > V then (S, V ) = (S 0 , V 0 )
16 Invoke GRC with δ = 0 and rank blocks by best-fit on PS
to obtain S 00 with volume V 00
17 if V 00 > V then (S, V ) = (S 00 , V 00 )

// update past performance

18 if V > Vb then (bestSol , VB ) = (S, V )
19 if V < Vw then Vw = V
20 nδ = nδ + 1
21 Vδ = Sum δ + V

// react to past performance

22 if iter (mod 500) = 0
23 mean δ = Vδ /nδ , ∀δ ∈ D
10
24 P − Vw )/(Vb − Vw )) , ∀δ ∈ D
eval δ = ((mean
25 TotalEval = δ∈D eval δ
26 pδ = eval δ /TotalEval , ∀δ ∈ D.
27 return BestSol

51
 set avg box# box type# avg box# per type
BR00 205.8 1 205.8
BR01 150.4 3 50.1
BR02 136.7 5 27.3
BR03 134.3 8 16.8
BR04 132.9 10 13.3
BR05 132.9 12 11.1
BR06 131.5 15 8.8
BR07 130.3 20 6.5
BR08 130.7 30 4.4
BR09 128.9 40 3.2
BR10 130.2 50 2.6
BR11 129.5 60 2.2
BR12 130.3 70 1.9
BR13 130.4 80 1.6
BR14 130.0 90 1.4
BR15 129.9 100 1.3
avg. 1-7 135.6 10.4 19.1
avg. 8-15 130.0 65.0 2.3
avg. 1-15 132.6 39.5 10.2

Table 2.1: Chracteristics of 1600 BR test instances

first analyze the impact of varying each element to identify the best choices for each
element in Section 2.5. For this purpose, we selected 160 instances (the first ten instances
from each set) to form a smaller test bed. Using a smaller test bed allows a broader range
of experiments to be conducted since each experiment takes much less time to complete
compared to using the complete test sets. It also reduces the risk of over-fitting of our ID-
GLA algorithm to the test data; it is well known in the artificial intelligence community
that an over-fitted algorithm may not work well for instances outside the test bed.
We then compare our final version of ID-GLA to the best performing SCLP algorithms
in the literature based on the entire 1600 test instances and report the detailed results in
Section 2.6.
Our ID-GLA algorithm was implemented as a sequential Java program and compiled
using the 64-bit Java Development Kit 1.6.0 from Oracle. All experiments were conducted
on a rack mounted server with Intel Xeon E5520 Quad-Core CPUs clocked at 2.27GHz.
The operating system is CentOS linux version 5. Since our ID-GLA algorithm is fully
deterministic, we execute it only once for each problem instance.

52
2.5 Calibration of ID-GLA
According to our conceptual model, ID-GLA can be dissected into six elements. In this
section, we analyze the impact of varying each element. We will vary one element at a
time while keeping the choice made for other elements unchanged. The base version of
ID-GLA is configured as follows:

• Residual Space Representation (E1): We use the cover representation

• Candidate Block Generation (E2): Up to 10,000 blocks are generated in ad-

vance. For weakly heterogeneous instances, only simple blocks are generated; for
strongly heterogeneous instances, guillotine blocks with volume utilization at least
98% are generated. An instance is considered weakly heterogeneous if the average
number of boxes per type is greater than six

• Space Selection (E3): Rank residual spaces by ADM (anchor distance using
Manhattan distance between two points). The Single-Best-Space scheme is used,
i.e., for each state only one best residual space is selected

• Block Selection (E4): Rank blocks by fitness function f (r, b) = V + α · (Vloss +

Vwaste ) (page 28), where α = −1

• Block Placement (E5): The selected block is placed at the anchor corner of the
selected residual space

• Search Strategy (E6): Iterative doubling greedy with two-step look ahead

• Termination Condition: For every instance, the candidate blocks are first gener-
ated, then 32 CPU seconds are allocated for the search phase. The algorithm stops
when the time limit is reached

The impact of using different residual space representations is reported in Section

2.5.1. We investigate the effect of using various block types in Section 2.5.2. Section 2.5.3
analyzes the impact of different ranking functions to select residual spaces. The effect of
using different fitness measures for selecting blocks is reported in Section 2.5.4, and the
impact of using different overarching search strategies is reported in Section 2.5.5. Finally,
the impact of placing a greater emphasis on space selection is investigated in 2.5.6.

2.5.1 Impact of Residual Space Representation and Manage-

ment (E1,E5)
The base version of ID-GLA will be referred to as the Cover version, as it uses a cover
representation of residual spaces. In addition, we implemented two versions of ID-GLA
that uses partition representations:

53
 • Part-Eval: the partition representation where the partition that maximizes the
volume of the largest residual space and minimizes rejected volume is selected (see
page 38). For E5, when blocks are placed inside a residual space, only the corner
closest to the origin is considered (unlike in the base version, where all eight corners
are considered)

• Part-Fanslau: the partition representation where the partition is produced by ap-

plying cuts on the axes in descending order of reduced size (see page 38). This
implementation also differs from the base version in residual space selection. Specif-
ically, residual spaces are stored in a stack and the space on top of the stack is
selected

Table 2.2 compares the three versions of ID-GLA based on the smaller test bed con-
sisting of 160 instances. For each algorithm, the average volume utilization over the 10
instances in each test set is reported. Since the 16 test sets are commonly classified into
three groups by heterogeneity of boxes into BR0 (homogeneous), BR1-7 (weakly hetero-
geneous) and BR8-15 (strongly heterogeneous) in existing literature, we also report the
averages over BR1-7, BR8-15 and BR1-15 in the last three rows.

set Cover (%) Part-Eval (%) Part-Fanslau (%)

BR00 87.25 86.34 86.35
BR01 94.71 94.10 93.97
BR02 95.82 95.02 95.19
BR03 95.82 95.33 94.96
BR04 95.79 94.54 94.87
BR05 95.49 94.49 94.81
BR06 95.27 94.20 94.44
BR07 95.09 93.82 93.94
BR08 94.03 93.06 93.44
BR09 93.92 93.26 93.26
BR10 93.83 92.89 93.11
BR11 93.80 92.42 92.95
BR12 93.44 92.08 92.56
BR13 93.17 92.13 92.68
BR14 93.19 92.14 92.56
BR15 93.33 92.42 92.36
avg. 1-7 95.43 94.50 94.60
avg. 8-15 93.59 92.55 92.86
avg. 1-15 94.45 93.46 93.67

Table 2.2: Volume utilization of best solutions by ID-GLA using various residual space
representations, averaged over the first 10 instances of test sets BR0-15

54
 We plotted the average volume utilization of the three algorithms over test sets BR1-
BR15 in Figure 2.16. We can see that as the heterogeneity of the boxes increases, the per-
formance of all three algorithms increases initially and then decreases. This is consistent
with results reported in existing literature. We can also see that the cover representation
outperforms both partition representations on the majority of test sets. This is likely due
to the completeness of the search space offered by the cover representation (Section 2.3.1).

96

95.5

95

94.5
Cover
94
Part-Eval
93.5
Part-Fanslau
93

92.5

92
BR09
BR10
BR11
BR01
BR02
BR03
BR04
BR05
BR06
BR07
BR08

BR12
BR13
BR14
BR15

Figure 2.16: Volume utilization of best solutions by ID-GLA using various residual space
representations, averaged over the first 10 instances of test sets BR1-15

2.5.2 Impact of Using Various Block Types (E2)

We will refer to the base version of ID-GLA as the SB GB version, which signifies that it
generates simple blocks as candidates for an SCLP instance when the average box count
per box type is greater than six, and generates guillotine blocks otherwise. In addition, we
implemented six versions of ID-GLA that generates different types of blocks as candidates
(as described in Section 2.3.2):

• GB: guillotine blocks

• SB: simple blocks

• SL: (simple) layers of boxes

• C: columns of boxes

• B: trivial blocks that consist of a single box

• 6L: the blocks used by Parreño et. al. [11], i.e., up to six layers (L1 - L6 defined in
Section 2.3.2) are generated for each orientation of a box type. When this type of
blocks is used, blocks are generated dynamically for the selected residual space

55
 Except for 6L, the sets of candidate blocks are listed in decreasing order in two senses.
Firstly, in terms of cardinality, B ⊆ C ⊆ · · · ⊆ GB . Table 2.3 reports the average number
of blocks generated for the first 10 instances in test sets BR0-15, which are plotted into
a graph in Figure 2.17. Secondly, in terms of the number of boxes per block (or volume
of boxes per block), GB contains blocks that are larger than blocks in SB , etc. Table
2.4 reports the number of boxes per block. For every instance, the average box count per
block is first computed, and then we compute the average over the first 10 instances in
each test set. The corresponding plot is shown in Figure 2.18.

set GB SB SL C B
BR00 1184.3 631.1 279.0 11.4 3.8
BR01 6213.9 1382.7 959.5 38.4 12.8
BR02 8009.8 1842.2 1448.9 69.9 23.3
BR03 8322.8 1884.8 1643.5 108.0 36.0
BR04 8459.8 1922.0 1757.3 138.0 46.0
BR05 8845.3 1821.0 1712.0 166.2 55.4
BR06 8866.3 1945.4 1865.0 207.6 69.2
BR07 9054.0 1823.3 1783.3 274.2 91.8
BR08 9199.2 1782.8 1769.7 396.8 134.7
BR09 9187.0 1405.2 1403.4 492.3 178.1
BR10 9277.8 1285.4 1285.0 575.7 222.7
BR11 9355.2 1145.1 1145.0 619.5 267.8
BR12 9173.7 1054.9 1054.9 649.8 311.7
BR13 9509.1 1019.7 1019.7 694.0 357.2
BR14 9054.1 904.3 904.3 672.7 402.2
BR15 7862.8 821.7 821.7 665.3 448.2
avg. 1-7 8253.1 1803.1 1595.6 143.2 47.8
avg. 8-15 9077.4 1177.4 1175.5 595.8 290.3
avg. 1-15 8692.7 1469.4 1371.5 384.6 177.1

Table 2.3: Average block count over the first 10 instances of test sets BR0-BR15

Since the 6L strategy maximizes the size of layers subject to box availability and the
cross section of the residual space, in terms of cardinality 6L blocks are smaller than
layers and not larger than columns. In terms of box count, the blocks produced by the
6L strategy are larger than the average layer.
Table 2.5 compares the seven versions of ID-GLA based on the smaller test bed com-
prising 160 instances. For each algorithm, the average volume utilization over 10 instances
in each test set is reported. The averages over test sets BR1-7 (weakly heterogeneous
SCLP instances), BR8-15 (strongly heterogeneous SCLP instances) and BR1-15 (all SCLP
instances except homogeneous instances) are given in the last three rows.

56
 10000
9000
8000
7000
GB
6000
SB
5000
4000 SL
3000 C
2000 B
1000
0

Figure 2.17: Average block count over the first 10 instances of test sets BR0-BR15

set GB SB SL C B
BR00 35.6 35.1 15.1 5.6 1.0
BR01 31.6 18.8 14.8 6.0 1.0
BR02 23.6 13.7 12.0 6.0 1.0
BR03 16.5 9.4 8.7 5.7 1.0
BR04 14.1 7.7 7.3 5.6 1.0
BR05 12.3 6.5 6.2 5.2 1.0
BR06 10.2 5.8 5.6 5.0 1.0
BR07 9.1 4.7 4.6 4.4 1.0
BR08 7.2 3.8 3.7 3.7 1.0
BR09 6.9 3.0 3.0 2.9 1.0
BR10 6.3 2.5 2.5 2.6 1.0
BR11 6.1 2.2 2.2 2.3 1.0
BR12 5.9 2.0 2.0 2.1 1.0
BR13 5.8 1.9 1.9 1.9 1.0
BR14 6.2 1.7 1.7 1.7 1.0
BR15 5.7 1.5 1.5 1.5 1.0
avg. 1-7 16.8 9.5 8.5 5.4 1.0
avg. 8-15 6.3 2.3 2.3 2.3 1.0
avg. 1-15 11.2 5.7 5.2 3.8 1.0

Table 2.4: Average box count per block over first 10 instances of test sets BR0-15

57
 35.0

30.0

25.0
GB
20.0
SB
15.0 SL

10.0 C
B
5.0

0.0

Figure 2.18: Average box count per block averaged over the first 10 instances of test sets
BR0-BR15

set SG GB (%) GB (%) SB (%) SL (%) C (%) B (%) 6L (%)

BR00 87.25 87.10 87.25 87.14 86.32 86.45 85.47
BR01 94.71 94.70 94.71 94.89 92.39 91.29 87.66
BR02 95.82 95.79 95.82 95.67 92.60 91.27 88.64
BR03 95.83 95.57 95.83 95.86 91.77 89.83 90.67
BR04 95.79 95.47 95.79 95.42 90.28 89.48 90.28
BR05 95.49 95.64 95.49 95.39 90.06 89.73 89.98
BR06 95.28 95.18 95.28 95.13 88.71 89.66 88.83
BR07 95.02 94.97 94.86 94.97 88.58 89.39 89.36
BR08 94.48 94.48 94.27 94.24 89.58 89.08 89.66
BR09 94.24 94.24 93.77 93.81 91.19 89.29 91.47
BR10 93.83 93.83 93.09 92.90 91.63 89.87 91.21
BR11 93.60 93.60 92.67 92.70 91.91 89.82 91.89
BR12 93.23 93.23 92.25 92.33 91.70 89.77 91.50
BR13 93.21 93.21 91.73 91.66 91.02 90.26 90.98
BR14 92.92 92.92 91.35 91.18 91.16 89.82 91.08
BR15 92.43 92.43 91.05 91.26 90.95 90.47 91.01
avg. 1-7 95.42 95.33 95.40 95.33 90.63 90.09 89.35
avg. 8-15 93.49 93.49 92.52 92.51 91.14 89.80 91.10
avg. 1-15 94.39 94.35 93.86 93.83 90.90 89.93 90.28

Table 2.5: Volume utilization of best solutions by ID-GLA using various types of candidate
blocks, averaged over the first 10 instances of test sets BR0-15

58
 We also plotted the average volume utilization of the six algorithms (excluding the
base version) over test sets BR1-BR15 in Figure 2.19. This allowed us to make a few
interesting observations.

96.00
95.00
94.00
GB
93.00
SB
92.00
SL
91.00
C
90.00
B
89.00
6L
88.00
87.00

Figure 2.19: Volume utilization of best solutions by ID-GLA using different types of
candidate blocks, averaged over the first 10 instances of test sets BR1-15

Firstly, except for 6L, ID-GLA produces better solutions over all 160 test cases when
using larger candidate blocks. In particular, the three versions of ID-GLA using guillotine
blocks (GB), simple blocks (SB) and layers (SL) produce much better solutions than the
two versions of ID-GLA using columns (C) and single boxes (B) on test sets BR1-BR10.
This may be due to the shortcuts introduced into the search space by larger blocks (in
terms of box count). As explained in Section 2.3.2 (page 43), such shortcuts increase the
odds of transitioning to states with compact local arrangements of boxes and hence lead
to high quality solutions.
Secondly, from BR10 to BR15, the performance difference between using simple blocks,
layers, columns, and 6L diminishes as heterogeneity increases. This is because both the
number of blocks (Figure 2.17) and average box count per blocks (Figure 2.18) are similar
for these sets.
Thirdly, for test sets BR1-7, the best solutions are obtained by using simple blocks;
using larger blocks such as guillotine blocks slightly reduces the quality of solutions. One
possible explanation is that there are many more guillotine blocks than simple blocks.
Having too many choices for each state increases the difficulty of making correct decisions
in the early stages of the search, which increases the probability of guiding the search into
a suboptimal region of the search space. Another possible reason is that guillotine blocks
that are not simple blocks usually include wasted volume, hence moving from one state
to another state using guillotine blocks will increase the total amount of wasted volume
most of the time. The wasted volume accumulates and eventually leads to solutions with
lower volume utilization.

59
 Finally, the performance results on test sets BR11-BR15 suggest that as the hetero-
geneity of instances increase, the upside of using larger blocks outweighs its downside,
i.e., using guillotine blocks outperforms simple blocks by a large margin.
Since simple blocks perform best when heterogeneity is low and guillotine blocks per-
form best when heterogeneity is high, we would like to combine the strengths of both
strategies. We used average box count per box type to measure the heterogeneity of in-
stances (this measure is easy to compute). When the average box count per box type is
greater than 6 (the majority of instances in BR0-7 fall into this category) we use simple
blocks, otherwise we use guillotine blocks. Experimental results show that this strategy
achieves better results than using simple blocks or guillotine blocks alone on the majority
of test sets (Figure 2.20).

96.00
95.50
95.00
94.50
94.00
GB
93.50
93.00 SB
92.50 SG_GB
92.00
91.50
91.00

Figure 2.20: ID-GLA base version (SB GB) vs ID-GLA using SB or GB alone: volume
utilization of best solutions, averaged over the first 10 instances of test sets BR1-15

2.5.3 Impact of Ranking Functions for Residual Space Selection

(E3)
The base version of ID-GLA will be referred to as the ADM version, as the anchor distance
used to select residual spaces is the Manhattan distance between two points. In addition,
we implemented two other versions of ID-GLA:
• ADE: select residual space by anchor distance using Euclidean distance between
two points

• ADL: select residual space by anchor distance using lexicographic distance between
two points
Table 2.6 reports the volume utilization of the best solutions found by the three ver-
sions of ID-GLA, averaged over the first 10 instances of test sets BR0-15. Except for BR0,

60
the result is also plotted in Figure 2.21. We can see that both ADL and ADM perform
noticeably better than ADE, and ADM performs slightly better than ADL on the major-
ity of test sets. Since Manhattan distance is also simpler to compute than lexicographic
distance, we decided to use ADM in our final version of the ID-GLA algorithm.

set ADE (%) ADL (%) ADM (%)

BR00 87.07 87.25 87.25
BR01 94.73 94.69 94.71
BR02 95.65 95.76 95.82
BR03 95.30 95.91 95.82
BR04 95.57 95.69 95.79
BR05 94.97 95.41 95.49
BR06 94.97 95.24 95.28
BR07 94.52 94.69 95.12
BR08 93.31 94.00 94.07
BR09 93.42 94.00 93.92
BR10 92.68 93.45 93.83
BR11 92.71 93.50 93.80
BR12 92.39 93.20 93.46
BR13 92.02 93.14 93.17
BR14 92.52 92.80 93.19
BR15 92.10 93.00 93.33
avg. 1-7 95.10 95.34 95.43
avg. 8-15 92.64 93.38 93.60
avg. 1-15 93.79 94.30 94.45

Table 2.6: Volume utilization of best solutions by ID-GLA using various space selection
strategies, averaged over the first 10 instances of test sets BR0-15

2.5.4 Impact of Fitness Measure for Block Selection (E4)

In the base version of ID-GLA, a given block b is ranked for loading into a residual space
r using the fitness function f (r, b) = V + α · (Vloss + Vwaste ), where V is the total volume
of the block, Vloss is an estimation of potential future volume loss, Vwaste is the amount of
wasted volume in the block, and α = −1 is a coefficient (see page 28). Since this function
primarily ranks blocks by volume, we refer to our base version as volume-fit (α = −1). In
addition, we implemented four other versions of ID-GLA:

• volume-fit (α = 0): prefer blocks with larger volume; this is the fitness measure
used by Fanslau and Bortfeldt [4] and one of the two fitness measures used by
Parreño et. al. [11]

61
 96.00

95.50

95.00

94.50
ADE
94.00
ADL
93.50
ADM
93.00

92.50

92.00

Figure 2.21: Volume utilization of best solutions by ID-GLA using various space selection
strategies, averaged over the first 10 instances of test sets BR1-15

• volume-fit (α = −0.5): prefer blocks with larger volume while slightly penalizing
blocks that incur volume loss

• volume-fit (α = −2): prefer blocks with larger volume while greatly penalizing
blocks that incur volume loss

• best-fit: prefer blocks that fit best into the selected residual space (as given by
Section 2.3.4); this is one of the two fitness measures used by Parreño et. al. [11]

Table 2.7 reports the volume utilization of the best solutions found by the five versions
of ID-GLA, averaged over the first 10 instances of test sets BR0-15. We see that the
volume-fit versions greatly outperform the best-fit version. We plotted the results for the
four versions of ID-GLA using the volume-fit fitness measure in Figure 2.22 to help us
decide which version is best (test set BR0 is excluded). We can see that α = 0 performs
noticeably worse than the other three versions on the majority of test sets. This suggests
that taking potential volume loss (Vloss +Vwaste ) into account as a penalty helps to guide the
search into more promising directions. The performance differences between α = −0.5,
α = −1 and α = −2 are quite small, so we are unable to conclusively determine the
best setting based on these experiments. We decided to pick α = −1 since its overall
performance on BR1-15 is slightly better.

2.5.5 Impact of Overarching Search Strategy (E6)

The search strategy for the base version of our ID-GLA approach is an iterative-doubling
greedy two-step look ahead tree search. To investigate the effect of different search strate-
gies, we implemented two other versions:

62
 set α = 0 α = −0.5 α = −1 α = −2 best-fit
BR00 87.10 87.10 87.25 87.38 85.30
BR01 94.40 94.64 94.71 94.80 81.20
BR02 95.37 95.73 95.82 95.90 76.24
BR03 95.33 95.64 95.82 95.92 77.99
BR04 94.99 95.84 95.79 95.93 76.75
BR05 94.72 95.40 95.48 95.41 76.37
BR06 94.76 95.26 95.27 95.31 75.61
BR07 94.27 95.13 95.07 94.75 75.01
BR08 93.44 93.73 94.02 94.06 74.80
BR09 93.50 93.84 93.83 93.87 74.01
BR10 93.27 93.64 93.80 93.82 73.18
BR11 93.14 93.36 93.74 93.32 73.09
BR12 92.95 93.41 93.35 93.27 74.07
BR13 92.71 93.12 93.07 92.96 73.29
BR14 92.87 93.06 93.06 92.79 73.66
BR15 92.95 93.14 93.33 93.04 73.69
avg. 1-7 94.83 95.38 95.42 95.43 77.02
avg. 8-15 93.10 93.41 93.53 93.39 73.72
avg. 1-15 93.91 94.33 94.41 94.34 75.26

Table 2.7: Volume utilization of best solutions by ID-GLA using various block selection
strategies, averaged over the first 10 instances of test sets BR0-15

96.00

95.50

95.00

94.50 a=0
a=-0.5
94.00
a=-1
93.50
a=-2
93.00

92.50

Figure 2.22: Volume utilization of best solutions by ID-GLA using various volume-fit
block selection strategies, averaged over the first 10 instances of test sets BR1-15

63
 • ID-GPCTS: the two-step look ahead in ID-GLA is replaced by PCTS, which is
the search strategy used in the CLTRS algorithm by Fanslau and Bortfeldt [4] (see
Section 2.3.6 for details).

• RGRASP: the reactive GRASP algorithm by Parreño et. al [11]. We have changed
the termination condition to stop ater 32 CPU seconds. Since this search strategy
is stochastic in nature, for each instance we invoked RGRASP 10 times and took
the average.

Table 2.8 reports the volume utilization of the best solutions found by each search
strategy, averaged over the first 10 instances of test sets BR0-15. The results for BR1-15
are plotted in Figure 2.23. Both ID-GLA and ID-GPCTS clearly outperform RGRASP.
ID-GLA is slightly better than ID-GPCTS, although the difference is marginal. Since two-
step look ahead is a much simpler search strategy than PCTS, we prefer to use ID-GLA
in the final version of our algorithm.

set ID-GLA ID-GPCTS RGRASP

BR00 87.25 86.98 87.22
BR01 94.71 94.55 93.50
BR02 95.82 95.89 93.76
BR03 95.82 95.66 92.86
BR04 95.79 95.59 92.28
BR05 95.48 95.35 92.01
BR06 95.27 95.13 91.44
BR07 95.12 95.07 90.93
BR08 94.02 93.96 90.26
BR09 93.89 93.92 90.23
BR10 93.83 93.63 90.03
BR11 93.74 93.17 89.93
BR12 93.40 93.03 89.85
BR13 93.12 93.18 89.58
BR14 93.19 93.12 89.65
BR15 93.33 93.16 89.79
avg. 1-7 95.43 95.32 92.40
avg. 8-15 93.56 93.40 89.92
avg. 1-15 94.43 94.29 91.07

Table 2.8: Volume utilization of best solutions by various search strategies, averaged over
the first 10 instances of test sets BR0-15

The depth d of the look ahead tree search employed by ID-GLA is an important
parameter, so we conducted a set of experiments to decide its best value. Table 2.9
reports the performance of ID-GLA when the look ahead search depth is set to various
values. The results for test sets BR1-15 are also plotted in Figure 2.24. We can easily

64
 96.00

95.00

94.00

93.00
ID-GLA
92.00 ID-GPCTS

91.00 RGRASP

90.00

89.00

Figure 2.23: Volume utilization of best solutions by various search strategies, averaged
over the first 10 instances of test sets BR1-15

eliminate d = 1 from consideration as it is clearly dominated by the other values on all

test sets. We can also eliminate d = 5, since it is dominated by d = 2, 3, 4 on the majority
of test sets (although the gap is small). There is no clearly superior setting among d = 2,
d = 3 and d = 4 in these experiments. We finally decided to set d = 2 as it slightly
outperforms d = 3 and d = 4 on strongly heterogeneous instances, which we believe are
the harder instances.

96

95
d=1
94 d=2
d=3
93
d=4

92 d=5

91

Figure 2.24: Volume utilization of best solutions found by ID-GLA using various search
depths, averaged over the first 10 instances of test sets BR1-15

2.5.6 Multi-Best-Space Scheme vs Single-Best-Space Scheme

The base version of ID-GLA uses the Single-Best-Space scheme (or Single for short),
which signifies that it only considers one residual space for each state during the search.

65
 set d=1 d=2 d=3 d=4 d=5
BR00 86.63 87.25 87.38 87.29 86.93
BR01 93.17 94.71 94.49 94.44 94.03
BR02 94.56 95.82 96.01 95.77 95.58
BR03 94.00 95.82 95.91 95.81 95.63
BR04 93.76 95.79 95.80 95.92 95.70
BR05 93.48 95.48 95.59 95.38 95.16
BR06 93.56 95.28 95.47 95.25 95.18
BR07 93.23 95.12 95.04 95.15 94.79
BR08 92.61 94.03 94.08 94.02 93.95
BR09 92.53 93.91 93.81 93.72 93.77
BR10 92.48 93.83 93.75 93.74 93.60
BR11 92.20 93.74 93.42 93.30 93.29
BR12 91.93 93.43 93.15 93.20 93.15
BR13 91.95 93.12 93.19 93.14 93.06
BR14 91.54 93.19 93.14 92.96 92.80
BR15 91.95 93.33 93.27 93.21 93.18
avg. 1-7 93.68 95.43 95.47 95.39 95.15
avg. 8-15 92.15 93.57 93.48 93.41 93.35
avg. 1-15 92.86 94.44 94.41 94.33 94.19

Table 2.9: Volume utilization of best solutions by ID-GLA using various search depths,
averaged over the first 10 instances of test sets BR0-15

66
In addition, we implemented two other versions of ID-GLA:

• Multi: the Multi-Best-Space scheme is used, i.e., for each state we will consider a
few residual spaces

• Better: after candidate blocks are generated, we allocate half the remaining CPU
time on separate executions of ID-GLA using Single-Best-Space and Multi-Best-
Space, and then take the better solution

Table 2.10 summarizes the results obtained by these three algorithms on the 160
instances under the headings Single, Multi and Better, respectively. Entries in bold font
under the column Single indicates that Single-Best-Space outperformed Multi-Best-Space
on average, and vice versa for entries in bold font under the column Multi. We can
see from the last three rows of the table that on average, Single-Best-Space is slightly
better for strongly heterogeneous instances, Multi-Best-Space is slightly better for weakly
heterogeneous instances, and the overall performance for the two algorithms is almost the
same.

set Single Multi Better

BR00 87.43 87.39 87.39
BR01 94.97 95.01 95.09
BR02 96.17 96.30 96.32
BR03 96.26 96.29 96.39
BR04 95.97 96.34 96.27
BR05 95.86 95.74 96.02
BR06 95.66 95.61 95.71
BR07 95.26 95.48 95.47
BR08 94.88 94.79 94.92
BR09 94.37 94.36 94.37
BR10 94.52 94.19 94.28
BR11 94.09 94.09 94.09
BR12 93.90 94.05 94.11
BR13 93.83 93.79 93.88
BR14 93.68 93.63 93.81
BR15 93.66 93.80 93.74
avg. 1-7 95.73 95.83 95.89
avg. 8-15 94.12 94.09 94.15
avg. 1-15 94.87 94.90 94.97

Table 2.10: Comparison of space selection strategies on 160 BR instances

We also observed that the solutions found by Single-Best-Space and Multi-Best-Space

tend to complement each other for many individual instances, i.e., for some instances
Single-Best-Space found solutions that are much better than Multi-Best-Space, whereas

67
for other instances the reverse is true. As a result, allocating half of the computational
resources to the Single-Best-Space scheme and the other half to the Mult-Best-Space
scheme is more effective than allocating all resources to either scheme alone.
We performed another set of experiments to analyze the convergency behavior of
the three space selection strategies. For each instance, after the candidate blocks are
generated, we performed the search for 500s and recorded the best solution found by
each algorithm every 10 CPU seconds. We grouped the 15 test sets BR1-15 into three
categories (BR1-5, BR6-10, and BR11-15) ordered by increasing heterogeneity. Figure
2.25 shows the results for these groups in three separate diagrams. In each diagram, the
vertical axis is the percentage volume utilization of the solutions, and the horizontal axis
is the time taken to produce the solutions in CPU seconds. The diagrams plot the average
of the best solutions for the 50 instances over time.
We see in Figure 2.25(a) that the Single-Best-Space scheme found better solutions
than the Multi-Best-Space scheme for the weakly heterogeneous instances BR1-5 up to
about 200 seconds, at which point Multi-Best-Space became superior. However, the trend
is reversed in Figure 2.25(b) for the BR6-10 instances with middling heterogeneity, where
the early solutions by Multi-Best-Space were better than Single-Best-Space, but the later
solutions were poorer. Finally, Figure 2.25(c) indicates that Single-Best-Space is better
for the strongly heterogeneous BR11-15 instances up to about 330 seconds, but Multi-
Best-Space is slightly better thereafter. For all three test sets, allocating half the time
to each scheme and then taking the better solution of the two is superior to using either
scheme alone (although the Single-Best-Space scheme was slightly better for BR11-15 up
to about 110 seconds).

2.6 Computational Experiments

Our final version of ID-GLA allocates half the CPU time to the Single-Best-Space scheme
and the other half to the Multi-Best-Space scheme, and simply takes the better solution
when the execution finishes. Other settings (except the CPU times) are the same as the
base version described in Section 2.5.
For the sake of brevity, we only make comparisons with the most recently published
and best algorithms since the average results on each individual test set for these lat-
est algorithms dominate those in earlier literature by large margins. In particular, we
only compare with complex search or meta-heuristic approaches rather than the simple
heuristics proposed in earlier work.
Table 2.11 compares our ID-GLA approach with existing algorithms that do not en-
force the full support constraint. Column 2 to column 9 are results extracted from existing
literature:
• GRASP: Greedy Randomized Adaptive Search Procedure [82];

68
 96.1
96.0
Volume Utilization (%)
95.9
95.8
95.7
95.6 Single
95.5 Multi
95.4 Better
95.3
95.2
10
40
70
100
130
160
190
220
250
280
310
340
370
400
430
460
490
CPU Time (s)

(a) Convergence of space selection strategies for BR1-BR5

95.0
94.9
Volume Utilization (%)

94.8
94.7
94.6
94.5 Single
94.4
Multi
94.3
94.2 Better
94.1
94.0
10
40
70
100
130
160
190
220
250
280
310
340
370
400
430
460
490

CPU Time (s)

(b) Convergence of space selection strategies for BR6-BR10

94.0

93.8
Volume Utilization (%)

93.6

93.4 Single
93.2 Multi
Better
93.0

92.8
10
40
70
100
130
160
190
220
250
280
310
340
370
400
430
460
490

CPU Time (s)

(c) Convergence of space selection strategies BR11-BR15

Figure 2.25: Convergency behavior of the different space selection strategies

69
 • IC: Iterated Construction [57];

• CD: Caving Degree [88];

• FDA: Fit Degree Algorithm [49];

• MS: Maximal Space [11];

• VNS: Variable Neighborhood Search [48];

• CLTRS: Container Loading by Tree Search [4];

• BRKGA: A parallel Biased Random-Key Genetic Algorithm [12]

The next three columns show the average percentage volume utilization achieved by
our ID-GLA approach when given a search time limit of 10, 300, and 500 CPU seconds
per instance, respectively. We do not include the time taken to generate blocks in this
time limit; this is reported separately in the last column BG (s) (for each test set, the
average over 100 instances are reported). The last row reports the average CPU time per
instance by each approach; for ID-GLA, this time includes the search time limit as well
as the time taken to generate blocks.

70
 set GRASP IC CD FDA MS VNS CLTRS BRKGA ID-GLA
2005 2005 2011 2008 2010 2010 2012 10s 300s 500s BG (s)
BR00 - - - - - 89.95 - 90.62 90.79 90.79 0.02
BR01 89.07 91.60 - 92.92 93.85 94.93 95.05 95.28 95.00 95.55 95.59 0.04
BR02 90.43 91.99 - 93.93 94.22 95.19 95.43 95.90 95.53 96.08 96.13 0.05
BR03 90.86 92.30 - 93.71 94.25 94.99 95.47 96.13 95.65 96.24 96.30 0.04
BR04 90.42 92.36 - 93.68 94.09 94.71 95.18 96.01 95.53 96.07 96.15 0.04
BR05 89.57 91.90 - 93.73 93.87 94.33 95.00 95.84 95.24 95.94 95.98 0.04
BR06 89.71 91.51 - 93.63 93.52 94.04 94.79 95.72 95.15 95.72 95.81 0.10
BR07 88.05 91.01 - 93.14 92.94 93.53 94.24 95.29 94.53 95.28 95.36 1.13
BR08 86.13 - 88.4 92.92 91.02 92.78 93.70 94.76 93.99 94.71 94.80 3.12
71

BR09 85.08 - 88.1 92.49 90.46 92.19 93.44 94.34 93.65 94.46 94.53 3.59
BR10 84.21 - 87.9 92.24 89.87 91.92 93.09 93.86 93.43 94.27 94.35 4.16
BR11 83.98 - 87.9 91.91 89.36 91.46 92.81 93.60 93.18 94.09 94.14 4.90
BR12 83.64 - 87.9 91.83 89.03 91.20 92.73 93.22 93.09 94.03 94.10 6.79
BR13 83.54 - 87.9 91.56 88.56 91.11 92.46 92.99 92.84 93.80 93.86 7.35
BR14 83.25 - 87.8 91.30 88.46 90.64 92.40 92.68 92.88 93.76 93.83 9.98
BR15 83.21 - 87.7 91.02 88.36 90.38 92.40 92.46 92.71 93.72 93.78 10.36
avg. 1-7 89.73 91.8 - 93.53 93.82 94.53 95.02 95.74 95.23 95.84 95.90 0.20
avg. 8-15 84.13 - 88.0 91.91 89.39 91.46 92.88 93.49 93.22 94.11 94.17 6.28
avg. 1-15 86.74 - - 92.67 91.46 92.89 93.88 94.54 94.16 94.91 94.98 3.45
Time 69s 707s 3.3h 633s 101s 296s 320s 147s 10s 300s 500s

Table 2.11: Comparison on 1600 BR instances, without full support constraint

 The results show that ID-GLA outperforms all approaches for each of the test sets
BR0-BR15 when given 300 seconds of CPU time. Although increasing the CPU time
from 300s to 500s will further improve solution quality, the amount of improvement is
very small.
Except for BRKGA, these algorithms (including ID-GLA) are all single-threaded,
i.e., non-parallel. Our ID-GLA algorithm outperforms the best single-threaded algorithm
CLTRS when given 10 CPU seconds. When given 300s, the improvement reaches as much
as 1.03% over the reigning best single-threaded approach CLTRS. Since the benchmarks
for these 16 sets of instances have been continuously improved in the past decade, it has
become increasingly harder to better the existing solutions. Hence, a 1.29% improvement
for BR8-BR15 and a 0.82% improvement for BR1-BR7 are significant results.
The best current approach is BRKGA, which is a parallel algorithm executed on a
machine with six cores. Our ID-GLA when given 300s performs slightly better than
BRKGA for BR1-7 by 0.10% on average; the gap becomes more significant for BR8-15,
where the improvement is 0.68%.

set PGL PGA HB GRASP CLTRS ID-GLA

(2000) (2002) (2006) (2005) (2010) 30s 150s Impr BG (s)
BR00 - - - - 89.83 90.25 90.29 0.46 0.00
BR01 89.9 88.10 89.39 89.07 94.51 94.25 94.40 -0.11 0.00
BR02 89.6 89.56 90.26 90.43 94.73 94.62 94.85 0.12 0.00
BR03 89.2 90.77 91.08 90.86 94.74 94.80 95.10 0.36 0.00
BR04 88.9 91.03 90.90 90.42 94.41 94.46 94.81 0.40 0.00
BR05 88.3 91.23 91.05 89.57 94.13 94.24 94.52 0.39 0.00
BR06 87.4 91.28 90.70 89.71 93.85 93.92 94.33 0.48 0.01
BR07 86.3 91.04 90.44 88.05 93.20 93.22 93.59 0.39 0.18
BR08 - 90.26 - 86.13 92.26 92.27 92.65 0.39 1.29
BR09 - 89.50 - 85.08 91.48 91.65 92.11 0.63 1.19
BR10 - 88.73 - 84.21 90.86 91.13 91.60 0.74 1.14
BR11 - 87.87 - 83.98 90.11 90.25 90.64 0.53 1.00
BR12 - 87.18 - 83.64 89.51 89.77 90.35 0.84 1.02
BR13 - 86.70 - 83.54 88.98 89.11 89.69 0.71 0.96
BR14 - 85.81 - 83.25 88.26 88.40 89.07 0.81 0.77
BR15 - 85.48 - 83.21 87.57 87.70 88.36 0.79 0.67
avg. 1-7 88.5 90.40 90.50 89.70 94.20 94.22 94.51 0.31 0.03
avg. 8-15 - 87.69 - 84.13 89.88 90.03 90.56 0.68 1.00
avg. 1-15 - 89.00 - 86.70 91.90 91.99 92.40 0.50 0.55
Time (s) - 183 - 69 320 30.55 150.55

Table 2.12: Comparison on 1600 BR instances with full support constraint

Table 2.12 compares ID-GLA with existing algorithms that enforce the full support
constraint. Columns 2 to 6 are results extracted from existing literature:
• PGL: Parallel Generalized Layer-wise loading approach [55];

72
 • PGA: Parallel Genetic Algorithm [90];

• HB: Heuristics embedded in tree search [24];

• GRASP: Greedy Randomized Adaptive Search Procedure [82];

• CLTRS: Container Loading by Tree Search [4]

The next two columns are the results of ID-GLA under the search time limits of 30 and
150 CPU seconds per instance, respectively. Column Impr gives the difference between
the volume utilization of solutions produced by ID-GLA and CLTRS, which is the best
algorithm for SCLP with the full support constraint enforced prior to this work and whose
results dominate all previous approaches for all 16 test cases. Once again, the time taken
to generate blocks is reported separately under column BG (s).
Given 30 CPU seconds per instance, ID-GLA outperforms CLTRS (the best existing
approach) for 14 out of the 16 test sets; for BR1 and BR2, our approach is slightly worse
than CLTRS. When given 150 CPU seconds, our approach outperforms CLTRS for 15 out
of the 16 test sets. For weakly heterogeneous instances (BR1-7), ID-GLA outperforms
CLTRS by 0.31% on average, while for strongly heterogeneous instances (BR8-15), it
outperforms CLTRS by 0.68%. An inspection of the values in column Impr suggests
that as the heterogeneity of the instances increases, the relative improvement of ID-GLA
compared to CLTRS increases.

2.7 Conclusion
In this chapter, we developed a new block building approach to solve the Single Container
Loading Problem with and without the full support constraint.
For the purpose of better understanding block building approaches for SCLP in general
and our ID-GLA algorithm in particular, we proposed a conceptual model consisting of
six elements, namely representing free space (E1), representing blocks (E2), selecting
free space (E3), selecting the block to load (E4), loading the selected block into the free
space (E5) and the overarching search strategy (E6). This conceptual model captures the
common structure of block building approaches.
We presented various options adopted by existing block building approaches for each
of the elements. We analyzed the impact of these choices and designed computational
experiments to compare their effectiveness. The computational experiments show that the
choices made in our ID-GLA approach are indeed more effective than the alternatives.
Computational experiments on the comprehensive set of 1600 standard benchmark
instances show that our ID-GLA approach outperforms all existing approaches for SCLP
both with and without the full support constraint.

73
 Our final implementation of ID-GLA allocates half the alloted time to Single-Best-
Space and half to Multi-Best-Space, and takes the better solution of the two. Our experi-
ments show that the two schemes are often complementary, and so this 50/50 allocation of
time is superior to using all the time on either scheme alone. Note that the Single-Best-
Space and Multi-Best-Space computations are totally independent and can be trivally
parallelized, which enables our ID-GLA approach to take advantage of the multi-core ar-
chitecture of the latest CPUs. The total execution time of this parallel version is expected
to be a little more than half of the sequential version.
Since our approach is able to obtain high quality solutions in a short amount of time, it
is a good candidate as a subroutine to solve other loading problems, such as the multiple
container loading problem and the 3D strip packing problem (3DSP). In the process of
solving the multiple container loading problem, the single container loading problem is
solved many times. Our approach may inspire more efficient algorithms to such problems.

74
Chapter 3

Algorithms for the Multiple

Container Loading Problem
The main objective of the Multiple Container Loading Cost Minimization Problem (MCLCMP)
is to load a set of given boxes into a set of containers such that the total shipping cost of
the utilized containers is minimized. One practical application of MCLCMP is to model
the process of shipping products, which is the task faced by one of our project clients that
is a buying agent for a multi-national retailer.
Since MCLCMP is an extremely hard combinatorial optimization problem, the main
objective is to develop heuristic algorithms that can find good solutions in reasonable time.
We will present three algorithms in increasing order of sophistication and effectiveness:
the Set Cover based Binary Search (SCBS) algorithm, the Prototype Column Genera-
tion (PCG) algorithm, and the Goal-driven Prototype Column Generation (GD-PCG)
algorithm.
All three algorithms are based on a set cover integer linear programming formulation
for MCLCMP. If a set of boxes can be loaded into a container, we call the set of boxes
and the associated container a loading pattern. MCLCMP can be naturally formulated as
a set cover (SC) problem, where the set to be covered is the set of all boxes and a loading
pattern “covers” a subset of boxes. We would like to select loading patterns (from a set of
candidates) to cover all boxes while minimizing the total cost of the associated containers.
The details of the set cover formulation will be discussed in Section 3.1.
Our approaches to MCLCMP are essentially two-level approaches. The burden of
finding feasible loading patterns is left to the algorithms for the Single Container Loading
Problem (SCLP), which are discussed in full detail in Chapter 2. This chapter mainly fo-
cuses on how to efficiently use the SCLP algorithms to produce candidate loading patterns
and find good solutions to the set cover formulations.
In practice, it is only possible to consider a limited number of loading patterns since
deciding whether a set of boxes can be loaded into a container is NP-hard. Hence, there
is a gap between the optimal solution to the set cover problem and the optimal solution
to MCLCMP. However, if the set of candidate loading patterns is sufficiently large and

75
diverse, good solutions can still be found. This is the main premise behind our first
algorithm.
Our PCG algorithm combines the strengths of the prototyping concept and the column
generation technique. The prototyping concept is similar to the one used in product design
and software engineering. Although producing high quality loading patterns is time-
consuming (roughly equivalent to solving SCLP), reasonable guesses for loading patterns
can be made quickly. We call such a guess a prototype, and using prototypes instead of
actual loading patterns will allow us to explore a much larger set of candidates in the set
cover problem. If the prototypes are close to actual feasible loading patterns (in terms
of the number of boxes of each type loaded), then there is a high probability that we
can convert the selected prototypes into actual loading patterns. Since a larger set of
candidates leads to a better optimal solution for the corresponding set cover problem, we
are more likely to obtain a better solution to MCLCMP. Column generation is a standard
technique for solving linear programs with a huge number of decision variables, where
only a small set of columns is initially included and new columns are generated as needed
by solving a pricing subproblem (in the matrix form of the set cover model, a column in
the coefficient matrix represents a loading pattern). In the case of MCLCMP, the pricing
subproblem is essentially a variant of the single container loading problem.
The GD-PCG algorithm improves on PCG in three respects. Firstly, the PCG algo-
rithm carries out the search in two stages and each stage approaches good solutions to
MCLCMP in its own dimension, whereas GD-PCG searches in both dimensions at the
same time. Secondly, we extend the set cover formulation for MCLCMP by taking the
expected overall volume utilization of the containers in a solution into account. Thirdly,
once a solution is found, a goal-driven search is carried out in the solution neighborhood
to improve the solution.
We focus on the special case of MCLCMP where there are an unlimited number of
containers of each type. This is done for two reasons. Firstly, doing so allows us to
simplify the presentation of the key ideas. Secondly, the number of containers available is
usually more than sufficient to contain all items to be loaded in practice, except for rare
instances during peak season. We briefly explain how our technique can be extended to
handle a limited number of containers towards the end of this chapter in Section 3.5.2.

3.1 Set Cover Formulations

We call a set of boxes and a container a loading pattern if the set of boxes can be loaded
into the container. Let P denote a set of candidate loading patterns, indexed by i =
1, . . . , |P|. The i-th loading pattern fills a container of type t with aji boxes of type j and
is represented by a column vector Ai with components aji . The cost associated with the
i-th loading pattern is given by ci = Ct . Let x be the integer decision variables, where

76
xi denotes the number of times the i-th loading pattern is used. A feasible solution to
the MCLCMP can be obtained by solving the following optimization model, which can
be considered a set partitioning formulation:

|P|
X
SP(P) : Minimize z = ci x i (3.1)
i=1
|P|
X
Subject to aji xi = nj , j = 1, . . . , N (3.2)
i=1

xi ≥ 0 and integer, i = 1, . . . , |P| (3.3)

where the objective function (3.1) computes the total cost of all selected containers, and
the constraints (3.2) ensure that the selected containers have sufficient space to load the
boxes of each type. If P includes all valid loading patterns, an optimal solution to SP(P)
is also an optimal soluton to MCLCMP.
We replace the equality constraints (3.2) by ≥ constraints to obtain the following set
cover formulation:

|P|
X
SC(P) : Minimize z = ci x i (3.4)
i=1
|P|
X
Subject to aji xi ≥ nj , j = 1, . . . , N (3.5)
i=1

xi ≥ 0 and integer, i = 1, . . . , |P| (3.6)

We prefer the set cover formulation over the set partitioning formulation for two rea-
sons. Firstly, it is much easier to find a feasible solution to SC(P) than SP(P), especially
when the set of candidate loading patterns is small and the number of box types are
large. As long as every box type appears in at least one candidate loading pattern (such a
requirement can be easily satisfied), we can always construct a feasible solution to SC(P).
Secondly, given a set of candidate loading patterns P, the optimal solution to SC(P)
is usually no worse (and often better) than SP(P) since every feasible solution to SP(P)
is also feasible to SC(P). A feasible solution to SC(P) can always be converted into a
feasible solution to MCLCMP when the full support constraint is not required. This is
because if the loading patterns selected involve excess boxes of type j, we can remove boxes
of type j from the MCLCMP solution until only the required number of boxes remains
(since the support of boxes is not considered, the resulting packing patterns are clearly
still feasible). When additional constraints such as full support is enforced, this is not
always true (Figure 3.1 provides a counterexample). Nevertheless, for most constraints
encountered in practice, if a set of boxes can be loaded into a container, then a subset of

77
these boxes can often also be loaded into the container.

4
2

3
1

Figure 3.1: A possible arrangement of 5 boxes where the removal of the middle box
(shaded) leads to partial support of box 4. Since this is the only possible arrangment (up
to symmetry) of boxes 1 - 4, there is no full support solution.

We are only able to consider a very small set of candidate loading patterns. A good
solution to MCLCMP usually requires high quality loading patterns where the volume
utilizations of the containers are high. In other words, we need good solutions to SCLP.
For realistic SCLP instances, it takes state-of-the-art SCLP algorithms a few seconds to
a few hours of CPU time to find a reasonably good solution (that are a few percentage
points away from optimal). Hence, any algorithm that relies on solving SCLP instances
to produce loading patterns can only explore a tiny fraction of the set of all valid loading
patterns (which grows exponentially to the number of boxes inside a container and can
easily reach millions) in reasonable time. Since SCLP is NP-hard, this situation will not
change much in the near future unless P=NP or there are fundamental changes in the
computing model.
As a direct consequence of the inability to consider all valid loading patterns, there is
usually a gap between an optimal solution to SC(P) and an optimal solution to MCLCMP.
The size of the gap mainly depends on:

• |P|: the number of the candidate loading patterns considered. The larger the set,
the smaller the gap, with all other things being equal. This is because the optimal
soluton to SC(P1 ) is no worse than SC(P2 ) if P1 ⊇ P2

• the quality of the individual loading patterns in P. Generally speaking, the more
boxes we can load into a single container, the smaller the gap, all other things being
equal. In particular, if we improve the quality of a loading pattern p ∈ P by loading
more boxes, it can never increase the gap (when the full support constraint is not
required)

• how well the loading patterns complement each other. If all the loading patterns
involve loading several boxes of only a few types, we are forced to select more

78
 containers in order to load the boxes for the remaining types. In contrast, a set of
loading patterns that complement each other is more likely to fully utilize the space
within the containers

3.1.1 Loading Factor

Since we are only able to consider a small set of candidate loading patterns, the selected
loading patterns in an optimal solution to SC(P) may offer excessive capacity for some
box types, i.e., for some j the inequality (3.5) is strictly greater. The presence of ex-
cessive capacity offers an opportunity to reduce the cost by selecting a set of containers
with smaller capacity. Hence, we introduced a loading factor α to inequality (3.5) and
parameterized the model as follows:

|P|
X
SC(P, α) : Minimize z = ci x i (3.7)
i=1
|P|
X
Subject to aji xi ≥ α · nj , j = 1, . . . , N (3.8)
i=1

xi ≥ 0 and integer, i = 1, . . . , |P| (3.9)

The loading factor α is the percentage of boxes that is guaranteed to be loaded into
the selected containers. For example, the solution found by SC(P, 0.97) will guarantee
that at least 97% of each type of box can be loaded into the containers selected, while
the remaining 3% has no guarantee. It may be possible to load the unguaranteed 3% into
the containers selected by SC(P, 0.97), whereupon we would obtain a feasible solution
to MCLCMP. Note that the cost of the optimal solution of SC(P, α) is a non-decreasing
function of α, i.e., if α1 < α2 , then any feasible solution to SC(P, α2 ) is also a feasible
solution to SC(P, α1 ); hence, an optimal solution for SC(P, α1 ) is at least as good as an
optimal solution for SC(P, α2 ).
One possible application of this parameterized formulation is to apply binary search
on the loading factor to increase the probability of finding better solutions to MCLCMP.
The details of this approach are described in the following section.

3.2 Set Cover Based Binary Search (SCBS) Algo-

rithm
The set cover based binary search (SCBS) algorithm tries to find a solution to MCLCMP
by solving a series of set cover formulations SC(P, α) resulting from a binary search on the
loading factor α. Performing the binary search increases the probability of finding better

79
solutions by minimizing the gap between an optimal solution to SC(P, α) and an optimal
solution to MCLCMP. Over the course of devising our SCBS algorithm, we developed
enhancements to some SCLP algorithms in literature to increase the quality of loading
patterns generated. In addition, we employ three heuristic strategies to produce a set
of diversified single container loading patterns that are more likely to complement each
other, which is helpful in reducing the size of the gap.

3.2.1 Binary Search on Loading Factor

The idea behind our technique is to solve SC(P, α) in order to provide an estimate of the
number of containers needed to guarantee the successful loading of a percentage of the
input boxes. We then attempt to insert the remaining boxes into the unused capacity of
selected containers using the subroutine Insert. If we are able to successfully load all
boxes, then we we have found a solution to the original MCLCMP instance and we reduce
the loading factor α; otherwise, we increase α. Since the cost of the optimal solution of
SC(P, α) is a non-decreasing function of α, we employ a binary search procedure that
terminates after maxIter iterations to find the lowest possible value of α efficiently (for
our implementation, we set maxIter = 8). See Algorithm 7.
A set of candidate loading patterns P is first generated using the three strategies
described in Section 3.2.2 (line 1 in SCBS). We then invoke the Binary-Search function
to perform binary search up to maxIter iterations on the range [α0 , 1] for the loading
factor α (line 3).
Next, we solve the set cover model SC(P, α) using a standard integer programming
solver CPLEX to produce the solution x (line 5). The solution has a corresponding list of
selected loading patterns patts. For each loading pattern pi ∈ P with xi > 0, xi copies of
pi are included in patts to reflect the fact that pi is used xi times in the solution (line 6).
We then load containers with boxes according to the patterns in patts. At the end of this
process, there may be boxes left over. If so, we invoke the Insert subroutine to insert as
many leftover boxes into loaded containers as possible (line 11). Finally, we update the
binary search range accordingly (lines 12-16) and proceed to the next iteration (line 17).
The aim of the Insert subroutine is to attempt to load the remaining boxes into the
selected containers. In effect, given the set of leftover boxes B , the subroutine unloads
each container in turn (chosen in descending order of volume utilization) and uses SCLP-
Solver to reload the container inclusive of the leftover boxes. Over the course of this
process, new loading patterns might be discovered, which we add to our set of candidate
loading patterns P.
The Insert subroutine potentially helps to improve solution quality in two ways.
Firstly, the unloading-and-reloading process might result in a solution that loads all boxes
into the containers, which corresponds to a feasible loading plan with potentially higher

80
Algorithm 7 Set Cover based Binary Search Algorithm for MCLCMP

SCBS(Inst, α0 , maxIter )
1 Generate the set of loading patterns P
2 return Binary-Search(Inst, Enhanced-GRASPMod, α0 , maxIter )

Binary-Search(Inst, SCLP-Solver, α0 , maxIter )

// Input: Inst: the MCLCMP instance to be solved
// SCLP-Solver: an SCLP algorithm
// α0 : the range of loading factor is [α0 , 1]
// maxIter : maximum iterations of binary search
// Output: The best solution to the MCLCMP
1 bestSol = NULL
2 αl = α0 , αh = 1, α = α0 , iter = 0
3 while iter < maxIter
4 Remaining boxes RB = all boxes in Inst
5 Solve SC(P, α) using CPLEX; let x be the solution
6 patts = {pi ∈ P | xi > 0}, xi copies of pi are included in patts
7 for each pattern p ∈ patts
8 Load a container with boxes based on p
9 Remove loaded boxes from RB
10 Let CList be the list of containers loaded
11 if RB is not empty, then invoke Insert(RB , CList, P, SCLP-Solver)
12 if RB is not empty
13 αl = α;
14 else αh = α
15 create the corresponding MCLCMP solution sol
16 update bestSol if sol is a better solution
17 α = (αh + αl )/2, iter = iter + 1
18 return bestSol

Insert(B, CList, P, SCLP-Solver)

1 Sort CList in descending order of volume utilization
2 for each loaded container c ∈ CList
3 Let Bc be the set of boxes loaded into c
4 SCLPInst = the SCLP instance with container c and boxes B ∪ Bc
5 Invoke SCLP-Solver to solve SCLPInst; let p be the resulting loading
pattern, and let Bp be the set of boxes in p
6 Reload the container c according to p
7 B = B − Bp
8 P = P ∪ {p}
9 if B is empty, then break

81
utilization than the original set cover formulation. Secondly, the side effect of introducing
new loading patterns into P could improve the solutions generated in later iterations.

3.2.2 Strategies for Generating Packing Patterns

We developed three fast heuristic strategies to generate a reasonably large number of
diversified loading patterns, namely the G4-heuristic Knapsack (G4KP) strategy, the
Sequential Application of GRASP (S-GRASP) strategy, and the Application of GRASP
on Combinations (C-GRASP) strategy. The aim of all three strategies is to generate
diverse and utilization-efficient loading patterns for different combinations of container
and boxes by finding solutions for SCLP instances, for use when solving the set cover
formulation SC(P, α).

The G4-Heuristic Knapsack Strategy

In the G4-heuristic Knapsack (G4KP) strategy, we extend the G4-heuristic [9] for the 2D
pallet loading problem to 3D to solve SCLP with homogeneous boxes.
We assume that a container of dimensions L × W × H is placed such that the H-side
is parallel to the vertical direction and the bottom face (L × W ) is on a horizontal plane.
Let the dimensions of a box be arbitrarily assigned as its length, width, and height, and
denoted by l, w, and h, respectively. A box can be placed in 6 possible ways, of which
there are 2 each with the l-side placed vertically, and similarly for the w- and h-sides
(resulting in 3 vertical orientations). We fill the container layer by layer from the bottom
up along the vertical direction with boxes of the same type. For each layer, we impose
the restriction that all boxes must be in the same vertical orientation, and we search for a
packing that maximizes the number of boxes. Boxes in different layers can have different
vertical orientations.
Consider the vertical orientation for a box where the h-side is vertical. We can create
a layer of height h by packing as many boxes as possible in this vertical orientation. This
problem is identical to placing as many rectangles of dimensions l × w into a rectangle of
dimensions L × W as possible, which is an instance of the 2D pallet loading problem.
We make use of the G4-heuristic [9], which recursively divides the containing rectangle
into 4 sub-rectangles as shown in Figure 3.2. Assuming the sides of a rectangle are integral,
then the number of ways in which it can be divided in this way is at most L2 × W 2 . This
algorithm produces high quality solutions for the 2D pallet loading problem in pseudo-
polynomial time. Let Nh be the number of boxes in the solution found by the G4-heuristic.
Similarly, let Nl and Nw be the number of boxes in the solutions for the l- and w-side
vertical orientations, respectively.
If we treat each layer as an item, then the problem becomes a one-dimensional knapsack
problem with 3 types of items of sizes Nl , Nw , and Nh . Let Il , Iw , and Ih be 0-1 constants

82
 4
2

3
1

Figure 3.2: G4-heuristic

that indicate whether boxes are allowed to be placed in the l-side, w-side, and h-side
vertical orientations, respectively, where 1 indicates that the vertical orientation is allowed
and 0 otherwise; these values are dependent on the problem instance and are part of the
input. Let xl , xw , and xh be integer variables that denote the number of layers in which
boxes are placed in the l-side, w-side, and h-side vertical orientations, respectively. We
can model this problem using linear integer programming:

G4KP : Maximize z = Nl xl Il + Nw xw Iw + Nh xh Ih (3.10)

Subject to lxl Il + wxw Iw + hxh Ih ≤ H (3.11)
xl , xw , xh ≥ 0 and integer (3.12)
Il , Iw , Ih ∈ {0, 1} (3.13)

The objective (3.10) is to maximize the total number of boxes in all layers in a con-
tainer, subject to the constraint (3.11) that the sum of the heights of all layers does not
exceed the height of the container.
For each container type t and each box type j, we assume an unlimited supply of boxes
to form an instance of the single container loading problem with homogeneous boxes. We
use the G4KP strategy to find solutions for each instance, and add the resulting loading
patterns into our set of loading patterns P. This strategy produces loading patterns that
only employ one type of box, which may be particularly useful in the scenario where there
are proportionally many boxes of one type, and therefore the optimal solution is likely to
consist of some containers that are loaded entirely with one type of box. Furthermore, it
is desirable in practice to load a container with only one type of product during shipping
for ease of inventory management. This scenario is common in the sea freight industry,
where forwarders often ship large quantities of a particular product.
In the above discussion, we assumed that the layers are built along the height direction
from the bottom up. In fact, layers can also be built on the W × H face along the length
direction, or on the L × H face along the width direction. For a given box type and
container type, the G4KP strategy therefore solves the above linear program three times,

83
once for each direction, and returns the best result. Hence, the linear program G4KP is
solved 3M N times in total, resulting in M N loading patterns.

Sequential Application of GRASP Strategy

In the Sequential Application of GRASP strategy (S-GRASP), we try to solve the MCLCMP
instance using only one type of container. We load one container at a time until all boxes
have been loaded. Each time, we make use of the Greedy Randomized Adaptive Search
Procedure (GRASP) [82] to produce a solution to the SCLP instance. The best solution
found by GRASP is converted into a loading pattern and added to P. The S-GRASP
strategy is applied once for each of the M different types of containers.
The original GRASP algorithm for SCLP made use of the wall building constructive
heuristic GRMOD [91], which built walls against the W × H face of the container. A wall
is a single layer of homogeneous boxes placed in the same orientation and arranged into
an a × b grid on the W × H plane (Figure 3.3). The walls are placed side by side along the
length dimension (which simulates the loading of goods via a rear door situated on the
W × H face of the container). It is performed in two phases. In the construction phase,
an initial solution is generated: the algorithm repeatedly picks a region of free space (i.e.,
residual space), then uniformly randomly chooses one out of the top δ% of all possible
walls in terms of volume utilization and loads it into the residual space, subject to the
availability of the boxes. The value of δ is dynamically adjusted every 500 iterations based
on information gathered from previous iterations [82]. In the improvement phase, a part
of the best solution found in the construction phase is undone, and then redone by greedily
choosing the best wall to load in terms of volume utilization. In our implementation, if
the best soluiton is constructed in K steps, we perform the undo-redo operation for the
last k steps for all k = K down to 2 and record the best solution found.

Figure 3.3: A wall is a vertical layer of boxes against W × H face

We made two modifications to the GRMOD heuristic in our implementation. Firstly,

84
we used a different way to generate residual spaces. In the original GRMOD heuristic,
after a wall is built, 3 residual spaces are generated. The left diagram in Figure 3.4
illustrates the 3 residual spaces c1, c2, and c3 generated by the GRMOD heuristic after
wall b is built. However, there are in fact 6 different ways to partition the residual space,
including the alternative illustrated in the right diagram. Both ways shown generate a
residual space c1 that is fully supported by the placed wall, which allows the checking of
supporting area constraints if desired.

Figure 3.4: Two ways of generating residual spaces

If a residual space is too small to hold the smallest box remaining, then it cannot be
used at all and is called rejected space, otherwise it is called useful space. It would be
desirable to minimize the total volume of the rejected spaces (thereby maximizing the
amount of useful space) so that more boxes can potentially be loaded. We would also
like to minimize the amount of fragmentation of the residual space, i.e., we prefer to have
large useful spaces. Therefore, we calculate the fitness of the above two ways of generating
residual space and select the one with the higher fitness value:

fitness = vol. of largest useful space − total vol. of rejected space (3.14)

Secondly, we modified the evaluation function that ranks a particular loading con-
figuration by taking into account the amount of rejected space generated. The original
GRMOD heuristic only considered the volume utilization, which is equivalent to greedily
selecting the locally optimal arrangement. However, there are arrangements with high
utilization that produce a large amount of rejected space, which negatively affects the
overall utilization, resulting in a solution that is globally suboptimal. Therefore, we used
the following evaluation function:

eval = utilization − volume lost (3.15)

where volume lost is the total volume of rejected space in percentage terms. For example,
for the arrangement illustrated in the left diagram of Figure 3.4, if c1 is rejected space,

85
then the evaluation for that arrangement would be:

eval = b/(b + c1 + c2 + c3) − c1/(b + c1 + c2 + c3) (3.16)

For each container type t, we create a sequence of SCLP instances and repeatedly
apply the above GRASP algorithm to solve the instances. As boxes are loaded, they
are removed from subsequent problems in the sequence. Each of the generated loading
patterns is added into the set P for use in the solution of the parameterized set cover
formulation.
This technique takes advantage of the stochastic nature of GRASP to produce a va-
riety of packing patterns. These generated patterns can potentially make use of any
combination of boxes, unlike the patterns generated by the G4KP strategy that consist
of only one type of box.

Application of GRASP on Combinations Strategy

In the Application of GRASP on Combinations (C-GRASP) strategy, we wish to generate

loading patterns that load exactly r, 2 ≤ r ≤ N types of boxes for each type of container
using the above GRASP algorithm, which serves to diversify our set of packing patterns
to include different numbers of types of boxes. Since it is not practical to generate
packing plans for all Nr combinations for large N , we only generate up to R = 5 packing

patterns using a probabilistic sampling strategy for each container type t and each value
of r, 2 ≤ r ≤ N .
We illustrate our procedure using the following MCLCMP instance. There are two
container types with corresponding volumes V1 = 200 and V2 = 100. There are three
types of boxes with n1 = 15, n2 = 20, and n3 = 25 boxes of each type available. The
volume of each box type is v1 = 10, v2 = 15, and v3 = 20. For container type 1 and r = 2:

1. Enumerate all possible combinations of r box types and place them into the set
BoxTypeCombo. In our example, BoxTypeCombo = {(1, 2), (2, 3), (1, 3)}

2. For each combination in BoxTypeCombo, assign a probability value in proportion

to the total volume of all combinations (see Table 3.1)

P
Combination Total Box Volume ( vi · ni ) Probability
(1, 2) 10 × 15 + 15 × 20 = 450 0.281
(2, 3) 15 × 20 + 20 × 25 = 500 0.313
(1, 3) 10 × 15 + 20 × 25 = 650 0.406

Table 3.1: Probability of combination selection

86
 3. Choose a combination in BoxTypeCombo according to the probabilities, and remove
it from BoxTypeCombo. Assume in our example that (1, 3) is chosen

4. Create an instance of SCLP with only boxes in the chosen combination, where the
number of boxes of each type is proportional to the total volume of the selected
box types, rounded down. In our example, the number of boxes n01 of type 1 is
b Vv11 · (v1 · n1 )/(v1 · n1 + v3 · n3 )c = b 200
10
× 150/(150 + 500)c = 4. Similarly, the number
of boxes n03 of type 3 is b 20 × 500/(150 + 500)c = 7. If the rounded-down value for
200

a box type becomes 0, we set it to 1

5. Generate a loading pattern for the SCLP instance using the GRASP algorithm and
add this pattern to P. Assume that the GRASP algorithm successfully finds a
loading pattern that loads 4 boxes of type 1 and 6 boxes of type 3 into the container

6. Subtract the boxes used by the packing pattern from the original problem. In our
example, we set n1 = 11 and n3 = 19

7. Go back to Step 2, until R = 5 packing patterns are generated or all combinations

are exhausted

For the special case of r = N (i.e., all box types are considered), we always generate
R packing patterns. For each container type, we generate up to R loading patterns for
each value of r = 2, 3, . . . , N . Since there are M types of containers, the above procedure
generates up to M × (N − 1) × R loading patterns. For our implementation, we set R = 5.
By devising the SCLP instances such that the number of boxes of each type is pro-
portional to the total volume of such remaining boxes, the C-GRASP strategy generates
packing patterns that use a number of each box type that follows this proportion. Fur-
thermore, the total volume of all boxes in the instance is likely to be close to the volume
of the container. The premise behind this approach is, should a good loading pattern be
found, then it can be repeatedly used to load most of the boxes of the chosen types.

3.3 Prototype Column Generation

We have argued in Section 3.1 that the gap between an optimal solution to SC(P) and
an optimal solution to the corresponding MCLCMP mainly depends on:

• |P|: the number of candidate loading patterns considered

• the quality of the individual loading patterns in P

• how well the loading patterns complement each other

87
 We can potentially improve the efficiency and effectiveness of our SCBS algorithm
based on the following two key observations. Firstly, SCBS generates a set of candidate
loading patterns at the beginning, but only a small portion of these pattens is selected to
form a solution to MCLCMP. Hence, a large portion of the computational effort of pro-
ducing the initial candidates can be considered wasted. This inefficiency can be partially
addressed by employing the column generation technique. In the matrix form of the set
cover model, each column in the coefficient matrix represents a loading pattern. In the
column generation technique, only a small set of columns is initially included and new
columns are generated as needed by solving a pricing subproblem. In addition, the loading
patterns produced by solving the pricing subproblems will only improve the solution. In
a sense, these loading patterns better complement the set of existing candidate loading
patterns than randomly selected loading patterns.
Secondly, in the course of the execution of SCBS or column generation, we need to
repeatedly solve single container loading problems. Since SCLP itself is a hard combi-
natorial optimization problem, finding a good solution is often time consuming. We are
therefore facing a tradeoff, where the more time we spend in improving the quality of
loading patterns, the fewer loading patterns we can consider. This tradeoff severely limits
the effectiveness of SCBS and the column generation approach. We attempt to overcome
this issue by borrowing the prototyping concept that is commonly employed in product
design and software engineering. Although producing high quality loading patterns is time
consuming, reasonable guesses for loading patterns can be made quickly. If the guesses
are close to actual feasible loading patterns (in terms of the number of boxes of each type
loaded), then using such guesses instead of actual loading patterns will allow us to find
a good solution to MCLCMP using significantly less CPU time. We call such a guess a
prototype (of a column). Our PCG algorithm is similar to column generation, where the
prototype columns play similar roles to actual columns in a column generation technique.
These prototypes are realized into actual loading patterns only when required.
We will first briefly recap the theory behind column generation in the context of
solving the set cover formulation of MCLCMP in Section 3.3.1. We then explain how
prototyping and column generation can be combined to solve MCLCMP in Section 3.3.2.
The complete implementation of our prototype column generation (PCG) algorithm also
includes a procedure to generate candidate prototypes (Section 3.3.3), as well as a modified
ID-GLA algorithm for SCLP to realize prototypes into loading patterns (Section 3.3.4).

88
3.3.1 Preliminaries on Column Generation Techniques
For convenience of exposition, we rewrite the set cover formulation SC(P) in matrix form
as follows:

SC(P) : Minimize z = cT x (3.17)

Subject to Ax ≥ n, ∀(ci , Ai ) ∈ P (3.18)
xi ≥ 0 and integer, i = 1, . . . , |P| (3.19)

where (ci , Ai ) is the i-th loading pattern, with ci being the cost of the container in the
loading pattern, and Ai (the i-th column vector of the coefficient matrix A) representing
the set of boxes in the loading pattern. Due to this closed relation, we will use the terms
column and loading pattern interchangeably. The matrix A consists of exactly N rows,
one for each box type. The j-th component of vector n is the number of boxes nj of type
j.
The set of candidate loading patterns P acts like a filter that controls the tradeoff
between computing time and the quality of the solution. If it consists of all valid loading
patterns, the optimal solution to SC(P) is also an optimal solution to the MCLCMP
without the full support constraint and a lower bound for the MCLCMP with the full
support constraint. Since we never attempt to enumerate all members of P, we can think
of P as a set of loading patterns that satisfy certain conditions.
We briefly recap the theory behind column generation [92, revised simplex method
(pp.197) and Dantzig-Wolfe decomposition (pp.333)]. The column generation approach
can be directly applied to a linear program with huge numbers of variables (called the
master problem) to obtain an optimal solution. First, a restricted master problem (RMP)
is solved. The RMP consists of only a subset of columns of the original linear program
(LP). Next, values of the dual variables associated with the optimal solution of the RMP
are passed onto the pricing subproblem as cost coefficients. The pricing subproblem is
then solved to identify (or price out) columns with negative reduced cost ci − πAi , where
Ai is the i-th column to be generated (we assume without loss of generality that the
original problem is a minimization problem). Adding these columns to the RMP and
re-solving the revised RMP will result in an improved solution to the original LP. We
repeat this procedure until no such column exists, whereupon the optimal solution to the
RMP is also the optimal solution to the original LP.
We can apply the column generation technique to solve the set cover formulation
SC(P) as follows. First, remove the integral constraints in SC(P) to obtain its linear
relaxation LPSC(P). We then construct an initial RMP that includes only a subset of
columns the in LPSC and has a feasible solution. Such an RMP can be easily constructed
as follows. For each box type j and container type t, we try to load as many boxes of

89
type j as possbile into a container of type t assuming all boxes are placed in the same
orientation. Since such loading patterns can be easily computed, we assume they are
always included in P. We construct the initial RMP to include columns corresponding
to such loading patterns. Since this set of initial columns involves all box types, we can
solve this RMP using the simplex method to find an optimal solution.
Let πj be the value of the dual variable associated with the constraint corresponding to
box type j (inequalities (3.18)). For each container type t, we can formulate the following
pricing subproblem:

N
X
Pricing(t) : Minimize Ct − πj y j (3.20)
j=1
N
X
Subject to (lj wj hj )yj ≤ Lt Wt Ht (3.21)
j=1

0 ≤ yj ≤ nj and integer j = 1, . . . , N (3.22)

yj boxes of type j can be
loaded into a container of (3.23)
type t
(Ct , y) ∈ P (3.24)

where Ct is the cost of a container of type t, lj wj hj is the volume of a box of type j, and
Lt Wt Ht is the volume of the container. Constraints (3.23) require that the solution y is a
valid loading pattern, i.e., yj boxes of type j can be loaded into a container of type t while
satisfying all physical loading constraints. Constraints (3.24) restrict the search for valid
loading patterns within the set P (if P includes all valid loading patterns, constraints
(3.24) can be simply ignored).
If any of the t pricing problems has a feasible solution y with a negative objective
value, then we have found a promising loading pattern (Ct , y). We add the solution y
into the RMP as a new column Ai and introduce a new variable xi with coefficient ci = Ct
into the objective function of the RMP (if more than one pricing problem has a feasible
solution with negative objective value, we can add any or all of them into the RMP). We
then solve the revised RMP using the simplex method to find an optimal solution. This
process is repeated until no more columns can be added, whereupon the optimal solution
to the RMP is the optimal solution to LPSC(P).
At the end of this column generation process, we obtain an optimal solution to the
LP relaxation of the original problem SC(P), which is usually not an integral solution
(and hence is infeasible to the MCLCMP). For the set cover formulation, we can simply
round the fractional values up to obtain a feasible integer solution. However, it is hard
to convert a fractional solution into an integral one for integer programs in general, and

90
the implementation of a branching process may be required to find a feasible integral
solution. One standard technique is to combine column generation with a branch and
bound process, resulting in a technique called branch-and-price.

3.3.2 Prototype Column Generation Algorithm

Observe that the pricing problems of MCLCMP are essentially single container loading
problems with a general cost function, which is NP-hard, so finding a good solution is
expected to be time consuming. However, if we discard the loading constraints (3.23), then
the resulting problem is a knapsack problem, which can be solved efficiently even for large
instances. While a feasible solution to the knapsack problem may not be realizable into a
loading pattern, many SCLP algorithms are able to produce loading patterns with volume
utilization well above 90% for the weakly heterogeneous instances that are commonly
encountered in the shipping industry. Hence, the discrepancy between a knapsack solution
and its SCLP solution is expected to be small (in terms of box count). If our objective
is to find a solution that is close to optimal rather than always requiring the optimal
solution, then we can use the knapsack solution instead of actual SCLP solutions as a
reasonable approximation, and attempt to rectify the discrepancy when needed. We call
the resulting strategy Prototype Column Generation (PCG).
In prototype column generation, all columns in the constraint matrix of the master
problem (the LP relaxation of SC(P)) are initially prototypes. As we proceed, more
prototypes are added into the constraint matrix and some prototypes are realized into
actual loading patterns (by solving the SCLP). Hence, a column Ai either corresponds to
a prototype or an actual loading pattern. For simplicity of presentation, we rearrange the
variables (and corresponding columns in the constraint matrix) such that all prototypes
precede realized loading patterns. The submatrix formed by all prototypes is denoted by
Au (the subscript u stands for “unrealized”) and the submatrix formed by all realized
loading patterns is denoted by Ar (the subscript r stands for “realized”). Therefore,
A = [Au Ar ]. Correspondingly, the decision variables associated with prototypes are
denoted by column vector xu and the decision variables associated with loading patterns
are denoted by column vector xr . The cost coefficients associated with xu and xr are cu
and cr , respectively. We use Pu to denote the set of prototypes and Pr to denote the set of
realized loading patterns, where Pu ∪ Pr = P. The set cover formulation with prototypes
for MCLCMP can be rewritten in matrix form as:

SCP(Pu , Pr ) : Minimize z = cTu xu + cTr xr (3.25)

" #
xu
Subject to [Au Ar ] ≥n (3.26)
xr
x ≥ 0 and integer (3.27)

91
 Let Qu ⊆ Pu . We denote a restricted master problem that consists of only columns
corresponding to Qu and Pr as SCP-RMP(Qu , Pr ).
We further classify the prototypes in Pu − Qu by container type, and use the notation
Put to denote the set of prototypes for container type t, i.e.,

M
[
Pu = ( Put ) ∪ Qu , where Put and Qu are pairwise disjoint
t=1

Our PCG algorithm can be considered an iterative application of the column gener-
ation technique. It is implemented as three nested loops (see the listing below). The
outermost loop (steps 2 - 4) enlarges the set of candidate prototypes considered in
each iteration for up to Kpcg iterations, i.e., we are solving a series of set cover for-
(k) (k) (k) (k+1)
mulations with prototypes SCP(Pu , Pr ), k = 1, . . . , Kpcg with Pu ⊂ Pu and
(k) (k+1)
Pr ⊆ Pr , k = 1, . . . , Kpcg − 1. Hence, we are essentially enlarging the search space it-
eratively. The middle loop (steps 2 - 3) gradually realizes prototypes into loading patterns,
(k,l) (k,l)
i.e., we are solving a series of set cover formuations with prototypes SCP(Pu , Pr ),
(k,l) (k,l+1) (k,l) (k,l+1)
l = 1, . . . , Kgap , where Pu ⊃ Pu and Pr ⊂ Pr , and Kgap is a user-defined
parameter. We can expect that the optimal solution to SCP will become closer to the
optimal solution of SC (which is a more accurate model for the MCLCMP) as the al-
gorithm progresses. The innermost loop is a direct application of column generation to
(k,l) (k,l)
find the optimal solution to the LP relaxation of SCP(Pu , Pr ). It essentially solves
(k,l,r) (k,l)
a series of LP relaxations of SCP-RMP(Qu , Pr ) such that the optimal solutions are
monotonically non-increasing and will eventually converge to an optimal solution of the
(k,l) (k,l)
LP relaxation of SCP(Pu , Pr ).

Step 1: Initialization

a) Generate candidate prototypes: we generate a large set of diverse prototypes

Put for each container type t. A prototype p ∈ Put is a feasible solution to
Pricing(t) with loading constraints (3.23) removed. One possible generation
algorithm is described in Section 3.3.3. We leave Pr empty.
b) Formulate restricted master problem with prototypes SCP-RMP: we randomly
sample a small set of prototypes from each Put to construct the initial Qu such
that each box type appears in at least one prototype in Qu . We delete all
prototypes Qu from their respective Put . We formulate the restricted master
problem SCP-RMP(Qu , Pr ).

Step 2: Solve the LP relaxation of SCP(Pu , Pr ) using column generation

a) Solve the LP relaxation of SCP-RMP(Qu , Pr ) using the revised simplex method.

Let πj denote the value of the dual variable associated with the constraint for
box type j (inequalities (3.26)).

92
 b) Solve the pricing problem Pricing(t) for each container type t. We scan the set
Put to find a prototype that minimizes the value of objective function (3.20).
If the objective value of such a prototype is negative, we: 1) add it to Qu , 2)
revise SCP-RMP(Qu , Pr ) accordingly, and 3) remove it from Put .
c) If some prototypes have been added to Qu , we repeat step 2 to solve the revised
SCP-RMP(Qu , Pr ); otherwise, we have obtained an optimal solution to the LP
relaxation of SCP(Pu , Pr ), and we proceed to step 3.

Step 3: Resolve discrepancies

a) Realize selected prototypes: we solve SCP-RMP(Qu , Pr ) as an integer program

using a commercial solver. If any prototype appears in the solution (i.e., the
corresponding decision variable has a positive value), we invoke our ID-GLA
algorithm (Section 2.1.5, page 29) to create a loading pattern that is as close
to the prototype as possible (in terms of the box count of each type). We then
delete this prototype from Qu , and add the realized loading pattern to Pr .
b) Find feasible solution to MCLCMP: we solve a restricted master problem that
only involves the realized packing patterns SCP-RMP(∅, Pr ) to obtain a feasible
solution to the MCLCMP.
c) Check gap: Compute the gap between the solution found in step 3b and the
solution to the LP relaxation of SCP-RMP(Qu , Pr ) found in step 2. If the
gap is larger than the allowed tolerance , repeat steps 2 and 3 up to Kgap
iterations; otherwise, proceed to step 4.

Step 4. Enlarge candidate prototypes: if the gap computed in step 3c is larger than
tolerance , we try to enlarge the sets of candidate prototypes Put (by generating new
prototypes) and repeat steps 2 and 3 for up to Kpcg iterations; otherwise, proceed
to step 5.

Step 5. Post optimization: Formulate a set cover problem using only realized
loading patterns SC(Pr , α). We invoke Binary-Search as described in Algorithm 7
in Section 3.2.1 to solve SC(Pr , α), and update the best known solution if a better
solution to MCLCMP is found. In the process of the binary search, whenever an
SCLP instance is encountered, we use ID-GLA presented in Section 2.1.5 (page 29)
to solve it.

There is an important difference between our prototype column generation and classic
column generation. In column generation, the pricing problems are dynamically formu-
lated and the feasible region (or solution space) is implicitly defined by the constraints.
The feasible region is explored by manipulating the constraints (e.g., when the pricing

93
problem is solved as an LP problem using the simplex method) or is dynamically evalu-
ated (e.g., local search heuristics or meta-heuristics navigate through the solution space
by moving from a feasible solution to its neighbors while evaluating the constraints to
ensure feasibility). In contrast, in PCG the feasible region of the pricing problems are
represented as sets Pu whose elements are explicitly enumerated.
There are a few advantages to using such an explicit representation. Firstly, we can
easily avoid getting trapped in an infinite loop. One challenge in correctly implementing
column generation (or simplex algorithms in general) is to avoid entering an infinite loop
due to cycling through the same set of columns. The potential risk of infinite loops can
be explained as follows. At the end of step 2, we get an optimal solution x∗ to the
LP relaxation of SCP(Pu , Pr ), which is usually fractional (and therefore infeasible to the
original problem). We proceed to step 3 to obtain an integer solution (which is worse
than the fractional solution x∗ ). When we subsequently return to step 2, the column
generation process will find an optimal solution again. It is possible that this optimal
solution is exactly the same as x∗ (possibly after cycling through a few solutions with
the same objective value as x∗ ). Once this happens, the process will loop indefinitely.
In classic column generation, the mechanism used to prevent such cycling behavior is
to modify either the RMP or the pricing problem after each iteration, so that a column
that is selected by the pricing problem will never be selected again in the future. The
pricing problem solved in each iteration must be formulated to be different from previous
iterations, which often alters the structure of the pricing problems and complicates the
algorithms to solve them. However, our approach allows us to simply remove a prototype
from the candidates Put to avoid cycling, and the structure of the pricing problem remains
unchanged.
Secondly, we can explicitly control the order of the prototypes explored. We can utilize
problem-specific domain knowledge to explore the most promising regions first, which can
potentially speed up the convergence of the process substantially.
Thirdly, with some modifications, our PCG algorithm can converge to an optimal
solution. This will be useful if we want to solve small instances exactly. For example,
if we want to find an optimal solution to MCLCMP without the full support constraint,
we only need to set Kpcg to a large enough number; since Put is finite, we will eventually
exhaustively enumerate Put . We say that a loading pattern p dominates a loading pattern q
if p consists of at least as many boxes as q for each box type j = 1, . . . , N . In step 3a when
realizing a prototype, if we use an SCLP algorithm that enumerates all non-dominated
loading patterns for the SCLP problem, we will eventually enumerate all non-dominated
loading patterns. Hence, the optimal solution to SCP(Pu , Pr ) is also an optimal solution
to the non-support variant of MCLCMP.
A disadvantage of the explicit representation of candidate prototypes is extensive
memory usage. However, for many practical problems, this is a minor issue due to the

94
vast amounts of memory available to the average PC that can store millions of proto-
types. With the aid of problem-specific domain knowledge, having such large numbers of
prototypes is likely to lead to a solution close to the optimal solution.
Theoretically speaking, in our implementation of PCG, prototypes are solutions to the
relaxations of the pricing problems (where the loading constraints are removed). Proto-
typing and relaxation are indeed similar in the sense that both attempt to find solutions
that are very close to solutions of the original problem, and the emphasis is on reducing the
computation time. Complex constraints are often relaxed so that the resultant problem is
much easier to solve. However, there is an important distinction between the prototyping
concept and relaxation. In relaxation, the solution space of the relaxed problem is larger
than the original problem, and hence an optimal solution to the relaxed problem is a
valid lower bound to the original problem. This is vital for designing an exact algorithm,
since optimal solutions to the original problem will never be discarded in the process. In
contrast, the main objective of our prototyping strategy is to find a good solution, and
we do not have the burden of ensuring that the solution is a valid lower bound. This
greater degree of freedom opens up further possibilities for improving the efficiency of the
algorithm.
For example, when applying prototyping, we can first conduct simulations to find out
the average gap between the prototypes and the realized loading patterns (based on a
large set of randomly generated SCLP instances). We can then introduce a discount to
this gap by including a coefficient β into the relaxation of the pricing problem:

N
X
Pricing(t, β) : Minimize Ct − πj yj (3.28)
j=1
N
X
Subject to (lj wj hj )yj ≤ β · Lt Wt Ht (3.29)
j=1

0 ≤ yj ≤ nj and integer j = 1, . . . , N (3.30)

(Ct , y) ∈ P (3.31)

If the gap is about 2%, it is reasonable to believe that a solution to Pricing(t, 0.98) is
more similar to a realized loading pattern than a solution to Pricing(t, 1.0). In this case,
we can still consider an optimal solution to Pricing(t, 0.98) as a prototype, but it need
not be a valid lower bound to the pricing problem.
There are two main advantages of the PCG algorithm over the traditional column
generation technique: 1) we avoid the time consuming activity of producing feasible solu-
tions to the pricing problem when constructing the candidate prototypes Put , allowing the
master problem to explore more possibilities, and 2) the prototypes are not realized unless
they form part of the basis of an optimal solution, which avoids unnecessarily computing

95
loading patterns that are never utilized.
The PCG algorithm also inherits advantages from column generation techniques.
Many practical constraints that are hard to formulate can be easily incorporated into
the pricing subproblem; we only need to modify the algorithms for the pricing problem
to handle them, while the master problem and the overall algorithm remains unchanged.
For example, to address the full support constraint in MCLCMP, we only need to design
a container loading algorithm that ensures the full support constraint is satisfied.

3.3.3 Generating Candidate Prototypes

An integral part of the PCG strategy is to first quickly produce a large number of diverse,
high-quality prototypes Put . For MCLCMP, these prototypes are approximate solutions
to SCLP instances: they respect the loading volume constraints and box availability
constraints while ignoring the physical loading constraints.
Consider a container of type t with volume Lt Wt Ht . The volume of a box of type j
is given by lj wj hj . The maximum number of boxes of type j that can be loaded into a
container of type t is given by uj = min(nj , b(Lt Wt Ht )/(lj wj hj )c). Let SN be a user-
defined parameter called the step number. We can generate up to (SN + 1)N prototypes
for container type t as follows:

Step 1. Generate Candidates: Let pT = (p1 , p2 , . . . , pN ) denote a prototype, where

pj is the number of boxes of type j. For each box type j, there are at most SN + 1
possible choices for pj generated by stepping through the range [0, uj ] using equal
step lengths. The step length is given by SL = max{buj /SN c, 1}, and the resultant
choices for pj are 0, 1 × SL, 2 × SL, .... With N box types, we can generate up to
(SN + 1)N initial prototypes (where the total volume of the boxes does not exceed
the volume of the container).

Step 2. Maximize Prototypes: For each prototype p generated, we try to maximize

it so that no more boxes can be added without violating the volume constraint. To
do so, we uniformly randomly select a box type j and increase pj by 1 if possible
(i.e., pj < uj and the addition of the box does not violate the volume constraint).
We repeat this process until no more boxes can be added.

Step 3. Remove Dominated Prototypes: A prototype p = (p1 , p2 , . . . , pN ) is dom-

inated by another prototype q = (q1 , q2 , . . . , qN ) if pj ≤ qj for all box types. We
remove all prototypes that are dominated by other prototypes.

3.3.4 Realizing Prototypes

Realizing a prototype is equivalent to solving an SCLP instance. We can adapt the
ID-GLA algorithm developed in Section 2.1.5 (page 29) for this purpose. There are two

96
major modifications in our approach. Firstly, since there are multiple container types,
we generate a candidate block list for each type of container in advance. Whenever an
instance of SCLP needs to be solved, we select the blocks that are feasible subject to the
availability of boxes to be retained as the candidate blocks for that SCLP instance. In
this way, we can avoid redundant computations when generating blocks. Secondly, we
retain a few best solutions instead of one.
Since the CPU time allocated to realize a prototype is usually very short (a few seconds
at most), we will only employ the Single-Best-Space scheme when ranking placements
(Section 2.1.4, page 27). The depth limit of the look ahead tree search is set to 2.

3.4 Goal-driven Prototype Column Generation

The GD-PCG algorithm improves PCG in three respects. Firstly, the PCG algorithm
carries out the search in two stages and each stage approaches good solutions of MCLCMP
in its own dimension, whereas GD-PCG searches in both dimensions at the same time.
Secondly, we extend the set cover formulation with prototypes SCP by introducing a new
parameter γ, which reflects the estimated overall volume utilization of containers in an
MCLCMP solution. Thirdly, once a solution is found, a goal-driven search (Section 3.4.1)
is carried out in the neighborhood of the solution in order to improve it.
Given an MCLCMP instance, the execution of the PCG algorithm can be divided
into two stages. In the first stage (steps 2-4, page 92), a series of minimization problems
(k,l) (k,l)
SCP-RMP(Pu , Pr ), k = 1, . . . , Kpcg , l = 1, . . . , Kgap are explored, where the outer
loop introduces new prototypes and the middle loop gradually realizes prototypes into
actual loading patterns. Hence, the minimization problems more accurately model the
MCLCMP instance as the algorithm progresses. In the second stage of PCG (step 5, page
93), a binary search is carried out on loading factor α, and a series of set cover formulations
SC(Pr , α) are solved. The search performed in the two stages are carried out along two
independent dimensions. If we think of the search space as a two-dimensional plane and
plot the trail of our search, we will find that the search proceeds along one line in the first
stage, and then turns 90 degrees and proceeds along another line in the second stage.
In GD-PCG, we search along both dimensions in a single stage, i.e., we vary the set
of columns (that includes both prototypes and realized loading patterns) and the load-
ing factor at the same time. We extend the various formulations in PCG by adding the
loading factor α; when α is set to 1.0, the formulations reduce to the corresponding for-
mulations in PCG. The set cover formulation with prototypes for MCLCMP now becomes

97
SCP(Pu , Pr , α):

SCP(Pu , Pr , α) : Minimize z = cTu xu + cTr xr (3.32)

" #
xu
Subject to [Au Ar ] ≥α·n (3.33)
xr
x ≥ 0 and integer (3.34)

where Pu is a set of prototypes and Pr is a set of realized loading patterns.

We generalize the above model by taking the expected overall volume utilization of
containers in a solution into account. In any feasible solution to MCLCMP, the total
volume of the selected containers must be at least the total volume of all the boxes. Fur-
thermore, every selected container represents a loading plan, and in general the containers
are seldom fully utilized after realization regardless of the SCLP solver used. Hence, to
account for this underutilization, we require the total volume of the selected containers
to be slightly increased. Let v be the vector corresponding to the volumes of the selected
containers. The extended model is as follows:

SCP(Pu , Pr , α, γ) : Minimize z = cTu xu + cTr xr (3.35)

" #
xu
Subject to [Au Ar ] ≥α·n (3.36)
xr
x ≥ 0 and integer (3.37)
N
1X
vuT xu + vrT xr ≥ nj lj wj hj (3.38)
γ j=1

The parameter γ can be interpreted as the overall volume utilization of the loading
patterns produced by the underlying SCLP solver. By setting γ to a value that is slightly
less than 1.0, some combinations of prototypes that are unlikely to be realizable are
removed from consideration. If γ is too small, we may exclude optimal solutions. When γ
is set to 1, the extended model SCP(Pu , Pr , α, 1.0) is equivalent to SCP(Pu , Pr , α). Since
the time allocated to realizing a prototype is limited, we can safely assume that the volume
utilization for the majority of SCLP instances will be less than 99%. Consequently, we
can set γ = 0.99 to speed up our algorithm without compromising the solution quality
too much.
Let Qu ⊆ Pu ; we denote a restricted master problem that consists of only columns
corresponding to Qu and Pr as SCP-RMP(Qu , Pr , α, γ). We further classify the prototypes
in Pu − Qu by container type and use Put to denote the set of prototypes for container
type t.
Similar to PCG, GD-PCG iteratively applies column generation and is implemented
as loops nested in three levels. The details of GD-PCG are given in Algorithm 8.

98
Algorithm 8 Goal-Driven Prototype Column Generation

GD-PCG(Inst, SCLP-Solver, γ, α0 , ∆α, Kpcg , Kgap , TLCPLEX , TLSCLP )

// Input: Inst: the MCLCMP instance to be solved
// SCLP-Solver: an SCLP algorithm
// γ: the estimated capability of SCLP-Solver
// α0 , ∆α: the initial loading factor and step length
// Kpcg , Kgap : number of iterations in outer and middle for-loop
// TLCPLEX : time limit for each call to CPLEX (lines 8, 9 and 24)
// TLSCLP : time limit for each call to SCLP-Solver
// Output: The best solution to the MCLCMP
1 bestSol = NULL
2 Generate prototypes Put for each type t (see Section 3.3.3)
3 Construct Qu s.t. each box type appears in some prototype p ∈ Qu
4 Delete Qu from Put
5 for k = 1 to Kpcg by 1 // enlarge set of prototypes
6 for l = 1 to Kgap by 1 // search in two dimensions
7 α = min{α0 + (l − 1) · ∆α, 1.0}
8 Solve the LP relaxation of SCP(Pu , Pr , 1.0, γ) using column
generation; update Qu , Pr , Put accordingly

9 Let x be the solution to SCP-RMP(Qu , Pr , α, γ) found by CPLEX

// Create MCLCMP solution based on x
10 Let RB be the set of boxes in Inst
11 for each xi > 0
12 if p = (ci , Ai ) ∈ Qu
13 Remove p from Qu
14 p = realize prototype p using SCLP-Solver
15 Add p to Pr
16 Load xi containers according to loading pattern p
17 Remove loaded boxes from RB
18 Let CList be the list of containers loaded
19 Remove excess boxes from CList
20 if RB 6= ∅ then invoke Insert(RB , CList, Pr , SCLP-Solver)

21 if RB is empty
22 GoalDrivenSearch(CList, Pr , SCLP-Solver)
23 update bestSol if CList is a better solution

24 Solve SCP-RMP(∅, Pr , 1.0, 1.0) to obtain MCLCMP solution sol

25 GoalDrivenSearch(sol , Pr , SCLP-Solver)
26 update bestSol if sol is a better solution
27 Generate more prototypes and add them to Put
28 return bestSol

99
 The outer for-loop iteratively enlarges the set of prototypes considered, in a manner
similar to the outer loop of PCG (step 2-4, page 92). Using a superscript (k) to indicate
(k) (k+1)
the prototypes and loading patterns at the end of the k-th iteration, we have Pu ⊂ Pu
(k) (k+1)
and Pr ⊆ Pr , k = 1, . . . , Kpcg − 1.
The middle for-loop carries out a two-dimensional search that gradually converts pro-
totypes into loading patterns. If we fix the loading factor at one, i.e., set α0 = 1.0 and
∆α = 0, this loop is essentially identical to the middle loop in PCG (step 2-3, page 92).
If we use the pair (k, l) as a superscript to label the prototypes and loading patterns
at the end of the l-th iteration of the middle for-loop in the k-th iteration of the outer
(k,l) (k,l+1) (k,l) (k,l+1)
for-loop, we have Pu ⊃ Pu and Pr ⊂ Pr . As more prototypes are realized
(k,l) (k,l)
into loading patterns, SCP(Pu , Pr , α, γ) models MCLCMP more accurately.
There are two inner loops. The first inner loop (line 8) is a direct application of column
(k,l) (k,l)
generation to find the optimal solution to the LP relaxation of SCP(Pu , Pr , 1.0, γ).
It functions exactly the same as the inner loop of PCG (step 2, page 92), and reduces
the set of prototypes to be considered. At the end of this loop, we have identified a
(k,l,r)
subset of prototypes Qu that captures all the necessary information from the entire
(k,l)
set of prototypes Pu , in the sense that an optimal solution to the LP relaxation of
(k,l,r) (k,l) (k,l) (k,l)
SCP-RMP(Qu , Pr , 1.0, γ) is also an optimal solution to SCP(Pu , Pr , 1.0, γ).
The second inner loop (line 9 - 20) largely resembles step 3a of PCG (page 93). We
(k,l,r) (k,l)
first find a solution x to the integer program SCP-RMP(Qu , Pr , α, γ) using the
commercial solver CPLEX. For each prototype that appears in the solution, we try to
realize it by solving the corresponding SCLP instance using SCLP-Solver. We then load
containers according to the loading patterns. Since we are solving set cover formulations
instead of set packing, for some box types there may be more boxes loaded than required
by the original MCLCMP instance; we remove such excess boxes (line 19). If there are
leftover boxes, we try to “squeeze” them into the loaded containers by invoking Insert
(page 81), which has a side effect of producing new loading patterns.
If all leftover boxes are loaded, CList represents a feasible solution to the MCLCMP
instance. At this point, we immediately invoke GoalDrivenSearch to search for a
better solution (line 22). New loading patterns produced in the process will be added to
Pr .
Line 24 solves the set cover formulation for MCLCMP to find a feasible solution (note
that SCP-RMP(∅, Pr , 1.0, 1.0) is identical to SC(Pr )). This step resembles step 3b of PCG
(page 93). Once again, GoalDrivenSearch is invoked to improve the solution found
(line 25).

100
3.4.1 Goal-driven Search
Whenever we find a solution to MCLCMP, we invoke the procedure
GoalDrivenSearch to further improve the solution. Our GoalDrivenSearch pro-
cedure considers each used container and replaces it with a cheaper container if possible,
thereby producing a better MCLCMP solution.
The GoalDrivenSearch process is shown in Algorithm 9. We first sort the list of
used containers CList in decreasing order of cost. We then consider each loaded container
C in turn, and attempt to replace it with some other cheaper container. To do so, we
first compute the list of containers whose individual costs are less than C in increasing
order of cost. Then for each cheaper container C 0 , we replace the container C by C 0 and
call the procedure Insert. If the resulting solution contains all boxes (i.e., BoxList is
empty), then we have found a superior solution with reduced cost that uses the container
C 0 instead of C.

Algorithm 9 Improve solution by replacing containers

GoalDrivenSearch(CList, Pr , SCLP-Solver)
1 Sort containers in CList in decreasing order of cost
2 for each loaded container C ∈ CList
3 BoxList = all boxes in C
4 CList 0 = the list of containers whose individual costs are less than C
in increasing order of cost
5 for each container C 0 ∈ CList 0
6 Insert(BoxList, CList \ {C} ∪ {C 0 }, Pr , SCLP-Solver)
7 if BoxList is empty
8 CList = CList \ {C} ∪ {C 0 }

3.5 Handling the Full Support Constraint and Lim-

ited Supply of Containers
3.5.1 Full Support Constraint
To handle the full support constraint, we only need to require that the following two
conditions are satisfied: 1) the SCLP algorithm used to realize prototypes into actual
loading patterns ensures that the base area of all loaded boxes are fully supported, and 2)
we can recover a feasible solution to MCLCMP in step 3b) of the PCG scheme (described
in Section 3.3.2) from a solution to the restricted master problem RMP. Condition 1) can
be easily satisfied by using the version of ID-GLA that handles the full support constraint.

101
 For condition 2), let x∗ be an optimal solution to SCP-RMP(∅, Pr ) in step 3b) of the
PCG scheme. If none of the inequalities (3.26) are strict at x∗ , then the selected patterns
form a feasible solution to MCLCMP and nothing more needs to be done.
However, if some inequality strictly holds, then the selected loading patterns provide
excessive capacity for the corresponding box type. If we can remove the extra boxes from
the selected containers without violating the full support constraint, we recover a feasible
solution to the MCLCMP. Full support constraint is violated only if we try to remove
a box that supports other boxes. Therefore, when removing extra boxes, we prefer to
remove boxes that do not support other boxes whenever possible. More precisely, we try
to remove extra boxes one by one. For each extra box, we try to find a container in which
the extra box do not support any other boxes. If we can find such a container in our
solution, we remove the extra box from the container. If we can successfully remove all
extra boxes, we recover a feasible solution to the MCLCMP and we are done. Since the
number of extra boxes is usually small (compared to the demand of that box type), we
will usually be successful.
If there are still extra boxes left, we are forced to remove those extra boxes and leave
some boxes in some containers partially supported. In this case, we try to restore the
full support requirement by solving the SCLP again for those affected containers. If we
can find a fully supported SCLP solution to each of the affected container, we recover a
feasible solution to the MCLCMP. Since removing extra boxes leaves more free space in
the container, the SCLP algorithm will almost always be able to find a feasible loading
pattern.
In the worst case, if there are some containers where we failed to find a feasible SCLP
solution, i.e., some boxes cannot be loaded into the container, we can replace the container
by a larger container (in terms of volume) or even add an extra container (with lowest
cost) to obtain a feasible solution. Therefore, we can always recover a feasible solution to
MCLCMP based on the solution to SCP-RMP(∅, Pr ).

3.5.2 Limited Supply of Containers

When the number of containers is limited, we can set a limit on the number of containers
used for each type in our formulation for MCLCMP. Let Ut be the number of available
containers of type t. We can extend the set cover formulation for MCLCMP as follows.
First, we group all possible loading patterns into M groups by container type. We assume
that there are Pt single container loading patterns for container type t, t = 1, . . . , M . The
i-th loading pattern in the t-th group fills a container of type t with atij boxes of type
j. The cost associated with the i-th loading pattern is given by Ct . Let x be the integer
decision variables, where xti denotes the number of times that the i-th packing pattern
(in the t-th group) is used. A feasible solution to MCLCMP can be obtained by solving

102
the following optimization model:

M X
X Pt
SCU(P) : Minimize z = Ct xti (3.39)
t=1 i=1
M
XX Pt
Subject to atij xti ≥ nj , j = 1, . . . , N (3.40)
t=1 i=1
XPt
−xti ≥ −Ut , t = 1, . . . , M (3.41)
i=1

xti ≥ 0 and integer (3.42)

where the objective function (3.39) computes the total cost of all selected containers;
the inequalities (3.40) ensure that the selected containers have sufficient space to pack the
boxes of each type, where nj is the number of boxes to be packed for box type j; and the
new set of inequalities (3.41) ensures the number of containers used for each type does
not exceed their availability.
We arrange the columns in the constraint matrix of SCU into groups according to the
container type, i.e., A = [A1 A2 . . . AM ]. The i-th column in group At is a column vector
Ati that has N + M components. The first N components form a vector ati corresponding
to the i-th packing pattern of container type t. The next M components form a vector
−et where all components are zero except the t-th component, which is -1.
Let πj be the value of the dual variable associated with the constraint corresponding
to box type j (inequalities (3.40)), and ut be the value of the dual variable associated
with the constraint corresponding to container type t (inequalities (3.41)). The vector ati
is the solution to the following pricing subproblem (corresponding to container type t):

N
X
PricingU(t) : Minimize Ct − πj yj − (−1)ut (3.43)
j=1
N
X
Subject to (lj wj hj )yj ≤ Lt Wt Ht (3.44)
j=1

0 ≤ yj ≤ nj and integer j = 1, . . . , N (3.45)

yj boxes of type j can be
loaded into a container of (3.46)
type t
(Ct , y) ∈ Pt (3.47)

where Ct is the cost of a container of type t, lj wj hj is the volume of a box of type

103
j, and Lt Wt Ht is the volume of the container. Constraints (3.46) require that yj boxes
of type j can be loaded into a container of type t while satisfying all physical loading
constraints.
Hence, we can modify the PCG scheme in Section 3.3.2 to handle the limited supply
of containers as follows: 1) formulate the restricted master problem based on SCU instead
of SC, and 2) solve the pricing subproblems PricingU(t) instead of Pricing(t). Note that
the concepts of loading factor α and estimated overall volumue utilization of containers
γ can be introduced into SCU in a similar manner.

3.6 Test Instances

The effectiveness of SCBS, PCG and GD-PCG can only be tested empirically by con-
ducting computational experiments since they are built upon heuristic rules rather than
mathematical models with provable performance guarantees. In this section, we describe
the three sets of test instances that we used to evaluate our algorithms. The first set was
created by Ivancic et. al. [56] and includes 47 instances (Section 3.6.1). We generated the
second set of 350 instances in a way that ensures each instance has a known optimal solu-
tion with less than 100% utilization (Section 3.6.2). The third set contains 190 instances
and are based on real orders from an international acoustics equipment manufacturer
(Section 3.6.3).

3.6.1 The 47 IMM 3D Bin Packing Instances

Ivancic et. al. [56] proposed 64 instances for the multiple container loading problem: 47
instances use only one type of container, and 17 instances use 2-3 types of containers.
Unfortunately, we were unable to locate the 17 instances with multiple container types
despite searching online repositories and contacting the authors. Currently, the 47 in-
stances with a single container type are commonly used to compare the performance of
3D bin packing and multiple container loading algorithms.
Table 3.2 summarizes the 47 instances, which we call the IMM instances. The columns
bt and boxes give the number of box types and the total number of boxes, respectively,
for each test instance. The number of boxes of each box type are given in columns n1 , n2 ,
n3 , n4 and n5 , respectively. The columns VLB, KLB, BPP and ILB give lower bounds to
the optimal solutions and are computed by the following methods:

• VLB: the volume lower bound computed as the total volume of boxes divided by
the volume of the container, rounded up.

• KLB: the knapsack volume lower bound computed in two steps. Step 1: solve a
1D knapsack problem to find the maximum volume of boxes that one container

104
 can hold. Step 2: divide the total volume of boxes by the optimal solution of the
knapsack problem and round up.

• BPP: the bin packing lower bound. By ignoring the 3D aspect of the packing
problem, we obtain a 1D bin packing problem. The optimal solution to the 1D bin
packing problem is a valid lower bound.

• ILB: the lower bound computed by Ivancic et. al. [56] with an additional constraint
that type 1 boxes cannot be loaded into the same container as type 2 boxes. Hence,
this measure is not a valid lower bound for the 3D bin packing problem. However,
since this measure has been misused as a valid lower bound by a few publications,
we include it here for completeness.

3.6.2 350 New MTC Instances with Known Optimal Solutions

One drawback of the 47 IMM instances is that the optimal solutions are not known.
Although a few lower bounds have been computed for these instances, the tightness of
the bounds are unknown. In this section, we propose a method to generate instances for
MCLCMP with known optimal solutions.
Our technique begins by partitioning the containers into rectangular sub-regions. We
then try to fill each sub-region using only one type of box, which allows us to easily
control the number of box types in a container. We will only generate loading patterns
with high volume utilization so that when multiple such loading patterns are combined
into a solution to MCLCMP, the resulting solution is likely to be optimal. We will prove
later in this section that when the parameters are carefully chosen, the created solution
is indeed optimal.
Three types of containers are commonly used in the sea freight industry, called the 20-
foot (20’) container, the 40-foot (40’) container, and the 40-foot high cube (40’h) container.
We use these three types of containers to create our MCLCMP instances. Table 3.3 lists
the specifications for each container. The dimensions are given in centimeters for better
granularity.
Figure 3.5 illustrates one possible partitioning of two containers, where sub-regions
with the same dimensions are given the same label. In this example, there are three types
of sub-regions labelled C1, C2 and C3, respectively. If we fill each type of sub-region with
boxes of the same type, we can create an SCLP loading pattern with exactly three types
of boxes, which in turn can be used to create MCLCMP instances with exactly three
types of boxes.
For each type of sub-region, we would like to generate a box type that can fill up
the sub-region with high volume utilization. In addition, we would like the generated
box types to reflect common scenarios found in practice. To that end, we inspected the

105
No. bt boxes VLB KLB BPP ILB n1 n2 n3 n4 n5
1 2 70 19 19 19 19 20 50
2 2 70 7 7 7 7 20 50
3 4 180 19 19 19 19 45 60 50 25
4 4 180 26 26 26 26 45 60 50 25
5 4 180 46 46 46 46 45 60 50 25
6 3 103 10 10 10 10 35 40 28
7 3 103 16 16 16 16 35 40 28
8 3 103 4 4 4 4 35 40 28
9 2 110 16 16 17 18 50 60
10 2 110 37 38 43 47 50 60
11 2 110 14 14 14 16 50 60
12 3 95 45 45 53 45 25 30 40
13 3 95 20 20 21 22 25 30 40
14 3 95 27 27 27 28 25 30 40
15 3 95 11 11 11 11 28 37 30
16 3 95 21 21 21 21 28 37 30
17 3 95 7 7 7 7 28 37 30
18 3 47 2 2 2 2 15 12 20
19 3 47 3 3 3 3 15 12 20
20 3 47 4 4 4 4 15 12 20
21 5 95 17 17 17 17 20 17 13 24 21
22 5 95 8 8 8 8 20 17 13 24 21
23 5 95 17 17 17 17 20 17 13 24 21
24 4 72 5 5 5 5 18 20 12 22
25 4 72 4 4 4 4 18 20 12 22
26 4 72 3 3 3 3 18 20 12 22
27 3 95 4 4 4 4 43 22 30
28 3 95 9 9 9 9 43 22 30
29 4 118 15 15 15 15 30 28 37 23
30 4 118 18 18 18 18 30 28 37 23
31 4 118 11 11 11 11 30 28 37 23
32 3 90 4 4 4 4 35 40 15
33 3 90 4 4 4 4 35 40 15
34 3 90 7 7 7 7 35 40 15
35 2 84 2 2 2 3 56 28
36 2 84 10 10 10 11 56 28
37 3 102 12 12 12 12 25 32 45
38 3 102 25 25 26 26 25 32 45
39 3 102 12 12 12 12 25 32 45
40 4 85 7 7 7 7 25 25 15 20
41 4 85 14 14 14 14 25 25 15 20
42 3 90 4 4 4 4 35 30 25
43 3 90 3 3 3 3 35 30 25
44 3 90 3 3 3 3 35 30 25
45 4 99 2 2 2 2 25 20 20 34
46 4 99 2 2 2 2 25 20 20 34
47 4 99 3 3 3 3 25 20 20 34

Table 3.2: The bin packing problems IMM01-47

106
 container type volume length width height cost (USD) cost/cm3
20’ V1 590 235 239 900 2.71E-5
40’ V2 1203 235 239 1700 2.51E-5
40’h V3 1203 235 270 1800 2.36E-5

Table 3.3: Container types

Figure 3.5: Partitions for two containers

dimensions of 16 types of household appliances, e.g., television sets, air-conditioning units

and refrigerators; these are products that are commonly handled by one of our clients,
which is a buying agent for a large multinational retailer. Consequently, we set the ranges
for l, w, and h of the box types to be [27, 98], [19, 170], and [17, 67], respectively. We also
specified that the skewness of a box, defined as max{l, w, h}/ min{l, w, h}, must be less
than 7.5, which approximately corresponds to the largest skewness of the 16 considered
appliances (a DVD player).
To fill a sub-region, we enumerate all possible box types with integral dimensions and
skewness within the prescribed range. For each box type, we create an SCLP instance
where the container is the sub-region and with enough boxes to fully utilize the space
in the sub-region. Since the SCLP instance consists of only one type of box, we can
invoke the G4KP strategy to find a high quality loading pattern, and retain the pattern
in a candidate pool if its volume utilization is high. Finally, we randomly pick one
loading pattern from the candidate pool as the output of this procedure. This process is
implemented as RandFillSubRegion in Algorithm 10.
At the end of the algorithm, we discard the half of the patterns that are composed
of boxes with smaller volume. This is because the existence of several small boxes allows
small residual spaces to be easily filled, thereby reducing the difficulty of the problem.
We generated three types of MCLCMP instances to increase the variety of test data.

107
Algorithm 10 Randomly generate a box type that can fill a sub-region with high volume
utilization

RandFillSubRegion(L, W, H, [ll , lh ], [wl , wh ], [hl , hh ], maxSkewness, minUtil )

// Input: L, W, H the dimension of a sub-region
// [ll , lh ], [wl , wh ], [hl , hh ] the allowed ranges of box dimensions
// maxSkewness the maximum skewness of generated box
// minUtil the minimum volume utilization of generated loading patterns
// Output: ((l, w, h), n, p)
// (l, w, h) the dimensions of the generated box
// n number of boxes
// p a loading pattern
1 Initialize list of loading patterns Q = ∅
2 for each box type (l, w, h), l ∈ [ll , lh ], w ∈ [wl , wh ], h ∈ [hl , hh ]
3 Skip if max{l, w, h}/ min{l, w, h} > maxSkewness
4 Form an instance of SCLP with a container of dimensions L × W × H
and dL · W · H/(l · w · h)e boxes of dimensions l × w × h
5 Invoke G4KP on this instance; let p be the resulting loading pattern
6 if volume utilization of p is greater than minUtil
7 Q = Q∪p
8 Sort Q by volume of box type; discard the last 50% of Q
9 Randomly return p0 ∈ Q

Although the problem specification for all instances allow the use of all three types of
container, Type 1 instances have known optimal solutions that utilize only 40’ high cube
containers, Type 2 instances use 40’ and 40’ high cube containers, and Type 3 instances
require all three types of containers for the known optimal solution. For each type, we
generate 7 divisions of instances with 3 to 9 types of boxes, respectively.
Type 1 instances (40’h): Our generation process is as follows. For a test instance
with M box types, we arbitrarily partition the 40’h container into M types of sub-regions.
For the j-th type of sub-region, j = 1, 2, . . . , M , we invoke the RandFillSubRegion pro-
cedure to find a loading pattern with volume utilization higher than minUtil using n0j
boxes of dimensions lj × wj × hj . We simply repeat a loading pattern dj times if there
are dj sub-regions of type j. The combination of all loading patterns is therefore a valid
loading plan for the 40’h container with total utilization greater than minUtil . We then
randomly select an integer K40’h ∈ [3, 11] and multiply the number of boxes of each type
by K40’h . As a result, we have now generated an MCLCMP instance with three container
types and nj = K40’h · dj · nj boxes of dimensions lj × wj × hj with a known solution that
uses K40’h 40’ high cube containers.
We now show that the known solution is optimal if K40’h ≤ 11, minUtil = 0.99 and
the costs of the containers are as given in Table 3.3.

108
 We first construct an auxiliary minimization problem OP(K) as follows:

OP(K) : Minimize z = 900x1 + 1700x2 + 1800x3 (3.48)

Subject to V1 x1 + V2 x2 + V3 x3 ≥ 0.99KV3 (3.49)
x1 , x2 , x3 ≥ 0 and integers, (3.50)

where V1 , V2 , V3 are the volumes of a 20-foot, 40-foot and 40-foot high cube container,
respectively. Using a commercial IP solver to find the optimal solution for OP(K), we
can verify that the optimal solution is 1800K for K ≤ 11.
Consider an arbitrary optimal solution S for this MCLCMP instance that uses a1
20-foot, a2 40-foot, and a3 40-foot high cube containers. We only need to show that
x = (a1 , a2 , a3 )T is a feasible solution to OP(K40’h ) to conclude that the cost of S is
at least as high as 1800K40’h . This would in turn imply that the known solution must
be optimal, since the cost of the known solution to this MCLCMP instance is exactly
1800K40’h .
We proceed to show that x = (a1 , a2 , a3 )T is indeed a feasible solution to OP(K40’h ).
Let the total volume of boxes loaded into 20’, 40’, and 40’h containers in the solution S
be A, B, and C, respectively, and the total volume of all boxes in the problem instance
be V . Since S is a feasible solution of the MCLCMP instance, the sum of the volume of
boxes in all containers is the same as the total volume of all boxes (equation (3.51)), and
the total volume of containers of each type is large enough to accommodate the boxes
inside them (inequalities (3.52)).

A+B+C =V (3.51)

V1 a1 ≥ A, V2 a2 ≥ B, V3 a3 ≥ C (3.52)

Let u be the utilization of a 40’h container in our known solution. The total volume
of boxes in it is therefore V3 u, and the total volume of all boxes in K40’h containers is
K40’h V3 u. Since the known solution is a feasible solution, the total volume of all boxes in
K40’h containers is the same as the total volume of all boxes (equation (3.53)).

K40’h V3 u = V (3.53)

With equations (3.51), (3.52) and (3.53), we have:

V1 a1 + V2 a2 + V3 a3 ≥ A + B + C = V = K40’h V3 u ≥ 0.99K40’h V3 (3.54)

Hence, x1 = a1 , x2 = a2 , and x3 = a3 is a feasible solution to the OP(K40’h ).

For each value of M ∈ [3, 9], we generated 15 test cases by randomly selecting a value

109
for K40’h from the range [3, 11], for a total of 105 Type 1 instances.
Type 2 instances (40’ + 40’h): We use a similar technique as for Type 1 instances,
but we use both 40’ and 40’h containers.
Let K400 and K400 h be the number of 40’ and 40’h containers that we wish to include
in the known optimal solution, respectively. Using an argument similar to the Type 1
test instances, we can verify that any of the values for K400 and K400 h given in each row of
Table 3.4 ensures that the known solution with the corresponding number of containers
is optimal. For each value of M ∈ [3, 9], we generated 20 test cases by randomly selecting
a valid combination of values for K400 and K400 h , for a total of 140 Type 2 instances.

K400 range of K400 h

4 1, 2, . . . , 7
3 1, 2, . . . , 8
2 1, 2, . . . , 9
1 1, 2, . . . , 10

Table 3.4: Valid combinations of K400 and K400 h to ensure optimality of known solution

Type 3 instances (20’+40’+40’h): This test set includes all three container types
in the known optimal solutions, generated in a similar manner. Table 3.5 gives the
combinations of values for K200 , K400 , and K400 h that ensures the optimality of the known
solution. We generated 15 test cases for each value of M ∈ [3, 9] by randomly selecting
a valid combination of values for K200 , K400 and K400 h , for a total of 105 Type 3 test
instances.

K200 K400 range of K400 h

1 3 1, 2, . . . , 5
1 2 1, 2, . . . , 9
1 1 1, 2, . . . , 10

Table 3.5: Valid combinations of K200 , K400 and K400 h to ensure optimality of known
solution

We have therefore generated 50 test instances for each value of M ∈ [3, 9] for a total
of 350 test instances. They are grouped into 7 test sets of 50 instances each, labeled
mtc3, mtc4, . . . , mtc9, where mtc stands for “multiple-container test case” and the digit
corresponds to the value of M . The new instances and the known optimal solutions are
located at http://www.zhuwb.com/mclcmp, along with the partitions we used for each
test case. Table 3.6 summarizes the characteristics of the 350 MTC instances. Column
#boxes reports the average box count per instance, column opt. cost provides the total cost

110
of the optimal solutions, and column avg. vol. util. gives the average volume utilization
of the containers in the optimal solutions.

test set #instances #boxes opt. cost avg. vol. util.

mtc3 50 1828 585200 99.30%
mtc4 50 1871 611700 99.26%
mtc5 50 1890 627400 99.29%
mtc6 50 1930 614100 99.28%
mtc7 50 2136 674800 99.33%
mtc8 50 1734 577000 99.31%
mtc9 50 1886 628600 99.34%

Table 3.6: Summary of MTC Instances

Remarks on Instance Generation

Note that while we constructed the partitions of our containers by hand in these test
instances, the partitions can be completely arbitrary as long as there are M different
types of sub-regions, and a loading pattern with greater than 99% volume utilization can
be found for each sub-region. Furthermore, utilization values other than 99% can be used,
and the same process can be used to find the valid combinations for the number of each
container type that ensures the optimality of the solution. However, if the utilization value
is too small, then there may not exist a value of K40’h that ensures optimality for Type
1 instances. Note that it would also be undesirable to set the utilization value to 100%
(a perfect packing) because such instances are known to be easier to solve: for every 2D
perfect packing, there is a permutation of the boxes (rectangles) that yields that perfect
packing using the bottom-left heuristic [93, Theorem 1. pp. 9]. The same argument
applies to 3D perfect packings, so in the worst case we can enumerate the O(n!) solutions
to find an optimal solution. In contrast, the best known solution encoding scheme for
general 2D packing utilizes a sequence-pair [94], which implies that the enumeration of
O((n!)2 ) solutions may be required to find an optimal solution in the worst case.

3.6.3 190 GP Instances Based on Real Orders

We generated a new set of MCLCMP instances using data from an industrial project for an
international acoustics equipment manufacturer, divided into 190 instances with between
2 and 10 box types. Each instance of the data we obtained from this manufacturer
corresponds to an order of audio speakers, which were to be shipped in standard 20-
foot, 40-foot or 40-foot high cube containers (their prices are the same as for the MTC
instances). The original data describes relatively small orders that can be entirely loaded

111
into one container. Consequently, in order to convert this data into MCLCMP instances,
we multiplied the number of boxes of each type by 10.

3.7 Computational Experiments

SCBS, PCG and GD-PCG involve various strategies and parameters that may affect the
performance of the algorithm, so each algorithm must be carefuly calibrated to maximize
their effectiveness. We performed a series of computational experiments based on small
samples of the test instances to identify the best combination of strategies and parameter
values for the three algorithms. The main reason to use a small sample to calibrate our
algorithms is to avoid overfitting our algorithm to the given test data. If the parameters
of SCBS, PCG and GD-PCG are determined by a small sample of instances, and these
parameters also work well on the full set of test data, we can then reasonably conclude
that they are likely to work well on the unknown actual instances that arise in practice.
We report our calibration experiments for SCBS in Section 3.7.1 and for GD-PCG in
Section 3.7.2. Since GD-PCG is a generalization of PCG, the two algorithms are very
similar. The process of calibrating PCG is therefore very similar to GD-PCG, and hence
we omit the details of our calibration experiments for PCG and only report the best
configuration obtained in Section 3.7.3.
Our SCBS, PCG and GD-PCG algorithms were implemented as sequential algorithms
in Java, and no multi-threading was explicitly utilized. All experiments were conducted
on two sets of servers with the following configurations:

• HP Servers: each Hewlett-Packard server is equipped with one Intel Xeon E5430
CPU clocked at 2.66 GHz, 8 GB RAM and running CentOS 5.4. Oracle’s JDK 1.6.0
update 22 and ILog CPLEX 11.0 were installed. Both Java and CPLEX are 32-bit
editions.

• Dell Servers: each physical Dell server is equipped with one Intel Xeon E5520 CPU
clocked at 2.26 GHz (quad-core and hyper-threading enabled), 8 GB RAM, and
running the CentOS 5 linux operating system. Two virtual machines are emulated
by Virtual Box 3.0.2 and run simultaneously on a Dell server. Each virtual machine
is configured with one emulated CPU (same clock rate as physical server but only
single core), 3 GB RAM, and running 32-bit Windows XP Professional with SP2.
Oracle’s JDK 1.6.0 update 17 and ILog CPLEX 11.0 are installed on each virtual
machine. Our algorithms are executed by the emulated virtual machines. Hence, in
this setup, two copies of our algorithms are executed simultaneously on a physical
Dell server, one in each emulated virtual machine. Our algorithm uses the default
settings for CPLEX.

112
 The calibrated SCBS, PCG and GD-PCG algorithms are compared to the state-of-
the-art algorithms on the 47 IMM 3D bin packing instances in Section 3.7.4. The detailed
results achieved by SCBS on the 350 MTC instances are reported in Section 3.7.5, and then
we compare the performance of SCBS, PCG and GD-PCG on the 350 MTC instances
in Section 3.7.6. Finally, we also report the results obtained by GD-PCG on the GP
instances for future reference in Section 3.7.7.
All experiments were conducted on HP Servers, except for the experiments in Section
3.7.1 which were conducted on Dell Servers.

3.7.1 Calibration of SCBS

Given an MCLCMP instance, the performance of SCBS will be greatly affected by which
strategies are employed to generate the candidate loading patterns. It also depends on
other parameters such as the range of the loading factor [α0 , 1]. We attempt to identify the
best combination of strategies and parameter values through a series of computational
experiments based on a small sample of instances. This small sample consists of 21
MCLCMP instances randomly selected from the set of 350 MTC instances with known
optimal solutions. Recall that the MTC instances are grouped into 7 test sets, each
consisting of three types of instances; we randomly select one instance of each type from
each test set to form the sample.

Effectiveness of G4KP, S-GRASP and C-GRASP

We have developed three strategies for generating packing patterns, namely G4KP, S-
GRASP and C-GRASP, and we would like to know if they are indeed effective. We
implemented four versions of SCBS: the base version that includes all three strategies,
and three other versions that each include two of the three strategies.
The G4KP strategy uses the G4 heuristic to solve SCLP. Since the G4 heuristic is a
deterministic algorithm, so G4KP is also a deterministic algorithm. The S-GRASP and
C-GRASP strategies both use GRASP to solve SCLP. Although GRASP is a stochastic
algorithm, we have fixed the seed for the pseudorandom number generator to make it
deterministic, and as a result S-GRASP is also deterministic. As for C-GRASP, a prob-
abilistic sampling technique is used, so it remains stochastic even though we have made
the underlying GRASP deterministic. In addition, C-GRASP involves an additional pa-
rameter R; in this subsection we fixed R = 10.
Since C-GRASP is a stochastic algorithm, using different random seeds may produce
different results even on the same instance. Hence, for every version of SCBS that utilized
the C-GRASP strategy, we must analyze the impact due to randomness. Therefore, for
each of the three versions of SCBS that used C-GRASP, we executed it 5 times with
different random seeds.

113
 Table 3.7 shows the average gap to optimal for the four versions of SCBS under different
random seeds. The last row represents the base algorithm where all three strategies are
used. Each column gives the results for a particular random seed. Every cell reports the
average over 21 instances, i.e., for each instance the gap to optimal is recorded and their
average is reported. For the third row, since both the G4KP and S-GRASP strategies are
deterministic, the results are identical regardless of random seed.

Random Seed
Strategies 3 5 7 9 11
S-GRASP,C-GRASP 9.07% 9.02% 9.41% 8.95% 9.10%
G4KP,C-GRASP 8.94% 9.36% 8.88% 9.09% 8.94%
G4KP,S-GRASP 8.28% 8.28% 8.28% 8.28% 8.28%
ALL 8.26% 8.13% 8.16% 8.30% 7.95%

Table 3.7: Average gap to optimal for various strategies under different random seeds

The values in the last two rows are generally lower than the first two rows regardless
of random seed. However, we cannot definitively conclude from the table whether using
all strategies is superior or inferior to using only the G4KP and S-GRASP strategies.
Furthermore, since we have fixed the parameter R = 10 for C-GRASP, it is possible that
we may obtain better results for other values of R. Consequently, we opted to include all
strategies for the remaining experiments.
Finally, we see that the differences in solution quality caused by different random seeds
are relatively small when all strategies are included.

Finding Best Parameter Values

In this study, all three strategies G4KP, S-GRASP and C-GRASP are used. Our SCBS
approach involves three parameters:

• α0 : the lower bound for the range of the loading factor α to be searched

• R: The maximum number of loading patterns generated per container type and
number of box types in the C-GRASP strategy

• The random seed for C-GRASP

To find the best combination of R and α0 , we followed the practice advocated for the
design of experiments [95]. We employed the 22 factorial design with center point. For
the factor R we considered two levels 5 and 15; for the factor α0 we considered two levels
0.01 and 0.75. The center point is hence R = (5 + 15)/2 = 10 and α0 = 0.5. Since
we used binary search to decide the loading factor α, the range of the loading factor is
halved in each iteration. From the point of view of the size of the initial range, α0 = 0.5

114
is the middle point of α0 = 0 and α0 = 0.75. Furthermore, if we set α = 0, the set cover
formulation SC(P, α) is trivial, so we use a very small positive number instead of zero.
As a result, five combinations of R and α0 are tried. For each combination, we repeat-
edly solve each of the 21 instances five times using random seeds 3, 5, 7, 9 and 11, for a
total of 21 × 5 = 105 data points. Each data point includes the gap of the solution to the
optimal and the time used to obtain the solution.
To see the overall effect, we summarize the average gap and time for the five com-
binations in Table 3.8. We can see the general trend where as R is reduced, we obtain
solutions with smaller gaps to optimal; similarly, when we reduce α0 we obtain better
solutions. We achieve the best overall performance (in terms of gap to optimal) with
R = 5 and α0 = 0.01.

α0 = 0.01 α0 = 0.5 α0 = 0.75

avg. gap. avg. t(s) avg. gap. avg. t(s) avg. gap. avg. t(s)
R=5 7.80% 6621 8.44% 5834
R = 10 8.16% 7030
R = 15 7.96% 6192 8.27% 7153

Table 3.8: Overall performance of various combinations of R and α0

To check if the observed trend is consistent under different random seeds, we break
down the result by random seed in Table 3.9. We observe that the trend still holds for
seeds 3, 5, 7 and 11. For seed 9, the combination R = 5 and α0 = 0.01 is second best,
but a similar trend can still be observed in this case.

Impact of Randomness

Since the C-GRASP strategy used by SCBS contains a stochastic component, we would
expect that SCBS will produce slightly different solutions for the same input instance
when different random seeds are used. Ideally, we would like to minimize the fluctuations
due to such randomness. Table 3.10 gives the detailed results on the 21 instances produced
by SCBS with R = 5 and α0 = 0.01 under various random seeds. The gap to optimal
is reported for each instance. We see that for the majority of instances, the fluctuation
is small (far less than 2%). Occasionally, the fluctuation can be as large as 8%, e.g., for
instance mtc7-36 the gap to optimal using random seed 3 is 3.28% compared to 11.48% for
random seed 5. However, these fluctuations are mitigated when we examine the overall
performance on the 21 instances: the best average gap to optimal using seed 3 is 7.5%,
while the worst seed 9 is 8.1%, so the absolute difference is only 0.6%. As the number
of instances grows, we would expect the difference between the overall performance for
different random seeds to be insignificant, i.e., we believe no seed is significantly better
than any other seed. Hence, we can fix the random seed to an arbitrary number when

115
 α0 = 0.01 α0 = 0.5 α0 = 0.75
Seed R
avg. gap. avg. t(s) avg. gap. avg. t(s) avg. gap. avg. t(s)
5 7.50% 7182 8.53% 5808
3 10 8.26% 6320
15 7.91% 6242 8.30% 6645
5 7.84% 7213 8.57% 5788
5 10 8.13% 8106
15 8.00% 6337 8.05% 6448
5 8.00% 7636 8.55% 5780
7 10 8.16% 7877
15 8.09% 6306 8.46% 7106
5 8.10% 5411 8.59% 5882
9 10 8.30% 6536
15 7.77% 5840 8.29% 6818
5 7.56% 5665 7.98% 5912
11 10 7.95% 6310
15 8.01% 6233 8.22% 8747

Table 3.9: Effect of R and α0 broken down by random seed

assessing the overall performance of SCBS over a large set of instances.

When solving a particular instance in practice, we recommend executing SCBS a few
times with different random seeds and taking the best solution so as to minimize the
fluctuations in performance due to randomness. The execution of SCBS can be easily
carried out in parallel to take advantage of the multi-core CPU’s commonly available
nowadays, so the total execution time will not increase by too much as a result.

3.7.2 Calibration of GD-PCG

There are a few parameters in our algorithm that control the trade-offs between solution
quality, robustness and execution time. We attempted to identify the best configuration as
follows. Starting with a base configuration, we vary one parameter while keeping the other
parameters unchanged to create alternative configurations. We then conduct experiments
on a small set of test data to compare the performance of the various configurations. The
experiments in this subsection were conducted on 21 of the MTC instances. Recall that
the MTC instances are grouped into 7 test sets, each consisting of three types of instances;
we randomly select one instance of each type from each test set to form the sample.
After an experiment, we analyze the results to evaluate the impact of the parameter
on the algorithm’s performance, and then we pick a configuration that we believe achieved
the best balance of performance and robustness. We then use this configuration as the
new basis and proceed to decide the best value for the next parameter. We perform this

116
 seed
Instance
3 5 7 9 11
mtc3-1 7.78% 7.78% 7.78% 7.78% 7.78%
mtc3-16 5.59% 4.97% 5.59% 4.97% 5.59%
mtc3-36 6.25% 6.25% 6.25% 6.25% 6.25%
mtc4-1 4.44% 4.44% 4.44% 4.44% 4.44%
mtc4-16 4.90% 4.90% 4.90% 4.90% 4.90%
mtc4-36 2.27% 2.27% 2.27% 2.27% 2.27%
mtc5-1 6.25% 5.56% 6.25% 5.56% 5.56%
mtc5-16 11.27% 11.27% 11.27% 12.68% 9.86%
mtc5-36 7.14% 7.14% 7.14% 7.14% 8.16%
mtc6-1 14.81% 14.81% 14.81% 16.67% 16.67%
mtc6-16 5.10% 4.59% 5.10% 4.59% 4.59%
mtc6-36 5.30% 5.30% 6.06% 6.06% 2.27%
mtc7-1 14.81% 14.81% 14.81% 14.81% 14.81%
mtc7-16 7.38% 7.38% 8.20% 8.20% 3.28%
mtc7-36 3.28% 11.48% 11.48% 11.48% 11.48%
mtc8-1 12.50% 12.50% 12.50% 12.50% 12.50%
mtc8-16 3.45% 3.45% 3.45% 3.45% 3.45%
mtc8-36 10.13% 10.13% 10.13% 10.13% 10.13%
mtc9-1 8.64% 8.64% 8.64% 9.26% 8.64%
mtc9-16 7.26% 8.06% 8.06% 8.06% 7.26%
mtc9-36 8.97% 8.97% 8.97% 8.97% 8.97%
Avg 7.50% 7.84% 8.00% 8.10% 7.56%

Table 3.10: Gap to optimal obtained by R = 5, α0 = 0.01 using various random seeds

117
series of experiments such that the parameters that are expected to have the greatest
impact to performance are decided first.
Note that most parameters are interdependent, i.e., the best value for one parameter
depends on the values of other parameters. Hence, after we pick the “best values” for a
few parameters, it is necessary to verify that the choices we made for earlier parameters
remain the best choices. The entire process is essentially a manual search for the best
configuration in the parameter space by trial and error. Our calibration process ends
once a locally optimal configuration is found, i.e., if we vary any parameter in our final
configuration, the performance or robustness of the algorithm deteriorates.
Our experiments established that the following configuration for GD-PCG achieves a
good balance of effectiveness and robustness on our test data:

• The initial prototypes Qu includes 20 for each container type

• The number of iterations of the outer loop of GD-PCG Kpcg = 1 (line 5, Algorithm
8, page 99)

• The number of iterations of the middle loop of GD-PCG Kgap = 10 (line 6, Algo-
rithm 8, page 99)

• The time limit for each invocation of CPLEX TimeLimitCplex = 15s

• Perform the search by increasing α, specifically α0 = 0.85, ∆α = 0.02

• Estimated overall volume utilization γ = 0.99 (page 98)

• The time limit to realize a prototype by ID-GLA TimeLimitSCLP = 5s

We will use this “locally optimal” configuration as the base configuration to illustrate
how we varied one parameter at a time in order to pick the best value for each parameter.
For each configuration of the GD-PCG algorithm, we invoke it once for each instance
and record the best solution after each iteration of the middle loop. Since we know the
optimal solutions for the MTC test set, we can compute the percentage gap to optimal of
the produced solutions. After all 21 instances are solved, for each iteration of the middle
loop, we compute the average gap over the 21 instances and use it as the performance
indicator for that iteration. Finally, we plot the performance of each configuration over
the iterations. This allows us to easily visualize both the convergency behavior and the
overall performance of each configuration.

Impact of Search Direction of Loading Factor α

In the base version of GD-PCG, the value of α is initially set to α0 = 0.85 and increased
by ∆α = 0.02 in each iteration of the middle loop (line 6, Algorithm 8, page 99); this

118
corresponds to an upward linear search. We configured two additional versions of GD-
PCG:

• downward linear search: where α0 = 1.0 and ∆α = −0.02

• fixed α = 1.0: where ∆α = 0. This resembles the strategy used the PCG algorithm

Figure 3.6 plots the overall performance of the three configurations over the iterations.
Either upward (line labelled 0.85 ↑) or downward (line labelled 1.0 ↓) linear search on α
performs consistently better than using a fixed loading factor α = 1.0 throughout all 10
iterations. Since fixing the loading factor at α = 1.0 resembles the strategy used by the
PCG algorithm, we can conclude that the strategy by GD-PCG is better.

5.50%

5.00%

4.50%
Gap to Opt.

4.00% α = 1.00 ↓
α = 0.85 ↑
3.50%
α = 1.00
3.00%

2.50%
1 2 3 4 5 6 7 8 9 10
Iteration

Figure 3.6: Performance of various search strategies on loading factor α. Average gap to
optimal is reported for each iteration of the middle loop of GD-PCG

We prefer linear upward search on α in our final GD-PCG algorithm since it performs
better than both linear downward search and fixed loading factor.

Impact of Estimated Overall Volume Utilization γ

In the base version of GD-PCG, we set γ = 0.99, which indicates that we expect to utilize
up to 99% of the total volume of all containers in an MCLCMP solution. We created two
additional configurations with γ = 1.0 and γ = 0.98 for comparison. Figure 3.7 plots the
performance of these three versions of GD-PCG over the iterations.
We can see that γ = 0.99 outperforms γ = 1.0. This is mainly because, given the short
time frame, the underlying SCLP algorithm is unlikely to produce loading patterns with
volume utilization higher than 99%. Hence, setting γ = 0.99 eliminates those prototypes
that are very unlikely to be realized from consideration and improves the overall efficiency.
As we further reduce γ to 0.98, we eliminate more prototypes from consideration. It
happens that in the optimal soluitons of MTC instances, the average volume utilization of

119
 6.00%

5.50%

Gap to Opt. 5.00%

4.50%
γ=0.98
4.00%
γ=0.99
3.50% γ=1.00
3.00%

2.50%
1 2 3 4 5 6 7 8 9 10
Iteration

Figure 3.7: Performance of various settings of γ. Average gap to optimal is reported for
each iteration of the middle loop of GD-PCG

the containers are as high as 99%. Therefore, this setting eliminates the optimal solutions
and possibly many near-optimal solutions, which explains why γ = 0.98 is worse than
γ = 0.99 after five iterations.
This experiment shows that if we can guess the expected volume utilization, we can
improve the quality of the solutions. For instances in a real application, we do not
know the expected overall volume utilization in advance. However, we can still gather
some form of knowledge using statistics. For example, we can record the average volume
utilization of the solutions found by our SCLP solver over a series of trial runs, and then
set γ accordingly after a sufficient number of problem instances have been solved. If we
observed that the average is 95%, we can be a little bit conservative and set γ = 0.97.
Since the assortment of boxes in some applications (for example in factories) are expected
to be stable, this method of estimating the capability of the SCLP solver may be effective
as the volume utilization of containers is also likely to remain reasonably stable in the
same application environment.

Impact of GoalDrivenSearch

In the base version of GD-PCG, once a feasible solution is found, the

GoalDrivenSearch procedure is invoked to try to find an improved solution. We
implemented another version of GD-PCG where this goal driven search is disabled. The
comparison of these two versions of GD-PCG are plotted in Figure 3.8.
When GoalDrivenSearch is disabled (line labelled no GD), GD-PCG can still con-
verge to good results eventually, but it does not perform as well in earlier iterations. When
we compare the total execution time and time-to-best (Table 3.11), it becomes clearer that
GD-PCG converges much faster when GoalDrivenSearch is enabled. Hence, we can

120
 4.50%
4.00%
3.50%
3.00%
2.50%
GD
2.00%
no GD
1.50%
1.00%
0.50%
0.00%
1 2 3 4 5 6 7 8 9 10

Figure 3.8: Impact of GoalDrivenSearch on overall performance. Average gap to

optimal is reported for each iteration of the middle loop of GD-PCG

conclude that the

GoalDrivenSearch procedure introduced in GD-PCG is indeed useful.

Goal-driven avg. gap avg. t(s) avg. ttb(s)

enabled 2.88% 1151 340
disabled 2.92% 1767 405

Table 3.11: Impact of GoalDrivenSearch on overall performance

Impact of CPLEX Time Limit

In the base version, we set the time limit for each invocation of CPLEX to be 15 seconds.
That is, when solving the LP and IP models, if an optimal solution cannot be found
before the time limit, the best solution found so far will be returned when the time limit
is reached. We have tried setting the time limit to be 2s, 5s, 10s, 15s, 20s, and 25s. The
overall performance over the iterations is plotted in Figure 3.9. In general, there is not
much difference.
Although setting the CPLEX time limit to 15s seems slightly better than the other
settings, the difference is slight. When we look at the final solutions at iteration 10, the
difference is even smaller (column avg. gap in Table 3.12).
However, the time limit for CPLEX does impact both the total execution time and
how quickly we can find the best solutions. Table 3.12 reports the total execution time
in column avg. t(s) and the time when the best solution is found in column avg. ttb(s);
both values are averaged over the 21 test instances. As expected, as the time limit for
CPLEX decreases, the total execution time decreases. The increase in total execution

121
 5.00%

4.50%
2s
Gap to Opt.

4.00%
5s
10s
3.50%
15s
3.00% 20s
25s
2.50%
1 2 3 4 5 6 7 8 9 10
Iterations

Figure 3.9: Performance of various settings for CPLEX time limit. Average gap to optimal
is reported for each iteration of the middle loop of GD-PCG

CPLEX Time avg. gap avg. t(s) avg. ttb(s)

2s 3.09% 1041 413
5s 2.98% 1094 379
10s 2.92% 1131 412
15s 2.88% 1151 340
20s 2.98% 1275 381
25s 2.98% 1276 414

Table 3.12: Impact of CPLEX time limit on overall performance

122
time is not in proportion to the increase in CPLEX time limit. This is mainly because
the set cover problem is well-studied and CPLEX is able to find an optimal solution for
many instances in a short time. Only a few large instances causes CPLEX to eventually
reach the time limit.
The time-to-best ttb shows an interesting trend that is different from the total execu-
tion time. As the time limit for CPLEX decreases, the time-to-best first decreases and
then increases, with the minimum achieved when the CPLEX time limit is set to 15s. This
indicates a change in the behavior of GD-PCG. One possible explanation for this change
is as follows. When the time limit for CPLEX is reduced, the quality of the solution found
by CPLEX is also reduced (the average gap to optimal is enlarged). Initially, the reduced
time limit does not lead to much deterioration of the solution quality by CPLEX, which
leads to a net reduction in time-to-best. When the time limit is very short, the solutions
found by CPLEX are comparatively poor, so GD-PCG must rely more on the Insert and
GoalDrivenSearch procedures to improve the solution. Furthermore, the inner loop
that iteratively adds columns until an optimal solution to LP is found may also require
more iterations. The net result is an increased time-to-best on average.
Based on these observations, we prefer to set the CPLEX time limit to 15s for two
reasons. Firstly, we feel that time-to-best is a more meaningful indicator of the speed of
an algorithm, since total execution time can be easily adjusted by changing the number
of iterations Kgap . When we set the CPLEX time limit to 15s, the average time-to-best is
shortest. Secondly, there is a possible change of behavior in GD-PCG when the CPLEX
time limit is further reduced, where the algorithm shifts from relying on solving the set
cover formulation in order to identify high quality solutions to relying more on the ad-hoc
GoalDrivenSearch procedure to improve solutions. We feel that solving the set cover
formulation represents the high level decision in solving MCLCMP, so relying on solving
set cover is more reliable.

Impact of SCLP Time Limit

In the base version, the time limit for solving one instance of SCLP is set to 5s. We also
tried 2.5s and 10s, and plotted the results in Figure 3.10.
We can see that both 5s and 10s outperform 2.5s. This is because increasing the SCLP
time limit will always improve (though not monotonically) the quality of the loading
patterns produced, hence the probability of finding better final solutions increases. When
the time limit for SCLP is sufficiently large, the quality of the SCLP solution will no
longer be the bottleneck, and a further increase of time allocated to SCLP will not result
in significant improvements in the overall solutions.
From Table 3.13, we can see that increases in the SCLP time limit have a very signifi-
cant impact on the total execution time (column avg. t(s)) and time-to-best (column avg.
ttb(s)). Although SCLP with time limits of 10s and 5s converged to similar solutions after

123
 5.00%

4.50%
Gap to Opt.
4.00%
2.5s
3.50% 5s
10s
3.00%

2.50%
1 2 3 4 5 6 7 8 9 10
Iteration

Figure 3.10: Performance of various settings for SCLP time limit. Average gap to optimal
is reported for each iteration of the middle loop of GD-PCG

the same number of iterations (7 iterations), from the execution time point of view the
time-to-best for the 10s version is 60% more than for the 5s version. This is not surprising
since the former takes twice the time to solve each SCLP instance.
Based on these observations, we picked 5s as the time limit for SCLP, since increasing
it from 5s to 10s does not improve the overall solutions while significantly increasing the
total execution time and time-to-best.

SCLP Time avg. gap avg. t(s) avg. ttb(s)

2.5s 3.26% 704 226
5s 2.88% 1151 340
10s 2.92% 1972 556

Table 3.13: Impact of SCLP time limit on overall performance

3.7.3 Calibration of PCG

The best configuration for PCG was identified with a series of computational experiments
very similar to GD-PCG. Since the calibration process is similar, we omit the details and
only summarize the best configuration as follows:

• The number of initial prototypes for each container type |Put | = 20

• The number of iterations of the outer loop in step 4 of the PCG scheme Kpcg = 1
(page 93)

• The maximum number of iterations to close the gap in step 3c of the PCG scheme
Kgap = 20 (page 93), and the maximum tolerance between the LP relaxation of

124
 RMPP and RMP  = 0

• The time limit for each invocation of CPLEX TimeLimitCplex = 15s

• Number of iterations of binary search in step 5 of PCG algorithm is set to 6 (page

93)

• The SCLP solver is configured as follows

– The time limit to realize a prototype by ID-GLA TimeLimitSCLP = 5s

– The search depth in the look ahead tree search is set to 2
– The Single-Best-Space scheme is used

3.7.4 Comparisons on IMM 3D Bin-Packing Instances

The 47 instances of the bin-packing problems proposed by Ivancic et. al. [56] have become a
standard benchmark test set for multiple container loading problems. Only one container
type is used, and the objective is to minimize the number of containers used to pack all
the boxes. We compared our SCBS and PCG approaches with the following algorithms
that do not consider the full support constraint:

• IMM: an integer programming based approach by Ivancic et. al. [56]; the result is
reported by Bischoff and Ratcliff [14]

• BO: the heuristic by Bortfeldt [96]

• IC: the Iterated Construction approach by Lim and Zhang [57]

• SA : the simulated annealing approach by Takahara [97]

• MS : the multi-start local search approach by Takahara [98]

In Table 3.14, column lb reports the valid lower bounds (computed by only considering
the volume and solving the corresponding 1D BPP exactly). The values stated for each
technique is the number of containers required for the solution generated. The columns
tt(s) under the headings SCBS and PCG report the total execution time by SCBS and
PCG, respectively. The last row reports the average time taken by SCBS and PCG ove
rall 47 instances.
For each of the 47 instances, we executed SCBS five times using random seeds 3, 5, 7,
9, and 11. The results corresponding to various seeds are very similar (the total number
of bins for the 47 instances are 693, 693, 691, 691 and 692, respectively); we only report
the detailed results corresponding to seed 11 in Table 3.14 due to space limitations.
We have modified step 1 of the PCG scheme by setting a sufficiently large step number
SN so that the step length is 1 when generating candidate prototypes (Section 3.3.3).

125
 SCBS PCG
No. lb IMM BO IC SA MS
bin# tt(s) bin# tt(s)
1 19 26 25 25 25 25 25 12 25 0.51
2 7 11 10 10 10 10 10 4 9 4.70
3 19 20 20 19 20 20 19 168 19 3.14
4 26 27 28 26 26 26 26 75 26 1.01
5 46 65 51 51 51 51 51 176 51 0.38
6 10 10 10 10 10 10 10 12 10 0.32
7 16 16 16 16 16 16 16 15 16 0.03
8 4 5 4 4 4 4 4 12 4 10.18
9 17 19 19 19 19 19 19 18 19 1.16
10 43 55 55 55 55 55 55 28 55 0.17
11 14 18 18 16 16 16 16 22 16 1.21
12 53 55 53 53 53 53 53 58 53 0.10
13 21 27 25 25 25 25 25 52 25 1.70
14 27 28 28 27 27 27 27 21 27 1.15
15 11 11 11 11 11 11 11 13 11 3.07
16 21 34 26 26 26 26 26 44 26 0.84
17 7 8 7 7 7 7 7 34 7 12.60
18 2 3 2 2 2 2 2 9 2 15.27
19 3 3 3 3 3 3 3 8 3 7.11
20 4 5 5 5 5 5 5 18 5 13.78
21 17 24 21 20 20 20 20 159 20 11.26
22 8 10 9 9 9 9 8 105 8 12.05
23 17 21 20 20 20 20 19 74 19 6.98
24 5 6 6 5 5 5 5 61 5 12.24
25 4 6 5 5 5 5 5 16 5 389.86
26 3 3 3 3 3 3 3 20 3 19.17
27 4 5 5 5 5 5 4 27 4 34.35
28 9 10 10 9 10 10 10 46 9 2.88
29 15 18 17 17 17 17 17 140 16 16.38
30 18 24 22 22 22 22 22 140 22 11.32
31 11 13 13 12 13 13 12 63 12 60.45
32 4 5 4 4 4 4 4 19 4 15.34
33 4 5 5 4 5 5 4 29 4 8.68
34 7 9 8 8 8 8 8 9 8 10.32
35 2 3 2 2 2 2 2 11 2 45.04
36 10 18 14 14 14 14 14 13 14 2.33
37 12 26 23 23 23 23 23 28 23 28.29
38 26 50 45 45 45 45 45 44 45 0.96
39 12 16 15 15 15 15 15 30 15 32.73
40 7 9 9 9 9 9 8 24 8 93.98
41 14 16 15 15 15 15 15 81 15 6.15
42 4 4 4 4 4 4 4 19 4 9.70
43 3 3 3 3 3 3 3 15 3 17.23
44 3 4 3 3 3 3 3 18 3 25.98
45 2 3 3 3 3 3 3 57 2 520.90
46 2 2 2 2 2 2 2 43 2 56.08
47 3 4 3 3 3 3 3 39 3 40.71
total 596 763 705 694 698 698 691 687
avg tme 45 33.40

Table 3.14: Results on bin packing problems IMM01-47 without full support constraint;
SCBS uses seed 11; new best solutions are in bold; worse solutions are in italics

126
The main purpose is to make sure a sufficiently large number of candidate prototypes are
generated. This is because both the number of box types and number of boxes per type
is small for most of the instances, so the number of all possible patterns is small.
For 45 out of the 47 instances, our SCBS algorithm found solutions that are the same
as the best results in literature. For instance no. 23, SCBS improves the best known
result by 1, while it is worse than the best known result by 1 for instance 28. Our PCG
algorithm finds better or equal solutions for all 47 instances. It finds new best solutions
for instances no. 2, no. 29 and no. 45.
Over all test instances, the total number of bins required by SCBS (691) and PCG
(687) are less than all existing approaches. PCG improves on SCBS by three bins while
using less CPU time on average. This suggests that combining prototypes with column
generation is a more efficient and effective method than existing approaches.
We also incorporated the neccessary changes into PCG to handle the full support
constraint (Section 3.5.1) and compared it with the following algorithms that also enforce
the full support constraint in Table 3.15:

• SEQ: the sequential version of the approach by Eley [50].

• SIM: the simultaneous version of the approach by Eley [50].

• BOT: the set cover based bottleneck approach by Eley [59].

For the full support case, our PCG algorithm achieves the same or better results than
the existing approaches for all instances. The total number of containers required over all
instances for PCG is 693 compared to the 699 containers required by the previous best
approach. In addition, PCG finds six new best solutions (highlighted in bold).
Although the SCBS and PCG algorithms were developed for MCLCMP rather than
the specific bin-packing problem variant, they are able to slightly improve on existing
techniques for the bin-packing problem. Importantly, it is unclear how these existing
algorithms can be adapted to solve MCLCMP, where the costs for multiple container
types are different.

3.7.5 Results of SCBS on MTC Instances

Since our SCBS algorithm has a stochastic component, we executed SCBS three times for
each instance, and we fixed the initial seed used by the pseudorandom number generator
to 3, 11 and 5 for the three executions.
Table 3.16 provides the results for the SCBS approach on the 350 MTC instances.
The columns under the headings seed = 3, seed = 11 and seed = 5 present the results
for SCBS when the pseudorandom number generator is initialized with seed 3, 11 and
5, respectively. The instances are divided into seven sets mtc3 - mtc9 of 50 instances

127
 PCG
No. lb SEQ SIM BOT
bin# tt(s)
1 19 27 26 25 25 0.50
2 7 11 10 10 10 3.44
3 19 21 22 20 19 2.20
4 26 29 30 26 26 0.90
5 46 55 51 51 51 0.29
6 10 10 10 10 10 0.25
7 16 16 16 16 16 0.03
8 4 4 4 4 4 8.59
9 17 19 19 19 19 0.87
10 43 55 55 55 55 0.14
11 14 17 18 17 17 1.19
12 53 53 53 53 53 0.09
13 21 25 25 25 25 1.24
14 27 27 27 27 27 0.85
15 11 12 12 11 11 2.51
16 21 28 26 26 26 0.58
17 7 8 7 7 7 8.77
18 2 2 2 2 2 12.05
19 3 3 3 3 3 3.30
20 4 5 5 5 5 7.59
21 17 24 26 20 20 6.98
22 8 9 9 8 8 16.79
23 17 21 21 20 20 5.76
24 5 6 6 6 5 20.58
25 4 6 5 5 5 308.89
26 3 3 3 3 3 52.53
27 4 5 5 5 4 68.15
28 9 11 10 10 10 26.81
29 15 18 18 17 17 12.81
30 18 22 23 22 22 5.82
31 11 13 14 13 12 33.25
32 4 4 4 4 4 14.53
33 4 5 5 5 4 8.84
34 7 8 9 8 8 10.33
35 2 2 2 2 2 45.05
36 10 18 14 14 14 2.40
37 12 26 23 23 23 26.15
38 26 46 45 45 45 0.86
39 12 15 15 15 15 18.16
40 7 9 9 8 8 58.21
41 14 16 15 15 15 2.43
42 4 4 4 4 4 9.69
43 3 3 3 3 3 16.92
44 3 4 4 4 3 24.37
45 2 3 3 3 3 619.77
46 2 2 2 2 2 56.85
47 3 3 3 3 3 42.24
total 596 733 721 699 693
avg tme 33.42

Table 3.15: Results on bin packing problems IMM01-47 with full support constraint; new
best solutions are in bold.

128
each, where the suffix gives the number of box types in each instance in that set. The
gap columns give the average percentage difference between the SCBS solution and the
optimal solution, computed as (cost − optimal cost)/optimal cost. The vol. util columns
provide the average volume utilization of the containers in the solutions found by SCBS.
The columns t(s) give the average time taken by SCBS in CPU seconds. Finally, the last
row of the table provides the average over 350 instances.

seed = 3 seed = 11 seed = 5

set gap vol.util t(s) gap vol.util t(s) gap vol.util t(s)
mtc3 5.45% 95.24% 727 5.42% 95.28% 717 5.47% 95.35% 729
mtc4 5.43% 94.50% 1282 5.30% 94.56% 1272 5.53% 94.35% 1307
mtc5 6.78% 93.65% 2040 6.76% 93.63% 1976 6.82% 93.61% 1993
mtc6 7.66% 92.78% 3139 7.65% 92.90% 3060 7.67% 93.08% 3065
mtc7 6.94% 93.17% 4303 7.08% 93.18% 4337 7.01% 93.08% 4381
mtc8 8.81% 91.81% 5126 9.13% 91.72% 5149 8.91% 91.70% 5128
mtc9 9.00% 91.59% 6782 9.06% 91.62% 6871 9.42% 91.49% 6696
avg. 7.15% 93.25% 3343 7.20% 93.27% 3340 7.26% 93.24% 3328

Table 3.16: Results of SCBS on MTC instances

The results show that even though SCBS has a stochastic component, the overall
performance on any of the 7 sets of instances is stable regardless of the random seed
used. Hence, we base the following analysis on the results obtained using seed 3. The
results show that the average gap between the SCBS approach and the known optimal
solution over all 7 sets of instances is 7.15%, and this gap increases as the number of
box types increases. This is not a small difference, which shows that although SCBS
outperforms existing algorithms for the standard bin packing test problems, it is only
moderately successful when solving MCLCMP instances. Also note that the average
volume utilization of the SCBS solutions is less than 92% for test sets mtc8 and mtc9
even though the optimal solution has a volume utilization of over 99.30%. It is reasonable
to say that the MCLCMP is a difficult problem that deserves further research.

3.7.6 Comparison between SCBS, PCG and GD-PCG on MTC

Instances
Table 3.17 compares SCBS, PCG and GD-PCG on the 350 MTC instances without the
full support constraint. All figures reported in the table are averaged over the 50 instances
of each test set except the last column SN. Given the cost of the solution found and the
optimal solution for an instance, the gap from optimal for an algorithm is calculated
as (cost − opt)/opt; the columns gap report the average gap from optimal over the 50
instances, and the columns t(s) give the average time taken in CPU seconds for the

129
corresponding algorithm. For the GD-PCG approach, the column ttb(s) is the average
amount of computation time in CPU seconds required for GD-PCG to first find its final
best solution, and the column SN is the value of the step number parameter SN that
controls the number of candidate prototypes generated.

SCBS PCG GD-PCG

set
gap t(s) gap t(s) gap t(s) ttb(s) SN
mtc3 5.76% 1725 2.86% 784 2.54% 907 223 30
mtc4 6.11% 3523 2.75% 1189 2.56% 1075 228 20
mtc5 7.45% 5806 3.43% 1467 2.69% 1222 380 20
mtc6 8.77% 8319 4.03% 1334 2.61% 1158 324 10
mtc7 8.87% 11815 4.08% 1332 2.40% 1216 394 10
mtc8 10.80% 12197 5.94% 864 3.10% 1079 376 10
mtc9 10.56% 15989 5.58% 951 2.66% 1153 425 10
avg. 8.33% 8482 4.10% 1132 2.65% 1116 336

Table 3.17: Computational results on MTC instances (without full support constraint)

The results indicate that the gap between PCG and the optimal solution is signifi-
cantly smaller than the gap between SCBS and the optimal solution. Since a smaller gap
to optimal implies better solution quality, we can conclude that PCG produces better so-
lutions than SCBS on average. Although the problem sizes (in terms of number of boxes
per instance) are approximately the same across all 7 test sets, the gap to optimal for
both SCBS and PCG increases as the number of box types increases. This observation
is in line with the common understanding that strongly heterogeneous container packing
instances are generally harder than weakly heterogeneous instances.
For the SCBS algorithm, the increasing heterogeneity not only causes the quality
of the solutions to deteriorate, it also increases the CPU time required on average. In
contrast, the PCG algorithm behaves differently, where the CPU time first increases as
heterogeneity increases and then decreases. Also note that the variation in CPU time
for PCG is not as large as SCBS across the seven test sets. Since the computational
environments for PCG and SCBS are identical, and the average execution time of PCG
is only about 1/8 of SCBS, we can conclude that PCG produces higher quality solutions
using less computation time.
The results also indicate that the average gap to optimal for GD-PCG is significantly
smaller than that for SCBS and PCG. Furthermore, the performance of GD-PCG is less
affected by the heterogeneity of the test instances, since both the gaps to optimal and
the total execution times of GD-PCG are more consistent across the seven test sets than
PCG.
Since the SCLP algorithm employed by GD-PCG is identical to PCG and the average
total execution time of GD-PCG is similar to PCG, we can conclude that the increase in

130
solution quality is mainly due to the enhancements introduced in GD-PCG.

PCG GD-PCG
set
gap t(s) gap t(s) ttb(s) SN
mtc3 3.21% 894 3.24% 1056 228 30
mtc4 2.98% 1362 2.96% 1170 300 20
mtc5 3.96% 1630 3.11% 1346 438 20
mtc6 4.37% 1442 3.07% 1338 481 10
mtc7 4.42% 1423 2.67% 1399 567 10
mtc8 6.39% 937 3.60% 1211 561 10
mtc9 6.02% 1123 3.03% 1322 598 10
avg. 4.48% 1259 3.10% 1263 453

Table 3.18: Computational results on MTC instances (with full support constraint)

Table 3.18 compares PCG and GD-PCG on the MTC instances with the full support
constraint enforced. The results are similar to those for the MTC instances without
full support. GD-PCG produces higher quality solutions on average than PCG with
comparable total execution time. Once again, both the quality of the solutions and the
total execution time of GD-PCG is more consistent across the seven test sets than PCG.

3.7.7 GD-PCG results on 190 GP instances

Table 3.19 reports the results obtained by GD-PCG on the 190 GP instances for future
reference. The test data is classified into sets by the number of box types as given by the
column #types, and the number of instances in each set is given by the column count. The
results with and without the full support constraint are reported under the headings GD-
PCG (Full Support) and GD-PCG, respectively. The columns cost provide the average
costs of the solutions over the test sets. The columns t(s) give the average time taken in
CPU seconds, and the column SN shows the value of the step number parameter SN that
controls the number of candidate prototypes generated.

3.8 Conclusion
This chapter studies the multiple container loading cost minimization problem, which has
the practical application of modeling the shipping of products in many large corporations.
MCLCMP can be naturally modeled as a set cover problem. We introduced a loading
factor to the set cover formulation and solved it with different loading factor values that
are determined using a binary search in our SCBS algorithm. In SCBS, we first generate
a variety of single container loading plans using three strategies, and then select from this
set of single container loading plans to form a solution to the multiple container loading

131
 GP Instances GD-PCG (Full Support) GD-PCG
#type count cost t(s) SN cost t(s)
2 64 17087.5 1585.0 30 16992.2 1549.4
3 29 14106.9 1508.3 30 14069.0 1388.9
4 38 12942.1 1440.2 20 12852.6 1373.0
5 15 10466.7 1254.4 20 10446.7 1059.1
6 21 13276.2 1613.3 10 13195.2 1504.2
7 9 11911.1 1438.7 10 11822.2 1332.9
8 9 16655.6 2140.3 10 16544.4 2062.4
9 4 13950.0 2063.9 10 13950.0 1665.5
10 1 10500.0 1575.2 5 10500.0 1442.7

Table 3.19: Computational results on GP instances (based on real data)

problem. The computational results show that such an approach produces reasonably
good solutions to MCLCMP and outperforms all existing approaches in literature.
The set cover formulation involves an exponential number of columns. A common
strategy to overcome this factor is to solve it using column generation, i.e., columns are
generated on demand by solving pricing problems. The pricing problem of MCLCMP is
similar to a single container loading problem, which is itself NP-hard. The key observation
is that solving the pricing problem is usually computationally intensive, and the result is
often not selected as part of the final solution. Hence, it is worthwhile to postpone this
computationally intensive task as much as possible until it has been proven necessary.
This observation leads to a new algorithm, which we call prototype column generation.
The key feature of prototype column generation is the use of quick approximations (called
prototypes) instead of actual columns, and we only attempt to realize the prototypes into
actual columns when they are selected as part of an optimal solution in some intermediate
step.
The main difficulty of this strategy stems from the fact that the selected prototypes
may not be realized exactly, resulting in an actual column that differs from its prototype
slightly. Such discrepancies must be resolved to obtain a feasible solution to the original
problem. In our proposed PCG scheme, our strategy to resolve this issue is to try to
iteratively close the gap between the solutions that use realized columns and the solutions
that use the prototypes.
The GD-PCG algorithm improves on PCG in three respects. Firstly, the PCG algo-
rithm carries out the search in two stages and each stage approaches good solutions to
MCLCMP in its own dimension, whereas GD-PCG searches in both dimensions at the
same time. Secondly, we introduced a parameter γ into the set cover formulation for
MCLCMP that roughly estimates the expected overall volume utilization of containers
in a solution. Thirdly, once a solution is found, a goal-driven search is carried out in the
solution’s neighborhood to improve the solution.

132
 The computational results on 350 MCLCMP instances show that PCG produces signif-
icantly better results than SCBS using comparable CPU time. GD-PCG further improves
the efficiency and effectiveness of PCG.
Many real world applications have natural set cover formulations, where the columns in
the constraint matrix of the formulation have a natural interpretation. It is also often the
case that the pricing problems for these applications are NP-hard. Our PCG and GD-PCG
approaches to solving MCLCMP may be usable in such applications after modification,
or inspire similar approaches within the confines of the problem domain.

133
Chapter 4

Algorithms for 2D/3D Bin Packing

Problems
The three-dimensional bin packing problem (3D-BPP) analyzed in this chapter is defined
as follows. We are given n items that are 3D rectangular boxes, and an unlimited number
of identical bins with dimensions L × W × H. The dimensions of the i-th item, 1 ≤ i ≤ n,
is denoted by li × wi × hi , and we assume that the boxes cannot be rotated. The aim of
the problem is to load all n items into a number of bins such that:

• Placement is orthogonal (i.e., axis-aligned)

• Every item must be completely inside a bin

• Any two items inside the same bin must be interior-disjoint

• The number of bins used is minimized

Bin packing problems of dimensions other than three can be defined similarly. For
example, for the 2D-BPP, both the items and the bins are represented by rectangles
instead of boxes. In this chapter, we assume that bins are placed in the first octant of
a Cartesian coordinate system with one corner at the origin. The length L of the bin is
parallel to the X-axis, the height H is parallel to the Y -axis and the width W is parallel
to the Z-axis.
2D/3D bin packing problem instances are usually strongly heterogeneous, i.e., usually
every box in the input differs in dimensions. One of the main challenges when attempting
to find loading plans with high volume utilization for strongly heterogeneous instances is
to avoid the fragmentation of free space into several unusable small parts after a few items
are packed. We propose a defragmentation technique based on comparability graphs to
combine fragmented space into a continuous usable space, which potentially allows the
packing of additional items (Section 4.1). We illustrate how space defragmentation can
be employed to enhance a constructive heuristic in Section 4.2. In conjunction with a
bin shuffling strategy for incremental improvement described in Section 4.3, our resultant

134
 1
1

3 3
2 2

(a) Usable space is fragmented, (b) Item 1 is pushed

item 3 cannot be packed upwards to make
room for item 3

Figure 4.1: Example of space defragmentation

algorithm outperforms all leading meta-heuristic approaches based on the commonly used
benchmark data by a significant margin. Section 4.4 discusses an alternative method of
implementing the space defragmentation concept based on visibility graphs and the issues
that arise. The test data used in our computational experiments are described in Section
4.5, and the results are given in Section 4.6; the results suggest both space defragmentation
and bin shuffling are effective in improving solution quality.

4.1 Space Defragmentation

A primary objective for bin packing problems (and packing problems in general) is to
identify dense packing patterns so that the utilization of space within each bin is high.
When this is achieved, the number of bins required is naturally reduced. The main
obstacle against achieving a dense packing of items is the fragmentation of usable space
as items are loaded into bins. For example, Figure 4.1(a) shows the situation inside a bin
after two items are loaded. The usable space in the bin is divided into two disconnected
parts, and even though the total area of the usable space in the bin is sufficient to load
item 3, neither part is large enough to accommodate the item. However, by pushing item
1 upwards, we can make enough room to load item 3 (Figure 4.1(b)).
This is the basis for our space defragmentation operations. In particular, when at-
tempting to place an item i at some position p (i.e., the corner of item i that is closest
to the origin is at point p) and there is not enough space to accommodate the item due
to the presence of existing items, we can attempt to push all items that overlap with i
away from the origin in order to make room for the new item; the pushed items may in
turn cause other items to be pushed away. The net effect of pushing the items is to unite
fragmented usable space into a continuous area, which might be large enough to hold the
new item.
There are two tasks to perform when implementing this concept. Firstly, we must
determine if there is sufficient space to accommodate item i after pushing the items away
from p; secondly, the item i must be loaded at p. A naive implementation would be to first

135
 7
5
6 8

3
1
2 4

Figure 4.2: A packing pattern and its X-comparability graph

push all boxes that are beyond p as far as possible along each axis, checking for overlapping
with all other items in the process; this takes O(n2 ) time, where n is the number of items
in the bin. Then, check that there is sufficient space at p to accommodate the item, and
load the item if this is the case. Assuming the number of possible positions for insertion
is O(n), then this would take O(n3 ) time per item. In this section, we present an O(n2 )
algorithm that utilizes the space defragmentation concept by efficiently determining the
distance that an item can be pushed along an axis, using the concept of a comparability
graph for an axis.
For any item i in a bin, its projection onto the X-axis is an interval that we denote
by [xi , xi ]. Therefore, the length of an item i is li = xi − xi . We can construct the X-
comparability graph GX = (VX , EX ) for the set of intervals corresponding to the items in
a bin as follows:

• Every item i corresponds to a vertex vi ∈ VX

• Each vertex vi is assigned a weight equal to li

• There is a directed edge (vi , vj ) ∈ EX from vertex vi to vj if and only if xi ≤ xj ,

i.e., item i lies entirely to the left of item j

GX is a directed acyclic graph; similar graphs can be constructed for the other axes
in the same manner. Figure 4.2 shows an example of a packing in a bin along with
the corresponding X-comparability graph. We define the length of a path as the sum of
the weights of all vertices in the path. A packing can also be represented by a packing
class as proposed by Fekete and Schepers [85], which are a set of interval graphs, one for
each axis, with certain constraints; our comparability graphs are transitively orientated
complements of these interval graphs.
Given a packing with X-comparability graph GX , we can right-justify all items along
the X-axis such that [xri , xri ] is the projection of item i on the X-axis after right-justification,
where

 min {xrj } : ∃(vi , vj ) ∈ EX
xri = (vi ,vj )∈EX (4.1)
 L : otherwise

136
Theorem 4.1 A feasible packing with X-comparability graph GX remains feasible after
all items are right-justified along the X-axis. Furthermore, the comparability graphs for
the other axes for the resultant packing is the same as for the original packing.

Proof: The second part of the theorem is readily apparent because after right-justification
along the X-axis, the Y - and Z-coordinates of all items are unchanged.
Let GrX be the X-comparability graph of the packing after all items are right-justified.
Consider an edge (vi , vj ) ∈ EX . After right justification, by the definition in Equation
(4.1), we know that xri ≤ xrj . It follows by the definition of the X-comparability graph
r
that (vi , vj ) ∈ EX . Hence, all edges in GX are also in GrX .
Observe that for any two items i and j, they are disjoint if and only if vi and vj are
adjacent in at least one of GX , GY or GZ . As the original packing is feasible, for all items
i and j, vi and vj are adjacent in at least one of the comparability graphs. Since all edges
in GX are also in GrX , this implies that they are also adjacent in at least one of GrX , GY
or GZ . Hence, all items i and j remain disjoint after right-justification on the X-axis.
It suffices to show that all items are fully within the bin after right-justification. Since
right-justification never translates any item to the left, xi ≤ xri , ∀i. Also, by Equation
(4.1), xri ≤ L. Hence, all items are fully within the bin.


For any given point x on the X-axis, we call the set of items whose right endpoint lies
to the right of x the right set at x, denoted by Rx = {i : xi > x}. The set of all other
items in the bin is called the left set at x, denoted by Lx = {i : xi ≤ x}. We define an
operator Push(GX , x), which right-justifies every item i ∈ Rx along the X-axis.

Corollary 4.2 A feasible packing with X-comparability graph GX remains feasible after
the Push(GX , x) operation for any x. Furthermore, the comparability graphs for the
other axes for the resultant packing is the same as for the original packing.

Proof: There are two possible cases of infeasibility: either (a) an item is not fully
within the container, or (b) an item overlaps with another item. Since the Push(GX , x)
operation translates items to its right-justified positions, case (a) is impossible by the
same reasoning as in Theorem 4.1.
For case (b), consider any two items i and j. Without loss of generality, let xi ≤ xj
before the operation. There are four possible effects of Push(GX , x) on i and j: either
i is moved, j is moved, neither were moved, or both were moved. Obviously, an overlap
cannot be introduced if neither i nor j were affected by the operation, nor if only j was
translated to the right. If both i and j were right-justified, then by Theorem 4.1 they are
disjoint. Finally, it cannot be the case that only i is moved since if i ∈ Rx then j ∈ Rx .
Therefore, the resultant packing after the Push(GX , x) operation must be feasible.

137
 

For three-dimensional packing problems, we define a composite operator

Push-out(b, (x, y, z)), which attempts to collate usable space in bin b around a reference
point (x, y, z) by performing Push(GX , x), Push(GY , y) and Push(GZ , z). The second
part of Corollary 4.2 guarantees that the three Push operations can be performed in any
order, and the resultant packing will be the same.
We now describe how xri can be computed in Θ(n log n) time for all items without
explicitly constructing the X-comparability graph GX , where n is the number of items
in the bin. This is done by computing the value of ∆Xi = xri − xi for each item i. The
computation is similar for the other dimensions.
First, sort the 2n endpoints of the n intervals corresponding to the projections of the
items on the X-axis; left endpoints take precedence in a tie. We explain the procedure by
imagining a vertical line sweeping from right to left along the X-axis. The vertical line
serves two purposes:
1) It defines the set of intervals that lie completely to the left of the vertical line, i.e.,
Lx = {i|xi ≤ x}, where x is the location of the vertical line;

2) It maintains a boundary x0 that marks the greatest value for the right endpoint of
any interval in Lx . Conceptually, we can simultaneously translate all intervals in
Lx to the right until the right endpoint of some interval in Lx coincides with the
boundary. If i is the interval with largest xi in Lx , then ∆Xi = x0 − xi
At the beginning, we set the boundary x0 = L. When the vertical line encounters a
right endpoint xi , we update ∆Xi = x0 − xi . When the vertical line encounters a left
endpoint xi , we update the boundary x0 = min{x0 , xi + ∆Xi }. This correctly updates
the invariant x0 because for any interval j ∈ Lx , j lies to the left of [xi , xi ]. By the
construction of the comparability graph, there is an edge from j to i; hence, i lies on
some path passing through j. If i in fact lies on the longest path P (j) involving vj , then
xi + ∆Xi is the effective right boundary for j. The pseudocode is provided in Algorithm
11.
Finally, we show that once the values of xri , y ri and z ri are computed for all items
i, then determining if Push-out(b, (x, y, z)) produces sufficient space to accomodate an
item can be done in O(n) time.
Let S(p) be the set of items that overlap with the current item i when i is placed at
a position p (i.e., p = (xi , y i , z i )). For every item j ∈ S(p), we right-justify it along the
respective axes. Let S 0 (p) denote the set of items after translation.

Theorem 4.3 The operation Push-out(b, p) will produce sufficient space to allow the
current item i to be placed at p if and only if no items in S 0 (p) overlap with item i when
item i is placed at p.

138
Algorithm 11 Compute xri for each item i in bin b

Compute-RJpos-X(b)
1 P = list of left and right endpoints xi and xi for all items i ∈ b
2 sort P by X-coordinate in descending order;
left endpoints take precedence in a tie
3 x0 = L
4 for each point x ∈ P
5 if x is a left endpoint xi for some i
6 x0 = min(x0 , ∆Xi + xi )
7 if x is a right endpoint xi for some i
8 ∆Xi = x0 − xi
9 for all items i
10 xri = xi + ∆Xi

Proof: (⇒) Push-out(b, p) translates all items in S(p) to their respective positions in
S 0 (p). If this produces sufficient space, then none of the items in S 0 (p) will overlap with
item i when it is placed at p.
(⇐) For every item j in the bin, j 6= i, we define an overlapping index f (j) where
f (j) = k indicates that the interior of the projection of item j intersects the interior of
the projection of item i on k different axes. Hence, item j overlaps with item i if and only
if f (j) = 3. By definition, ∀j ∈ S(p), f (j) = 3 and ∀j ∈/ S(p), f (j) < 3.
Recall that Rx is the set of items whose right endpoint lies to the right of x on the
X-axis. Since Push(Gx , x) translates only the items in Rx to the right, this operation will
not increase the overlapping index; this implies that all items j 6∈ S(p) remain interior-
disjoint with respect to item i. A similar argument applies to the other axes. Therefore,
if all items j ∈ S(p) also do not overlap with item i after the Push-out(b, p) operation
(i.e., no item in S 0 (p) overlaps with item i), then there is sufficient space to place item i
at p.


We can therefore determine if item i can be placed at p by checking the resultant

position of all items j that overlap with i after right-justification on all axes. Since the
number of overlapping items is O(n), and assuming there are O(n) possible positions, this
procedure takes O(n2 ) time per item. In fact, this worst case scenario seldom occurs in
practice, and our experiments show that this operation runs in close to linear time on
standard 3D-BPP test cases.
Note that the comparability graph computation of the maximum translation distance
is conservative, i.e., it may be possible for an item i to be translated along the X-axis
further than xri . In order to compute the actual maximum translation distance for all

139
items along an axis in a given packing, conceptually we can instead use a visibility graph,
which comes at a cost of added computation time. We provide a discussion of this visibility
graph representation in Section 4.4.

4.2 A Constructive Heuristic

The extreme point insertion heuristic [8] is a constructive heuristic that loads items one at
a time in a given sequence until all items are loaded, and is the best existing constructive
heuristic for the 3D-BPP. In this section, we first describe the basic extreme point inser-
tion algorithm, followed by two enhancements to the algorithm based on the Push-out
operation.
Note that the basic extreme point insertion algorithm is almost equivalent to the EP-
FFD algorithm by Crainic et. al. [8] with the Volume-Height sorting rule. The main
difference is the tie breaking rule. For EP-FFD, when an item can be placed at multiple
extreme points in a bin, the one with the lowest z-, y-, x- coordinates is chosen. In
our case, we simply pick the first extreme point in the list, and new extreme points are
appended to the end of the list.

4.2.1 The Extreme Point Insertion Heuristic

The extreme point insertion heuristic represents the state of a bin by a list of extreme
points, where every extreme point is a candidate position to load a new item (i.e., the item
is placed such that its corner closest to the origin is at the extreme point). An empty bin
is represented by one extreme point (0, 0, 0). When a new item is loaded, it occupies one
extreme point and introduces a constant number of new extreme points (e.g., 2 extreme
points in 2D and 6 extreme points in 3D).
Figure 4.3(a) illustrates how the loading of a new item will introduce two extreme
points in the 2D case. Given the corner A that is closest to the origin, we can extend
−−→
two rays from the adjacent corners B and C towards the origin; the ray BB1 extends
−−→
from corner B towards the X-axis, while the ray CC1 extends from the corner C towards
the Y -axis. The two new extreme points are located where the rays intersect either the
surface of another item or the bin. Extreme points can be similarly defined for the 3D
case (Figure 4.3(b)); for each of the three corners B, C and D that are adjacent to the
corner A that is closest to the origin, two rays are extended towards the origin for a total
of six extreme points.
Given a sequence of items, the extreme point insertion heuristic attempts to load the
current item at an extreme point in an existing bin. If no such point exists, a new empty
bin is instantiated and the item is loaded into that bin at (0, 0, 0). This continues until
all items are loaded. We employed the first fit strategy when selecting the extreme point

140
 C2
Y
C1 C

C1 C
B2

A B
A O
B
D1
D
B1 B1

D2
X
O

(a) 2 extreme points for 2D (b) 6 extreme points for 3D

Figure 4.3: Extreme points

for the current item: all non-empty bins are maintained in an ordered list, and for each
non-empty bin, its extreme points are also maintained in an ordered list. The current item
is loaded into the first bin that can accommodate the item at the first feasible extreme
point in that bin.
Our basic extreme point insertion heuristic is given in Algorithm 12. Given the list of
items to be loaded I as input, the algorithm computes the list B of bins required to load
all items. Initially, B = ∅. In each iteration, the first fit strategy is employed to locate
a suitable extreme point to load the current item. If the current item can be loaded at
some position p inside some bin b ∈ B (line 6), then the loading is performed and new
extreme points produced are appended to the end of b.EP -list. However, if no feasible
extreme point exists (line 12), then we introduce a new empty bin, append the new bin
to the end of B and load the current item into it.
Note that we first check in line 4 if the volume of empty space in the bin is sufficient to
accomodate the item before attempting to place the item. More sophisticated bounds can
be used for this purpose; for example, when there are many large items (i.e., items with
a dimension on some axis that exceeds half of the bin), then the lower bounds proposed
by Martello et. al. [7] and Boschetti and Mingozzi [99, 100] are more effective.

4.2.2 Two Enhancements to Extreme Point Insertion

We introduce two space defragmentation enhancements to the extreme point insertion
algorithm; the resultant algorithm is given in Algorithm 13. The first enhancement is
a straightforward application of the technique described in Section 4.1, i.e., rather than
checking if the current item i can be placed at p into the bin b given the current packing,
the algorithm checks if it can be placed at p after the Push-out(b, p) procedure (line
6). This involves calculating the values of xri , y ri and z ri for the items in the bin using
Algorithm 11, and then determining if the insertion at p is feasible in O(n) time. If the
insertion is feasible, then Push-out(b, p) is performed, the item is loaded, and then the
bin is normalized (i.e., all items are pushed towards the origin as far as possible).

141
Algorithm 12 Extreme Point Insertion using the First Fit Strategy

EP-Insert-Basic(I, B)
1 for each item i ∈ I
2 placed = FALSE
3 for each bin b ∈ B
4 if volume of item i is less than the space remaining in b
5 for each point p ∈ b.EP -list
6 if item i can be placed into bin b at point p
7 placed = TRUE
8 place item i at p
9 delete p from b.EP -list
10 append new extreme points to the end of b.EP -list
11 break and try to load the next item
12 if placed == FALSE
13 add an empty bin b0 to the end of B
14 place item i into b0 at (0, 0, 0)
15 append new extreme points to the end of b0 .EP -list

We describe the second enhancement with the conceptual example given in Figure 4.4,
where three items have previously been loaded into a bin; as a result, item 4 cannot be
loaded. However, suppose we inflate item 3 as much as possible (by pushing other items
away from the origin if neccessary), resulting in the inflated item 3’. If item 3’ is large
enough to encompass item 4, then we could replace item 3’ by item 4 (Figure 4.4(c)).
As long as the volume of item 3 is less than the volume of item 4, then performing
this inflate-and-replace operation will improve the packing in the bin in terms of space
utilization.
It can be readily seen that the maximum amount of inflation for an item j along an
axis is the same as the maximum distance that the item can be translated along that
axis. Hence, we can inflate an item j along the X-, Y - and Z-axes such that its right
endpoints become xrj , y rj and z rj , respectively. This procedure is given in Algorithm 14,
which implements the inflation of item j and its replacement with item i if it is feasible
and desirable.
We employ the second enhancement when all existing non-empty bins are unable to
accommodate the current item (line 14). At this point, we consider all loaded items j in
each existing bin b in turn, and attempt the
Inflate-and-Replace(b, i, j) procedure. A new empty bin is added only if this strategy
is unsuccessful (line 24).
The procedure Normalize moves all items as close to the origin as possible, resulting
in a normalized packing. We use a standard normalization procedure for this purpose,

142
Algorithm 13 Extreme Point Insertion with Space Defragmentation

EP-Insert-SD(I, B)
1 for each item i ∈ I
2 placed = FALSE
3 for each bin b ∈ B
4 if volume of item i is less than the space remaining in b
5 for each point p ∈ b.EP -list
6 if item i can be placed at point p after Push-out
7 placed = TRUE
8 Push-out(b, p)
9 place item i at p
10 Normalize(b)
11 update extreme points b.EP -list
12 update xri , y ri and z ri for all items k in b
13 break and try to load the next item
14 if placed == FALSE
15 for each bin b ∈ B
16 for each item j ∈ b
17 if Inflate-and-Replace(b, i, j) == TRUE
18 placed = TRUE
19 Normalize(b)
20 update extreme points b.EP -list
21 update xri , y ri and z ri for all items k in b
22 insert j to the front of I
23 break and try to load the next item
24 if placed == FALSE
25 add an empty bin b0 to the end of B
26 place item i into b0 at (0, 0, 0)
27 append new extreme points to the end of b0 .EP -list

Algorithm 14 Inflate-and-Replace Procedure

Inflate-and-Replace(b, i, j)
1 if the volume of item i is greater than the volume of item j
and (li ≤ xrj − xj ) and (wi ≤ z rj − z j ) and (hi ≤ y rj − y j )
2 remove j from b
3 Push-out(b, (xj , y j , z j ))
4 Place item i at (xj , y j , z j ) in bin b
5 return TRUE
6 return FALSE

which translates all items in the bin as far as possible towards the origin along the X-
axis, then the Y -axis, then the Z-axis, and repeats until none of the items can be further

143
 1
1

4
2 3’ 4
2
3

(a) A bin with 3 items, item 4 can- (b) Inflating item 3

not be loaded

4
2 3

(c) Replacing item 3 with item 4

Figure 4.4: Inflate-and-Replace Operator

translated along all three axes.

After the Normalize procedure is executed, the set of extreme points for the affected
bin must be updated. Our current implementation recomputes all the extreme points in
the bin, which takes O(n2 ) time where n is the number of items in the bin.

4.3 Bin Shuffling

We implemented a simple iterated local search strategy called bin shuffling that employs
our Ep-Insert-SD procedure as a subroutine. The bin shuffling strategy is motivated by
the example given in Figure 4.5(a), where six items 1 − 6 are to be loaded in order. The
solution produced by EP-Insert-SD requires 3 bins (Figure 4.5(b)). However, we could
reorder the bins (e.g., to the sequence Bin 3, Bin 2, Bin 1), and then attempt to move
items from later bins to earlier bins. If an item cannot be loaded into an earlier bin, it
remains in its original bin in the same position. In our example, items 1 and 2 from Bin
1 can be loaded into Bin 2, and items 3 and 4 from Bin 1 can similarly be loaded into
Bin 3. As a result, one fewer bin is required (Figure 4.5(c)). Note that applying this bin
shuffling strategy will never result in a solution that requires additional bins since new
bins are never introduced in the process.
Our preliminary experiments reveal that when the bin packing problem instance is
large in the sense that the solution requires many bins, then a single application of the
bin shuffling strategy can reduce the number of required bins by 5-10%. However, for
problems that require few bins, we found that although the above strategy often results
in a denser packing for the bins at the front of the list while reducing the number of
items in the bins at the back of the list, it is seldom the case that all the items in a bin

144
 1 2 3 4

5 6

(a) Items to be loaded

3 4
6
2
5
1

Bin 1 Bin 2 Bin 3

(b) Solution produced by EP-Insert-SD

2
4
1
6
3 5

Bin 3 Bin 2 Bin 1

(c) Shuffle bins and move items from later bins to earlier bins

Figure 4.5: Motivation for Bin Shuffling Strategy

145
will be removed. Therefore, we designed a goal-driven local search technique based on an
approximation of the bin shuffling strategy, which attempts in each iteration to load at
least one item from the bin with the lowest volume utilization into other bins.
The bin shuffling strategy is approximated as follows. As items are loaded when
constructing a solution (e.g., using the EP-Insert-SD procedure), their sequence of
insertion into each bin is recorded. For example, the recorded sequences for Figure 4.5(b)
would be (1, 2, 3, 4), (5), (6). We then permute the bins while preserving the insertion
sequences for each bin to obtain a new sequence of items, e.g., (6), (5), (1, 2, 3, 4); this
sequence can then be the input for a constructive heuristic to produce a new solution.
Although this implementation of bin shuffling does not guarantee an improved solution,
it can be conveniently integrated into our goal-driven technique.

Algorithm 15 Solution Improvement using Bin Shuffling

Bin-Shuffle-Improve(B)
1 b = the bin with lowest volume utilization in B
2 U = all items in bin b sorted by volume in descending order
3 remove b from B
4 K = 200, minLeftCount = |U |
5 while U is not empty
6 for k = 1 to K
7 I 0 = Shuffle(B)
8 insert the first (largest) item u from U at a random location in I 0
9 EP-Insert-SD(I 0 , B 0 )
10 if B 0 contains an equal number or fewer bins than B
11 B = B0
12 remove u from U
13 load as many items from U as possible into B using first-fit
extreme point insertion with space defragmentation
14 break
15 if k > K
16 randomly remove one item from some bin in B and insert it into U
17 if |U | < minLeftCount
18 minLeftCount = |U |
19 K = 200
20 else K = 50
21 return B

Given a current solution, we can use Algorithm 15 to search for an improved solution.
First, we identify the bin with the lowest volume utilization and unload all items from this
bin (line 2); this results in a list of non-empty bins B and a list of items U to be loaded.
We shuffle the bins in B to obtain a new sequence of items I 0 (line 7). Then, we insert the
largest item u ∈ U at a random position in I 0 and invoke the EP-Insert-SD procedure

146
on I 0 to obtain a solution B 0 . If B 0 has an equal number or fewer bins than B (line 10),
we have successfully loaded u into existing bins. This successful insertion suggests that
the current sequence I 0 produces a good solution using EP-Insert-SD, so we proceed to
attempt to insert all other items in U (in decreasing order of volume) into B 0 using the
same sequence (line 13). However, if B 0 has more bins than B, then we repeat the bin
shuffling operation up to K times; this is essentially a local search. After K consecutive
unsuccessful attempts, we randomly remove an item from B (line 16), insert it into U
and restart the procedure. This continues until U = ∅, indicating a solution that uses one
fewer bin.
In our implementation, we initially set K to 200. Whenever a new search state is
accepted, we update the value of K dynamically (line 17): if the number of items in U is
the lowest found so far, then we set K = 200; otherwise, we set K = 50.
Our overall approach is as follows. We first sort all items in descending order of volume,
breaking ties by descending order of height as suggested by Crainic et. al. [8], and then
invoke the EP-Insert-SD procedure to construct an initial solution. While the time limit
is not exceeded, we iteratively improve the solution using Algorithm 15. We refer to our
algorithm as Bin Shuffling using Extreme Point insertion with Space Defragmentation
(BS-EPSD). The BS-EPSD algorithm can be employed on d-dimensional bin packing
problems for d ≥ 2.

4.4 Space Defragmentation by Visibility Graphs

The use of comparability graphs to compute the distance that an item can be translated
along an axis has two advantages. Firstly, it allows the Push-out operation to be
performed in O(n2 ) time in the worst case and close to linear time in practice. Secondly,
since the comparability graphs for each axis are independent, the translations along each
axis can be done in any order. However, the comparability graph computation of the
maximum translation distance is conservative, i.e., it may be possible for an item i to be
translated along the X-axis further than xri . For example, given the packing in Figure
4.6(a), right-justification along the X-axis using the comparability graph representation
results in the packing in Figure 4.6(b). In particular, there is an edge (v2 , v6 ) in the
X-comparability graph, which prevents item 2 from being translated further.
In order to compute the actual maximum translation distance for all items along an
axis in a given packing, conceptually we can instead use a visibility graph. For the X-axis,
the X-visibility graph GX = (VX , Ex ) is constructed as follows:

• Every item i corresponds to a vertex vi ∈ VX

• Each vertex vi is assigned a weight equal to li

147
 (a) (b)

Figure 4.6: Conservativeness of comparability graph

• There is a directed edge (vi , vj ) ∈ EX from vertex vi to vj if and only if (1) there
exists a line segment parallel to the X-axis that intersects the interior of both items
i and j, and does not intersect the interior of any other item; and (2) xi < xj

Like comparability graphs, visibility graphs are directed acyclic graphs. Figure 4.7(a)
shows an example of a 2D packing in a bin and its X-visibility graph is shown in Figure
4.7(b). If an edge (vi , vj ) is in the edge set of the visibility graph GX , then items i and
j are said to be X-intervisible. The definition of the right-justification of a packing with
X-visibility graph GX is identical to that for comparability graphs in Equation (4.1).

7
5
6 8

3
1
2 4

(a) (b)

Figure 4.7: Visibility graph representation

For the 2D case, the X-visibility graph can be computed in O(n log n) time by trans-
forming it into a vertical line segment visibility problem: for each item i, instantiate two
vertical line segments Li and Ri corresponding to its left and right sides, respectively. We
can construct the bar visibility graph (BVG) for these 2n line segments in O(n log n) time
[101]. The BVG can be transformed into the X-visibility graph GX by considering each
edge and retaining only the edges of the form (Ri , Lj ). Since a BVG is a planar graph, it
has at most 3n − 5 edges, so this transformation can be done in O(n) time. Hence, the
total running time for this construction is O(n log n).
Unfortunately, the explicit construction of visibility graphs for the 3D case takes Ω(n2 )
time, as evidenced by Figure 4.8: with n/2 items of dimensions 1 × W × 1 and n/2 items
of dimensions 1 × 1 × H packed in the given configuration, there are n2 /4 edges in the

148
 Figure 4.8: Constructing 3D visibility graphs takes Ω(n2 ) time

corresponding X-visibility graph. This can be achieved by checking for the intervisibility
of each item with all other items in O(n2 ) time, which is asymptotically slower than
constructing comparability graphs in O(n log n) time. Note that this observation does
not exclude the possibility of an asymptotically faster algorithm that does not explicitly
construct the visibility graph.
Currently, the visibility graph implementation of space defragmentation is impractical
for the 3D case; our preliminary experiments show that using the comparability graph
implementation is distinctly superior for 3D-BPP. Also note that unlike for comparabil-
ity graphs, the visibility graph version of the Push operation along an axis may alter
the visibility graphs for the other axes, which must therefore be recomputed after each
execution of Push. Furthermore, the order of the axes chosen is not independent, e.g.,
translating along the X-axis followed by the Y -axis may result in a different packing from
translating along the Y -axis first.
Finally, recall that d-dimensional generalized left-justified packings can be represented
by d interval graphs (called packing classes) as shown by Fekete and Schepers [85]. Since
each interval graph has O(n2 ) edges, this implies a natural progression in the number
of possible packings as the dimensionality d of the problem increases. However, using
the visibility graph representation, we see that the visibility graphs representing each
axis of a 2D packing only have O(n) edges because they are planar, but there are O(n2 )
edges for cases with d ≥ 3. This observation suggests that 3D packing is intrinsically more
difficult than 2D packing, which was not apparent from the packing class representation. A
more thorough examination of the visibility graph representation of packings may provide
further insight into the complexities of packing problems.

4.5 Test Instances

4.5.1 Standard Bin Packing Instances
For 2D-BPP, we considered two sets of standard benchmark instances. The first set was
generated by Berkey and Wang [1] and consists of 6 classes, which we number 1-6. The

149
 B D

A C
O

Figure 4.9: 4 categories of item sizes

second set was generated by Martello and Vigo [2] and consists of 4 classes, which we
number 7-10. Each class of instances is further divided into 5 groups, where every group
consists of 10 instances with same number of items; the number of items per instance
in the five groups are 20, 40, 60, 80 and 100, respectively. All 500 instances and their
corresponding best known solution values are available at http://www.or.deis.unibo.
it/research_pages/ORinstances/ORinstances.htm.
For 3D-BPP, we used the 320 instances generated by Martello et. al. [3] for our ex-
periments. This set of instances consists of 8 classes, and each class is further divided
into 4 groups. Every group consists of 10 instances with the same number of items;
the number of items per instance in the 4 groups are 50, 100, 150 and 200, respec-
tively. This set of instances can be reproduced by the instance generator available at
http://www.diku.dk/~pisinger/codes.html.

4.5.2 New Bin Packing Instances

The existing standard 3D test instances (which we will refer to as the existing test sets
for the remainder of this discussion) examined in the previous section were proposed
in the 1980’s and 1990’s, and both computational power and logistical necessities have
moved on since then. From our discussions with the general manager of a leading third
party logistics company, we discovered that the existing test sets were inadequate for
the modeling of the activities of modern consolidation centres. In such companies, there
are two major activities that can be modeled using 3D-BPP. First, various boxes are
loaded onto pallets of a standard dimension, and there are typically between 10 and a few
dozen boxes per pallet. Second, sometimes goods of various sizes are placed directly into
shipping containers (of a standard size) without involving pallets. A typical order for the
company in question could require between 5 and 50 containers, which translates to as
many as 50,000 boxes.
There are two serious shortcomings to the existing test sets when modeling such ac-
tivities. Firstly, an inspection of the values in Tables 4.5 and 4.6, specifically columns n
and LB, show that the largest instances only contain 200 boxes, and the lower bounds
for the solutions reveal that the average number of boxes per container is between 4 and
10 in the optimal solution. The existing test instances are therefore too small to reflect
the magnitude of the task of faced by third party logistics companies.

150
 The second shortcoming is clarified by classifying items by size into 2d categories;
Figure 4.9 shows the 2D case. The container is divided into 4 equal regions A, B, C
and D, each with dimensions L/2 × W/2. Assuming an item i is placed with its bottom
left corner at point O, its top right corner will lie in one of the 4 regions. We categorize
each item by the location of its top right corner as an A-item, B-item, C-item or D-item,
respectively.
Observe that a container cannot contain two D-items. Hence, the number of D-
items in the problem instance represents a lower bound on the optimal solution for the
problem. Furthermore, note that two B-items cannot be placed in the same bin at the
same level along the Y -axis, and the same holds true for two C-items along the X-axis.
Therefore, if a problem has a large proportion of B-, C- or D- items, then the number of
possible solutions (and correspondingly the search space) is significantly reduced. With
this analysis, it is clear that the most challenging 3D-BPP instances in terms of the size
of the search space would involve a majority of A-items, a small proportion of B- and
C-items, and very few D-items. A similar argument can be made for the 3D case.
The generation criteria for the existing test sets are reported by Martello et. al. [7].
Only class 5 contains a large proportion (60%) of items that are smaller than half the
size of the bin in all three dimensions. For classes 1-4, 90% of the items have at least two
dimensions that are larger than half the bin size, while for classes 6-8, about 7/8 of the
items have at least one dimension greater than half the bin size. As a result, the difficulty
of these test cases are reduced, and therefore there is less margin for the evaluation of
algorithms when using these test cases as benchmarks. In fact, it is likely that most of the
examined algorithms were able to find the optimal solutions for many of the instances.
The existing test sets are useful in modeling the case where very large pieces of heavy
machinery that take up a large proportion of a container are loaded along with smaller
accessories, but they do not accurately reflect other common scenarios.
Consequently, we generated three new sets of test instances for 3D cases. The Type
1 instances duplicate each item in the existing test set 65 times, resulting in problem
instances with 65 times more items. The Type 2 instances also duplicate each item in the
existing test set 65 times, and the bin size is doubled on each dimension (resulting in a
bin that is 8 times larger); this ensures that all items are A-items.
The Type 3 instances are based on the requirements of the third party logistics com-
pany in question. They are divided into two classes, representing two common pallet-
loading scenarios, where the height of a pallet is either half of a standard 20-foot container
(allowing two pallets to be stacked), or it is the entire height. The unit of measurement is
centimeters for better granularity. Each class is further divided into 5 groups, each consist-
ing of 10 problem instances with 2000, 4000, 6000, 8000 and 10000 items, for a total of 100
instances. The dimensions of the items are based on actual data provided by the company.
We varied the sizes of each item within a range of ±10 cm for each dimension, resulting

151
in heterogeneous instances; this increases the difficulty of the problems, and models the
common scenario where third party logistics companies are required to pack and redis-
tribute several similar but slightly different products. In particular, these instances all
have a large majority of A-items. All three sets of new test instances and their solutions
produced by the BS-EPSD algorithm can be found at http://www.zhuwb.com/3d-bpp.

4.6 Computational Experiments

To evaluate the effectiveness of the BS-EPSD algorithm, we compared its performance
with those of the leading algorithms for the 2D and 3D bin packing problems. The
experiments were conducted on a PC with an Intel Core i7 920 CPU clocked at 2.66 GHz
with 12GB RAM running Windows 7 64-bit edition. The 64-bit Java Development Kit
1.7.0 from Oracle was used to implement the algorithm.

4.6.1 Effectiveness of Space Defragmentation

The initial solution of BS-EPSD is constructed by EP-Insert-SD. There are two differ-
ences between our EP-Insert-SD procedure and the EP-FFD heuristic by Crainic et.
al. [8]: (1) in EP-FFD, if an item can be placed at multiple extreme points, the one with
the lowest (z, y, x)-coordinate is chosen, whereas in EP-Insert-SD we simply choose the
first in the list (new extreme points are appended to the end of the list); (2) EP-Insert-
SD incorporates the two enhancements introduced in Section 4.2.2. Crainic et. al. [8] has
used the following sorting rules to sort items:

• Volume-Height: sort items by nonincreasing volume, then by nonincreasing height

• Height-Volume: sort items by nonincreasing height, then by nonincreasing volume

• Area-Height: sort items by nonincreasing base area, then by nonincreasing height

• Height-Area: sort items by nonincreasing height, then by nonincreasing base area

• No-Sort: items are placed in the order they appear in the input without sorting

Their experiments on 3D bin packing instances (classes 1,4-8) reveal that sorting items by
Area-Height is most effective for EP-FFD, followed by Height-Area. To further increase
the effectiveness of their approach, they created two “clustered” versions of sorting rules:

• Clustered Area-Height: items with similar base area are grouped into clusters. Sort
clusters by nonincreasing base area. Items within a cluster are sorted by the Area-
Height rule

• Clustered Height-Area: similar to Clustered Area-Height with the roles of base area
and height interchanged

152
 When clustered sorting rules are employed, the number of clusters from the range
1, ..., 100 are tried. We conducted similar experiments on 3D bin packing instances and
found that among the four non-clustered sorting rules, Volume-Height works best for our
EP-Insert-SD algorithm followed by Height-Volume. We created two similar clustered
sorting rules:

• Clustered Volume-Height: similar to Clustered Area-Height with volume playing

the role of base area

• Clustered Height-Volume: similar to Clustered Volume-Height with the roles of

volume and height interchanged

Table 4.1 compares EP-Insert-SD with EP-FFD under various sorting rules. We
also implemented a version of EP-Insert-SD that sorts the extreme points in exactly
the same order as EP-FFD and reported the results in column sort EP. Comparing the
columns EP-Insert-SD and sort EP, we see that sorting the extreme points does not
affect the overall solution quality. Column Impr reports the percentage improvement of
EP-Insert-SD over EP-FFD. The results show that for all five non-clustered sorting
rules, EP-Insert-SD outperforms EP-FFD, which suggests that the two enhancements
based on space defragmentation techniques are useful. It is also worth noting that the two
enhancements altered the behavior of FFD: for the original EP-FFD, Area-Height is most
effective, whereas for EP-Insert-SD Volume-Height is most effective. The clustering
technique [8] is also useful for EP-Insert-SD, as we can see that the Clustered Volume-
Height rule produces much better results than the Volume-Height rule. Of course, this
increase in effectiveness is obtained at the expense of increased computation time. Also
note that there is still a big gap between EP-Insert-SD using Clustered Volume-Height
and our BS-EPSD algorithm, with a total of 7376 bins compared to 7269 bins for the
240 3D-BPP instances in classes 1,4-8, which suggests that the bin shuffling technique we
employed is more effective.

Sorting Rule EP-FFD EP-Insert-SD sort EP Impr

No Sort 806.1 794.4 794.4 1.47%
Height-Volume 785.3 777.8 777.8 0.96%
Volume-Height 807.5 745.2 745.2 8.36%
Area-Height 766.9 762.6 762.6 0.56%
Height-Area 778.9 775.8 775.8 0.40%
Clustered Area-Height 748.1 745.4 745.4 0.36%
Clustered Height-Area 746.5 747.1 747.1 -0.08%
Clustered Volume-Height - 737.6 737.6
Clustered Height-Volume - 742.4 742.4

Table 4.1: EP-Insert-SD vs EP-FFD using various sorting rules

153
4.6.2 Component Analysis
We believe the two enhancements Push-Out and Inflate-and-Replace as well as the
bin shuffling strategy are most important to the success of BS-EPSD. We disabled some
components and report their effect in Table 4.2. The column BS-EPSD is the base algo-
rithm that includes all three components. The column no push disables Push-Out, the
column no replace disables Inflate-and-Replace, and the column bin-shuffle only dis-
ables both Push-Out and Inflate-and-Replace. Finally, the column Init reports the
initial solution by BS-EPSD, which is equivalent to disabling the bin shuffling strategy.
We can see that the solution quality decreases when either Push-Out or Inflate-and-
Replace is disabled, and when both are disabled the solution quality deteriorates further.
This confirms that both Push-Out and Inflate-and-Replace are useful. The big gap
between Init and BS-EPSD shows that bin shuffling is very important; however, the big
gap between bin-shuffle only and BS-EPSD also suggests that using bin shuffling alone
is not sufficient to beat the best existing approaches.

Test Set BS-EPSD no push no replace bin-shuffle only Init

2D class 1-10 (10s) 7236 7245 7245 7255 7367
3D class 1-8 (30s) 9795 9811 9820 9833 10068
3D class 1,4-7 (30s) 7269 7284 7285 7297 7452

Table 4.2: Effect of components of BS-EPSD

4.6.3 Convergence Over Time

To see how quickly BS-EPSD converges, for each 2D and 3D instance we executed BS-
EPSD for 300s and recorded the best solution found after 16ms, 31ms, 62ms, ..., 128s,
256s. Figure 4.10 shows the improvement to solution quality over time in a logarithmic
scale. Line 2D C1-6 represents the overall results for the first six classes of 2D instances,
computed as follows. At each specific time, we compute the total number of bins for all
instances and divided it by the total number of bins in the initial solutions to obtain a
percentage. We can see that for the 2D instances, the curve becomes flat after about 1s.
For the 3D instances, the curve is noticeably flatter after 64s. Since the CPU times are in
a logarithmic scale, the solution quality is unlikely to significantly improve by increasing
CPU time once the curve becomes flat.

4.6.4 Comparison with Existing Algorithms on Standard In-

stances
We compared our algorithm to the leading meta-heuristic algorithms in existing literature:

HG: the hybrid GRASP/VND algorithm by Parreño et. al. [77]

154
 100.00%

99.50%

99.00%

98.50%
2D C1-6
98.00% 2D C7-10
3D C1,4-8
97.50%

97.00%

CPU time (seconds)

Figure 4.10: Improvement of solution quality over time

SCH: the Set Cover based Heuristic algorithm by Monaci and Toth [60]

GLS: the Guided Local Search algorithm by Faroe et. al. [74]

TS3: the Tabu Search algorithm by Lodi et. al. [37] for 2D bin packing; and by
Lodi et. al. [102] for 3D bin packing

HBP: the HBP heuristic developed by Boschetti and Mingozzi [100]

TS2 Pack: the two-level tabu search algorithm by Crainic et. al. [75]

GASP: the Greedy Adaptive Search Procedure by Perboli et. al. [76]

The computational environments of these existing algorithms are summarized in Table

4.3. The last two columns give the time limits allocated to each algorithm for the 2D and
3D bin packing problems, respectively.

Algorithm CPU Language 2D 3D

GLS Digital 500 au workstation C 100s 1000s
500 MHz 21164 CPU
SCH Digital Alpha 533 MHz FORTRAN 77 100s -
TS3 (2D) Silicon Graphics INDY FORTRAN 77 100s -
R4000sc 100MHz
TS3 (3D) Digital Alpha 533 MHz FORTRAN 77 - 1000s
HG Pentium Mobile 1500 MHz C++ 15s 150s
TS2 Pack Pentium4 2000 MHz C++ - 300s
HBP Pentium III Intel 933 MHz FORTRAN 77 - -
GASP Pentium4 3GHz C++ 3s 5s
BS-EPSD Intel Core i7 920 2.66 GHz Java 1.7.0 10s 30s
BS-EPSD (fast) Intel Core i7 920 2.66 GHz Java 1.7.0 0.6s 1s

Table 4.3: Computational environments of various bin packing algorithms

155
 For each algorithm, we first compute the average number of bins required for each
group of 10 instances. We then sum the group averages for each class and report it as
an entry in the corresponding row. Table 4.4 reports the computational results at class
level. A dash (‘-’) indicates that the results for that class of instances were not reported
by the publication that proposed the corresponding algorithm.
The column bin# is the best solution found by our BS-EPSD algorithm, where the
time limit is set to 10 seconds of CPU time for each 2D instance, and 30 seconds of CPU
time for each 3D instance. We recorded the time when the best solution is first found,
and the average over all instances in a class is reported in column tb (s). For the 500 2D
instances, the best solutions of 430 instances were found within 10 milliseconds, and only
8 instances required 1 - 10s. Hence, the average time to best reported in tb (s) is much less
than 1 second even though the time limit is 10 CPU seconds. For the 320 3D instances,
the best solutions of 218 instances were found within 1 second, and only 26 instances
required 10 - 30s.

Existing Approaches BS-EPSD

Class HG SCH GLS TS3 HBP TS2 Pack GASP fast bin# tb (s)
1 99.7 99.7 100.2 101.5 99.9 - 100.1 99.7 99.7 0.01
2 12.4 12.4 12.4 13.0 12.4 - 12.9 12.4 12.4 0.02
3 69.6 69.6 70.2 72.6 70.3 - 70.6 69.6 69.5 0.07
4 12.3 12.4 12.5 12.8 12.5 - 13.0 12.4 12.3 0.18
2D 5 89.3 89.3 90.2 91.3 89.9 - 90.1 89.4 89.2 0.22
6 11.2 11.2 11.4 11.5 11.3 - 11.8 11.2 11.1 0.02
7 82.8 82.7 83.4 84.0 83.2 - 83.1 82.8 82.7 0.08
8 83.4 83.6 84.1 84.4 83.9 - 83.6 83.5 83.4 0.02
9 213.0 213.0 213.0 213.1 213.0 - 213.0 213.0 213.0 0.00
10 50.4 50.4 51.0 51.8 51.1 - 51.4 50.8 50.3 0.13
All classes 724.1 724.3 728.4 736.0 727.5 - 729.6 724.8 723.6

1 127.3 - 128.3 127.9 - 128.2 128.9 128.9 127.4 1.59

2 125.8 - - 126.8 - - - 127.4 125.7 3.52
3 126.9 - - 127.5 - - - 127.8 126.9 2.06
3D 4 294.0 - 294.2 294.0 - 293.9 294 294.0 294.0 0.00
5 70.5 - 70.8 71.4 - 71.0 71.8 71.9 70.3 4.82
6 95.4 - 96.0 96.1 - 95.8 96.5 96.5 95.5 1.69
7 59.4 - 59.0 60.0 - 59.0 61 60.1 58.4 3.14
8 82.0 - 81.9 82.6 - 81.9 84.2 83.2 81.3 3.77
All classes 981.3 - - 986.3 - - - 989.8 979.5
Class 1, 4-8 728.6 - 730.2 732.0 - 729.8 736.4 734.6 726.9

Table 4.4: Comparison at class level with existing approaches on 2D and 3D instances

Over all 500 2D instances, BS-EPSD outperforms the best existing algorithm HG by
5 bins. Over all 320 3D instances, BS-EPSD outperforms the best existing algorithm HG
by 18 bins; when classes 2 and 3 are excluded, BS-EPSD outperforms HG by 17 bins.

156
 Tables 4.5 and 4.6 show the detailed results on the 2D instances. Each row repre-
sents a group of 10 instances with the same number of items, and the reported result
is the average number of bins required in the final solution over the 10 instances in the
group. For each group of instances, column n provides the number of items per instance.
Column LB is the lower bound taken from http://www.or.deis.unibo.it/research_
pages/ORinstances/ORinstances.htm. Columns 5 to 9 correspond to the leading meta-
heuristic algorithms in existing literature. Since the TS2 Pack algorithm did not report
results for 2D-BPP instances, it is excluded from comparison. The column Init gives
the statistics of the initial solutions constructed by EP-Insert-SD, where the items are
sorted in descending order of volume, while the column bin# corresponds to the final
results produced by our algorithm. The time limit is set to 10 seconds of CPU time for
each 2D instance.
Values in bold signify that the technique achieved the best solution out of all the
examined techniques; the BS-EPSD algorithm achieved equal or superior solutions com-
pared to the leading meta-heuristic approaches for all but one group of instances. Column
tb (s) gives the average time taken by BS-EPSD to find the best solution for that group
of instances in seconds. Although we allocated a time limit of 10 seconds for each 2D
instance, the best solution for most instances was found very quickly, which suggests a
rapid convergence rate for the algorithm. Column opt.# counts the number of optimal
solutions found by BS-EPSD for each class.
Table 4.7 gives the results on the 3D instances; the meanings of the column headings
are similar to Table 4.5. The column LB is the lower bound found by the code implemented
by Martello et. al. [3] using the lower bound L2 described by Martello et. al. [7]. The
source code can be downloaded from http://www.diku.dk/~pisinger/codes.html. The
columns opt.# count the number of optimal solutions found for each class. The HBP
algorithm did not report results for 3D-BPP and is excluded from comparison. Column
tb (s) reports the average time taken by BS-EPSD to find the best solution for that group of
instances in seconds; once again, the values show that the best solution for most instances
was found well within the 30-second imposed time limit, which suggests that the algorithm
also converges rapidly for 3D instances. Furthermore, the BS-EPSD algorithm found
equivalent or superior solutions compared to the leading meta-heuristic approaches for all
but 7 out of the 32 groups of instances.
Since the GASP algorithm [76] is also able to produce high-quality solutions in a short
amount of CPU time, we created a fast version of BS-EPSD for a fairer comparison. The
GASP algorithm was executed on a Pentium-4 3GHz CPU with time limit set to 3s and
5s per instance for 2D and 3D, respectively. The results are summarized in column GASP
in Table 4.4. For the fast version of BS-EPSD, we set the time limit to 0.6s and 1s per
instance for 2D and 3D, respectively. Our time limit is 1/5 of GASP, even though our
CPU is not 5 times faster; this is to ensure that the improvement in solution quality is not

157
 Existing Approaches BS-EPSD (10s)
c Bin Size n LB HG SCH GLS TS3 HBP Init bin# tb (s) opt.#
1 10*10 20 7.1 7.1 7.1 7.1 7.1 7.1 7.1 7.1 0.001 10
10*10 40 13.4 13.4 13.4 13.4 13.5 13.4 13.7 13.4 0.002 10
10*10 60 19.7 20.0 20.0 20.1 20.1 20.1 20.2 20.0 0.030 7
10*10 80 27.4 27.5 27.5 27.5 28.2 27.5 27.6 27.5 0.000 9
10*10 100 31.7 31.7 31.7 32.1 32.6 31.8 32.2 31.7 0.018 10

2 30*30 20 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 0.000 10
30*30 40 1.9 1.9 1.9 1.9 2.0 1.9 2.0 1.9 0.020 10
30*30 60 2.5 2.5 2.5 2.5 2.7 2.5 2.7 2.5 0.004 10
30*30 80 3.1 3.1 3.1 3.1 3.3 3.1 3.3 3.1 0.038 10
30*30 100 3.9 3.9 3.9 3.9 4.0 3.9 4.0 3.9 0.045 10

3 40*40 20 5.1 5.1 5.1 5.1 5.5 5.1 5.3 5.1 0.006 10
40*40 40 9.2 9.4 9.4 9.4 9.7 9.5 9.9 9.3 0.108 9
40*40 60 13.6 13.9 13.9 14.0 14.0 14.0 14.3 13.9 0.037 7
40*40 80 18.7 18.9 18.9 19.1 19.8 19.1 19.6 18.9 0.059 8
40*40 100 22.1 22.3 22.3 22.6 23.6 22.6 23.2 22.3 0.124 8

4 100*100 20 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 0.000 10
100*100 40 1.9 1.9 1.9 1.9 1.9 1.9 1.9 1.9 0.001 10
100*100 60 2.3 2.5 2.5 2.5 2.6 2.5 2.5 2.5 0.002 8
100*100 80 3.0 3.1 3.2 3.3 3.3 3.3 3.2 3.2 0.003 8
100*100 100 3.7 3.8 3.8 3.8 4.0 3.8 3.9 3.7 0.909 10

5 100*100 20 6.5 6.5 6.5 6.5 6.6 6.5 6.6 6.5 0.012 10
100*100 40 11.9 11.9 11.9 11.9 11.9 11.9 12.2 11.9 0.002 10
100*100 60 17.9 18.0 18.0 18.1 18.2 18.0 18.5 18.0 0.024 9
100*100 80 24.1 24.7 24.7 24.9 25.1 24.8 25.1 24.7 0.001 4
100*100 100 27.9 28.2 28.2 28.8 29.5 28.7 28.9 28.1 1.054 8

6 300*300 20 1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0 0.000 10
300*300 40 1.5 1.7 1.7 1.8 1.9 1.8 1.9 1.6 0.099 9
300*300 60 2.1 2.1 2.1 2.2 2.2 2.1 2.2 2.1 0.003 10
300*300 80 3.0 3.0 3.0 3.0 3.0 3.0 3.0 3.0 0.003 10
300*300 100 3.2 3.4 3.4 3.4 3.4 3.4 3.4 3.4 0.004 8

Table 4.5: Comparison at group level on the 6 classes of 2D instances by [1]

158
 Existing Approaches BS-EPSD (10s)
c Bin Size n LB HG SCH GLS TS3 HBP Init bin# tb (s) opt.#
7 100*100 20 5.5 5.5 5.5 5.5 5.5 5.5 6.0 5.5 0.000 10
100*100 40 10.9 11.1 11.1 11.3 11.4 11.1 11.6 11.1 0.020 8
100*100 60 15.6 15.9 15.8 15.9 16.2 16.0 16.3 15.8 0.324 8
100*100 80 22.4 23.2 23.2 23.2 23.2 23.2 23.4 23.2 0.001 2
100*100 100 26.9 27.1 27.1 27.5 27.7 27.4 27.7 27.1 0.043 8

8 100*100 20 5.8 5.8 5.8 5.8 5.8 5.8 6.0 5.8 0.002 10
100*100 40 11.2 11.3 11.3 11.4 11.4 11.3 11.7 11.3 0.010 9
100*100 60 15.9 16.1 16.2 16.3 16.2 16.2 16.6 16.1 0.069 8
100*100 80 22.3 22.4 22.4 22.5 22.6 22.6 22.7 22.4 0.005 9
100*100 100 27.4 27.8 27.9 28.1 28.4 28.0 28.1 27.8 0.028 6

9 100*100 20 14.3 14.3 14.3 14.3 14.3 14.3 14.4 14.3 0.000 10
100*100 40 27.8 27.8 27.8 27.8 27.8 27.8 28.0 27.8 0.000 10
100*100 60 43.7 43.7 43.7 43.7 43.8 43.7 43.9 43.7 0.000 10
100*100 80 57.7 57.7 57.7 57.7 57.7 57.7 57.8 57.7 0.000 10
100*100 100 69.5 69.5 69.5 69.5 69.5 69.5 69.6 69.5 0.000 10

10 100*100 20 4.2 4.2 4.2 4.2 4.3 4.3 4.3 4.2 0.002 10
100*100 40 7.4 7.4 7.4 7.4 7.5 7.4 7.4 7.4 0.000 10
100*100 60 9.8 10.0 10.1 10.2 10.4 10.2 10.4 10.0 0.239 8
100*100 80 12.3 12.9 12.8 13.0 13.0 13.0 13.1 12.8 0.241 5
100*100 100 15.3 15.9 15.9 16.2 16.6 16.2 16.3 15.9 0.148 4

Table 4.6: Comparison at group level on the 4 classes of 2D instances by [2]

159
 Existing Approaches BS-EPSD (30s)
c n LB HG GLS TS3 TS2 Pack GASP Init bin# tb (s) opt.#
1 50 12.5 13.4 13.4 13.4 13.4 13.4 14.3 13.4 0.05 3
100 25.1 26.6 26.7 26.6 26.7 26.9 27.7 26.6 0.49 1
150 34.7 36.4 37.0 36.7 37.0 37.0 37.9 36.5 2.78 0
200 48.4 50.9 51.2 51.2 51.1 51.6 52.3 50.9 3.04 0
2 50 12.7 13.8 - 13.8 - - 14.8 13.8 0.10 1
100 24.1 25.7 - 25.7 - - 26.4 25.6 3.12 0
150 35.1 36.9 - 37.2 - - 38.1 36.8 4.02 2
200 47.5 49.4 - 50.1 - - 51.0 49.5 6.82 0
3 50 12.3 13.3 - 13.3 - - 13.9 13.3 0.15 3
100 24.7 26.0 - 26.0 - - 27.1 25.9 2.27 2
150 36.0 37.6 - 37.7 - - 39.1 37.6 3.53 1
200 47.8 50.0 - 50.5 - - 51.2 50.1 2.28 0
4 50 28.9 29.4 29.4 29.4 29.4 29.4 29.7 29.4 0.00 6
100 57.6 59.0 59.0 59.0 58.9 59.0 59.2 59.0 0.00 1
150 85.2 86.8 86.8 86.8 86.8 86.8 87.6 86.8 0.00 1
200 116.3 118.8 119.0 118.8 118.8 118.8 119.5 118.8 0.00 1
5 50 7.4 8.3 8.3 8.4 8.3 8.4 8.5 8.3 0.04 3
100 12.9 15.0 15.1 15.0 15.2 15.1 15.4 14.9 2.49 0
150 17.4 20.1 20.2 20.4 20.1 20.6 21.0 19.9 11.31 0
200 24.4 27.1 27.2 27.6 27.4 27.7 28.1 27.2 5.45 0
6 50 9.1 9.8 9.8 9.9 9.8 9.9 10.3 9.8 0.14 4
100 17.5 19.0 19.1 19.1 19.1 19.1 19.5 19.0 0.56 0
150 26.9 29.2 29.4 29.4 29.2 29.5 30.1 29.2 3.66 0
200 35.0 37.4 37.7 37.7 37.7 38.0 38.2 37.5 2.41 0
7 50 6.4 7.4 7.4 7.5 7.4 7.5 7.6 7.4 0.00 1
100 10.9 12.5 12.3 12.5 12.3 12.7 12.9 12.2 1.09 1
150 13.7 16.0 15.8 16.1 15.8 16.6 16.3 15.4 6.59 0
200 21.0 23.5 23.5 23.9 23.5 24.2 24.2 23.4 4.89 0
8 50 8.3 9.2 9.2 9.3 9.2 9.3 9.7 9.2 0.05 3
100 17.6 18.9 18.9 18.9 18.8 19.0 19.6 18.9 0.32 2
150 21.3 24.1 23.9 24.1 23.9 24.8 25.0 23.7 5.00 1
200 26.7 29.8 29.9 30.3 30.0 31.1 30.6 29.5 9.69 0

Table 4.7: Comparsion at group level on 8 classes of 3D instances by [3]

160
due to increased CPU power. The results of the fast version of BS-EPSD are summarized
in column fast in Table 4.4. Overall our fast version outperforms GASP by 48 bins on 2D
instances and 18 bins on 3D instances. At class level, our fast version outperforms GASP
for 9 out of 10 classes of 2D instances and found equal solutions for the remaining class.
For the 3D instances, our fast version outperforms GASP for classes 7 and 8, matches
GASP for classes 1, 4, 6 and is poorer than GASP by one bin for class 7.
Parreño et. al. [77] have kindly supplied us with a Windows binary executable of their
hybrid GRASP/VND algorithm. This allows us to compare our BS-EPSD algorithm on
the same computational environment as hybrid GRASP/VND. To show that our BS-
EPSD is indeed more effective than hybrid GRASP/VND, we gave more CPU time for
hybrid GRASP/VND.
We executed their algorithm on the same environment as BS-EPSD with time limits
of 15s per instance for 2D and 150s per instance for 3D. The 2D and 3D results are
summarized at class level in Table 4.8 and Table 4.9 under the headings HG (15s) and
HG (150s), respectively. Since hybrid GRASP/VND may stop before the time limit due
to the iteration limit, we recorded the total execution time for each instance and report
the average under column avg tt(s). For comparison, the corresponding results of our
BS-EPSD are summarized under headings BS-EPSD (10s) and BS-EPSD (30s). For
BS-EPSD, we recorded the time when the best solution is found for each instance, and
the average for a class is reported under the column tb (s). The column LB is the lower
bound: for 2D the lower bound is taken from http://www.or.deis.unibo.it/research_
pages/ORinstances/ORinstances.htm and for 3D the lower bound is found by the code
implemented by Martello et. al. [3] using the lower bound L2 described by Martello et. al.
[7]. The source code can be downloaded from http://www.diku.dk/~pisinger/codes.
html. The columns opt.# count the number of optimal solutions found for each class.
For the 2D instances, the results found by hybrid GRASP/VND on our machine
are exactly the same as those reported by the original authors despite the increase in
computational power. For the 3D instances, the results found by hybrid GRASP/VND
on our environment are slightly better than those originally reported. Overall, our BS-
EPSD algorithm outperforms hybrid GRASP/VND on both the 2D and 3D instances
even though a stricter time limit is imposed. BS-EPSD finds better or equal solutions for
all 10 classes of 2D instances and 6 classes of 3D instances. For classes 1 and 6 of 3D,
BS-EPSD uses 1 more bin than hybrid GRASP/VND (highlighted in bold in Table 4.9).
It is also worth noting that our BS-EPSD found 5 more optimal solutions than hybrid
GRASP/VND for the 2D instances and 2 more optimal solutions for the 3D instances.
Since hybrid GRASP/VNS finds 432 optimal solutions out of 500 2D instances, it is
reasonable to conclude that the solutions it finds for the rest of the instances are near-
optimal. This may explain why our BS-EPSD finds only slightly better solutions than
hybrid/GRASP for the 2D instances.

161
 HG (15s) BS-EPSD (10s)
Class LB bin# avg tt(s) opt.# bin# tb (s) opt.#
1 99.3 99.7 13.46 46 99.7 0.01 46
2 12.4 12.4 11.21 50 12.4 0.02 50
3 68.7 69.6 13.26 41 69.5 0.07 42
4 11.9 12.3 11.45 46 12.3 0.18 46
5 88.3 89.3 13.45 40 89.2 0.22 41
6 10.8 11.2 10.99 46 11.1 0.02 47
7 81.3 82.7 13.01 36 82.7 0.08 36
8 82.6 83.5 13.40 41 83.4 0.02 42
9 213 213.0 12.80 50 213.0 0.00 50
10 49 50.4 12.77 36 50.3 0.13 37
All 717.3 724.1 432 723.6 437

Table 4.8: Comparison at class level with hybrid GRASP/VND on 2D instances

HG (150s) BS-EPSD (30s)

Class LB bin# avg tt(s) opt.# bin# tb (s) opt.#
1 120.7 127.3 52.13913 4 127.4 1.59 4
2 119.4 125.8 62.69378 2 125.7 3.52 3
3 120.8 126.9 66.59598 5 126.9 2.06 6
4 288 294.0 126.4917 9 294.0 0.00 9
5 62.1 70.5 101.5246 3 70.3 4.82 3
6 88.5 95.4 86.19638 4 95.5 1.69 4
7 52 59.0 117.6057 2 58.4 3.14 2
8 73.9 81.8 95.9149 6 81.3 3.77 6
All 980.7 35 979.5 37
1,4-8 728.0 28 726.9 28

Table 4.9: Comparison at class level with hybrid GRASP/VND on 3D instances

162
4.6.5 Comparison with Hybrid GRASP/VND on New Instances
We compared our BS-EPSD algorithm with the hybrid GRASP/VND algorithm by Parreño
et. al. [77] on our newly generated bin packing instances. The Windows binary exe-
cutable provided by the authors was executed in the same computational environment as
BS-EPSD. The time limit imposed for the hybrid GRASP/VND algorithm is 300s per
instance, whereas BS-EPSD is given 60s (except for instances no. 2 and 3 in class 5 of
Type 2, where the initial solution took 69s and 77s to produce, respectively).
The results for the Type 1 and Type 2 instances are summarized in Table 4.10. Column
t0 (s) reports the average time taken by BS-EPSD to find the initial soluiton. Column tb (s)
reports the average time taken by BS-EPSD to find the best solution. Column Impr gives
the percentage improvement of the BS-EPSD algorithm over the hybrid GRASP/VND in
terms of the number of bins required; the values show that BS-EPSD outperforms hybrid
GRASP/VND for all but one class of instances (Type 2, class 6), by about 1.40% for
Type 1 data and about 2.17% for Type 2 data overall. There is a wider relative gap in the
performances of the two techniques for the new instances compared with the existing test
sets. In particular, the only difference between the Type 1 instances and the existing test
sets is the number of items; the item composition is otherwise identical. This suggests
that BS-EPSD scales better than the hybrid GRASP/VND algorithm.

HG (300s) BS-EPSD (60s)

Type Class bin# avg. tt(s) init t0 (s) bin# tb (s) impr
1 8304.7 305.5 8288.9 3.5 8187.6 42.9 1.41%
2 8186.6 300.8 8186.5 3.8 8074.8 38.9 1.37%
3 8244.2 301.0 8252.8 3.8 8146.3 41.8 1.19%
Type 1 4 19072.0 322.3 19110.9 2.4 18942.1 16.1 0.68%
5 4575.4 300.9 4559.5 2.8 4455.5 36.1 2.62%
6 6136.3 307.7 6110.6 2.6 6057.4 25.7 1.29%
7 3786.0 301.1 3749.0 3.1 3686.8 27.7 2.62%
8 5320.8 302.5 5288.8 2.7 5185.4 31.4 2.54%
All classes 63626.0 63547.0 62735.9 1.40%

1 962.6 301.1 981.6 13.5 942.1 28.9 2.13%

2 954.1 301.0 972.9 15.0 928.6 28.5 2.67%
3 958.6 301.3 983.9 14.8 935.6 28.9 2.40%
Type 2 4 1564.4 301.0 1623.3 9.8 1516.3 32.8 3.07%
5 507.3 301.3 497.5 20.1 492.5 30.6 2.92%
6 705.0 300.8 727.5 15.9 719.2 31.1 -2.01%
7 412.2 300.8 399.6 23.7 399.2 25.3 3.15%
8 590.4 301.5 578.9 14.7 576.6 19.8 2.34%
All classes 6654.6 6765.2 6510.1 2.17%

Table 4.10: Summarized results for Type 1 and Type 2 instances

163
 Table 4.11 gives the summarized results for the Type 3 instances. The results show
that BS-EPSD outperforms hybrid GRASP/VND for all categories, by about 0.98% for
the class 1 instances and about 0.78% for the class 2 instances. Note that the generated
solutions have an average load of about 10 items per bin for the class 1 instances and
about 20 per bin for class 2 instances, which closely approximates typical values for the
loading of boxes onto pallets.

HG (300s) BS-EPSD (60s)

Class Bin Size n bin# avg. tt(s) init t0 (s) bin# tb (s) Impr
120*80*104 2000 216.4 300.0 218.5 0.5 214.4 7.0 0.92%
120*80*104 4000 376.0 300.1 377.2 2.2 371.5 10.5 1.20%
1 120*80*104 6000 732.0 300.2 736.5 4.0 725.9 15.6 0.83%
120*80*104 8000 716.8 300.6 717.4 8.7 704.2 35.4 1.76%
120*80*104 10000 1175.6 355.2 1176.8 12.4 1169.2 29.0 0.54%
Total 3216.8 3226.4 3185.2 0.98%

120*80*224 2000 96.7 300.0 97.8 1.0 96.5 11.3 0.21%

120*80*224 4000 167.9 300.2 167.5 4.1 165.6 10.1 1.37%
2 120*80*224 6000 319.2 300.2 319.3 7.7 316.7 23.3 0.78%
120*80*224 8000 326.4 300.4 325.3 16.6 322.2 35.9 1.29%
120*80*224 10000 482.5 300.6 483.1 23.3 480.9 37.4 0.33%
Total 1392.7 1393.0 1381.9 0.78%

Table 4.11: Summarized results for Type 3 instances

4.7 Conclusion
Space defragmentation is a natural concept that has not been employed in existing ap-
proaches to packing problems. When packing items manually, humans often move existing
items in order to allow an extra item to be loaded, and also replace a smaller item with
a larger one. We have devised algorithms that mimic these operations. By incorporat-
ing space defragmentation into the extreme point insertion constructive heuristic along
with a bin-shuffling iterated local search strategy, the resultant algorithm outperformed
all existing approaches for both the 2- and 3-dimensional bin packing problem. We also
generated three new classes of problem instances for 3D-BPP that contain a large number
of items to better reflect the scale of practical problems faced by a modern third party
logistics company.
The concept of space defragmentation introduces a new class of operators that is read-
ily applicable to a wide range of d-dimensional cutting and packing problems. Examples
include 2D packing, container loading, strip packing, and the large number of applications
where packing is a sub-problem.

164
 In this chapter, we proposed two space defragmentation operators. The first is to
perform Push-out in order to produce sufficient space for the loading of a new item;
the second is Inflate-and-Replace. Both operators can be incorporated into many
simple heuristics (other than extreme point insertion), which can in turn be employed by
meta-heuristics. Other operators that employ the space defragmentation concept can be
devised. For instance, a Push-and-Replace operator might first perform Push-out,
and then replace the items that overlap with the target item when placed at position p if
the total volume utilization is increased as a result.
The bin-shuffling strategy described in Section 4.3 can also be applied directly or
adapted to a wide variety of bin packing problems. Variants include bin packing prob-
lems of different dimensionalities, additional contraints such as stability and fragility, and
different objective functions. In particular, the EP-Insert-SD procedure can be replaced
by any sequence-based heuristic for bin packing that is customised for the problem.

165
Chapter 5

Conclusion

5.1 Summary of Contributions

In this thesis, we studied three packing problems commonly faced by the logistics depart-
ments of many companies, namely the single container loading problem (SCLP), the mul-
tiple container loading cost minimization problem (MCLCMP) and the three-dimensional
orthogonal bin packing problem (3D-BPP).
There are two motivations for investigating SCLP. Firstly, SCLP is a subproblem of
MCLCMP, so an efficient and effective SCLP algorithm may be an important component
of a good MCLCMP solution. Secondly, SCLP models a wide variety of applications
in the logistics industry. For many medium or small corporations, the size of a typical
order is about that of one standard container. In such cases, SCLP can be used in the
order taking process to help estimate whether the order can fit into one container, which
would reduce the unit shipping price. Many chain stores (e.g., supermarkets) replenish
inventory daily or every few days using vehicles. In such cases, loading a vehicle can also
be modeled as SCLP.
MCLCMP and 3D-BPP mainly model the needs of large corporations, which handle
large orders that require multiple containers. In such cases, the objective is to devise
loading plans to load all items in the order while minimizing the total shipping cost.
MCLCMP models the cases where the products are directly loaded onto the floor of the
containers, or where the products are first palletized onto pallets with different heights
that are then loaded into containers. 3D-BPP models the cases where the products are
first palletized onto pallets of the same height before being loaded into containers.
The heterogeneity of the box assortment has a major impact on the volume utilization
of the packing plans for these problems. In applications where the orders come in batches
(e.g., from large buyers) or when shipping products from factories to warehouses, there are
usually only a few types of products per container. Such instances are commonly referred
to as weakly heterogeneous. In applications such as the tasks faced by a courier company
where the items are from several different customers, there are many types of products
per container. Such instances are commonly called strongly heterogeneous. MCLCMP is

166
more suitable for weakly heterogeneous applications, whereas 3D-BPP is more suitable
for strongly heterogeneous instances.
Among existing algorithms for SCLP, block building approaches have been the most
successful. We dissected the seemingly disparate block building approaches into compo-
nents, and proposed a conceptual model to capture the common structure of such ap-
proaches. Our conceptual model consists of six elements, namely representing free space
(E1), representing blocks (E2), selecting free space (E3), selecting the block to load (E4),
loading the selected block into the free space (E5) and the overarching search strategy
(E6). This conceptual model helps to identify the most effective strategy for each com-
ponent by allowing us to compare and constrast various approaches. We picked the most
successful strategies from existing approaches for each element and refined them, resulting
in a new algorithm called the iterative-doubling greedy lookahead algorithm (ID-GLA).
Experiments on standard benchmark data confirmed that our new algorithm outperforms
all existing approaches using comparable computational resources.
Since MCLCMP models the situation where there are few product types per container
and each container is able to hold many items, the most suitable approach is to first
formulate it as a set cover problem, and then solve the set cover problem. We devised
three algorithms with increasing sophistication and effectiveness using this approach.
In the SCBS algorithm, we pre-generate a set of single container loading patterns.
The main premise behind SCBS is that when a sufficient number of diverse SCLP loading
patterns are present, we can select a subset of patterns whose members complement each
other, which would cover the total demand effectively.
Since many of the pre-generated loading patterns may not be selected, a more effective
approach is to generate SCLP loading patterns only when needed. One common method
that employs this strategy is the column generation technique, where SCLP loading pat-
terns are generated on demand by solving pricing problems (which are similar to SCLP
instances). Since columns generated on demand may not appear in the final solution, we
took the idea one step further by combining column generation with the concept of proto-
typing, i.e., we only solve the pricing problem approximately in order to get a prototype
that is “close enough” to the actual loading pattern. We work on prototypes instead of
real loading patterns and attempt to realize prototypes into loading patterns only when
they are needed. The resulting algorithm is called prototype column generation (PCG).
The PCG algorithm is further refined into a goal-driven prototype column genera-
tion (GD-PCG) approach. There are two main differences between GD-PCG and PCG.
Firstly, the PCG algorithm carries out its search in two stages and each stage approaches
good solutions to MCLCMP in its own dimension, whereas GD-PCG searches in both
dimensions at the same time. Secondly, once a solution is found, a goal-driven search is
carried out in the solution neighborhood to improve the solution.
We also refined the set cover formulation of MCLCMP by adding two parameters:

167
a loading factor α that captures the mismatch between the optimal set cover solution
and the solution based on the limited number of loading patterns we can explore, and
γ value that roughly estimates expected overall volume utilization of containers in a
solution. Computational experiments show that both the loading factor and the additional
information γ (even though this information is very approximate) are useful in improving
the effectiveness of our approaches.
3D-BPP models the situation where there are many types of products per container
and each container is able to hold only a few (up to a few dozen) items. For such
scenarios, the most suitable approach is to use sequence based heuristics. We devised a
simple iterated local search to produce loading sequences, where each loading sequence
is converted into a solution by a first-fit heuristic adopted from existing literature. Our
main contribution is to model the packing of items inside a bin by comparability graphs,
which allows us to devise operations that collate fragmented loading space into continuous
space. Computational experiments show that including such operations greatly enhances
existing heuristics.
To summarize, there are three main contributions in this study. Firstly, we devised
effective algorithms for three common problems faced by the logistics industry. Since
many products are shipped via containers or vehicles with rectangular loading spaces, an
increase of a single percent in volume utilization will likely result in tremendous savings
both monetarily and in terms of reducing energy usage and carbon emissions. Secondly,
we combined the prototyping concept with column generation and demonstrated its ef-
fectiveness on MCLCMP. Since many real-word optimization problems, such as vehicle
routing problems and crew scheduling problems, can be naturally formulated as a set cover
and share a similar structure with MCLCMP, our GD-PCG algorithm may be adaptable
for use in such applications. Thirdly, space fragmentation is the main challenge faced by
heterogeneous orthogonal packing problems; our defragmentation technique developed for
3D-BPP may inspire new algorithms for similar problems.

5.2 Future Research

Although we have devised effective algorithms for three packing problems and addressed
two important considerations, namely volume utilization (or total cost of shipping) and
the stability constraint, there are still many applications that are more appropriately
modeled with other variants of packing problems. For one company in Hong Kong that
produces heavy machinery, the key factor is not volume utilization but ensuring that
the load is properly balanced. This problem can be modeled by including a requirement
where the center of gravity of the loading plan must be within a defined zone. Some
companies (especially in developed countries where labor costs are high) employ robots
for packing tasks. In such cases, a loading sequence is also needed, and such sequences

168
must be implementable by robotic arms subject to their physical constraints (such as the
degree of freedom of movement, rotation angle, etc.). One possible research direction is
to adapt our approaches to such applications.
We believe the concept of prototyping can be adapted to address other optimization
problems where the set cover formulation is natural and the pricing subproblem is hard.
We may also combine GD-PCG with learning algorithms or other statistical methods, so
that we can more accurately estimate the capability of the underlying SCLP algorithm.
We believe more accurate knowledge about SCLP will lead to a more effective overall
algorithm for MCLCMP.
The space defragmentation operations that we devised for 3D-BPP can be potentially
applied to other variants of orthogonal packing problems. These operations (and others
that utilize the concept of defragmenting free space) represent a new class of operators
for packing problems, supplementing the existing simple heuristic operations such as first-
fit or best-fit. The inclusion of space defragmentation operations can potentially allow
a search algorithm to more thoroughly explore the solution space, resulting in better
solutions.

169
Bibliography

[1] J. O. Berkey and P. Y. Wang. Two-Dimensional Finite Bin-Packing Algorithms.

The Journal of the Operational Research Society, 38(5):423–429, 1987.

[2] Silvano Martello and Daniele Vigo. Exact Solution of the Two-Dimensional Finite
Bin Packing Problem. Management Science, 44(3):388–399, 1998.

[3] Silvano Martello, David Pisinger, Daniele Vigo, Edgar Den Boef, and Jan Korst.
Algorithm 864: General and robot-packable variants of the three-dimensional bin
packing problem. ACM Transactions on Mathematical Software, 33(1):7+, 2007.

[4] Tobias Fanslau and Andreas Bortfeldt. A Tree Search Algorithm for Solving the
Container Loading Problem. INFORMS Journal on Computing, 22(2):222–235,
2010.

[5] C. Alves and J. M. Valerio de Carvalho. New integer programming formulations and
an exact algorithm for the ordered cutting stock problem. Journal of the Operational
Research Society, 59(11):1520–1531, 2007.

[6] G. Belov and G. Scheithauer. A branch-and-cut-and-price algorithm for one-

dimensional stock cutting and two-dimensional two-stage cutting. European Journal
of Operational Research, 171(1):85–106, 2006.

[7] Silvano Martello, David Pisinger, and Daniele Vigo. The Three-Dimensional Bin
Packing Problem. Operations Research, 48(2):256–267, 2000.

[8] Teodor G. Crainic, Guido Perboli, and Roberto Tadei. Extreme Point-Based
Heuristics for Three-Dimensional Bin Packing. INFORMS Journal on Computing,
20(3):368–384, 2008.

[9] Guntram Scheithauer and Johannes Terno. The G4-heuristic for the pallet loading
problem. Journal of the Operational Research Society, 47(4):511–522, 1996.

[10] Lauro Lins, Sóstenes Lins, and Reinaldo Morabito. An n-tet graph approach for non-
guillotine packings of n-dimensional boxes into an n-container. European Journal
of Operational Research, 141(2):421–439, 2002.

170
[11] F. Parreño, R. Alvarez-Valdes, J. M. Tamarit, and J. F. Oliveira. A Maximal-Space
Algorithm for the Container Loading Problem. INFORMS Journal on Computing,
20(3):412–422, 2008.

[12] José F. Gonçalves and Mauricio G. C. Resende. A parallel multi-population bi-

ased random-key genetic algorithm for a container loading problem. Computers &
Operations Research, 39(2):179–190, 2012.

[13] H. Carpenter and W. B. Dowsland. Practical Considerations of the Pallet-Loading

Problem. The Journal of the Operational Research Society, 36(6):489–497, 1985.

[14] E. E. Bischoff and M. S. W. Ratcliff. Issues in the Development of Approaches

to Container Loading. OMEGA the International Journal of Management Science,
23(4):377–390, 1995.

[15] Søren G. Christensen and David M. Rousøe. Container loading with multi-drop con-
straints. International Transactions in Operational Research, 16(6):727–743, 2009.

[16] Wenbin Zhu, Hu Qin, Andrew Lim, and Lei Wang. A Two-stage Tabu Search
Algorithm with Enhanced Packing Heuristics for the 3L-CVRP and M3L-CVRP.
Computers & Operations Research, 39(9), 2012.

[17] Andreas Bortfeldt. A hybrid algorithm for the capacitated vehicle routing prob-
lem with three-dimensional loading constraints. Computers & Operations Research,
39(9):2248–2257, 2012.

[18] Qingfang Ruan, Zhengqian Zhang, Lixin Miao, and Haitao Shen. A hybrid ap-
proach for the vehicle routing problem with three-dimensional loading constraints.
Computers & Operations Research, 2011.

[19] Guenther Fuellerer, Karl F. Doerner, Richard F. Hartl, and Manuel Iori. Meta-
heuristics for vehicle routing problems with three-dimensional loading constraints.
European Journal of Operational Research, 201(3):751–759, 2010.

[20] Christos D. Tarantilis, Emmanouil E. Zachariadis, and Chris T. Kiranoudis. A

Hybrid Metaheuristic Algorithm for the Integrated Vehicle Routing and Three-
Dimensional Container-Loading Problem. IEEE Transactions on Intelligent Trans-
portation Systems, 10(2):255–271, 2009.

[21] Michel Gendreau, Manuel Iori, Gilbert Laporte, and Silvano Martello. A Tabu
Search Algorithm for a Routing and Container Loading Problem. Transportation
Science, 40(3):342–350, 2006.

[22] M. S. W. Ratcliff and E. E. Bischoff. Allowing for weight considerations in container

loading. OR Spectrum, 20(1):65–71, 1998.

171
[23] A. Paul Davies and Eberhard E. Bischoff. Weight distribution considerations in
container loading. European Journal of Operational Research, 114(3):509–527, 1999.

[24] E. E. Bischoff. Three-dimensional packing of items with limited load bearing

strength. European Journal of Operational Research, 168(3):952–966, 2006.

[25] Jidong Ren, Yajie Tian, and Tetsuo Sawaragi. A tree search method for the con-
tainer loading problem with shipment priority. European Journal of Operational
Research, 214(3):526–535, 2011.

[26] J. Egeblad and D. Pisinger. Heuristic approaches for the two- and three-dimensional
knapsack packing problem. Computers & Operations Research, 36(4):1026–1049,
2009.

[27] Florian Diedrich, Rolf Harren, Klaus Jansen, Ralf Thöle, and Henning Thomas.
Approximation Algorithms for 3D Orthogonal Knapsack. Journal of Computer
Science and Technology, 23(5):749–762, 2008.

[28] Sándor Fekete and Jörg Schepers. A new exact algorithm for general orthogonal
d-dimensional knapsack problems. In Rainer Burkard and Gerhard Woeginger,
editors, Algorithms ESA ’97, volume 1284, chapter 12, pages 144–156. Springer
Berlin Heidelberg, Berlin, Heidelberg, 1997.

[29] A. Letchford. Analysis of upper bounds for the Pallet Loading Problem. European
Journal of Operational Research, 132(3):582–593, 2001.

[30] Adrian Smith and Phillip De Cani. An Algorithm to Optimize the Layout of Boxes
in Pallets. The Journal of the Operational Research Society, 31(7):573–578, 1980.

[31] Kathryn A. Dowsland. An exact algorithm for the pallet loading problem. European
Journal of Operational Research, 31(1):78–84, 1987.

[32] S. Bhattacharya. An exact depth-first algorithm for the pallet loading problem.
European Journal of Operational Research, 110(3):610–625, 1998.

[33] R. Morabito and S. Morales. A Simple and Effective Recursive Procedure for the
Manufacturer’s Pallet Loading Problem. The Journal of the Operational Research
Society, 49(8):819–828, 1998.

[34] Fuh Hwa and C. J. Hsiao. A Three-Dimensional Pallet Loading Method for Single-
Size Boxes. The Journal of the Operational Research Society, 48(7):726–735, 1997.

[35] R. Alvarezvaldes, F. Parreno, and J. Tamarit. A branch-and-cut algorithm for the

pallet loading problem. Computers & Operations Research, 32(11):3007–3029, 2005.

172
[36] Andrea Lodi, Silvano Martello, and Daniele Vigo. Recent advances on two-
dimensional bin packing problems. Discrete Applied Mathematics, 123(1-3):379–396,
2002.

[37] Andrea Lodi, Silvano Martello, and Daniele Vigo. Heuristic and Metaheuristic
Approaches for a Class of Two-Dimensional Bin Packing Problems. INFORMS
Journal on Computing, 11(4):345–357, 1999.

[38] Harald Dyckhoff and Ute Finke. Cutting and Packing in Production and Distribu-
tion: A Typology and Bibliography. Contributions to Management Science. Physica-
Verlag, Heidelberg, German, 1 edition, 1992.

[39] Harald Dyckhoff. A typology of cutting and packing problems. European Journal
of Operational Research, 44(2):145–159, 1990.

[40] Gerhard Wäscher, Heike Haussner, and Holger Schumann. An improved typol-
ogy of cutting and packing problems. European Journal of Operational Research,
183(3):1109–1130, 2007.

[41] David Pisinger. Heuristics for the container loading problem. European Journal of
Operational Research, 141(2):382–392, 2002.

[42] Sándor P. Fekete, Jörg Schepers, and Jan C. van der Veen. An Exact Algorithm
for Higher-Dimensional Orthogonal Packing. Operations Research, 55(3):569–587,
2007.

[43] C. F. Chien and W. T. Wu. A recursive computational procedure for container

loading. Computers & Industrial Engineering, 35(1-2):319–322, 1998.

[44] M. Arenales. An AND/OR-graph approach to the solution of two-dimensional non-

guillotine cutting problems. European Journal of Operational Research, 84(3):599–
617, 1995.

[45] G. Scheithauer and U. Sommerweis. 4-Block heuristic for the rectangle packing
problem. European Journal of Operational Research, 108(3):509–526, 1998.

[46] Reinaldo Morabito and Marcos Arenalest. An AND/OR-graph Approach to the

Container Loading Problem. International Transactions in Operational Research,
1(1):59–73, 1994.

[47] H. Gehring and A. Bortfeldt. A Genetic Algorithm for Solving the Container Load-
ing Problem. International Transactions in Operational Research, 4(5-6):401–418,
1997.

173
[48] F. Parreño, R. Alvarez-Valdes, J. E. Oliveira, and J. M. Tamarit. Neighborhood
structures for the container loading problem: a VNS implementation. Journal of
Heuristics, 16(1):1–22, 2010.

[49] Kun He and Wenqi Huang. An efficient placement heuristic for three-dimensional
rectangular packing. Computers & Operations Research, 38(1):227–233, 2011.

[50] Michael Eley. Solving container loading problems by block arrangement. European
Journal of Operational Research, 141(2):393–409, 2002.

[51] A. Bortfeldt, H. Gehring, and D. Mack. A parallel tabu search algorithm for solving
the container loading problem. Parallel Computing, 29(5):641–662, 2003.

[52] D. Mack, A. Bortfeldt, and H. Gehring. A parallel hybrid local search algorithm for
the container loading problem. International Transactions in Operational Research,
11(5):511–533, 2004.

[53] A. Lim, B. Rodrigues, Y. Yang, A. Lim, B. Rodrigues, and Y. Yang. 3-D Container
Packing Heuristics. Applied Intelligence, 22(2):125–134, 2005.

[54] Andreas Bortfeldt and Hermann Gehring. A hybrid genetic algorithm for the con-
tainer loading problem. European Journal of Operational Research, 131(1):143–161,
2001.

[55] Johannes Terno, Guntram Scheithauer, Uta Sommerweiss, and Jan Riehme. An
efficient approach for the multi-pallet loading problem. European Journal of Oper-
ational Research, 123(2):372–381, 2000.

[56] N. Ivancic, K. Mathur, and B. B. Mohanty. An integer programming based heuristic

approach to the three-dimensional packing problem. Journal of Manufacturing and
Operations Management, 2:268–298, 1989.

[57] Andrew Lim and Xingwen Zhang. The container loading problem. In SAC ’05:
Proceedings of the 2005 ACM symposium on Applied computing, pages 913–917,
New York, NY, USA, 2005. ACM.

[58] Shigeyuki Takahara and Sadaaki Miyamoto. An evolutionary approach for the mul-
tiple container loading problem. In HIS ’05: Proceedings of the Fifth International
Conference on Hybrid Intelligent Systems, pages 227–232. IEEE, 2005.

[59] Michael Eley. A bottleneck assignment approach to the multiple container loading
problem. OR Spectrum, 25(1):45–60, 2003.

[60] Michele Monaci and Paolo Toth. A Set-Covering-Based Heuristic Approach for
Bin-Packing Problems. INFORMS Journal on Computing, 18(1):71–85, 2006.

174
[61] L. R. Ford and D. R. Fulkerson. A Suggested Computation for Maximal Multi-
Commodity Network Flows. Management Science, 5(1):97–101, 1958.

[62] George B. Dantzig and Philip Wolfe. Decomposition Principle for Linear Programs.
Operations Research, 8(1):101–111, 1960.

[63] P. C. Gilmore and R. E. Gomory. A Linear Programming Approach to the Cutting-

Stock Problem. Operations Research, 9(6):849–859, 1961.

[64] P. C. Gilmore and R. E. Gomory. A Linear Programming Approach to the Cutting

Stock Problem–Part II. Operations Research, 11(6):863–888, 1963.

[65] Jacques Desrosiers, François Soumis, and Martin Desrochers. Routing with time
windows by column generation. Networks, 14(4):545–565, 1984.

[66] Cynthia Barnhart, Ellis L. Johnson, George L. Nemhauser, Martin W. P. Savels-

bergh, and Pamela H. Vance. Branch-and-Price: Column Generation for Solving
Huge Integer Programs. Operations Research, 46(3):316–329, 1998.

[67] Alberto Ceselli, Giovanni Righini, and Matteo Salani. A Column Generation Al-
gorithm for a Rich Vehicle-Routing Problem. Transportation Science, 43(1):56–69,
2009.

[68] Elvin Çoban, İbrahim Muter, Duygu Taş, İlker Birbil, Kerem Bülbül, Güvenç Şahin,
Y. İlker Topçu, Dilek Tüzün, and Hüsnü Yenigün. Column Generation Approaches
to a Robust Airline Crew Pairing Model For Managing Extra Flights. In Bern-
hard Fleischmann, Karl-Heinz Borgwardt, Robert Klein, and Axel Tuma, editors,
Operations Research Proceedings 2008, chapter 71, pages 439–444. Springer Berlin
Heidelberg, Berlin, Heidelberg, 2009.

[69] Martin Desrochers and Francois Soumis. A Column Generation Approach to the
Urban Transit Crew Scheduling Problem. Transportation Science, 23(1):1–13, 1989.

[70] David Pisinger and Mikkel Sigurd. The two-dimensional bin packing problem with
variable bin sizes and costs. Discrete Optimization, 2(2):154–167, 2005.

[71] Marco E. Lubbecke and Jacques Desrosiers. Selected Topics in Column Generation.
Operations Research, 53(6):1007–1023, 2005.

[72] Patrick Healy, Marcus Creavin, and Ago Kuusik. An optimal algorithm for rectangle
placement. Operations Research Letters, 24(1-2):73–80, 1999.

[73] Brenda S. Baker, Edward G. Coffman, and Ronald L. Rivest. Orthogonal Packings
in Two Dimensions. SIAM Journal on Computing, 9(4):846–855, 1980.

175
[74] Oluf Faroe, David Pisinger, and Martin Zachariasen. Guided Local Search for
the Three-Dimensional Bin-Packing Problem. INFORMS Journal on Computing,
15(3):267–283, 2003.

[75] Teodor G. Crainic, Guido Perboli, and Roberto Tadei. TS2PACK: A two-level
tabu search for the three-dimensional bin packing problem. European Journal of
Operational Research, 195(3):744–760, 2009.

[76] G. Perboli, T. G. Crainic, and R. Tadei. An efficient metaheuristic for multi-

dimensional multi-container packing. In Automation Science and Engineering
(CASE), 2011 IEEE Conference on, pages 563–568. IEEE, 2011.

[77] F. Parreño, R. Alvarez-Valdes, J. F. Oliveira, and J. M. Tamarit. A hybrid

GRASP/VND algorithm for two- and three-dimensional bin packing. Annals of
Operations Research, 179(1):203–220, 2010.

[78] Y. Wu. An effective quasi-human based heuristic for solving the rectangle packing
problem. European Journal of Operational Research, 141(2):341–358, 2002.

[79] Silvano Martello and Paolo Toth. Knapsack Problems: Algorithms and Computer
Implementations. Wiley Interscience Series in Discrete Mathematics and Optimiza-
tion. John Wiley & Sons Ltd., Baffins Lane, Chichester, West Sussex PO19 1UD,
England, 1990.

[80] K. K. Lai and J. W. M. Chan. Developing a simulated annealing algorithm for the
cutting stock problem. Computers & Industrial Engineering, 32(1):115–127, 1997.

[81] A. Lim, B. Rodrigues, and Y. Wang. A multi-faced buildup algorithm for three-
dimensional packing problems. OMEGA the International Journal of Management
Science, 31(6):471–481, 2003.

[82] Ana Moura and José F. Oliveira. A GRASP approach to the container-loading
problem. IEEE Intelligent Systems, 20(4):50–57, 2005.

[83] Lijun Wei, Wee-Chong Oon, Wenbin Zhu, and Andrew Lim. A skyline heuristic
for the 2D rectangular packing and strip packing problems. European Journal of
Operational Research, 215(2):337–346, 2011.

[84] Silvano Martello, Michele Monaci, and Daniele Vigo. An Exact Approach to the
Strip-Packing Problem. INFORMS Journal on Computing, 15(3):310–319, 2003.

[85] Sándor P. Fekete and Jörg Schepers. A Combinatorial Characterization of Higher-

Dimensional Orthogonal Packing. Mathematics of Operations Research, 29(2):353–
368, 2004.

176
[86] Phil Hanlon. Counting Interval Graphs. Transactions of the American Mathematical
Society, 272(2):383–426, 1982.

[87] Wenqi Huang, Duanbing Chen, and Ruchu Xu. A new heuristic algorithm for
rectangle packing. Computers & Operations Research, 34(11):3270–3280, 2007.

[88] Wenqi Huang and Kun He. A caving degree approach for the single container loading
problem. European Journal of Operational Research, 196(1):93–101, 2009.

[89] E. Hopper. An empirical investigation of meta-heuristic and heuristic algorithms

for a 2D packing problem. European Journal of Operational Research, 128(1):34–57,
2001.

[90] Hermann Gehring and Andreas Bortfeldt. A Parallel Genetic Algorithm for Solving
the Container Loading Problem. International Transactions in Operational Re-
search, 9(4):497–511, 2002.

[91] J. A. George and D. F. Robinson. A heuristic for packing boxes into a container.
Computers & Operations Research, 7(3):147–156, 1980.

[92] Mokhtar S. Bazaraa, John J. Jarvis, and Hanif D. Sherali. Linear Programming and
Network Flows. Wiley-Interscience, 3 edition, 2004.

[93] N. Lesh, J. Marks, A. McMahon, and M. Mitzenmacher. Exhaustive approaches to

2D rectangular perfect packings. Information Processing Letters, 90(1):7–14, 2004.

[94] Hiroshi Murata, Kunihiro Fujiyoshi, Shigetoshi Nakatake, and Yoji Kajitani. VLSI
module placement based on rectangle-packing by the sequence-pair. IEEE Transac-
tions on Computer-Aided Design of Integrated Circuits and Systems, 15(12):1518–
1524, 1996.

[95] Douglas C. Montgomery. Design and Analysis of Experiments. John Wiley & Sons.
Inc., 6 edition, 2005.

[96] Andreas Bortfeldt. A heuristic for multiple container loading problems. OR Spec-
trum, 22(2):239–261, 2000.

[97] Shigeyuki Takahara. A Simple Meta-heuristic Approach for the Multiple Container
Loading Problem. In SMC ’06: IEEE International Conference on Systems, Man
and Cybernetics, 2006, volume 3, pages 2328–2333, 2006.

[98] Shigeyuki Takahara. A Multi-start Local Search Approach to the Multiple Container
Loading Problem. In Witold Bednorz, editor, Advances in Greedy Algorithms, pages
55–68. IN-TECH, I-TECH Education and Publishing, Zieglergasse 14 1070 Vienna
Austria, European Union, 2008.

177
 [99] Marco A. Boschetti and Aristide Mingozzi. The two-dimensional finite bin packing
problem. Part I: New lower bounds for the oriented case. 4OR: A Quarterly Journal
of Operations Research, 1(1):27–42, 2003.

[100] Marco A. Boschetti and Aristide Mingozzi. The Two-Dimensional Finite Bin Pack-
ing Problem. Part II: New lower and upper bounds. 4OR: A Quarterly Journal of
Operations Research, 1(2):135–147, 2003.

[101] E. Lodi and L. Pagli. A VLSI Solution to the Vertical Segment Visibility Problem.
Computers, IEEE Transactions on, C-35(10):923–928, 1986.

[102] Andrea Lodi, Silvano Martello, and Daniele Vigo. Heuristic algorithms for the
three-dimensional bin packing problem. European Journal of Operational Research,
141(2):410–420, 2002.

178