Designing simulation experiments The final stage in analyzing a system with simulation is to...

Designing simulation experiments

The final stage in analyzing a system with simulation is to

optimize over the system parameters in such a way as to

optimize performance. As stated earlier, simulations is

fundamentally a descriptive tool, not a prescriptive tool. With

care and a lot of computer time, it is possible to optimize

with simulation. In many ways, optimizing with simulation is

very similar to nonlinear optimization.


First, let's suppose we have a single quantity to optimize

over. This might be the number of machines to place in a

plant, the number of units at which to reorder in an inventory

system, or the number of dollars to put into a particular

portfolio. Let this quantity be denoted x. Suppose you have

a simulation that will determine the performance given x,

denoted .


If was deterministic, you would simply optimize over x by

any of the techniques covered in your Intro (like binary

search, golden section search, and so on). The only

difference in simulation is that is not deterministic, but

rather it is stochastic. This means that sufficient runs must

be made in order to ensure that the choices ( is better

than ) are made correctly. Because these tests must be

made repeatedly, either the allowance for error must be

very, very small, or some allowance for making an error

must devised.


This is particularly true when working with more than

one parameter. In this case, it is not even clear how to

use nonlinear algorithms. After all, such things as

derivatives are not available. In this case, you begin at a

particular point. For each parameter, you look at

increasing it a bit and decreasing it a bit. If there are n

parameters, there are possibilities, so you get .


You then choose the best and that is the next point you

examine. This is continued until you reach a point

where no increase or decrease improves your solution.

This can be sped up somewhat by using factor

analysis, and factorial design, which reduces the

possibilities to a more manageable number.


Consider the following data points, giving the

simulation results of two different systems (each data

point is the aggregation of the results of a single run):

X: 10, 16, 22, 2, 46, 23, 14, 89, 32, 12

Y: 11, 33, 83, 12, 21, 41, 3, 19, 15, 8

Y-X : 1, 17, 61, 10, -25, 18, -11, -70, -17, -4

Analyze the above data to determine if the expected

value of X is greater than the expected value of Y by

subtracting each X value from the corresponding Y value.

Can you distinguish the systems?

Do the same for the following sets of data. Now can you

distinguish the data? Note that the numbers are the same:

why does this lead to a different conclusion?

X: 10, 16, 22, 2, 46, 23, 14, 89, 32, 12

Y: 8, 15, 19, 3, 41, 21, 12, 83, 33, 11

Y-X : -2, -1, -3, 1, -5, -2, -2 ,-6, 1, -1

Bank Simulation Example

Description of the System

A bank with five tellers opens its doors at 9 a.m. and closes its doors at

5 p.m., but operates until all the customers in line by 5 p.m. have been

served.

Each teller has a separate queue. An arriving customer joins the

shortest line. If two queues have the same length, the customer joins

the leftmost queue (the one closest to the door). When a customer at

the end of a line notices a departure that makes another line shorter

than the customer’s present one, the customer can change to the

shorter line.


Questions to be Answered About this System

The bank’s management is concerned about the quality of service

currently provided to customers and is thinking of adding one or more

new tellers. How many tellers should they add?

Why is simulation necessary?

Simulation will be used to answer this question because hiring one or

more new tellers, training them, and then watching to see how the

system is effected would be impractical and expensive.


High-level Model of the System

Pictorial Representation:

The customer being served by teller 3 completes service, causing the

customer from the tail of queue 2 to jockey.


Input to the System

The inter-arrival times of customers are exponential random variables

with mean 1 minute.

The service times of customers are exponential random variables with

mean 4.5 minutes.

Output Statistics to be Gathered

For each case, n = 5, 6, and 7 tellers,

• Average number of customers in the queue

• Average delay in the queue

• Maximum delay in the queue


Notes on jockeying:

Let ni be the total number of customers (in the queue plus in service) in

front of teller i at a particular instant. If the completion of a customer’s

service at teller i causes nj > ni + 1 for some teller j, then the customer

from the tail of queue j jockeys to the tail of queue i.

