gpss_manual

· Any Table Entity.

Dynamic windows place a load on the system because large numbers of messages returned from the simulation must be processed. We recommend that only a few online windows be used at a time when the simulation must be run. It is much easier to open a large number of Snapshots and Windows when the simulation is HALTed first.

Each of these Snapshot and Dynamic Window types is treated in detail in Chapter 5.

Printing Windows

Any simulation window can be printed by selecting File / Print from the Main Menu.

Testing

After you have created one or more GPSS models, you then normally enter a period of testing, tracing, and debugging your simulations. GPSS World provides you with many testing facilities, including visual aids, for use during the testing process. In addition, the high level of interactivity provided by GPSS World allows you to manipulate the simulations for the purpose of problem determination.

First, you need to verify that the simulation is behaving as you expect. The GPSS World graphics windows are ideal for this purpose. We suggest that you start the simulation, and then begin to explore the overall behavior of your models as they converge to steady state behavior.

One of the most useful windows for debugging is the Journal View of the Simulation Object. When you cause the Trace Indicator of a Transaction to be turned on, all Block entries of that Transaction cause a Trace Message to be displayed in the Journal View. You can place TRACE Blocks inside the model for this purpose, or you can use TRACE Statements in Manual Simulation Mode, to control the Trace Indicator of individual Transaction Entities.

For serious debugging you will probably need to place stops at certain places in the simulation, and then observe the state of the simulation by taking snapshots and opening dynamic windows. Snapshots of the CEC and FEC, in conjunction with the STEP Command, are often sufficient to determine why certain events occurred. The FEC and CEC are visible in Simulation Snapshot or can be displayed using a REPORT Command.

Difficult debugging problems can often be best tackled by running a simulation to an important time, and then saving the Simulation Object. Stop conditions and memorized expressions are automatically saved with it. Then, by repeatedly reopening it as a new Simulation Object, you can rerun the simulation from the saved state.

All SNAs are accessible using the SHOW Command. GPSS World allows you to redefine entities, redefine PLUS Procedures, change the values of user defined names, and to manipulate the simulation by entering Manual Simulation Statements. You can then continue the simulation without a retranslating.

Error Stops

An Error Stop is an error condition which prevents a Statement from completing normally within a simulation. You must correct the conditions causing the Error Stop before the simulation can proceed.

When an Error Stop occurs, the Simulation Object sends a series of notification messages to the Journal View. If the nature of the error is not clear from the error message in the data window, you should consult Chapter 13 of this manual. Each Error Stop message is listed in Chapter 13, and usually a remedial action is suggested. You may then enter any Statements required to understand and fix the problem which caused the error.

Chapter 10 contains a section on finding and correcting problems in your

simulations.

The Debug Toolbar

Most of the dynamic Simulation Windows have an additional toolbar called the Debug Toolbar that lets you debug using only mousing operations.

Figure 2—18. The Blocks Window Debug Toolbar

The Blocks window has the best Debug Toolbar because you can select a Block Icon with the mouse, then click on the Place button to place a Stop condition that HALTs the simulation when a Transaction attempts to enter that Block. When the Block is selected, if you click on the Remove button, the original Stop Condition is removed.

Most of the other Simulation Windows have toolbars without the Place and Remove buttons. But they do have the rest. Use the Halt button to send a HALT Command to the Simulation Object. The Continue button resumes the simulation and the Step button causes the simulation to attempt to enter a single Block, and then HALT.

You can view the collection of Stop Conditions in the User Stops Snapshot.

SELECT Window / Simulation Snapshots / User Stops

Figure 2—19. The User Stops Snapshot

The User Stops Snapshot displays the set of all active Stop Conditions. A Stop Condition is defined by a Transaction Number and a Block Entity Number. Any attempt of a Transaction of the stated number to enter a Block of the stated number causes a HALT Command to be invoked. The value of 0 is special. Since no Transaction or Block has a number of 0, this value is used to indicate "Any". For example, the window above has a single Stop Condition which occurs when any Transaction attempts to enter Block 3.

Stop Conditions are added to the list using the STOP Command or via a Debug Toolbar. You can remove any or all Stop Conditions by STOP ,,OFF Command, via a Debug Toolbar, or by selecting and clicking the Remove or Remove All buttons in the User Stops Snapshot.

Experimentation

After you have established credibility in your GPSS Model, you enter the experimental phase of the project. During this period, you run your model repeatedly to experiment with the effects of proposed actions on your simulated system. The most efficient design of simulation experiments and interpretation of data requires the application of formal statistical methods. These topics elsewhere in this manual.

It is up to you to establish that the effects you have observed in your simulations are above the statistical noise level. The Analysis of Variance provided by the ANOVA Library Procedure 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 power of PLUS Experiments enables you to run complex experiments unattended, even exploring Response Surfaces and collecting data for advanced statistical treatment. Be sure to study Lesson 19 in The GPSS World Tutorial Manual to get started with your experimentation.

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 the GPSS World simulation environment tries to make the process as easy and immediate as possible.

