Keywords

7.1 Introduction

Container loading is a typical packing problem, concerning the orthogonal placement of small boxes (i.e., rectangular parallelepipeds) into a big box, maximizing the loaded volume. A very large number of specialist works are devoted to this subject and the reader is referred to the available literature for a wide-ranging overview (e.g., [1]). Hereinafter, we shall recall the modeling-based methodology discussed in depth in a dedicated chapter of this book [2].

This approach has been conceived to solve complex non-standard packing problems, allowing for tetris-like items inside convex domains, with additional conditions, such as balancing. The container loading problem, as per its classical formulation, represents a specific case addressed by the general MILP (Mixed Integer Linear Programming) mathematical model discussed in Fasano [2], Section2. This can be utilized, directly, when a limited number of items are involved. Otherwise, when large-scale instances have to be coped with, the above-mentioned MILP model represents the basic “engine” of the overall heuristic approach outlined in Fasano [2], Section 6. Specific versions of this model are, in such cases, adopted to support all the relevant phases of the whole heuristic process, i.e.: Initialization, Packing, Item-exchange, Hole-filling. The present chapter focuses on what we currently consider the most promising solution strategies relevant to the modeling-based approach in question. These act at two different levels.

Firstly, an ad hoc strategy, delineated in Sect. 7.2.1, has been looked into for the above-mentioned overall heuristic procedure. As pointed out in Fasano [2], Section 6, indeed, the way the various modules (i.e., Initialization, Packing, Item-exchange, Hole-filling) are activated/executed actually determines a specific heuristics.

Secondly, dedicated MILP strategies have been studied to work out the general MILP model, as utilized in its different versions, i.e. either when the container loading problem is tackled tout court, or the various phases of the heuristic process have to be performed. As is well known, when managing an MILP model, the solution search effectiveness is strongly affected by the general features of the optimizer adopted, but even more by the way it is “driven.” For instance, different branch and bound (B&B) strategies may yield very different outcomes, both in terms of solution quality and computational effort. In our research, IBM ILOG CPLEX [3] has been selected as the MILP solver and appropriate drivers set up to solve the MILP model, in its various versions, efficiently. This is the subject of Sect. 7.2.2.

A dedicated experimental analysis, covering non-trivial instances, has been carried out. Although the strategies proposed here are suitable for a number of non-standard packing issues, not limited to the classical container loading problem, our attention has been concentrated on it. In this case, the procedure put forward in the present chapter (as well as the modeling-based approach in general), being aimed at non-standard applications, is typically outperformed by most of the off-the-shelf algorithms, specific for the classical container loading problem (e.g., [4]). The choice of focusing on this problem in particular, however, aims to offer a useful reference in a standard test framework. Section 7.3.1 reports computational results relevant to the direct solution of the MILP model, with small-scale instances. Section 7.3.2 shows outcomes regarding demanding test cases, solved by the heuristics of Sect. 7.2.1. Insights concerning the presence of balancing conditions are additionally provided in Sect. 7.3.3, to draw the reader’s attention to an application quite frequent in practice.

7.2 Solution Search Strategies

7.2.1 Heuristic Approach

A specific procedure deriving from the overall heuristic approach proposed in Fasano [2] is outlined in this section (in a streamlined form). Major interrelated concepts are those of relative position and abstract configuration. A relative position between two items expresses that one, with respect to the other, is located in compliance with one of the following conditions: on the left, on the right, in front, behind, above or below. An abstract configuration, relative to N items, is a set of \( \frac{N\left(N-1\right)}{2} \) relative positions, one for each pair of items, that are feasible (i.e., all of them can be respected) in any unbounded domain. With a given abstract configuration items may be rotated and translated, keeping their relative positions unaltered.

The underlying idea of the overall heuristic approach is to generate a sequence of abstract configurations that allow the feasible placement (i.e., with no overlapping) of an increasing number of items in the given domain (i.e., the container), maximizing the loaded volume.

In the specific heuristics proposed in this chapter, the whole process is split into two macro-phases, i.e. the main and the incremental one, respectively, see Fig. 7.1. Both of them activate the modules of the overall heuristic approach (i.e., Initialization, Packing, Item-exchange, Hole-filling) sequentially. The macro-phases are executed recursively, performing a number of cycles. Items are added, time after time, following an overall greedy approach. At each module execution, the selection of items as candidates for loading (in addition to those previously accepted) is made on a larger-first priority criterion. This way, the procedure attempts to load items with the largest volumes whilst the domain is still quite unexploited. On the contrary, the smaller ones are tentatively introduced to fill the empty spaces, when high loading percentages have already been attained. At each module execution, the current abstract configuration is taken as input and an upgraded one is provided by it (if executed successfully).

