## 5 Computational Experiments  
The proposed algorithm was implemented using Python 3.7. All experiments were run in a computer with an Intel Xeon E5-2650 v4 with 32 GB of RAM. As far as we know, there are no public instances for the studied problem. Hence, we generated a set of instances, which are available at [[https://www.researchgate.net/publication/356874077_instances_flowShop](https://www.researchgate.net/publication/356874077_instances_flowShop)]([https://www.researchgate.net/publication/356874077_instances_flowShop](https://www.researchgate.net/publication/356874077_instances_flowShop)) (access on 1 February 2022). This set consists of 20 instances, and it is based on the production scenario defined in Section 2, which includes ten processing machines and two additional batch machines, distributed in four different paths. A total of four different types of jobs were considered, each type being processed on a specific path. The instances were identified following the nomenclature _j_m_y, where \(j\) is the sum of jobs to be processed; \(m\) defines the sum of machines (including both regular and batching machines); and \(y\) is a sequential number, used to identify the instances with the same number of jobs and machines in an easy and comprehensive way. Notice that, depending on the instance, the number of jobs varies between 30 and 1600. We defined unrelated and machine-dependent setup times for every job. Thus, every job has different set-up times on every machine. We also defined unrelated and machine-dependent processing times. Hence, for each job \(j\), a processing time at each machine \(i\) was defined. Our algorithms were run considering 60 s of computing time for instances with 30 jobs and 300 s for instances with 200 and 400 jobs, while it employed a maximum of 900 s for instances with 800 jobs or more. Table 1 shows the results of the algorithm described in Section 4 for the defined instances. The first column identifies the instance. Subsequently, the following two columns present the solutions obtained using the AnyLogic simulation tool, which simulates the production scenario. In that sense, we provided the total makespan of each solution when the jobs are processed in the system using a first-in-first-out (FIFO) strategy and the computation time--in seconds--required to reach them. Using this strategy, the jobs enter in the system without any logical ordering, i.e., following the alphanumerical order as provided in the instances. We provide this information with the aim of validating the quality of our algorithm. Similarly, the next two columns report the makespan, with its corresponding computational time, provided by our approach using the above-mentioned FIFO strategy. The following two columns present the results of our approach using the same strategy combined with biased-randomization techniques. This allows us to enter jobs in the system in a different order at each algorithm iteration. In our case, a geometric  
probability distribution, driven by a single parameter \(\beta\) was employed to induce this behavior. The value for this parameter was set after a quick tuning process over a random sample of instances, establishing a good performance whenever \(\beta\) falls between 0.3 and 0.4 (i.e., any random value inside this interval will generate similar results). Specifically, these columns provides the best-found solution (makespan) and the computational time--in seconds--to reach it. Similarly, the next four columns display the makespans and the computational times when the BR-NEH and BR-STNEH sorting strategies were applied. Finally, the last three columns of the table report the gaps for the different strategies with respect to the initial FIFO one. Our results show that our approach is highly competitive regarding computational times with respect to the Anylogic simulator.