How to reduce time spent in the RU queue: An agent-based model of restaurational choices on campus
Nobody likes long waiting lines. This study examines three hypothesized causes for extended waiting lines in front of the RU (Restaurant Universitaire) and looked at 3 proposals that could be hypothesized to reduce time spent waiting for the students of HEC Paris at lunch on a weekday.
Instead of considering waiting lines as a mathematical issue as one would in queueing theory, we created with the agent-based modeling software NetLogo a model of the HEC campus around lunchtime on a weekday. We simulated the actions of between 1000 and 1500 bounded-rational students with heterogeneous traits and preferences.
To better visualize our findings, we built an interactive dashboard. Based on our simulations, it displays 1) a calculator of expected waiting time at the RU given a selection of parameters, and 2) an interactive boxplot. To access the online interactive dashboard, click here. It takes approximately 30 seconds for the platform to set up. Although we do not use simulation-based econometric techniques, clear trends emerge as our empirical findings of 600 simulations suggest the following:
To test our hypotheses, we used simulations of the HEC campus on a weekday with the software NetLogo, a program specialized in multi-agent systems or agent-based modelling.
In NetLogo, the world exists as a map of square patches (like pixels), in which agents can walk around and interact with the environment and other agents. In this model, we programmed the map and the interaction of students to be representative of the HEC campus, with 471.441 patches, where up to 1500 students can walk around.
Figure 1: Interface of the HEC agent-based model on NetLogo
In a simulation run, each student decides where to eat: either at home, at the RU, or at the food truck if one is present on campus, and then takes the quickest route towards the desired location, avoiding bumping into other students. This means that at bottlenecks (e.g., the main entrances of the T building), walking speed is affected by the presence of other students.
Significant heterogeneity exists among students, and therefore we allowed student characteristics to vary among multiple dimensions as depicted below:
Differences in choices of restauration: Does one prefer eating at the RU, at home, or at the food truck?
Varying degrees of patience: When confronted with a large waiting line for those desiring to eat at the RU. The probability that one stays in line when confronted with a large expected waiting time varies per individual.
Differences in preferred eating times: Certain students prefer to eat their lunch early in the day, whereas others will easily eat 30 minutes later.
Location at the start of the simulation: Some students have classes in the T building, whereas others are in their rooms.
To construct the model, we used external data in two main calibrations to render the model more realistic.
First, in order to build the environment of the campus, we used environmental data from Openstreetmaps on QGIS, as well as notes from on-location identification of informal walking paths (e.g., regularly used short-cuts on the grass).
Second, in order to calibrate both the preferences and the behavior of the agents, we used data resulting from a small survey run among certain HEC students. This calibration tackled student preferences, as well as student decision-making (e.g., which cues are used to decide to join the waiting line or go back to one’s room). The proportions resulting from this calibration can be found in the Appendix.
We ran the simulations on two computational devices. In order to reduce the need for additional computational resources, we wanted to limit the values that the parameters could take, and yet be able to identify clear trends if such exist. In a simulation, the 5 core parameters therefore take the following values:
Opening time: 11:10, 11:15, 11:20, 11:25 or 11:30
Presence of food truck: Yes or No
Number of students: 1000 or 1500
Number of classes in the T building: 10 or 20
Seconds between two students paying at the RU: 4, 5 or 6
We end up with 5*2*2*2*3 = 120 parameter sets, which we each run 5 times with different seeds, yielding a total of 600 simulations.
Graph 1: Summary of the average spent in line in front of the RU across 600 simulations (each dot is a single simulation)
Changing the opening hours of the RU
First, we tackle the effect of changing the RU’s opening hours. The interpretation of this parameter is straightforward: what is the effect of changing the opening hours of the RU on the average waiting time of students who will eat at the RU, given that the time at which classes end remains unchanged?
Unsurprisingly, the majority of variance of the average waiting times across simulations is explained by changes in the opening hours, as changes of this parameter account for
83% of total variance observed across simulations. More specifically, we found that increasing the opening time by 5 minutes increases the average waiting time by 190 seconds. We also found that this effect is somewhat exponential: Extending the opening time from 11:10 to 11:15 increases waiting time by 140 seconds, whilst increasing it from 11:25 to 11:30 increases waiting time by 243 seconds.
Changing the number of classes taking place at the T building
Second, we looked at whether changing the number of classes physically taking place inside the T building had any effect. As we expected this variable to have little effects, we ran only two values for this parameter: either 10 or 20 classes.
Although we found a statistically significant effect, the actual effect is relatively small, affecting waiting times by less than 2 seconds for an additional class at the T building. This is consistent with what we expected, as this effect is mainly a translation of the formation of waiting lines at the exits of the T building. We have identified these exits to be bottlenecks if too many students seek to exit at the same time.
Changing the speed at which students can pay at the RU
Finally, we considered the speed at which students can pay at the RU.
In our model, we ran simulations in which the variable “flowruinseconds” (i.e., the number of seconds between completion of payment at the cashier of two students standing in the queue) took the values 4, 5, or 6 seconds. Indirectly, this parameter tackles changes to the number of cash registers, or even the introduction of faster methods of payments, but does not deliver evidence of the possible effectiveness of a specific solution.
Assuming that the payment at the cashier forms the bottleneck inside the RU, we found that decreasing the “flowruinseconds” by one second decreases the average waiting time by 114 seconds, or nearly two minutes. Changes in this parameter explain 9.89% of the variance observed across simulations.
Visualizing our Results: Interactive Dashboard
Data Minds is a Data Science association, so we aim to use data science techniques to both build our model and visualize our results. An example of this is Graph 1 shown above, which is a combination of a factor plot and a swarmplot, and was created using the seaborn python visualization library.
In order to better visualize our findings, we have created an interactive dashboard with the Python libraries Voilà and ipywidgets (for layout and interactive gadgets). The dashboard contains (1) an interactive boxplot created using plotly, which allows the user to choose the different input variables of the model and see the distribution of the waiting times, and (2) a display of the average waiting time given a set of values of the input variables to the model that can be selected by the user. The average waiting time is obtained from a random forest regressor model trained with the data obtained from our simulations.
This dashboard is deployed using the cloud platform Heroku, and can be accessed freely with a computer. To access the interactive dashboard, click here. It takes approximately 30 seconds for the platform to set up. If it is not working, try to close your browser and restart.
We used the software NetLogo to develop a multi-agent model intending to mimic the dynamics on the HEC campus on a weekday at lunchtime. Our results are that:
We found that increasing the opening time by 5 minutes increases the average waiting times by 190 seconds. This is most likely due to the fact that we calibrated the model on the survey results, which found queues for expected waiting time had an influence on very few students.
We found that changing the number of classes taking place at the T building has a minimal effect on average waiting times. As mentioned before, we expected this to happen as the formation of long queues at the bottlenecks at the exits of the T building is a rare event.
We found that decreasing the average payment-time at the cashier of two students standing in the RU queue by one second decreases the average waiting time by 114 seconds, or nearly two minutes, a quite sizable effect. This shows possible gains on waiting time realized by increasing the speed of payment at the cash registers inside the RU.
Should you exhibit further interest in this article’s model and analysis, please find further information in the Appendix and in the NetLogo code description.
We hereby emphasize that we do not claim that this study was a scientific attempt at estimating precisely the outcome of policy changes, but rather the development of an approach to studying waiting lines in the HEC context that we saw fit as a HEC Data Minds study.
Since we desired a shorter format for this article than we originally intended, we cut out what could be perceived as tedious descriptions of the model. Appendix 1 and 2 concern the NetLogo model, Appendix 3, 4 and 5 concern the analysis.
Appendix 1: The proportions of restauration choices
Appendix 2: Additional information on building the model and running the simulations
As students can only walk on campus on “walkable paths” (excluding buildings and the pond for example), the model has to determine for each patch how many realistic “steps” it is away from every location that a student may want to reach. Each patch therefore has a vector of values, representing the steps it is away from all these buildings.
To import the outline of the buildings on campus from Openworldmap, we imported 5 separate shapefiles created with the software QGIS.
The NetLogo model required calculating distances of 471.441 patches from all residential buildings on campus, as well as from the RU and the food truck. Performing these calculations took 2 hours, despite the optimized Java and Scala code of the NetLogo software. We, therefore, saved the resulting vectors of each patch and saved it to a CSV file that we import and use to reallocate the vectors in the setup of every simulation. This procedure takes roughly one minute.
Appendix 3: Additional considerations for the analysis of effects
Another aspect that we did not study in-depth is the effect of the total number of students present on campus. Since students decide to join the queue based on a given preference for smaller queues*, changes in slope as can be seen in Graph 1 in the Results section are small. However, as we did not consider a campus with more than 1500 students, it is possible that this effect would be more noteworthy in a model with a larger number of students.
* The probability that the student decides to join the queue is based on a distribution with mean 50 that can be found in the code of the model.
Appendix 4: Stata output of the analysis of the effects considered parameters on the mean waiting time
This was run in Stata. The variable “mean_wating_s” is the average waiting time of students in a given simulation after adjustment to transform the unit into seconds.
Appendix 5: Limitations of the study
There are, of course, multiple limitations to the approach adopted in this study.
First of all, we draw conclusions from simulations, which inherently means that it is not a perfect reflection of reality. Furthermore, the absolute perfect independence of the parameters from one another is not realistic.
Second, we did not use simulation-specific econometric techniques that could have been better suited to draw conclusions from the simulated output.
Third, we relied on a small-scale survey, which implies that calibration could be different if we had relied on a more representative sample of the HEC population, and we did not consider truncation when running the regressions.
Fourth, we did not look at potential interactions between the considered parameters, as we did not expect them to exist.
Finally, to limit our need for extensive computational resources, we only took 2 to 5 values for the studied parameters, and therefore we cannot extrapolate the dynamics of the model in simulations in which the parameters take values outside the range that we chose.