Reports

Standard Reports are discussed in Chapter 11, ANOVA Results in Chapter 12.

2.2.4 Using System Resources

Memory Request Limits

An arbitrary memory limit is used to protect your simulations from gross overstatements of memory requests. It is used to trigger an error condition when a memory request exceeds the limit. It applies to allocations of Table Entities, Matrix Entities, and Plot Windows.

You can change the limit if you need to by altering the limit in the Simulate page of the Model Settings Notebook. Select Edit / Settings and turn to the Simulate

page. Enter the new limit in the Max Memory Request entry field, and CLICK on OK.

Stack Size

The simulation stack is used for nested procedure calls. You can change the limit if you need to by altering the limit in the Simulate page of the Model Settings Notebook. Select Edit / Settings and turn to the Simulate page. Enter the new limit in the Stack Size entry field, and CLICK on OK.

Circular References

An arbitrary limit is used to protect your simulations from circular references. If your simulation uses highly nested GPSS, or PLUS procedure calls, it is possible that you may need to increase this value.

You can change the limit if you need to by altering the limit in the Simulate page of the Model Settings Notebook. Select Edit / Settings and turn to the Simulate

page. Enter the new limit in the Max Evaluation Depth entry field, and CLICK

on OK.

Chapter 3 - Model

Statements

A GPSS World model is a sequence of Model Statements. A

Model Statement may be either a GPSS Statement, a PLUS

Procedure definition, or a PLUS Experiment definition. A GPSS

Statement is either a Command or a Block Statement.

PLUS is an acronym for the Programming Language Under Simulation, GPSS World’s embedded programming language.

This chapter describes the use of Model Statements in the

GPSS World simulation environment. It then discusses the general structure of GPSS Statements. Individual GPSS

Commands are discussed in detail in Chapter 6, and Block

Statements are in Chapter 7. Of the PLUS Statements, only

PROCEDURE and EXPERIMENT are Model Statements. PLUS is described in detail in Chapter 8.

3.1. Using Model

Statements

Before you can run a simulation, you must Create a Simulation

Object. This is called the Initial Model Translation. It’s easy. You just open a Model Window on the Model Object, and

CHOOSE Command / Create Simulation

You will be told if any corrections need to be made, due to syntax errors.

When you have Translated a model successfully, the Simulation Object automatically gets a copy of the Translated model, and executes any Commands embedded in the Model Files. You can now open any of the online windows upon the simulation. If you have put one or more START Commands into one of the Model Files, the Simulation Object executes it in order with the other Commands, without waiting to be told to.

Any Model Statement can be part of the Initial Model

Translation, or can be sent to an existing simulation later, as an Interactive Statement.

3.1.1. Initial Model Translation

When a Model is Translated successfully, its Block Structure is created, a Procedure Registration List is created, a Command

List is created, and the whole thing is sent to the Simulation

Object.

executes it right away. Queued Commands, on the other hand are placed in the Simulation’s Command Queue. The

Simulation Object executes one Queued Command after the other, occasionally interrupted by Immediate Commands.

A Command List is created by the Initial Model Translation and sent to the Simulation Object, just as Interactive Commands are sent. As the Translator encounters Commands during the Initial Model Translation, they are placed on the list. When the whole model has been Translated, the Command List is sent to the Simulation Object after the Block structure and the

Procedure Registration List.

START, CONTINUE, and CONDUCT are Queued Commands.

When the Simulation Object takes one off the Command

Queue, the simulation runs until its Termination Count is nonpositive. More Commands may be waiting to be done after that.

The CONDUCT Command is used to run Experiments, which are a special kind of PLUS Procedures. Experiments are registered in a Simulation Object like any other PLUS Procedure, and they can have arguments passed to them by the CONDUCT Command. If a Simulation Object has only one Experiment and it is defined with no arguments, the CONDUCT Command does not even have to name the Experiment since there is no ambiguity.

The HALT Command is a special case. Not only is it an Immediate Command, but it has the effect of clearing off all

Commands form the Command Queue. When you send a HALT Command to the Simulation Object, the simulation is brought to the Halted State, and all activity on behalf of the simulation comes to an end. You are then free to control the simulation as you please.

3.1.5. Procedure Sequence

During the Initial Model Translation, when the Translator encounters a Procedure or Experiment Statement, it puts the

Translated Procedure on the Procedure Registration List. The Simulation Object registers all the user-defined Procedures when it receives the Translated model.

When the Simulation Object receives an Interactive Procedure Statement, it incorporates the Translated Procedure into the simulation’s Procedure Library, possibly replacing one that’s already there.

The invocation of a Procedure occurs when an Expression with a Procedure Call, or a Procedure Call Statement, in a PLUS