Fig. 7.1
figure 1

Heuristics overall logic

Full size image

7.2.1.1 Main Phase

A single cycle of the main phase consists of the prefixed sequence: Initialization, Packing, Item-exchange, and Hole-filling.

Their specific functionalities are summarized here below:

  • the Initialization module generates a preliminary abstract configuration, for a subset of the items available, by means of a relaxation of the general MILP model (allowing item overlapping);

  • the Packing module places items into the domain, in compliance with the current abstract configuration and maximizing the total volume loaded;

  • the Item-exchange module attempts advantageous exchanges between (subsets of) non-loaded and loaded items (both are set free, with respect to the current abstract configuration, and a new one is correspondently generated, if the module execution has been successful);

  • the Hole-filling module tries to add some of the unloaded items (that are set free, with respect to the current abstract configuration, and an upgraded one is correspondently generated, if the module execution has been successful). The Hole-filling module is first executed by fixing the orientation of all items involved. Afterwards, it is re-executed, if opportune, setting the item orientations free.

The main phase is carried on, by repeating single cycles, until either the loaded volume has attained 75 % of the domain’s or a maximum time limit has been reached. The abstract configuration obtained at the end of this phase is handed over to the next.

7.2.1.2 Incremental Phase

A single cycle of the incremental phase consists of the prefixed sequence: Hole-filling and Item-exchange (at this level of volume exploitation, indeed, the first two modules are no longer effective, in particular Initialization, being based on a relaxation of the MILP model). Also in this case, the Hole-filling module is firstly executed by fixing the orientation of all items involved. Afterwards, if re-executed, these are set free. Here, the Item-exchange module has the role of performing backward iterations (to make up for possible previous inappropriate moves). The relevant functionalities of both modules employed are the same as described above. A number of single cycles are executed, until either all items have been processed or a maximum time limit has been reached.

7.2.2 Model Solving by CPLEX

The heuristics introduced in Sect. 7.2.1, and all of the tests reported in this chapter, were performed utilizing IBM ILOG CPLEX (see [3]) as the MILP optimizer. CPLEX carries out the optimization process by a branch & cut (B&C) algorithm, including several general purpose heuristics. It is also able to perform parallel optimization. Like most of the optimizers available to date, CPLEX has a default strategy for the MILP solution, which is flexible and adaptable to the model characteristics. Its level of sophistication is so advanced that a number of ad hoc optimizer parameters, able to outperform the default mode, can hardly be found. Moreover, the risk of “over engineering” the setting of the parameters, tuning them to a particular class of instances, rather than to the model intrinsic characteristics, cannot be neglected. Sometimes however, it can be useful to define a specific CPLEX optimization strategy. This holds, in particular, when the solution search is somehow time-boxed, and the proof of optimality is not necessary. This is the case of the two situations dealt with in Sect. 7.3, concerning either the solution of the MILP model directly or the execution of the heuristics of Sect. 7.2.1.

7.2.2.1 Direct Solution

When some difficult instances, albeit with a limited number of items, are tackled by solving the MILP model directly, i.e. in the first situation, the number of nodes generated by the B&C procedure really tends to “explode.” In this circumstance, a specific strategy is needed, in order to reduce the node generation as much as possible and make the process spend more time at each B&B step, yielding (supposedly) better search choices. Another characteristic associated with the MILP model in question is that the LP-relaxation upper bound is usually coincident with the value of the optimal (integer) MILP solution. As a consequence, any strategy, aimed at generating cuts and improving the upper bound, results in being ineffective.

To cope with these difficult instances, an ad hoc approach was therefore devised. It is based on an intense employment of (CPLEX) heuristics, probing techniques (see [3]), a very limited use of cutting planes, and the “solution polishing” heuristics (see [3, 5]) that are activated when several solutions and at least 200 nodes have already been explored.

The priority order of the branching variables represents a further important feature of the approach studied. Since, from the model formulation and from the solution logic, some binary variables are supposedly able to induce a better separation in the search tree, they are provided with a higher priority in the process. Figure 7.2 illustrates the multiple CPLEX parameters (see [3]) that have been selected (the parameters not shown in the figure correspond to the default setting).

Fig. 7.2
figure 2

CPLEX parameter selection for the direct solution

Full size image

7.2.2.2 Heuristic Solution

When the heuristics of Sect. 7.2.1 is utilized, i.e. in the second situation, it is of paramount importance to obtain quick, albeit sub-optimal, solutions for each module execution. Proof of optimality is not needed at all, although sometimes the heuristics performances can be biased by too many run interruptions (based on predefined-maximum-time limits). The priority order of the branching variable declaration is the same as in the direct solution situation. Figure 7.3 reports the CPLEX parameters adopted for Initialization, Packing, Item-exchange, and Hole-filling, respectively.

