# Blocking Cyclic Job-Shop Scheduling Problems
## 5 Experimental Settings and Results  
In the literature, there is no benchmark dataset specifically designed for the cyclic JSS problem. Cyclic production systems have minimal part sets, which makes the problem significantly different to classic JSS. This leads to two major differences. First, the objective of the classic JSS is minimising the makespan, compared to cycle time in cyclic JSS. While both objectives have similarities, the resulting (optimal) schedules can be substantially different. Second, in the cyclic problem, there is less variety among the products but higher volumes relative to classic job shops. This leads to the size of the minimal part sets in cyclic JSS being smaller than the number of jobs in classic JSS. Due to the above reasons, for this study, we designed a number of benchmark problem instances (see Appendix A, which provides details of the algorithm for generating the instances) motivated by practical requirements and using typical characteristics seen in JSS. The MIPs developed in this study were programmed in Python 3.6 and all experiments were conducted on MonARCH, the campus cluster at Monash University. Each run was given four cores and a limit of 10 GB memory. The MIP models were solved using Gurobi 9.0.1 ([[http://www.gurobi.com/](http://www.gurobi.com/)]([http://www.gurobi.com/](http://www.gurobi.com/)) (accessed on 30 August 2022)). Each run was given one hour of execution time. Table 3 shows the results of the MIP models for the blocking CJSS problem without setups, with sequence-dependent anticipatory and nonanticipatory setups. There were 16 problem instances with different combinations of machines (K) and jobs (J), which were generated by the method described above. The results were split in three jobs: (1) cyclic job shop without sequence-dependent setups, (2) cyclic job shop with anticipatory sequence-dependent setups, and (3) cyclic job shop with nonanticipatory sequence-dependent setups. For each MIP, the details provided include the number of constraints (#**Cons**), number of variables (#**Vars**), the objective value of the best feasible solution (**BF**), the lower bound (**LB**), the gap between the upper and lower bounds \(\left(Gap=\frac{(BF-LB)}{LB}\right)\), and the total time taken. If no feasible solution was found, the corresponding **BF** and **Gap** columns have a dash (-). First, we considered cyclic JSS on its own. We see that for problems with a small number of jobs (three) the optimal solution was always found, and the time required was often quite small (under 30 s) relative to the time limit. Additionally, for a small number of machines (9, 12) and four jobs, the optimal solutions could also be found. For a larger number of jobs (five), feasible solutions were found but often with large gaps. For problems with six jobs, no feasible solutions were found irrespective of the number of machines. Nonetheless, the MIP always found lower bounds (the quality of which could not be guaranteed). Considering cyclic JSS with anticipatory setups, we see a similar pattern. However, in this case, the problems proved more difficult to solve with one more problem not being solved (18 machines and 5 jobs) compared to Cyclic JSS. Additionally, when solutions were found, if they were not optimal, the gaps were larger. This is not surprising, since the overhead of the anticipatory setup times makes the problem more complex. Finally, considering cyclic JSS with nonanticipatory setups, we see that it became even harder (compared to cyclic JSS and cyclic JSS with AS) to find solutions within the allowed time limits. The nonanticipatory setup required a job moving between machines to immediately leave the machine that it was currently on, and this meant that the MIP model struggled more when attempting to find a feasible solution.