SimEvents®

Interleaving of Block Operations

Overview of Interleaving of Block Operations

During the simulation of a SimEvents model, some sequences of block operations become interleaved when the application processes them. Interleaving can affect the simulation behavior. This section describes and illustrates interleaved block operations to help you understand the processing and make appropriate modeling choices.

Back to Top

How Interleaving of Block Operations Occurs

At all simulation times from an entity's generation to destruction, the entity resides in a block (or more than one block, if the entity advances from block to block at a given time instant). Blocks capable of holding an entity for a nonzero duration are called storage blocks. Blocks that permit an entity arrival but must output the entity at the same value of the simulation clock are called nonstorage blocks. During a simulation, whenever an entity departs from a block, the application processes enough queries, departures, arrivals, and other block operations until a subsequent storage block detects the entity's arrival. Some block operations, including the updates of statistical output signals that are intended to be updated after the entity's departure, are deferred until after a subsequent storage block detects the entity's arrival.

To change the sequence of block operations, you might need to insert storage blocks in key locations along entity paths in your model, as illustrated in Example: Sequence of Departures and Statistical Updates. A typical storage block to insert for this purpose is a server whose service time is 0.

Back to Top

Example: Sequence of Departures and Statistical Updates

Consider the sequence of operations in the Time-Based Entity Generator, Set Attribute, and Attribute Scope blocks shown below (open model).

At each time T = 1, 2, 3,..., 10, the application processes the following operations in the order listed:

The final operation of the Time-Based Entity Generator block is deliberately processed after operations of subsequent blocks in the entity path are processed. This explains why the plot shows a value of 0, not 1, at T=1.

Altering the Processing Sequence

If you want to be sure that the Set Attribute block reads the value at the A1 signal input port after the Time-Based Entity Generator block has updated its #d output signal, then insert a storage block between the two blocks. In this simple model , you can use a Single Server block with a Service time parameter of 0. The model, table, and plot are below (open model).

Consequences of Inserting a Storage Block

If the storage block you have inserted to alter the processing sequence holds the entity longer than you expect (beyond the zero-duration service time, for example), be aware that your simulation might change in other ways. You should consider the impact of either inserting or not inserting the storage block.

For example, suppose you add a gate block to the preceding example and view the average intergeneration time, w, of the entity generator block. When the gate is closed, a newly generated entity cannot advance immediately to the scope block. Whether this entity stays in the entity generator or a subsequent server block affects the w signal, as shown in the figures below.

Model with Gate and Without Storage Block

Open model.

When a storage block is present, the first pending entity stays there instead of in the entity generator. The earlier departure of the first entity from the entity generator increases the value of the w signal.

Model with Gate and Storage Block

Back to Top

Notifying, Monitoring, and Reactive Ports

Zero-Duration Values and Time-Based Blocks