Fig. 7.3
figure 3

CPLEX parameter selection for the heuristic solution

Full size image

7.3 Experimental Analysis

The experimental analysis of this section is an extension of the previous, reported in Fasano [6]. The test campaign referred to hereinafter was performed using IBM CPLEX 12.6.0.1 (see [3]) as the optimizing engine, and IBM EasyModeler as the model generator. More precisely, the MILP solver available within CPLEX, statically linked to the C++ code generated by EasyModeler, was adopted, using the open source Coin-OR OSI 0.105.3 library as the interface between EasyModeler and the optimizer. The following computational supports were moreover utilized:

  • platform: Lenovo Thinkpad W520 Laptop. with an Intel(R) Core (TM) i7-2620M at 2.7 GHz clock frequency (2 real core seen as 4 with Intel Hyperthreading) and 8 GB Ram available;

  • operating system: Windows(R) 7 Professional OS.

All the tests were run using a parallel version of CPLEX. CPLEX 12.6 can execute the B&C in two different parallel flavors: Parallel Optimization on threads on the same (multi core) CPU, and Distributed Parallel with a messaging protocol among distinct CPUs. During the tests, the Parallel Optimization on Threads was employed; the number of Threads is defaulted to the number of cores seen by the OS, i.e. 4.

This section reports first a group of tests concerning the solution of the MILP model directly. Experimental results relevant to the use of the heuristics outlined in Sect. 7.2.1 are presented next. Additionally, instances with the balancing requirement are provided. All the case studies considered hereinafter involve box-shaped items and domains.

7.3.1 Direct Solution of Standard Instances

In order to test the MILP model for solving the container loading problem directly, we selected 5 fabricated instances (see [7]), whose optimal solutions were known a priori. Among them, 4 have a cube as a domain of 8, 9, 10, and 11 units, respectively. They are denoted in the following as: Cube-8, Cube-9, Cube-10, and Cube-11 tests. The domain of the further instance is a rectangular parallelepiped, obtained by merging two Cube-8 domains. The relevant test is referred to as: Double-cube-8. For all the tests considered in this section, no additional condition was posed. The instance data concerning the items available are reported, test by test, in the following Tables 7.1, 7.2, 7.3, 7.4, and 7.5.

Table 7.1 Cube-8 items
Full size table
Table 7.2 Cube-9 items
Full size table
Table 7.3 Cube-10 items
Full size table
Table 7.4 Cube-11 items
Full size table
Table 7.5 Double-cube-8 items
Full size table

A maximum time limit of 1 h was set for each test case. Two out of five (i.e., Cube-8 and Cube-9) were solved to optimality; in two cases (i.e., Cube-10 and Cube-11) only one item was rejected; in one (i.e., Double-cube-8) those not loaded were three. The relevant results are shown in Table 7.6 while Figs. 7.4 and 7.5 provide graphical views of the solutions obtained for Cube-8 and Double-cube-8.

Table 7.6 Direct solution tests
Full size table
Fig. 7.4
figure 4

Cube-8 graphical results

Full size image
Fig. 7.5
figure 5

Double-cube-8 graphical results

Full size image

Instances of the above tests, with all items pre-oriented (correspondently to the fabricated optimal solutions) were considered. Surprisingly enough, none of them was solved to optimality within 1 h. Further pre-oriented instances for Cube-8 and Cube-9 were hence taken into account, additionally. In such cases, the item pre-orientation was derived from the solutions reported in Table 7.6. The optimal solutions (or some equivalent) were re-obtained in almost half the time of the non-pre-oriented instances. Our interpretation in regard is that, since several non-symmetric solutions exist, the more “degrees of freedom” there are, the more effective the CPLEX heuristics (including the “solution polishing”) results.

7.3.2 Heuristic Solution of Standard Instances

This section refers to 27 non-trivial test cases for the classical container loading problem, with no additional conditions. They are extracted from the reference: “Three Dimensional Cutting and Packing Data Sets - THPACK 1-7 BR” [8]: http://www.euro-online.org/web/ewg/25/esicup-euro-special-interest-group-on-cutting-and-packing. As is known, this test-bed consists of 7 sets of 100 test cases each. Among these, all those with an available number of items between 200 and 400 were selected. They are listed in Table 7.7 and, hereinafter, numbered sequentially, from 1 to 27.

Table 7.7 Selected test cases (THPACK 1-7 BR)
Full size table

The 27 selected test cases were solved using the heuristics of Sect. 7.2.1, with a maximum time limit of 1 h. The relevant results are summarized in Table 7.8 (the reported time elapses are often longer than 1 h, since the heuristics always finalized the last optimization steps, prior to performing the final housekeeping) (Fig. 7.6).

