HELP (Программа GPSS), страница 5

Blocks are placed in the simulation in the same order that they are encountered by the Translator. Commands are accumulated in an ordered list that is sent to the Simulation Object with the simulation. The list is scanned for Immediate Commands (SHOW, HALT, and CONDUCT), and the remainder are placed on the simulation’s Command Queue and executed one after the other. Command Lists sent interactively to an existing simulation are treated the same way.

Dynamic simulation windows (not Snapshots) are automatically refreshed when you Translate a model to ensure that the view is current. If an entity can no longer be found, say, in a Table Window, the Window will be closed automatically.

Controlling Simulations

GPSS Commandsare used to control the running of simulations. They are discussed in detail in Chapter 6. They may be embedded in a model or they may be sent as Interactive Statements.

Any Model Statementmay be sent to an existing simulation. Such statements are called Interactive Statements. You can control and view running simulations very closely with the operations that are available. To do so, use the Command menu in the Main Window. If the Command you need is not listed, select Command / Custom and type it into the entry field, and select OK. This action Translates the Command and sends it to the simulation. The Command menu is disabled until there is a simulation to receive interactions.

You may use GPSS Block Statements and PLUS Procedure definitions as Interactive Commands. Block Statements sent interactively to an existing simulation cause a temporary Block to be created and immediately destroyed after the Active Transaction attempts to enter it. This mode is called Manual Simulation. Procedure Statements sent to an existing Simulation Object register a user created PLUS Procedure, replacing any of that same name that may already exist.

Interactions are logged in the Journal View of the Simulation Object.

Running

Normally, a START Command is used to begin a simulation. It could be entered interactively or could be part of the Model Object. The START Statement specifies the Termination Count, which is an important state variable of the simulation. The Termination Count must be decremented to zero for the simulation to end. Any TERMINATEStatement in the simulation can decrement this count.

When the Simulation Object executes a START Command, Transactions will begin to circulate in the simulation. Normally, the simulation will end by itself and will produce a Standard Report when the Termination Count reaches zero. If an error stopoccurs, no report is written. Reporting options can be changed in the Settings of the Simulation Object. These are described above in Section 2.2.3.

Multiple simulations can be run unattended by using RESET, CLEAR, and START in a sequence of Commands. These are commonly used in PLUS Experiments, which can control and analyze extensive sets of simulation runs. PLUS Experiments are discussed in this manual in Section 8.2.4 , and in Lesson 19 of The GPSS World Tutorial Manual.

Stopping a Simulation

You may stop a running simulation in several ways.

· First, you can interrupt a simulation by sending a HALTCommand. HALT can be asserted by the b+a+H Hot Key, a Function Key, an Interactive Command from the Command menu, or as part of a Command File.

· Second, you can enter one or more stop conditions with the STOP Command, before you START or CONTINUE the simulation. STOP commands set conditions which when detected will cause the simulation to halt. When the simulation stops, previous stop conditions are not removed. If you CONTINUE a simulation after a stop condition was found, the original condition that caused the simulation to stop is ignored to allow the stopped Transaction to proceed. STOP conditions can be controlled by “Point and Shoot” operations in the Debug Toolbar using only the mouse. This is discussed below, and in Chapter 5.

· Third, you can resume the simulation with a STEP Command. After the specified number of Block entry attempts, the simulation will stop automatically.

· Fourth, when an error condition is detected, an Error Stop occurs. The simulation is halted and messages are sent to identify the reason.

· Fifth, you can simply wait for the simulation to complete. This occurs when the Termination Count falls to or below 0.

In each of these cases, when the simulation stops, the state of the simulation is reported to the Journal View of the Simulation Object.

Interactive Statements

Any Model Statement can be sent to an existing simulation. These are called Interactive Statements. They can be Commands, PLUS Procedure definitions, or even Block Statements.

Every simulation has a Command Queue associated with it. The Simulation Object performs each Command on the queue one after the other, until it is HALTed or until it runs out of things to do. Even Commands in the Model, other than HALT and SHOW, are placed on the Command queue before they are performed.

Interactive Commands are either Immediate or Queued. Immediate Commands, such as HALT and SHOW, are performed as soon as the Simulation Object receives them. All other Commands are queued. They are placed at the end of a list of Commands which have not yet been completed.