If there are two or more such tellers j (i.e., customers wanting to

move), the customer corresponding to the closest queue to the left

of teller i will jockey.


Simulation Design and Implementation

•Event description •Event type

•Arrival of a customer to the bank •1

•Departure of a customer upon completion of service

•2

•Bank closes its doors at 5 p.m. •3


Simulation Design and Implementation

Data Structures Needed

•Event list (one)Storing for each entry:

• Event time• Event type•Teller number if event type 2

•Teller lists (for each teller) Storing for each entry:

•Time of arrival to queue

•Teller busy bit (for each teller)

Subprogram Purpose

Arrive Processes type 1 events.

Depart (Teller_Num) Processes type 2 events, where Teller_Num is the number of the teller completing service.

Jockey(Teller_Num) Jockeys a customer from one queue to another where Teller_Num is the number of the teller completing service.(Jockey is called from Depart and is not an event routine.)

Bank_Closes Cancels the next scheduled arrival, thus preventing any future arrivals.

Report Generates a report and is called from the main program when the simulation ends.

Flowchart for subroutine Arrive

Flowchart for Subroutine Depart

Flowchart for Subroutine Jockey

Sample Output From the Simulation

Languages & Simulators

Possible features to consider in software selection include

the following

•Input

•Processing

•Output

•Environment

•Vendor

•Cost


Warning 1 : Know which features are appropriateCertain features in certain simulation software are not needed to perform the simulation for your system. Then do not chose the software or buy it without the feature included.

Warning 2 : Don’t make judgments on the basis “yes” or “no”. For instances the software you want to buy has the ability to model conveyers. You need software that can model conveyers, but you still need to ask whether the software can model your system’s conveyer. This is crucial as the aspect being model in the software might not be equivalent to the aspect needed for your conveyer system model.


Input considerations

•Point and click capability

•Importing file

•Exporting a file

•Syntax

•Interactive run controller (IRC)

•Interactive to other languages

•Input data analysis capabilities


Processing considerations

•Powerful constructs

•Speed

•Run-Time Flexibility

•Random variate generator

•Reset

•Independent replication

•Attributes and global variables

•Programming

•Portability


Output considerations

•Standardized report

•Customized report

•Business graphic

•Database maintenance

•Collection of Mathematical desired

•Custom performance Measures

•Write to file


Environment considerations

•Ease of use

•Ease of learning

•Quality of documentation

•Animation capability

•Run-only version

•Stability

•History

•Track record

•Support


As noted earlier, there are two basic approaches to

developing simulation models, either use a programming

language or a programming system. The two basic

approaches can be categorized as:

Languages - e.g. SLAM, ECSL, SIMAN. These are high

level programming languages which allow rapid

development compared with C++, Pascal, FORTRAN. It

is a relatively slow approach to building models but

extremely versatile.


Simulators - e.g. Witness, ProModel, TaylorII. These are

data driven systems with little or no programming required.

This approach is fast, easy but more limited in application.

Some simulators are now incorporating virtual reality (VR)

technology into their software. Witness now has a VR plug-

in whilst Deneb market a package called Quest.


A third approach can be derived from these two:

Hybrid systems - Arena combines the flexibility of a

simulation language (SIMAN) with the user-

friendliness of a data driven system. The user

exploits speed and flexibility of the different parts


So which approach to choose? A lot depends on the language you

plan to implement your system in. There are essentially three

types of languages you can use: general purpose languages,

simulation specific languages, and general languages designed

for simulation.


In the first class are languages like FORTAN, C, Pascal, and so on.

These are languages used for many applications. There are a

number of advantages to implementing simulations in general

languages: they tend to be very fast, there are few limitations on

what can be done, programmers are easily found, and simulations

can be done on a number of different computers (due to

standardization of language).

The disadvantage of this approach is cost. Simulations based on

general languages take knowledge of simulation implementation

and are generally very large, intricate programs. The time needed to

design, code, and verify such a system may be overwhelming.


The second class of languages are simulation specific, and include GPSS,

SIMAN, and SLAM. These languages take most of the work out of

