# Parallel Agent-Based Framework for Analyzing Urban Agricultural Supply Chains
## 5 Parallel Simulation  
In this work, we parallelize our proposed simulation model using an approximate optimistic approach [7]. We partition the simulation model into \(N\) logical processes (LPs), where each LP maintains a subset of entities that interact with one another. When we parallelize the proposed simulation model, a balance problem arises. Note that the communication patterns among farmers, fairground workers, and consumers may vary depending on the products and the season. Certain fruits and vegetables are harvested at specific times of the year. In addition, not all fruits and vegetables are available year-round, and some products are more frequently consumed during hot seasons and others during cold seasons. Therefore, the communication pattern between farmers, FW, and consumers is not uniform and changes throughout the year depending on the season. To address this problem, we use an optimistic approximate parallel simulation approach based on the _Bulk Synchronous Parallel_ (_BSP_) model. In the optimistic approximate approach, precision in the results is sacrificed by ignoring the occurrence of straggler events, allowing the simulation to continue advancing while improving execution time and memory usage. In this approach, the error in the results is highly dependent on the simulation model and is controlled through mechanisms that prevent the LPs distributed across processors from advancing too far in simulation time [7]. This approach uses a time window (\(W\)), which delimits the simulation time advance in each iteration. Each \(LP\) processes and generates events autonomously until reaching the end of the time window. If, during this period, an event targeting an agent assigned to another \(LP\) arises, an outgoing message is queued to be dispatched to the destination LP. At the end of each iteration, processors are synchronized and messages are sent. Algorithm 1 illustrates the approximate parallel simulation protocol. The input parameters are: (1) the time increment per iteration, \(W\); (2) the parameter \(K\), which determines how frequently the global virtual time (GVT) is updated; (3) the future event list (\(FE\)); (4) the total simulation time \(T_{max}\); and (5) additional configuration parameters such as the number of Logical Processes (LPs), number of processors, etc., grouped under \(InputParams\). The global virtual time (GVT) is computed periodically every \(K\) iterations to determine whether all LPs have reached the simulation horizon \(T_{max}\). The future event list (FEL) maintains all pending events, sorted by their times (\(e.time\)), which indicates when each event should be executed. In line 4, we initialize the next time window as \(W_{next}=W\), meaning that during the first iteration, all events with times \(\leq W\) will be processed. In line 5, the main loop begins and continues either until the simulation time reaches \(T_{max}\) or the FEL becomes empty (i.e., there are no more events to process). In line 6, the algorithm  
Figure 7: Price variation over time (blue line), estimated prices (dotted red line), and their corresponding variance. checks whether the local virtual time (LVT) falls within the current time window (\(W_{next}\)). If so, it retrieves the next event \(e\) from the FEL. In line 8, the algorithm updates the local virtual time of the LP, computed as the current value plus the execution time of the event. In other words, it advances the LP's clock. In line 9, if the event is local, it is executed. Otherwise, it is forwarded to the corresponding LP. In line 11, the time window is incremented in preparation for the next iteration. Then, in line 12, all outgoing messages are sent. In line 13, a synchronization ensures consistency among LPs, and in line 14, incoming messages are received. The GVT is updated every \(K\) iterations, calculated as the minimum LVT across all LPs. In line 11, the time window is updated for the next iteration. Then, in line 12, the messages are sent, and finally, in line 13, synchronization occurs.