gpss_manual

Chapter 13 -

Troubleshooting

The first part of this chapter discusses techniques that may be helpful in isolating an correcting problems that may occur. The second major section lists the error messages that may be displayed and what to do about them.

13.1. Problems Operating

GPSS World

Help Problems

If you get a "Help Not Available" Message for a particular topic, please email the code to problems@minutemansoftware.com so that the problem can be corrected.

Performance Problems

Performance problems and tips are discussed in Chapter 10 of this manual.

Memory Problems

Since each GPSS World process utilizes up to a gigabyte of virtual memory, an over commitment of memory usually reveals itself in high disk activity. This is easily remedied by the addition of more physical memory in your computer.

To screen for programming errors, GPSS World enforces an arbitrary limit on the size of memory requests. You can change this value in the Simulate Page of the Model Settings. The default is 500,000 bytes.

If you move or resize a Plot Window, you may see only partial curves on the plot. This means that there may not be enough space reserved to store the plotted points. You can change this value in the Report page of the Model Settings Notebook. The default is to allocate space for 10000 points.

Translation Errors

When you Translate a model, any syntax errors detected are listed in a circular message queue. You then select Search /

Next Error and Search / Previous Error in the Model Text

Window to work through the errors. Each selection places the cursor where the syntax scanner was when the error was detected.

Individual error messages are listed later in this chapter.

Tips

1. Debug a Model File before you use it as the target of an

INCLUDE Command. To do so, paste it into a new Model and

Translate it as if it were the Primary Model File. Correct any syntax errors before proceeding.

Keyboard Problems

Hot keys and preloaded Function Keys do not work unless a

Simulation Object can be found unambiguously.

Some of the Function keys are reserved for system use.

Disk Problems

The most common problem relating to disks is that you do not have enough space to complete an action.

Other causes can include a faulty medium, which is often corrected by reformatting, and more serious hardware errors.

Many of the files used by GPSS World put settings and other values into Object files. You cannot view and or modify these files with normal text editing programs.

13.2. Debugging

GPSS Models

GPSS World has many features which make it easy to find and fix problems in your simulations. The graphics windows allow you to determine if problems exist, and the interactive simulation environment allows you to fix them.

If you have encountered an Error Stop during a simulation, you will probably be able to fix the problem without even restarting the simulation. Be sure to read the explanation of the error message, below.

It is extremely important that you verify that your simulation is behaving as you intended. There are so many ways that things can be done that you should use the visualization features of

GPSS World to ensure that the simulation is doing what you want. You should plan ahead before beginning the testing phase. You may want to insert a few well-placed TRACE and UNTRACE blocks, and set up one or more STOP conditions before you begin the test. TRACE and UNTRACE can be used in Manual Simulation Mode, as well. Remember that all statements can be preloaded into the function keys, and that trace messages are written to the Journal Window, if one is open.

We recommend that you take a high level view before looking at specific results. First, use the Blocks Window to view the startup of the simulation. After you run the simulation past the starting conditions, you can use the graphics screens, starting with the Blocks Window, to get a general idea of how your simulation is working. You should look at the Tables, Facilities, Storages, and Matrices through the graphics windows and ensure that each entity is operating as you expected. Don’t forget that most windows have multiple views available. Look for congestion, heavily utilized resources, and under-utilized resources. GPSS World uses colors (normally red) in the graphics windows to draw your attention to congestion and heavy utilization. Look for accumulations of Transactions on Retry Chains. This indicates that blocking is occurring on one or more resources. Scan all the blocks in the model using the Blocks Window looking at current Transaction counts and the total Transaction counts.

It may be best to finish looking at all entities in the graphics windows before you begin to explore specific problems. Make a list of unexpected findings. Then view a Standard Report, looking for unusual results. Be sure to look at the Retry Chains for blocked Transactions.

When you are ready to go after individual problems, you will find that the debugging facilities of GPSS World are unexcelled. if you have not yet done so, you should review the graphics windows in Chapter 5, and the START, STEP, STOP, SHOW, and CONTINUE commands. You may wish to plot open an Expressions Window on specific values of interest in your simulation.

You can control the simulation very closely using the STOP,

STEP, START, CONTINUE, TRACE, and UNTRACE Statements, and the menus in the graphics windows. The menus allow you to select transactions and blocks for modification and/or for inserting stop conditions. You can do this with the mouse alone in the Blocks Window.

