| SimEvents® | |
| On this page… |
|---|
Attribute output delayed relative to entities Response to function call delayed relative to entities Statistical output delayed relative to entities |
Specify what diagnostic action the application should take, if any, when it detects situations that might cause problems or unexpected results in the simulation.
This pane appears only if your model contains a SimEvents® block.
The options are typically to do nothing or to display a warning or an error message.
A warning does not terminate a simulation, but an error does.
Select the diagnostic action to take if the application detects a situation in which a Get Attribute block updates a signal during entity advancement, but a subsequent block responds to the signal update after the entity has arrived. The event-processing sequence might cause the latter block to process the entity using outdated signal values.
Default: warning
The application does not check for this situation.
When the application detects this situation, it displays a warning.
When the application detects this situation, it terminates the simulation and displays an error message.
A Single Server block whose Service time parameter is 0 can address the problem by storing the entity while the latter block responds to the signal update.
Example of Solution
For details, see Using Block Diagrams to Manipulate Attributes.
| Parameter: propDiagAttribOutput |
| Type: double |
| Value: 0 | 1 | 2 |
| Default: 1 |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Efficiency | none |
Select the diagnostic action to take if the application detects a situation in which a block issues a function call during entity advancement, but subsequent blocks respond to the function call and its consequences after the entity has arrived. The event-processing sequence might cause subsequent blocks to process the entity using outdated values of a signal whose update is a consequence of the function call.
Default: warning
The application does not check for this situation.
When the application detects this situation, it displays a warning.
When the application detects this situation, it terminates the simulation and displays an error message.
A Single Server block whose Service time parameter is 0 can address the problem by storing the entity while subsequent blocks respond to the function call and its consequences.
Example of Solution
For details, see Example: Using Entity-Based Timing for Choosing a Port.
| Parameter: propDiagFcnCallOutput |
| Type: double |
| Value: 0 | 1 | 2 |
| Default: 1 |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Efficiency | none |
Unexpected Use of Old Value of Signal
Select the diagnostic action to take if the application detects a situation in which a block updates a statistical output signal during entity advancement, but a subsequent block responds to the signal update after the entity has arrived. The event-processing sequence might cause the latter block to process the entity using outdated signal values.
Default: warning
The application does not check for this situation.
When the application detects this situation, it displays a warning.
When the application detects this situation, it terminates the simulation and displays an error message.
A Single Server block whose Service time parameter is 0 can address the problem by storing the entity while the latter block responds to the signal update.
Example of Solution
For details, see Example: Sequence of Departures and Statistical Updates.
| Parameter: propDiagStatOutput |
| Type: double |
| Value: 0 | 1 | 2 |
| Default: 0 |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Efficiency | none |
Unexpected Use of Old Value of Signal
Select the diagnostic action to take if the application detects certain situations in which a block modifies an attribute that a subsequent block uses to determine its availability. In some of these cases, internal queries among blocks might result in a decision based on information that changes when the entity actually advances.
Default: warning
The application does not check for this situation.
When the application detects this situation, it displays a warning.
When the application detects this situation, it terminates the simulation and displays an error message.
A Single Server block whose Service time parameter is 0 can address the problem by storing the entity while the latter block responds to the signal update.
Example of Solution
The model is similar to the one in Example: Using Entity-Based Timing for Choosing a Port, but performs switching based on an attribute rather than a signal value.
| Parameter: propDiagChangeAttrib |
| Type: double |
| Value: 0 | 1 | 2 |
| Default: 2 |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Efficiency | none |
Querying Whether a Subsequent Block Can Accept an Entity
Select the diagnostic action to take if the application detects that multiple random number generators use the same seed value, which might cause correlations among random processes.
Default: warning
The application does not check for this situation.
When the application detects this situation, it displays a warning.
When the application detects this situation, it terminates the simulation and displays an error message.
If you set the parameter to warning, the warning message contains hyperlinks labeled "Randomize" and "Randomize All" that can help you address the problem.
The se_randomizeseeds function provides a programmatic way to address the problem.
Set the parameter to none if duplicate seeds are intentional in your model. For example, the Comparison of Routing Policies demo implements the same random arrival process multiple times, to compare routing policies.
| Parameter: propRNGIdenticalSeeds |
| Type: double |
| Value: 0 | 1 | 2 |
| Default: 1 |
| Application | Setting |
|---|---|
| Debugging | warning or error |
| Efficiency | none |
| SimEvents® Pane | Glossary | |
| © 1984-2008- The MathWorks, Inc. - Site Help - Patents - Trademarks - Privacy Policy - Preventing Piracy - RSS |