| SimEvents® | |
Troubleshooting a discrete-event simulation can be challenging because blocks that form an entity path operate in coupled ways. The block whose behavior surprises you might not be the source of a mistake. For example, after troubleshooting a surprising set of values in the #d output signal from a server, you might find that the problem is not in the server itself but rather in the configuration of a gate or switch block in another part of the model.
Some common problems relate to the simultaneity of events and the sequence in which the events are processed. When events occur simultaneously, it is because they have a causal relationship to each other or because their occurrence times happen to be equal or close enough.
This section describes some common problems. Specific symptoms and fixes are difficult to generalize, but this section offers examples or tips where feasible.
An unexpected simultaneity of events can result from roundoff error in event times or other floating-point quantities, and might cause the processing sequence to differ from your expectation about when each event should occur. Computers' use of floating-point arithmetic involves a finite set of numbers with finite precision. Events scheduled on the event calendar for times T and T+Δt are considered simultaneous if 0 ≤ Δt ≤ 128*eps*T, where eps is the floating-point relative accuracy in MATLAB software and T is the simulation time.
If you have a guess about which events' processing is suspect, then adjusting event priorities or using the Instantaneous Event Counting Scope block can help diagnose the problem. For examples involving event priorities, see Example: Choices of Values for Event Priorities and the Event Priorities demo. For an example using the Instantaneous Event Counting Scope block, see Example: Counting Events from Multiple Sources.
An unexpected lack of simultaneity can result from roundoff error in event times or other floating-point quantities. Computers' use of floating-point arithmetic involves a finite set of numbers with finite precision. Events scheduled on the event calendar for times T and T+Δt are considered simultaneous if 0 ≤ Δt ≤ 128*eps*T, where eps is the floating-point relative accuracy in MATLAB software and T is the simulation time.
If roundoff error is very small, then the event logging feature and scope blocks might not reveal enough precision to confirm whether events are simultaneous or only close. An alternative technique is to use the Discrete Event Signal to Workspace block to collect data in the MATLAB workspace.
If your model requires that certain events be simultaneous, then use modeling techniques aimed at effecting simultaneity. For an example, see Example: Choices of Values for Event Priorities.
An unexpected sequence for simultaneous events could result from the arbitrary or random handling of events having equal priorities, mentioned in Processing Sequence for Simultaneous Events. The sequence might even change when you run the simulation again. When the sequence is arbitrary, you should not make any assumptions about the sequence or its repeatability.
If you copy and paste blocks that have an event priority parameter, the parameter values do not change unless you manually change them.
An unexpected processing sequence for simultaneous block operations, including signal updates, could result from interleaving of block operations. For information and examples, see Interleaving of Block Operations.
The processing sequence for simultaneous events could have unexpected consequences in the simulation. To learn more about the processing sequence that occurs in your simulation, use the logging features described in Viewing the Event Calendar. To learn which events might be sensitive to priority, try perturbing the model by using different values of blocks' Resolve simultaneous signal updates according to event priority or Event priority parameters. Then run the simulation again and see if the behavior changes.
Time-based blocks have a slightly different definition of a trigger edge compared to event-based blocks. If you use event-based signals with Triggered Subsystem blocks or Stateflow blocks with trigger inputs, then the blocks might not run when you expect them to. For more information, suggestions, and an example, see Zero-Duration Values and Time-Based Blocks.
If you use a time-based block to process event-based signals, then the output signal might be a time-based signal. Depending on your model, you might notice that
The output signal assumes a new value at a later time than the event that caused the last update of the event-based signal.
The output signal assumes incorrect values.
An event-based block that uses the output signal, such as an Event-Based Entity Generator block, operates with incorrect timing.
You can avoid these problems by putting the time-based block in a discrete event subsystem, as described in Controlling Timing with Subsystems. If your time-based block is in a Function-Call Subsystem, then be sure to select Propagate execution context across subsystem boundary as described in Setting Up Function-Call Subsystems in SimEvents Models.
The model below (open model) adds the lengths of two queues. The queue lengths are event-based signals, while the Add block is a time-based block. It is important that the Add block use up-to-date values of its input signals each time the queue length changes and that the output signal's updates correspond to updates in one of the queue length signals.
If you build this model without having used simeventsstartup previously, or without using simeventsconfig later, then you might see the plot below. The incorrect timing is evident because the sum signal has updates at regular intervals that are smaller than the minimum intergeneration time of the entity generators.
If you correct the simulation parameters by using simeventsconfig on this model (with either the 'des' or 'hybrid' input argument), then the plot reveals correct update times but incorrect values. To check the values, you can connect the inputs and outputs of the Add block to separate Discrete Event Signal to Workspace blocks and examine the data in the MATLAB workspace.
A better model uses the discrete event subsystem illustrated in the Time-Driven and Event-Driven Addition demo.
During a discrete-event simulation, multiple events or signal updates can occur at a fixed value of the simulation clock. If these events and signal updates are not processed in the sequence that you expect, then you might notice that a computation or other operation uses a signal value from a previous time instead of from the current time. Some common situations occur when
A block defers the update of an output signal until a departing entity has finished advancing to a subsequent storage block, but an intermediate nonstorage block in the sequence uses that signal in a computation or to control an operation. Such deferral of updates applies to most SimEvents blocks that have both an entity output port and a signal output port.
For examples, see Example: Using a Signal or an Attribute and the Managing Race Conditions demo.
For details, see Interleaving of Block Operations.
For a technique you can use when the situation involves the Output Switch block's p input signal, see Using the Storage Option to Prevent Latency Problems.
An entity-departure subsystem updates its output signal after a block uses the value. A typical reason is that the block is responding to the arrival of an entity departing from the same block that generates the function call that calls the subsystem.
For an example showing how a Single Server block helps avoid this scenario, see Example: Using Entity-Based Timing for Choosing a Port.
A computation involving multiple signals is performed before all of the signals have been updated.
For details and an example, see Update Sequence for Output Signals.
A time-based block's use of a value of an event-based signal persists until the next time step of the time-based simulation clock, even if the block producing the event-based signal has already updated the value. In many cases, this is the correct behavior of the time-based block.
For an example, see Example: Plotting Entity Departures to Verify Timing.
If you need a time-based block to respond to events, consider using a discrete event subsystem as described in Controlling Timing with Subsystems.
If you want the application to advise you of some of these situations, use the configuration parameters related to race conditions. For details, see SimEvents Diagnostics Pane.
The goal in the next model (open model) is to use a service time of N seconds for the Nth entity. The Entity Counter block stores each entity's index, N, in an attribute. The top portion of the model uses the attribute directly to specify the service time, while the bottom portion creates a signal representing the attribute value and attempts to use the signal to specify the service time. These might appear to be equivalent approaches, but in fact only the top approach satisfies the goal.
The plot of the time in the bottom server block and a warning message in the Command Window both reveal a modeling error in the bottom portion of the model. The first entity's service time is 0, not 1, while the second entity's service time is 1, not 2. The discrepancy between entity index and service time occurs because the Get Attribute block processes the departure of the entity before the update of the signal at the A1 signal output port. That is, the server computes the service time for the newly arrived entity before the A1 signal reflects the index of that same entity. For more information about this phenomenon, see Interleaving of Block Operations.
The top portion of the model, where the server directly uses the attribute of each arriving entity, uses the expected service times. The phenomenon involving sequential processing of an entity departure and a signal update does not occur here because each entity carries its attributes with it.
Tip If your entity possesses an attribute containing a desired service time, switching criterion, timeout interval, or other quantity that a block can obtain from either an attribute or signal, it is usually better to use the attribute directly than to create a signal with the attribute's value and ensure that the signal is up-to-date when the entity arrives. |
When you create a loop in a signal connection, consider the effect of initial conditions. If you need to specify initial conditions for event-based signals, see Specifying Initial Values of Event-Based Signals.
The model below (open model) is problematic at T=0 because the initial reading of the t input signal representing the intergeneration time is 0. This signal does not assume a positive value until the first entity departs from the Read Timer block, which occurs after the first completion of service at T=1.
A better model (open model) would specify a nonzero initial condition for the w output signal from the Read Timer block.
In the model below (open model), the second server's #n signal has no updates before the first entity arrival there. As a result, the discrete event subsystem, whose role is to perform a NOT operation on the #n signal, does not execute before the first entity arrival at the server. However, no entity can arrive at the server until the gate opens. This logic causes entities to accumulate in the queue instead of advancing past the gate and to the servers.
A better model (open model) would define a positive initial condition for the en input signal to the gate.
The model below (open model) generates no entities because the logic is circular. The entity generator is waiting for a change in its input signal, but the server's output signal never changes until an entity arrives or departs at the server.
A better model (open model) would provide the first entity in a separate path. In the revised model below, the Time-Based Entity Generator block generates exactly one entity during the simulation, at T=0.
An entity path that forms a loop should contain a storage block. Storage blocks include queues and servers; for a list of storage blocks, see Storage and Nonstorage Blocks. The example below illustrates how the storage block can prevent a deadlock.
The model below (open model) contains a loop in the entity path from the Output Switch block to the Path Combiner block. The problem occurs when the switch selects the entity output port OUT2. The entity attempting to depart from the server looks for a subsequent storage block where it can reside, and it cannot reside in a routing block. Until the entity confirms that it can advance to a storage block, the entity cannot depart. However, until it departs, the server is not available to accept a new arrival. The result is a deadlock.
A better model (open model) would include a server with a service time of 0 in the looped entity path. This storage block provides a place for an entity to reside after it departs from the Output Switch block. After the service completion event is processed, the entity advances to the Path Combiner block and back to the Single Server block. Notice also that the looped entity path connects to the Path Combiner block's IN1 entity input port, not IN2. This ensures that entities on the looped path, not new entities from the queue, arrive back at the Single Server block.
When you use the Event-Based Random Number block to produce a random event-based signal, the block infers from a subsequent block the events upon which to generate a new random number from the distribution. The sequence of times at which the block generates a new random number depends on the port to which the block is connected and on events occurring in the simulation. To learn how to use this block, see Generating Random Signals.
The model below (open model) is incorrect because the Event-Based Random Number block cannot infer from the p input port of an Output Switch block when to generate a new random number. The Output Switch block is designed to listen for changes in its p input signal and respond when a change occurs; that is, the Output Switch cannot cause changes in the input signal value or tell the random number generator when to generate a new random number. The p input port of the Output Switch block is called a reactive port and it is not valid to connect a reactive signal input port to the Event-Based Random Number block.
If your goal is to generate a new random number corresponding to each entity that arrives at the switch, then a better model (open model) connects the Event-Based Random Number block to a Set Attribute block and sets the Output Switch block's Switching criterion parameter to From attribute. The random number generator then generates a new random number upon each entity arrival at the Set Attribute block. The connection of the Event-Based Random Number block to the A1 input port of the Set Attribute block is a supported connection because the A2 port is a notifying port. To learn more about reactive ports and notifying ports, see the reference page for the Event-Based Random Number block.
An unexpected correlation between random processes can result from nonunique initial seeds in different dialog boxes. If you copy and paste blocks that have an Initial seed or Seed parameter, the parameter values do not change unless you manually change them. Such blocks include:
Time-Based Entity Generator
Event-Based Random Number
Entity Splitter
Blocks in the Routing library
Uniform Random Number
Random Number
Masked subsystems that include any of the above blocks
To detect and correct some nonunique initial seeds, use a diagnostic setting as follows:
Open the Configuration Parameters dialog box for the model using Simulation > Configuration Parameters.
Navigate to the SimEvents Diagnostics pane of the dialog box.
Set Identical seeds for random number generators to warning.
When you run the simulation, the application checks for nonunique Initial seed parameter values in SimEvents library blocks. Upon detecting any, the application issues a warning message that includes instructions for solving the problem.
Exceptions You must monitor seed values manually if your model contains random-number-generating blocks that come from libraries other than the SimEvents libraries. To learn how to query and change seed values of such blocks, use the techniques illustrated in Working with Seeds Not in SimEvents Blocks. |
| Viewing Entity Locations | Recognizing Latency in Signal Updates | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |