I’m developing a clock class for my discrete event simulation. I already have events being held in a PriorityQueue and thus sorted according to which event has the nearest event time. However there’s one thing I can’t get my head around. In the papers about Discrete Event Simulation that I’ve read, it’s clearly stated that the clock jumps from events to events and therefore it is not necessary to have a clock which “ticks”.
But how would this work, I have an EventScheduler class which holds the events in the PriorityQueue. So after it figures out when this next event is, could I just invoke a “setTime” method in the Clock which the EventScheduler invokes with the given time of the next event? But then It would never really run as a clock it would just keep jumping to the next event ?
I was thinking that the clock runs (ticks) and then it knows when an event will occur from the EventScheduler and when the clock reaches that time, it processes the events , updates the system state and perhaps generates an output event.
Sorry for being a bit unclear but I’m just interested in any tips on how the clock works, does it tick and then only “do” stuff when an event occurs or does it just jump from events to events?
Also is there any built in functionality in java that you suggest I could use for this? E.g. Timer class
The idea is that nothing happens without going into your event queue. Think about it: what is you clock doing during a time when it “ticks”, but there are no events? Nothing. So why process those times at all?
So yes, you just go from event to event in the queue. Really, the “clock” in a discrete event is pretty much exactly what you’ve built: a priority queue sorted in “chronological” order and some sense of “now” that is the position in the queue.
If you pop off the head queue, then “now” could just be the head of the queue, and you’re done. Often times more sophisticated models may have further features, such as the ability to detect when events are attempted to be scheduled before “now” – this is, for instance, indicative of a model that is responding too slowly: in the real world, it would always be “late” and catching up to what’s going on in the simulation as a whole.
If you have e.g. a model that requires updating every second, then you have to put those events in the queue, or they don’t happen. Frequently, for problems that fit the discrete event simulation model well (in my career, this has been physics-based modeling), this is not a problem: your models usually “idle” when there are no events, and can have their state calculated at any particular time in the future when no events change their state.
If this is not true of your models, then perhaps discrete event modeling is not really a good fit for your problem domain.