The Release Gate block opens instantaneously at a discrete set of times during the simulation and is closed at all other times. The gate opens when a signal-based event or a function call occurs. By definition, the gate's opening permits one pending entity to arrive if able to advance immediately to the next block. No simulation time passes between the opening and subsequent closing of the gate; that is, the gate opens and then closes in the same time instant. If no entity is already pending when the gate opens, then the gate closes without processing any entities. It is possible for the gate to open multiple times in a fixed time instant, if multiple gate-opening events occur in that time instant.
An entity passing through a gate must already be pending before the gate-opening event occurs. Suppose a Release Gate block follows a Single Server block and a gate-opening event is scheduled simultaneously with a service completion event. If the gate-opening event is processed first, then the gate opens and closes before the entity completes its service, so the entity does not pass through the gate at that time instant. If the service completion is processed first, then the entity is already pending before the gate-opening event is processed, so the entity passes through the gate at that time instant. To learn more about the processing sequence for simultaneous events, see Event Sequencing.
In the example below (open modelmodel),
a Release Gate block with an input signal from a Pulse
Generator block ensures that entities begin their service
only at fixed time steps of 1 second, even though the entities arrive
asynchronously. In this example, the Release Gate block
has Open gate upon set to
in signal from port vc and Type of change
in signal value set to
while the Pulse Generator block has Period set
1. (Alternatively, you could set Open
gate upon to
Trigger from port tr and Trigger
The plots below show that the entity generation times can be noninteger values, but the service beginning times are always integers.
In the model below, two queue-server pairs operate in parallel
and an entity departs from the top queue only in response to a departure
from the bottom queue. In particular, departures from the bottom queue
block cause the Entity Departure Function-Call Generatort block
to issue a function call, which in turn causes the gate to open. The Release
Gate block in this model has the Open gate upon parameter
Function call from port fcn.
If the top queue in the model is empty when the bottom queue has a departure, then the gate opens but no entity arrives there.
When configuring a gate to open based on entity departures, be sure the logic matches your intentions. For example, when looking at the model shown above, you might assume that entities advance through the queue-server pairs during the simulation. However, if the Output Switch block is configured to select the first entity output port that is not blocked, and if the top queue has a large capacity relative to the number of entities generated during the simulation duration, then you might find that all entities advance to the top queue, not the bottom queue. As a result, no entities depart from the bottom queue and the gate never opens to permit entities to depart from the top queue. By contrast, if the Output Switch block is configured to select randomly between the two entity output ports, then it is likely that some entities reach the servers as expected.
An alternative to opening the gate upon departures from the
bottom queue is to open the gate upon changes in the value of the #d signal
output from that queue block. The #d signal represents
the number of entities that have departed from that block, so changes
in the value are equivalent to entity departures. To implement this
approach, set the Release Gate block's Open
gate upon parameter to
Change in signal from
port vc and connect the vc port
to the queue block's #d output signal.