The HALT Command is a special case. Not only is it an immediate Command, but it also deletes any remaining Queued Commands still on the Command queue. After a HALT Command is performed, the Simulation Object has nothing more to do on behalf of that simulation, for the moment, since the Command Queue is then empty.

Commands are not the only statements that can be used interactively. When a PLUS Procedure Statement is sent interactively, it causes the procedure to be registered within the simulation. Thereafter, the procedure can be invoked from any PLUS Expression. If a Procedure with the same name already exists within the simulation, it is redefined.

A PLUS Experiment is a special kind of Procedure. PLUS Experiments are can be sent interactively, as well. If any like-named PLUS Procedure (or Experiment) is currently registered with the Simulation Object, it is replaced. Then the Experiment can be invoked using a CONDUCT Command, which is discussed in Chapter 6.

Interactive Block Statements are called Manual Simulation Statements. When received by the Simulation Object, they cause a temporary Block to be created, and the Active Transaction to attempt to enter it. Then the Block is destroyed. In this manner, GPSS Blocks can be used as though they were commands, providing for a fine level of control over the simulation. Data Stream file I/O is supported interactively, as well. Data Streams are discussed in Section 4.16.

GENERATE Blocks are the only ones which cannot be used in Manual Simulation Mode. Instead, SPLIT Block Statements can be used to create Transactions interactively.

The are several ways to send a Model Statement to the simulation. You can use the Command submenu of the Main Window, you can use a “Hot Key”, and you can associate a GPSS Statement with a Function Key in the Model Settings Notebook.

To send a Command List to the Simulation Object

CHOOSE Command / Custom,

type the Command list, and

SELECT OK

This will Translate the Command list and send it to the simulation for execution.

It is often convenient to put a list of frequently used Commands in a small text file. You can then use an INCLUDE Command to send the whole sequence to the Simulation Object. Even easier, you can load a function key with an INCLUDE Command, and have the whole Command List performed by a single keystroke.

Redefining Entities

There are fifteen different entity typesthat you can create. The entity types are Transactions, Blocks, Facilities, GPSS Functions, Logicswitches, Matrices, Queues, Storages, Savevalues, Tables, Userchains, Variables, Numeric Groups, Transaction Groups, and Random Number Generators. The better you understand these entities and their properties, the more powerful your simulations will be. Chapter 4 is devoted to entities.

With the exception of Transactions, entities are never deleted from the simulation. However, some entity types can be redefined interactively. You can use STORAGE, TABLE, QTABLE, MATRIX, or VARIABLE Commands using the same label to do so. Similarly, PLUS Procedures may be redefined interactively.

A location label, or simply location, is a name used to label a Block Statement. This field is not required in a Block Statement. Unlike other entity types, Blocks may not be redefined in GPSS World. A similar flexibility can be achieved by using an EXECUTE Block and redefining its Operand A.

Viewing

A wide variety of windows are available for viewing simulations. Multiple windows of the same type may be opened on any simulation. All windows can be printed or saved for later use.

Simulation windows are divided into two categories: Snapshots and Dynamic Windows. All Simulation Snapshots and Windows are opened using the Window submenu in the Main Window. Use Window / Simulation Snapshot for a Snapshot and Window / Simulation Window for a Dynamic Window. The menus are disabled until there is a simulation to see.

Snapshotsare not updated online. They take a single picture that represents a view of the simulation at a single instant.

You can take Snapshots of the following items:

· Current Stop Conditions.

· Any Transaction in the simulation.

· The Current Events Chain.

· The Future Events Chain.

· Numeric Groups.

· Userchains.

· Transaction Groups.

Dynamic Windowsare updated as the simulation changes. They are refreshed when you Translate a model or cause a RESET event. You can open an online view of

· The Block Structure of the model.

· An arbitrary Expression list.

· The Facility Entities.

· The Logicswitch Entities.

· Any cross-section of a Matrix Entity.

· A Plot of multiple arbitrary Expressions.

· The Queue Entities.

· The Savevalue Entities.

· The Storage Entities.

· 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 presented 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 graphical 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. The PLUS Trace Setting can now be used to aid the development of PLUS Procedures. It is discussed below.

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 can be visualized in snapshots 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. They can be visualized dynamically in an Expression Window of a Plot Window.

Sometimes it is useful to make corrections in the middle of a debugging run. 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 that prevents a Statement from completing normally within a simulation. You must correct the conditions causing the Error Stop before the simulation can proceed.

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—19. The Blocks Window Debug Toolbar