 Welcome to my lecture on managing time in a simulation. You recall, time is one of the major elements that distinguishes discrete event simulation models from other kinds of models and other kinds of simulation models. In discrete event simulations, we have randomness as part of the simulation model. We've got time, which we're doing now, and we have issues related to the collection of output data because these are models that move over time. There are two basic ways of moving time in a simulation program. The simplest one, the first blush one, let's say, is the one they fixed time advanced method where we have a simulation moving over time. We have a simulation clock. Maybe the units are minutes, right? So we have a loop in our program that advances the clock one minute, looks around and says, is anything new happening? Did anything new happen between now and last minute? Did a new customer come into the system? Did anything change? Did a server go off duty? And if the answer is yes, you take care of it. If the answer is no, you increment again, and now you're another minute later. So we moved, let's say, from three minutes to four minutes to five minutes. And you keep on looking around to see what has to be done now that you've advanced the clock one minute. This has issues, clearly, mainly because there could be a lot of iterations, a lot of iterations traveling around this loop when nothing happens. So it kind of seems like a waste of time. And why don't we just look at the next thing that's supposed to happen because we know that events preschedule other events, right? Why don't we look for the next thing that's supposed to happen and just advance the simulation clock to that? And that's exactly what the next method, the variable time method, does. Clearly, most simulation models are going to be using this variable time method, the next event time advanced method to moving time. As long as you have one event in your system, all the other events can be booted up. So the clock will simply jump ahead to whatever the next event is that's supposed to occur. Of course, this means we have to keep track of events that are going to occur, and we have to keep track of them in order by time to occur. I guess we don't have to. It could do a search, but that's a waste. We might as well store these things in the first place in a particular order, in time order. How is all of this done? All of this is managed by something called the timing routine. Which is separate from, let's say, an arrival event routine where an arrival event routine might be done by the simulationist. What happens when a new entity arrives in the system, right? The timing routine is more likely to be done by whoever developed the software tool, assuming that it's a specialized simulation software tool. If this is a simulation in a general purpose language, that timing routine might be part of the library. We don't want to reinvent the wheel. We want to be able to build on what other people have done. This is to remind you of something you already learned in the lecture called simulation programming. We just selected some of the terminology that applies to time advance. We know what an event is. An event is the point in time when something happens to change the state of the system. The clock is the simulation clock, and it's a variable that includes the simulated time whenever we want to look at the system. One of the state variables is going to be time. What time is it right now? The event notice is a ticket. It's in programming terminology. It might be a record where you've got everything that you need in order to take care of that event. What's in the event notice? The type of event, maybe the ID internally to the event. What customer are we talking about? At the very least, they have to have those two items. Finally, the event list is a way we store these events. If we're talking about future events, because we're interested in the timing routine right now, there's something called the future events list, FEL. The event notices for events that have not yet occurred but have been pre-scheduled are stored on that list while the simulation is running in order of time to occur. Once they're stored in the right place, in the right order, all the timing routine has to do is take the first one off the list and say, okay, I'll move time up now to whatever the time is on this event notice, and that's the next time advance method. We're going to take a couple of minutes here and look under the hood. Not everyone is interested in this, I know. Not everyone is a programmer. Not everyone wants to know. When you drive a car, if something's wrong, you may not want to look under the hood. You may want to just go find the nearest gas station or service facility. But we'll take a quick look and see what the timing routine does and how the timing routine works. If you look at the flow chart coming in, it's coming in from the beginning of the program. It's left open just in case some housekeeping has to be done at the beginning of the program. The first thing you see is that the statistics we're collecting have to be initialized and two events are scheduled. So before even getting into the timing routine, two events are scheduled. When is the first arrival and when is the closing? When does the simulation start and when does the simulation end? Okay, now that A is going to be important on the next slide. Basically, once we've finished everything we can see and we have nothing left to do, there are no events that are in process that we have to work on. We come back here and say, okay, when's the next time something will happen? Any events remaining? Either that's a yes or a no. If there are no events remaining, it's presumably because it was end of day. The closing has appeared because at the closing we remove any events that might otherwise be waiting to happen. If you close the door, you're not taking in any new arrivals, even if one was pre-scheduled. So if there are no remaining events, the event list is empty. That's the end of the program. We go and collect our statistics. We report our statistics. If there are events remaining, if that's a yes, okay, let's get the next event off the list. And it's going to be the next event to occur. We look at it. We say, what kind of event is it? And let's move on to the next slide. So we're looking at this event that was just taken off the front of the list. We're saying, what kind of event is it? If it's a typical very small queuing simulation, it might either be an arrival event or it might be an end of service event. It could also be the closing event, remember, that was scheduled at the beginning before anything else happened. But we can ignore that pretty much. If it's an arrival event, you think about it, what happens when a customer arrives in a queuing simulation or in a queuing system? What happens? Either the customer is going to get into the service or the customer is going to get into the queue. If you're keeping track of the number of customers in the system, there should also be a flowchart element there that says, increment the number of entities, the number of customers in the system. And you may even need to keep that customer's arrival time so that when that customer is finished, you can compute time and system. But we're not worried about things like that right now because that's programmed inside the actual arrival routine. And we're really more interested right now in how the timing routine works, not in the details of what happens at each type of event. But in a macro level, on a larger level, yes, if we have an arrival, the arrival wants to know, can I go into service right away? Yes or no? If yes, we can schedule end of service for this customer and decrease the number of idle tellers. If there's only one, then the number of idle tellers is zero. On the other side, if the teller is not free, the customer has to be put into a queue at the back of the line if we're using a LIFO queue, rather a FIFO queue, first in, first out. And then when the queue is to move, when the teller is free, the person at the front of the queue will be taken into service. But before we finish with the arrivals, we have to schedule the next arrival. Because the only way we know that a next arrival can be scheduled at a certain time is by the fact that we have an arrival right now and we can generate a value from the inter-arrival time distribution. On the other hand, what kind of event, if it's an end of service, well, again, this is a discrete event simulation. What happens at this event when a customer finishes service, leaves the system? We can calculate time and system then, assuming we kept track of arrival. The customer member that has entities have attributes, so a customer would have an arrival time. And then we would ask, well, wait, maybe now that the customer went out of service, either the clerk is now going to be idle or another customer can go into service. So that's what that next bit is about. Is the queue empty? Okay, if it is, increment the number of idle tellers. If the queue is not empty, then we have to take the first person from the front of the queue, put them into service, schedule an end of service and calculate the time that that person has waited in the queue has been delayed without being served. In either case, if we've just had an arrival event or an end of service event, we want to go back to point A where we're advancing time because there's nothing else left to do. There are no more choices. Of course, if the event was a closing event, then we have to take care of some housekeeping bits that are related to the end of the simulation. This very brief lecture looked only at the aspect of a simulation model implementation that has to do with managing time. The read event simulations move over time. How is it done? We took a brief look under the hood to see what happens in the timing routine that must be built into any specialized simulation software tool. Thank you for joining this lecture.