## 6 The Proposed Simulation Optimization Algorithm
### Adding Discrete Event Simulation Principles to BR  
To synchronize the various events within the warehouse, the BR heuristic is enhanced with a discrete event simulation. Employing DES allows for a consistent and reliable evaluation of the impacts of BR decisions. Given the system's high parallelism and synchronization complexities, measuring the makespan of a set of operations would be infeasible without DES. Consequently, during the deterministic discrete event simulation of the system, a BR process is employed at each decision stage to select the next building element from a list of candidates. This hybrid BR-DES approach facilitates the rapid generation of a range of feasible solutions (in terms of event synchronization) guided by the logic of the constructive heuristic, ensuring potentially favorable solutions in terms of quality. The integration of BR with DES is depicted in Figure 7. The entire algorithm can be visualized as a multi-start framework, where, until the computational time does not surpass a predefined threshold, new, random but oriented solutions are continually generated from scratch. This architecture comprises two distinct components: the BR heuristic, which includes a Monte Carlo simulation that makes random but oriented decisions, and the discrete event simulation. Each new solution is created by running the simulation, delegating decisions to BR within what we term the algorithm simulation loop. Subsequently, the new solution is compared with the best solution obtained so far and this is replaced if superior. Within the simulation loop, key decisions made by BR include the sequencing of input and output operations, the selection of retrieved bundles to fulfil customer orders, and the allocation of storage locations for entering bundles. Specifically, input and output requests are jointly processed using an FIFO criterion. For each request, the algorithm strives to deliver a satisfactory and feasible solution--such as assigning a storage location for input operations or a set of bundles for output operations. If the solution found is deemed infeasible, the request is postponed, and the subsequent input request is processed. For instance, when \(k\in R^{in}\) represents an input request and the solution is infeasible, all subsequent input requests originating from the same input point \(s_{k}\) are deferred. This strategy minimizes changes to the input request queue, crucial due to the complexities of handling large metal bar bundles, as detailed in Section 4. Specifically, if the non-feasible input request involves storing a bundle of type \(c_{k}\), all subsequent inputs are postponed until after the next output request requiring retrieval of the same bundle type. This action, as exemplified in Table 2, ensures sufficient space is created by the output request, guaranteeing fulfillment of the previously postponed non-feasible request \(k\). \begin{table}
\begin{tabular}{c c c c c c c c} \hline \hline
**Request** & **Type** & **I/O Point** & **Bundle** & **Request** & **Type** & **I/O Point** & **Bundle** \\ \(k\) & \(\textbf{t}_{k}\) & \(\textbf{s}_{k}\) & **Type \(\textbf{c}_{k}\)** & \(\textbf{k}\) & \(\textbf{t}_{k}\) & \(\textbf{s}_{k}\) & **Type \(\textbf{c}_{k}\)** \\ \hline
1 & IN & 1 & A & 2 & IN & 2 & B \\ \hline
2 & IN & 2 & B & 4 & OUT & 3 & B \\ \hline
3 & IN & 1 & C & 5 & OUT & 3 & A \\ \hline
4 & OUT & 3 & B & 1 & IN & 1 & A \\ \hline
5 & OUT & 3 & A & 3 & IN & 1 & C \\ \hline
6 & IN & 2 & C & 6 & IN & 2 & C \\ \hline \hline \end{tabular}
\end{table} 
Table 2: List of requests before (left) and after (right) the postponement process. Figure 7: Flowchart of a generic discrete-event heuristic. If the non-feasible request pertains to an output, it is deferred until after the subsequent input that introduces the required product type into the system. The pseudo-code outlining the overall BR-DES algorithm is presented in Algorithm 1.