Table 7.8 Results for the selected test cases (THPACK 1-7 BR)
Full size table
Fig. 7.6
figure 6

Correlation between load factor and time spent in optimization

Full size image

Load factors range from 57.45 to 87.07 %, with an average of 77.92 % and a standard deviation of 7.52 (graphical results relative to Test case 17 are illustrated in Fig. 7.7). It is interesting to note that the time spent in optimization is inversely correlated, as pointed out in Fig. 7.6. This appears as an indication that the heuristics’ logic itself is more relevant than the optimizer speed. The instances are solved to a greater extent when the heuristics is able to generate easier sub-instances to solve. The heuristics’ overall logic and its specific module features (including possible function extensions) are expected to represent the objective of further research.

Fig. 7.7
figure 7

Test case 17 graphical results

Full size image

7.3.3 Heuristic Solution of Test Cases with Balancing Conditions

An extension of the classical loading problem is briefly discussed here. The (quite frequent in practice) balancing requirement, for which the overall center of mass (of the loaded container) must stay inside a convex domain is considered (see [6]). Each item (supposed to be of homogeneous density) is therefore represented by its side lengths and mass. In the following sections (for the sake of simplicity) no mass is associated with the container itself and the overall center of mass domain is assumed to be a (rectangular) parallelepiped.

7.3.3.1 Items Having the Same Density

The 27 test cases of Sect. 7.3.2 were reconsidered assuming that all items had the same density. These test cases were run with a very tight restriction on the center of mass domain, which consisted of a cube of 2 units, centered with respect to the container. Since the container was a box of 587 × 233 × 220 units, this meant a deviation from its center well below 0.5 % its side lengths. The relevant results are reported in Table 7.9.

Table 7.9 Results for the selected test cases with items of constant density
Full size table

Both from the load factor and computational performance viewpoints, the results are quite similar to the test cases reported in Sect. 7.3.2. A slight deviation from them can be noticed, consisting, essentially, of an average load factor decrement of a mere 1.14 %.

7.3.3.2 Items Having Different Densities

Three test cases, i.e. 4, 19 and 25, extracted from the set of 27 of Sect. 7.3.2 were considered, by providing the items with different densities (generated randomly). These are reported in Table 7.10 (referring to mass and volume units). For these three test cases the overall center of mass was requested to stay inside a slightly larger domain (roughly representing 5 % of tolerance over the length of each axis), centered with respect to the container. Table 7.11 shows the relevant results and Fig. 7.8 provides graphical views of the solution obtained for Test case 4.

Table 7.10 Items with different densities
Full size table
Table 7.11 Results for Test cases 4, 19, and 25 with central balancing
Full size table
Fig. 7.8
figure 8

Test case 4 (with balancing conditions) graphical results

Full size image

Finally Test cases 4, 19 and 25 were considered, maintaining the same masses reported in Table 7.10, but with different conditions concerning the position of the center of mass domain (that continued to have the same dimension as before). This was placed in an off-centered position, inside the container. This request can occur in practice, for instance, for structural reasons (see [9]). Table 7.12 reports, for Test cases 4, 19, and 25 respectively, the positions of the relevant domain centers. The results obtained are shown in Table 7.13. Test case 4 solution is represented graphically in Fig. 7.9.

Table 7.12 Center of mass domain off-centered locations
Full size table
Table 7.13 Results for Test cases 4, 19, and 25 with off-centered balancing
Full size table
Fig. 7.9
figure 9

Test case 4 (with off-centered balancing conditions) graphical results

Full size image

7.4 Conclusive Remarks

This work focuses on experimental aspects relevant to the container loading problem, solved by a modeling-based heuristic approach. The relevant MILP model is discussed in depth in another chapter of this book and represents the reference framework for the underlying mathematical formulation. This approach is aimed at coping with complex non-standard packing problems, involving tetris-like items, non-box-shaped domains and additional conditions, such as balancing.

A standard context has, nonetheless, been targeted in this chapter, addressing the container loading problem, as per its classical statement. This concerns the placement of box-shaped items (with the possibility of rotation) into a box-shaped domain, with no additional conditions, maximizing the loaded volume.

The general MILP model has been tested to solve directly non-large-scale fabricated instances, whose optimal solutions were known a priori. Afterwards, a set of complex case studies have been studied and further examples involving the additional condition of balancing provided.

Although for the specific experimental context considered, the proposed approach is usually outperformed by most of the off-the-shelf container loading optimization methods, the authors deem that the results shown here provide a useful reference in a standard-based framework. Further research relevant both to the heuristics overall logics and its specific features, referred to a more general non-standard context, is in the pipeline for the near future.