Procedure is executed. Invocations can be performed interactively, as well, by placing a Procedure invocation in the operand of a SHOW Command. Experiments can only be invoked by CONDUCT Commands

3.1.6. Saving Objects

All GPSS World Objects can be saved and opened in a later session. Models, Simulations, Reports, and Text Objects can all be modified and saved at any time. The File / Open Menu

Command is available to bring the object back.

A Simulation can be saved at any point in its run for the purposes of debugging, demonstration, replay, or simply to save an intermediate state of the Simulation Object

The act of saving a Simulation or Experiment causes a HALT Command to be sent to the Simulation Object. In the case of an Experiment, you will need to save the state of the completed part of the Experiment in Global Variables and Global Matrices if you don't want to restart the Experiment from the beginning when you reopen it.

3.2. GPSS Statements

There are two kinds of GPSS Statements: Block Statements, which cause a GPSS Block Entity to be created, and Commands, which do not. Commands either define a non-Block Entity or cause an action to occur. PLUS Statements are not discussed here.

Unlike a PLUS Statement, a GPSS Statement must reside on a single line of text, consisting of up to 250 characters.

GPSS Statements are composed of parts called fields. A field is a variable number of printable characters terminated by white space or a delimiter. Although the exact composition of a Statement varies a little, in general, a Statement is laid out as follows: Line number (optional) | Label (optional) | Verb (required) | Operands (depend on verb) | Comment (optional).

Arbitrary Line numbers are retained for compatibility purposes. If used, they must begin in column 1. However, they are ignored by the Translator. A line number given in an error message is an absolute cardinal number, denoting the place of the line in the Model File, and is not a user-selected line number.

3.2.1. GPSS Commands

The commands are described in detail in Chapter 6. They are: BVARIABLE - Define a Boolean Variable Entity.

CLEAR - Reset statistics and remove Transaction. CONDUCT - Execute a registered PLUS Experiment.

CONTINUE - Resume the simulation.

EQU - Assign a value to a User Variable.

EXIT - End the GPSS World Session.

FUNCTION - Define a Function Entity. FVARIABLE - Define an Fvariable Entity.

HALT - Stop the simulation and delete all Queued Commands. INCLUDE - Read and Translate a secondary Model File.

INITIAL - Initialize or modify a Logicswitch, Savevalue, or Matrix Entity.

INTEGRATE - Automatically integrate a time differential in a

User Variable.

MATRIX - Define a Matrix Entity.

QTABLE - Define a Qtable Entity.

REPORT - Set the name of the Report File or request an immediate report.

RESET - Reset the statistics of the simulation.

RMULT - Set the seeds of the first 7 Random Number

Generators

SHOW - Evaluate and display Expression.

START - Set the Termination Count and begin a simulation. STEP - Attempt a limited number of Block entries.

STOP - Set a stop condition based on Block entry attempts. STORAGE - Define a Storage Entity.

TABLE - Define a Table Entity.

VARIABLE - Define a Variable Entity.

3.2.2. GPSS Block Statements

A Block Statement creates a GPSS Block. When a Transaction enters a Block Entity, a special action occurs which is determined by the nature of the Block. The Block structure of the simulation is set when the Model Object is Translated. After a simulation is STARTed, it is the original sequence of Block Statements that determines the sequence of actions in the simulation. Unless the flow of Transactions is modified, each Active Transaction attempts to enter one Block after the other

in the original sequence. Block Statements received by the simulation after the original Model File was Translated, are

NOT incorporated into the Block structure of the simulation.

Instead, they cause a temporary block to be created, used, and destroyed in Manual Simulation Mode, which is discussed above.

The GPSS Block Statements are described, in detail, in Chapter 7. They are:

ADOPT - Change Assembly Set.

ADVANCE - Place Transaction on Future Events Chain. ALTER - Test and modify Transactions in a Group. ASSEMBLE - Wait for and destroy related Transactions.

ASSIGN - Modify Transaction Parameter.

BUFFER - Place Transaction at end of the Current Events

Chain.

CLOSE - End the Data Stream.

COUNT - Place count of entities into a Transaction Parameter.

DEPART - Decrement content of a Queue Entity.

DISPLACE - Change the Next Sequential Block of a Transaction.

ENTER - Occupy or wait for storage units in a Storage Entity. EXAMINE - Test group membership.

EXECUTE - Perform action specified by a different Block. FAVAIL - Change status of a Facility Entity to "available".

FUNAVAIL - Change status of a Facility Entity to "not available".

GATE - Test entity and modify Transaction flow.

GATHER - Wait for related Transactions.

GENERATE - Create Transaction and place on Future Events Chain.

INDEX - Modify Transaction Parameter.

INTEGRATION - Turn the integration of a User Variable On or

Off.

JOIN - Place a member into a Numeric or Transaction Group.