creating a simulation. All these systems can do all the queue

manipulation needed in a single line.

The main disadvantages of these languages are in their limited domain. It is

difficult, but not impossible, to create a financial portfolio planner in

SIMAN. It is just not designed for it. On the other hand, another

specialized simulation language can easily handle it within a 123

spreadsheet. It is also difficult to use other programs in the simulation.

Imagine trying to put in a network optimizer in a transportation simulator

if you are required to use SIMAN. Although there is the ability to link in

your own FORTRAN programs, the methods are cumbersome and

inefficient.


The final class includes such languages as SIMSCRIPT.

SIMSCRIPT is a general language in the sense that things like

network optimization and linear programming can be written in

the language. It is also a simulation language, for it has

commands to generate entities and manipulate queues. In many

ways, it is the best of both worlds, and its lack of popularity

surprises me. Perhaps by including everything, it has become

to complicated to be popular.


In most cases, simulation these days is done by an appropriate

special system, although there are still a substantial number of

holdovers from the general language school. If a reasonable

library of routines has been built up, then a general language

can have most of the advantages of the specialized language.

On the other hand, I have yet to see a set of libraries that make

FORTRAN as easy as SIMAN.

Practical issues

This section briefly identifies a number of practical issues surrounding the

use of discrete event simulation.

Current costs. Currently costs are very high.

Future costs. The introduction of cheaper systems may make simulation

more accessible and used not just when the risks are high.

Time for use. The time require to build, verify, validate, experiment and

analyze results can be lengthy and can put many off using simulation. In

practice, however, it is noted that users acquire a great knowledge and

understanding of their own manufacturing system.

Practical issues

Training. With the advent of easier to use commercial simulation systems

the issue of training is less significant, however, users must still

understand the basics of using simulation as well as using particular

simulation software.

Penetration. According to a survey by the UK’s Department of Trade and

Industry (DTI) (Simulation Study Group, 1991) the use of simulation is

low compared with CAD, MRP, etc. This is surprising since it is in

contrast with the high level of satisfaction expressed with those who

have used simulation.

Developments & trends

This section briefly discusses some developments in simulation and

speculates on future trends.

With the interesting demands for user-friendly software and the greater

availability of software libraries for creating them simulation user-

interfaces will become increasingly easier to use. There is an increase in

the use of graphical displays in which icons are dragged from a library

into the model. There is also a trend towards integration with other

software, hence in many package data export facilities exist to enable

the data to be easily moved, for example, to a spreadsheet.

Developments & trends

As noted earlier the costs of simulation software are likely to fall. The

increasing awareness of simulation and the increasing ease of use will

open up simulation to a wider audience and could result in lower prices

due to economies of scale. Also the advent of cheap packages such as

SIMUL8 could cause prices to fall.

There may also be a change in the way simulation models are built. It is

fair to say that the way in which discrete event simulation models are

built is different to many other approaches to building models. There are,

however, flow charting tools which have simulation capabilities

embedded within them. Hence there is a change here towards

embedding simulation into more traditional modeling tools thus requiring

less of a conceptual jump for new users.

Example :

Sample on Special Purposed Languages : GPSS

• First publish in 1961. Was developed for the express purpose of the

discrete systems.

• The system to be simulated is represented by a set of blocks

connected by lines.

• Each block represent an activity and each line represent the path to

the next activity.

• Entities that pass through the system are called transactions.

• The attributes are represented as parameter.

• Each block diagram is unique thus providing a ready interpretation

of the block diagram.

Example :

Sample on Special Purposed Languages : GPSS

Among the symbols used :

• GENERATE

• ADVANCE

A,B C,D,E,F,G

A,B

• TERMINATE

• TRANSFER

• ENTER

A

S

A

• SEIZE

• RELEASE

• LEAVE

A

A

A

QUEUE DEPART

MARK TABULATE

A AB B

A

A

B

Designing simulation experiments The final stage in analyzing a system with simulation is to...

Documents

Transcript of Designing simulation experiments The final stage in analyzing a system with simulation is to...