Fig. 1. The search tree for an OSS instance on three operations that is defined by the construction mechanism of building permutations of all operations from left to right. The inner nodes of the search tree are partial solutions, whereas the leaves are solutions.

Fig. 2. (a) The disjunctive graph representation [29] of a simple instance of the OSS problem consisting of 10 operations partitioned into 3 jobs, and 4 machines (processing times are omitted in this example). Problem specification: , . The nodes of the graph correspond to the operations. Furthermore, there are undirected arcs between every pair of operations being in the same job (dotted) or having to be processed on the same machine (dashed). In order to obtain a solution, the undirected arcs have to be directed without creating any cycles. This corresponds to finding permutations of the operations on the machines and in the jobs such that there are no cycles in the processing orders. (b) A feasible solution to the problem. The undirected arcs from (a) are directed and the new directed graph does not contain any cycles.

Fig. 3. The x-axis and the y-axis define different parameter settings of . On the x-axis are the pre-selection mechanisms, on the y-axis the strategies for setting k_ext, and the z-axis shows the percentage above the best known solution value of the average solution quality obtained in 20 runs of with the parameter settings as specified on the x- and y-axis. (a) and (b) show the results for instance (490 s per run), which is a difficult OSS problem instance from the benchmark set provided by Brucker et al. [35]. The results in (a) are obtained with , whereas the results in (b) are obtained with . (c) and (d) show in the same way the results for instance (100 s per run) from the benchmark set provided by Taillard [34]. The legends of the four graphs indicate the “height” of the contour lines given on the x-y plane (i.e., give a contour map of the performance surface).

Table 1. The table gives the results of with different parameter settings (as specified in the first column) for two different OSS benchmark instances

The second column of each table provides the average of the best solution values obtained in 20 runs of the algorithm. The third column gives the average computation time that was needed to obtain the best solution of a run. Finally, in the last column of each table, we have ranked the different parameter settings according to the average of the best solution values that are given in the second column.

Table 2. Results that show the influence of the pheromone update and the local search on the performance of

The table is organized as follows: the first column specifies the problem instance. Then, there are three columns for each of the four different versions of , that are (1) with pheromone update and local search, (2) without pheromone update, (3) without local search, and (4) without update and without local search. The first of the three respective columns gives the best solution found in 20 runs. An objective function value is in bold, if it beats the other three algorithm versions. In case of ties the average solution quality decides. The second column gives the average of the best solutions found in 20 runs, and the third column gives the average CPU time that was needed to find the best solutions in the 20 runs.

Table 3. Results for the OSS benchmark instances provided by Taillard [34].

For an explanation of the table format see Section 6.3.

Table 4. Results for the OSS benchmark instances provided by Brucker et al. [35]

For an explanation of the table format see Section 6.3.

Table 5. Results for the OSS benchmark instances provided by Guéret and Prins in [36]

For an explanation of the table format see Section 6.3. Note that the improved best known solutions for instances , , , and were obtained by different versions of (see Table 2(b)).