Event Delay Elements

Event Delay elements provide a mechanism for delaying a discrete event signal. Once an Event Delay receives a discrete event signal, it holds it for a specified time period, and then emits it.

You first specify when the element is to be triggered via the Trigger… button in the Event Delay dialog. The Trigger… button provides access to a standard Trigger dialog.

Each time the element is triggered, it waits for a specified time, and then emits a discrete event signal.

The delay time is computed based on a specified Delay Type. There are four types:

The last three options allow the delay time to have a specified dispersion. That is, they allow you to simulate variability in when a signal is emitted once the element is triggered. This is equivalent to saying that there is a distribution of actual delay times around some mean, and whenever the element is triggered, the delay time for that event is sampled from a distribution.

The first three options require a specified Delay Time (or a Mean Time if dispersion is specified). The Delay Time, and Mean Time must have dimensions of time and generally should be positive.

The fourth option requires a Stochastic that represents a distribution of Delay Times. The Stochastic element that is specified represents the distribution of the delay time. As such, it must have dimensions of time. The Distribution output of the Stochastic must be referenced:

Note: If the specified delay time is equal to zero, the event is emitted immediately (i.e., on the same update) without any delay. A negative delay time will result in a fatal error.

Note: The Use conveyer-belt approach box only impacts the behavior of the Delay if the delay time changes with time.

You can optionally specify that an Event Delay requires one or more Resources in order to process the signal.

Event Delay elements have the ability to influence when a model is updated. Typically, a model is updated at every “scheduled” timestep. That is, all the elements are computed at every timestep. However, an Event Delay can force a model to be updated between “scheduled” timesteps.

For example, suppose that you have specified a 10 day timestep. If an Event Delay receives a signal at 20 days, and has a 3 day delay time, GoldSim will insert an update (an “internal” event) between timesteps (i.e., at 23 days) in order to more accurately represent the event.

Warning: Event Delays are designed to interrupt the clock and insert a new update when the event is released. If you choose to disable unscheduled updates, the event in the Delay will be deferred to the next scheduled update (and hence the actual Delay Time will be longer than specified).

2. the cumulative number of discrete signals emitted (released) by the Delay (EventCount);

3. the number of discrete signals currently in transit within the Delay (Num_in_Transit);

4. the number of discrete signals currently in the queue (Num_in_Queue), which is only present if a capacity or a Resource Requirement is specified;

6. the current service time (Current_Service_Time). This represents the expected time it will take a new item (event) to transit the system. If there is no queue (no capacity or Resource requirements specified), or if no events have transited the system, then the current service time is simply reported as -1 (indicating no data). If there is a queue and at least one event has transited the system, the current service time is approximated as the time it took the most recent item to transit the system.

Note that the discrete event signal output itself cannot be saved or viewed as a result.

The example model EventDelay.gsm in the General Examples/Events folder of your GoldSim directory (accessed by selecting File | Open Example... from the main menu) contains an example of the use of Event Delay elements.