Occasionally, it is useful to know when certain transactions will be scheduled. You can look at the Current Events Chain and the Future Events Chain using the CEC and the FEC sna[shots. This will list transactions to be scheduled during the

current clock value, and those to be scheduled in the simulated future. The new Transaction Snapshot allows you to view the state of a Transaction no matter where it is in the simulation.

The TRACE Block can be used as a manual simulation command to turn on the trace indicator of the Active

Transaction. Trace messages are written to the Session

Journal, if you are using one.

The Journal Window can be quite helpful in program testing. Not only is it useful when you are Translating a non-GPSS World program for the first time, but you can use it to accumulate a chronology of entity definitions, trace messages.

You may want to make some minor alterations to your model, for debugging purposes. The speed of the Translator makes it easy. There are many possibilities.

∙You may want to "sandwich" a

SEIZE or ASSEMBLE Block between a JOIN and REMOVE Block. This will allow you to visualize the Delay Chain or the Match Chain in the Data Window by using the GROUPS command.

∙You may want to insert TRACE and UNTRACE blocks to cause special transactions to appear differently in the Blocks Window.

∙You may want to temporarily alter the flow of transactions for test purposes.

Sometimes problems occur which can be detected only when you compare two or more simulations. You should constantly be alert for unreasonable findings which deserve an explanation. For example, you should simulate treatments where the effects are well known. This provides an important check for the "reasonableness" of you simulation. The ANOVA

Window, discussed in Chapter 12. is available for calculating confidence intervals and for determining the significance of differences in results.

After you are satisfied that your simulation is doing exactly what you want, you are ready to validate it by comparing it to one or more known real-world systems. It is very important to build confidence in your simulation results by demonstrating that the simulation accurately predicts the real situation for one or more occasions, and that there is no known instance where

it is inaccurate. Although many unvalidated simulations are useful and effective, you should spend significant effort trying to find a way to compare predicted values to actual ones, if you can.

After the testing phase, you’re ready to simulate your system. It is up to you to establish that the effects you observe in your simulations are above the statistical noise level. The Analysis of Variance provided by the ANOVA Window can give you confidence that your results are due to more than just random variability. However, the design of experiments and the analysis of statistical data are highly developed disciplines worthy of considerable study. You may choose to apply even more sophisticated statistical techniques to your results.

The results of simulation studies often suggest new things to be studied. It is not unusual to cycle repeatedly through the

Testing and Experimentation phases in order to refine the final designs, or to improve the model in other ways. The interactive and unified design of GPSS World simulation environment make the process as easy and immediate as possible.

Manual Simulation Mode

You can use a TRACE or UNTRACE Statement in Manual

Simulation Mode to alter the Trace Indicator of the Active Transaction. To do this, put a STOP on a given Block or

Transaction using the STOP Command, or in the Blocks Window. When the simulation stops, type in TRACE as a Manual Simulation Statement. The current Active Transaction will be traced from that point on. When used this way, the TRACE Block does not become part of the model and only the single Transaction that has passed through the TRACE Block will produce trace messages.

Debugging techniques

Debugging simulations is usually a matter of placing stop conditions and examining the state of the simulation at specific instants. Snapshots of the CEC and FEC provide in depth looks at the events yet to occur. Stop conditions are normally set by the STOP Command. However the Point and Shoot debugging methods associated with the Blocks Window, and the Hot Keys, including ad hoc preloaded function keys, can speed the process considerably. Point and Shoot debugging is discussed in Chapter 2.

A common alternative approach is to use TRACE and UNTRACE Blocks to selectively turn on the Trace Indicators of certain key Transactions. Then, a chronology of the lifetime of each such transaction is written into the Journal Window.

TRACE and UNTRACE Blocks can be used in Manual Simulation Mode as if they were Commands to change the state of the Active Transactions.

Another useful technique is to use a Refuse Mode TEST Block to monitor for a specific condition. You can use a Stop

Condition to halt the simulation when an event is detected. For example, the following Statements will cause a simulation to be halted when the content of the Queue Entity Teller exceeds 20.

STOP ,Stopper GENERATE ,,,1

Tester TEST G Q$Teller,20 Stopper TERMINATE

Refuse Mode GATE and TEST Blocks use a lot of CPU time.

You may find it more convenient to HALT the simulation in some other manner shortly before the event is to occur, and then use a SPLIT Block in Manual Simulation Mode to send the test Transaction to the Block labeled Tester. In that case you would not use the GENERATE Block.

If you are having difficult determining exactly what the problem is, it is sometime useful to open windows of all types to screen for unusual circumstances. Look at all the entities that have been defined in your simulation. Look for red Blocks in the Blocks Window where congestion is occurring. Be sure to switch to the detailed views in each window when you can in order to examine all the state variables. A buildup in the Retry Chain of one or more entities is a common symptom of an inadvertent blocking condition.

The online windows make the simulation run very slowly. This is because the simulation must wait for the windows to be updated by a succession of messages sent from the Simulation Object. You may find it better to use stop conditions in order to open the dynamic windows only after the simulation has halted.

The Journal Window is useful during model building and testing. Even if you are not placing stop conditions, it is still a good idea keep a Journal Window open.

PLUS Procedures

The interactive environment provides many advantages for debugging PLUS Procedures.

If a PLUS Procedure is running when you enter a HALT

Command, the Procedure sends a message indicating the

Statement that was next to be performed, and then exits from the PLUS Procedure. The simulation is halted just after the previous Block entry. You can then use the SHOW Command to examine the state of the simulation. However, notice that the

temporary data items will no longer exist. For this reason, you may need to add additional debugging statements to your

PLUS Procedure until you are sure it is behaving correctly. One common method is to add additional assignment statements that place values in permanent User Variables or Matrix elements. These can be examined when the simulation is Halted. Another method is to temporarily define the PROCEDURE as an EXPERIMENT. Then you can use the DoCommand Library Procedure to SHOW itermediate values in the Simulation Object's Journal.

If you enter a CONTINUE Command after a PLUS Procedure has been interrupted, the Procedure is run again from the beginning. The Simulation Object restarts by scheduling the next Block entry, not by performing the PLUS Statement where it left off. This means that you may need to plan ahead, and add additional debugging statements into your PLUS Procedure. However, this is easier than it looks, because you can redefine the PLUS Procedure interactively. One way to do this is to place the PLUS Procedure in a separate file, and use interactive INCLUDE Commands to redefine the simulations’s version of the Procedure. Then, you can invoke the Procedure

Interactively by a SHOW Command, examine the results, and redefine the Procedure interactively to make corrections.

13.3. Error Messages

Error Conditions

There are many conditions which prevent the normal completion of a statement during a Session. Some messages originate with the Translator, some with the Simulation Object.

The latter events are called "Error Stops". Most Error Stops provide a message describing what went wrong. If you cannot determine the problem from the message, a longer explanation is available in this chapter. In general, you will find that you will need to modify the simulation before you retry the statement which failed.

If your model resides on multiple Model Files, you can determine which source file caused the problem. Error messages indicate the File Number of the Model File containing the Block Statement which failed. The file number gives the ordinal of the file containing the error. Files are considered numbered in the order in which they are encountered by the Translator, with duplicates considered as separate files. The Primary Model File is file 0.

GPSS World Errors

If operation is interrupted with a System Error Message Box, you should record the title of the box, and CLICK on Display

Register Information. In the next window record the name of the DLL or EXE file and the segmented address to the right of it. This information is normally in the third or fourth line down from the top.

It is possible that an internal error could cause a message to be written starting with "System error." followed by a message. If this happens, please report the error.

Error Reporting Procedure

Copy the message precisely, and write down the steps necessary to repeat the error. Test this procedure yourself to confirm that the error persists. Create a nonproprietary Model

Object that you can send to Minuteman Software to reproduce the error. Use the Help / About menu item in the Main

Window and write down the GPSS World Version type and number, and the Registered User information.. Then notify MINUTEMAN Software. If you do not have a paid-up

telephone support contract, send the problem description and supporting materials to support@minutemansoftware.com. Better yet, visit the Problems Page on our Internet Web site, www.minutemansoftware.com. You'll find it in the General

Information section. Generally, we must be able the reproduce the problem in order to fix it. Many problems occur only under a precise sequence of keystrokes and mousing operations.

Messages

A device-hardware failure has occurred.

An input or output operation has failed. The system reports that a hardware failure has occurred. Retry the operation. If the error persists, contact your hardware support person for assistance.

A system failure has occurred.

Please follow the Error Reporting Procedure, above.

A Transaction is blocked on an impossible condition.

The Active Transaction is attempting to wait for a condition which can never occur. Such a Transaction would never be able to enter the Block. You must change values, operands, or the flow of Transactions in the simulation to prevent this condition. Do not attempt to block on an integrated User Variable. Use the Transaction generation thresholds in the INTEGRATE Command for that purpose.