# Evolutionary Algorithms for Optimization Sequence of Cut in the Laser Cutting Path Problem
## 4 Overview of Application of ABRKGA to LCPP
### An Eulerian Heuristic to Generate Improved Individuals for LCPP
The space between items in the latter group enables the utilization of support, which is common in particular material cutting applications. We generated the dataset using the nesting approach outlined in [41], and for all tests, the laser machine parameters considered, \(V_{c}\) (cut) and \(V_{m}\) (air), were 16.67 mm/s and 400 mm/s, respectively. In [9], several hyperparameter settings have been tested for the GA and the BRKGA heuristics, executed ten times for each instance. The authors chose the best-performing configuration, which will be compared with our approach. In Table 3, we present the instances along with the corresponding number of vertices, the count of edges (for both the original and adapted layouts with the edge joints), and the number of polygons. We also tested ABRKGA with the value of \(\gamma\) presented in Table 2 and we have chosen to use a maximum (\(p_{max}=1000\)) and minimum (\(p_{min}=100\)), executing each instance ten times. Some instances present different vertices and edges due to applying the join procedure and split edges in the original input layout. It is necessary to highlight that joining segments are treated as particular cases of splitting edges. The algorithm of preprocessing input data, extracted by [6], converts the input file into a graph before addressing the LCPP. This conversion process can increase the number of edges of the original layout due to the realization of edge separation that occurs when a node of one figure touches the edge of another. For example, in Figure 6a) the \"end\" point separates edge 1 and edge 8. This procedure needs to occur to connect (C) groups of instances. \begin{table}
\begin{tabular}{l c c c c c c c c} \hline \hline \multirow{2}{*}{**Instance**} & \multicolumn{2}{c}{**Nodes**} & \multicolumn{4}{c}{**Edges**} & \multicolumn{2}{c}{**Polygons**} \\  & **(C)** & **(S)** & **(C)** & **(S)** & **(C)** & **(C)** & **(S)** & **(C)** & **(S)** \\ \hline albano & 156 & 164 & 164 & 164 & 173 & 164 & 24 & 24 \\ blaz1 & 39 & 44 & 44 & 44 & 46 & 44 & 7 & 7 \\ blaz2 & 70 & 80 & 88 & 80 & 89 & 80 & 14 & 13 \\ blaz3 & 97 & 132 & 132 & 132 & 130 & 132 & 21 & 21 \\ dighe1 & 20 & 54 & 46 & 54 & 38 & 54 & 15 & 15 \\ dighe2 & 20 & 46 & 38 & 46 & 30 & 46 & 10 & 10 \\ fu & 37 & 43 & 43 & 43 & 51 & 43 & 12 & 12 \\ inst\_10 pol & 20 & 40 & 39 & 40 & 29 & 40 & 10 & 10 \\ inst\_16 pol & 27 & 128 & 64 & 128 & 42 & 128 & 16 & 32 \\ inst\_2 pol & 7 & 8 & 8 & 8 & 8 & 8 & 2 & 2 \\ inst\_3 pol & 8 & 12 & 12 & 12 & 10 & 12 & 3 & 3 \\ inst\_4 pol & 10 & 16 & 16 & 16 & 13 & 16 & 4 & 4 \\ inst\_5 pol & 12 & 20 & 19 & 20 & 16 & 20 & 5 & 5 \\ inst\_6 pol & 13 & 24 & 23 & 24 & 18 & 24 & 6 & 6 \\ inst\_7 pol & 15 & 28 & 27 & 28 & 21 & 28 & 7 & 7 \\ inst\_8 pol & 16 & 32 & 31 & 32 & 23 & 32 & 8 & 8 \\ inst\_9 pol & 18 & 36 & 35 & 36 & 26 & 36 & 9 & 9 \\ inst\_26 pol & 210 & 264 & 264 & 264 & 237 & 264 & 66 & 66 \\ rcol & 33 & 36 & 36 & 36 & 40 & 36 & 7 & 7 \\ rco2 & 62 & 72 & 72 & 72 & 81 & 72 & 14 & 14 \\ roc3 & 82 & 108 & 108 & 108 & 116 & 108 & 21 & 21 \\ shapes2 & 68 & 70 & 70 & 70 & 78 & 70 & 8 & 8 \\ shapes4 & 127 & 140 & 140 & 140 & 147 & 140 & 16 & 16 \\ spfc & 55 & 55 & 55 & 55 & 63 & 55 & 11 & 11 \\ trousers & 350 & 388 & 388 & 388 & 424 & 388 & 64 & 64 \\ \hline \hline \end{tabular}
\end{table} 
Table 3: The properties of each instance were applied in our computational experiments. The table presents each instance’s number of nodes, edges, and polygons: (C) connected pieces and (S) separated. ### Results for the MIP Flow Model

In this subsection, we report the results obtained for the proposed MIP model. The model was implemented in JULIA 1.8.1 using JuMP library version 0.9, and the computational tests were carried out on a machine with a Linux Ubuntu 20.04 operational system, 16 GB of RAM, and an i7 processor with eight cores and 2.7 Hz speed. We set a time limit of 1 h (3600 s) for each instance. This value was adopted arbitrarily to establish a time control for the execution and validation of the model on the tests.