|
|
|
| R2012a Documentation → SimEvents | |
Learn more about SimEvents |
|
| Contents | Index |
| On this page… |
|---|
You can merge multiple paths into a single path using the Path Combiner block. Merging entity paths does not change the entities themselves, just as merging lanes on a road does not change the vehicles that travel on it. In particular, the Path Combiner block does not create aggregates or batches.
Here are some scenarios in which you might combine entity paths:
Attaching different data: Multiple entity generator blocks create entities having different values for a particular attribute. The entities then follow a merged path but might be treated differently later based on their individual attribute values.
Merging queues: Multiple queues merge into a single queue. (You might also use an Input Switch block for this, depending on the desired sequencing of entities in the single queue.)
Connecting a feedback path: A feedback path enters the same queue as an ordinary path.
The Path Combiner block does not experience any collisions, even if multiple entities attempt to arrive at the same time. The categories of behavior are as follows:
If the entity output port is not blocked when the entities attempt to arrive, then the sequence of arrivals depends on the sequence of departure events from blocks that precede the Path Combiner block. For example, the section Connecting Multiple Queues to the Output Switch describes a dependence on generation event priority values in the "No blockage" case.
Even if the departure time is the same for multiple entities, the sequence might affect the system's behavior. For example, if the entities advance to a queue, the departure sequence determines their positions in the queue.
If pending entities are waiting to advance to the Path Combiner block when its entity output port changes from blocked to unblocked, then the entity input ports are notified of the change sequentially. The change from blocked to unblocked means that an entity can advance to the Path Combiner block.
If at least two entities are waiting to advance to the Path Combiner block via distinct entity input ports, then the notification sequence is important because the first port to be notified of the change is the first to advance an entity to the Path Combiner block. The Input port precedence parameter determines which of the block's entity input ports is first in the notification sequence. For the list of options, see the online reference page for the Path Combiner block.
Consider the sequence of blocks in the figure below, in which a Path Combiner block merges three small queues into a single large queue.
Suppose the server is busy serving an entity, the single large queue (FIFO Queue4) is full, and each of the three small queues is nonempty. In this situation, the Path Combiner block's entity output port is blocked. When the entity in the server departs, an entity from the large queue advances to the server. The large queue is no longer full, so its entity input port becomes available. As a result, the Path Combiner block's entity output port changes from blocked to unblocked. The Path Combiner block uses the Input port precedence parameter to determine the sequence by which to notify entity input ports of the change. The sequence of notifications determines which of the three small queues is the first to advance an entity to the large queue via the Path Combiner block.
The Input port precedence parameter is relevant only when the entity output port changes from blocked to unblocked; the parameter is irrelevant in other situations. For example, if the large queue has infinite capacity, or if at most one of the three small queues is nonempty at any given time during the entire simulation, then all settings for the Input port precedence produce the same behavior.
The Input Switch block, described in Input Switching to Select an Arrival Path, has multiple entity input ports and one entity output ports. The same is true for the Path Combiner block. These two blocks differ in that
The Path Combiner block's acceptance of an entity arrival does not depend on which port the entity arrives at. By contrast, the Input Switch block accepts only those entities that arrive at the block's selected entity input port.
The Path Combiner block's Input port precedence parameter is relevant only in the specific situation described in Input Port Precedence. By contrast, the Input Switch block's Switching criterion parameter governs the block's behavior throughout the simulation.
When deciding whether to use a Path Combiner or Input Switch block in your model, consider how you want the simulation to behave when one source of entities is dormant for a long time but another source of entities is not. If you want the routing block to wait until an entity finally departs from the dormant source, then an Input Switch block would be more appropriate. If you want the routing block to accept arrivals from other entity sources that are not dormant, then a Path Combiner block would be more appropriate.
 | Input Switching to Select an Arrival Path | Example: A Packet Switch |  |
Learn how you can use SimEvents discrete-event simulation capabilities through these technical resources.
Get free kit| © 1984-2012- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |