How to read MOD pages

From Support

Jump to: navigation, search

Back to Model Library

In SIGMA, a model file has the file extension .MOD, and a library of them have been bundled with the SIGMA software package to illustrate the variety of uses for the SIGMA simulation package. These pages describe in detail each of the .MOD files, their use, and their significance in application and theory.

Contents

Description

This section is a description of the model, its purpose and significance to statistics, stochastic processes, probability theory, and queueing theory. It also outlines how to use the model to produce meaningful results.

Variables

This sections outlines the variables of a SIGMA model. The types of variables noted here are based off of queueing theory, and are not explicitly categorized as such in SIGMA. Most models have state variables, which describe the current state of the system, and additional variables, which are SIGMA-specific. All variables are defined in SIGMA.

State Variables

State variables are variables that describe the current state of the system. These are meaningful indicators in the simulation that describe what is happening, and the user may track these variables as a measure of the simulated system's performance.

For each variable, four columns are defined tell the user about the variable. Let's take AIRPORT.MOD as an example.

State Variables in AIRPORT.MOD
Variable Name Abbreviation Variable Description Type Size
QUEUE Q Number of customers in line Integer 1
SERVERS S Number of available tellers Integer 1

The Variable Name column is the name of the variable in SIGMA. The Abbreviation is the shortened form of the variable used in the event graph depicted a few sections below. The Type indicates whether the variable is a real, integer, or user defined variable. The Size indicates the size (or dimension) of the variable. If Size is 1 then the variable is only one-dimensional; however if the Size is greater than 1 then the variable may have additional dimensions which track other variables in the system. For example, if QUEUE had size of 2, then SIGMA would have two variables called QUEUE[1] and QUEUE[2] which represent two different queues. The Variable Description is what the variable is meant to represent, in plain English.

There are other additional state variables that do not say anything about the state of the system, but are used for other reasons such as programming logic, or transient entity modeling. These variables are also defined in the same syntax as state variables. Most non-state variables are parameters that are passed along edges.

Vertices

A vertex is a basic component of an event relationship graph. Its function is to execute state changes. Below is an example using AIRPORT.MOD:

Vertices in AIRPORT.MOD
Vertex Name Vertex Description State Changes
RUN The simulation is started None
ENTER Arrival of a customer Q=Q+1
START Start of Service S=S-1, Q=Q-1
LEAVE End of Service S=S+1
INPUT Execute to change the queue and number of servers Q=10, S=6

The Vertex Name is the name given to the vertex by the user which describes what the state change is. The Vertex Description is the description, which may be input into SIGMA, of the vertex, and is used when creating the English translation. The State Changes column is what code is actually executed when the vertex is activated, using the variable abbreviations defined above.

Initialization Conditions

Initialization conditions are required user inputs necessary to start a simulation run. In AIRPORT.MOD, the following initialization conditions are required:

Initialization Conditions in AIRPORT.MOD
Variable Description
Servers Initial number of servers

The Variable is the variable that is required to be changed by the user before the simulation can begin. If there is no user input, then SIGMA will default to 0 or whatever the model was saved as earlier.

Event Relationship Graph

The event relationship graph is a concise way of showing all the vertices, edges, variables, and state changes in the simulation model. The event graphs shown here are user-generated and cannot be seen in SIGMA. However, they do allow you to view the model in its entirety. For instructions on how to read an event graph see how to read an event graph.

Some SIGMA models do not have an event graph shown. Most of these include models with animation. As a result, an event graph will not be shown here but instead a screen shot of the SIGMA model.

Below is an example from AIRPORT.MOD:

AIRPORT.MOD
AIRPORT.MOD

English Description

An English description is a verbal description of a model, automatically generated by SIGMA. This is useful for debugging purposes as well as checking to see if the model makes sense. For instructions on how to retrieve an English description see here.

Below is an example from AIRPORT.MOD.

The SIGMA Model, AIRPORT.MOD, is a discrete event simulation. 
It models A LINE WITH SEVERAL SERVERS.
I. STATE VARIABLE DEFINITIONS.
For this simulation, the following state variables are defined:
QUEUE: NUMBER OF CUSTOMERS IN LINE (INITIALLY=0)   (integer valued)
SERVERS: NUMBER OF AVAILABLE TELLERS   (integer valued)
II. EVENT DEFINITIONS.
Simulation state changes are represented by event vertices (nodes or balls)in a SIGMA graph.  
Event vertex parameters, if any, are given in parentheses. Logical and dynamic relationships 
between pairs of events are represented in a SIGMA graph by edges (arrows) between event vertices.  
Unless otherwise stated, vertex execution priorities, to break time ties, are equal to 5.
1. The RUN(SERVERS) event occurs when INITIALIZATION OF THE NUMBER OF TELLERS.
   Initial values for, SERVERS, are needed for each run.
   After every occurrence of the RUN event:
   Unconditionally, INITIATE THE FIRST CUSTOMER ARRIVAL; that is, schedule the ENTER() event to
   occur without delay.
2. The ENTER() event occurs when ARRIVAL OF A CUSTOMER.
   This event causes the following state change(s):
   QUEUE=QUEUE+1
   After every occurrence of the ENTER event:
   Unconditionally, SCHEDULE THE NEXT ARRIVAL;
   that is, schedule the ENTER() event to occur in 1+5*RND time units.
   (Time ties are broken by an execution priority of 6.)
   If SERVERS>0, then START SERVICE WITH THE IDLE SERVER;
   that is, schedule the START() event to occur without delay.
3. The START() event occurs when START OF SERVICE.
   This event causes the following state change(s):
   SERVERS=SERVERS-1
   QUEUE=QUEUE-1
   After every occurrence of the START event:
   Unconditionally, THE CUSTOMER WILL BE IN SERVICE ABOUT 4 MINUTES;
   that is, schedule the LEAVE() event to occur in 20+4*RND time units.
   (Time ties are broken by an execution priority of 6.)
4. The LEAVE() event occurs when END OF SERVICE.
   This event causes the following state change(s):
   SERVERS=SERVERS+1
   After every occurrence of the LEAVE event:
   If QUEUE>0, then SERVICE THE WAITING CUSTOMER;
   that is, schedule the START() event to occur without delay.
5. The INPUT() event occurs when EXECUTE TO CHANGE THE QUEUE AND NUMBER OF SERVERS.
   This event causes the following state change(s):
   QUEUE=10
   SERVERS=6
   No additional events are scheduled here.

Comments

The comments section is a detailed area where you may learn how to use the model. Airport.MOD is illustrated below:

Instructions for changing the value of stats variables during a run:

Start AIRPORT.MOD. Watch the queue increase for a few seconds in the simulation plot window. Next, double-click on the INPUT vertex; it will not have executed since it is not connected to the graph. Open the EDIT VERTEX dialog box and click on the Execute button. When you click on the Execute button in an Edit Vertex dialog box during a run, that vertex will be the next event executed. State changes for this vertex will then occur.

The Dialog Box for the INPUT Vertex
The Dialog Box for the INPUT Vertex

To delete servers, double-click on the LEAVE vertex and close the resulting dialog box with the Remove button. This will remove the next pending LEAVE event, effectively removing one busy server. The Execute and Remove commands buttons at the bottom of the Edit Vertex dialog box are useful for executing an event or removing an event from the future events list during a run. Since the executed event can itself schedule or cancel other events, this gives complete run-time control over the future events list.




Back to Model Library

Personal tools
Navigation