Messages and Events

TANGRAM-II allows the description of general models (that is it is not tailored for a particular application). As such it is important to be aware of how TANGRAM-II handles messages and events to proper construct a model.

Messages are executed in zero time, so one issue is the order they are executed. TANGRAM-II executes the messages in the order they are generated by the actions. When an event triggers the event may send messages to other objects. The action associated to each message received may in turn generate more messages and the process continues until there is no more messages to be executed. When a message is processed during an action is included in a list of messages to be executed. After all messages in an action are processed the list of pending messages is searched, the action corresponding to the first message is executed and possibly new messages are added at the tail of the list.

When the simulation starts, samples for all the enabled events are generated and included in the event list in increasing order of time to trigger. (We recall that the value of the state variables changes only after the action is completely processed, including the execution of all messages associated with the action.) Whenever an event is enabled, a sample is generated. If more than one event is enabled after the execution of an action, then samples for them are generated and included in the event list. Assume that one of the enabled events triggers and the new state reached (after the execution of the action associated with the event) is such that all the other enabled events remain enabled. The TANGRAM-II simulator does not regenerate new samples for the events that remain enabled. The samples remain in the event list until either they trigger, or the associated event is disabled. In the last case the disabled events are removed from the event list.

To illustrate the process, consider an M/M/1/k queue. Assume that there are $n>1$ packets in queue when at time $t$ a packet departs from the server. A new customer enters service and a new sample for the departure event is generated, say to trigger at time $t_d > t$. Now assume a new customer arrives at $t < t_a < t_d$. The new state after the arrival is $n>1$ and so the departure event scheduled to trigger at $t_d$ remains in the event queue, and and no new sample for the departure event is generated.

Although the behavior above handles most situations, there are cases when the user needs to re-sample an event after an action is executed even if the event remains enabled in the new state. Although the current version of the simulator does not allow the user to automatically ask for re-sampling an event this can be easily accomplished as follows. Assume that two events $E_1$ and $E_2$ of object $O$ need to be re-sampled after any action is executed. Add a state variable Flush with gets only 2 values:0 and 1 (true or false). Then: (a) duplicate events $E_1$ and $E_2$ (name the ``new'' events as $E_1'$ and $E_2'$; (b) add a condition $Flush = 0$ for events $E_1$ and $E_2$ and $Flush = 1$ for events $E_1'$ and $E_2'$; (c) whenever an event triggers and the user wants to re-sample events $E_1$ and $E_2$, change the value of the $Flush$ state variable. Assume that $Flush = 0$ and $E_1$ and $E_2$ are enabled. If an event $E$ triggers and $Flush$ changes value, $E_1$ and $E_2$ are disabled even if the other conditions are enabled. Therefore, the samples for $E_1$ and $E_2$ are removed from the event list, and new samples are generated for $E_1'$ and $E_2'$, since they became enabled. Since all actions in $E_1'$ and $E_2'$ are identical to $E_1$ and $E_2$, what was accomplished with $Flush$ was simply to re-sample the events. An example will be given in the example section in example .

The user is encouraged to use the debug option in the config (ModelSpecific) menu and follow the execution of messages and events.

TANGRAM-II also offers the user the capability of generate several samples of an event after an action is executed. This is called event cloning, see §.