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.

Designing simulation experiments 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.

Designing simulation experiments 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.

Designing simulation experiments 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.

Designing simulation experiments 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.

Designing simulation experiments 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.

Bank Simulation Example 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.

Bank Simulation Example 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.

Bank Simulation Example 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

Bank Simulation Example 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.

Bank Simulation Example Simulation Design and Implementation Event descriptionEvent type Arrival of a customer to the bank1 Departure of a customer upon completion of service 2 Bank closes its doors at 5 p.m.3

Bank Simulation Example 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)

SubprogramPurpose ArriveProcesses 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_ClosesCancels the next scheduled arrival, thus preventing any future arrivals. ReportGenerates 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

Languages & Simulators Warning 1 : Know which features are appropriate Certain 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.

Languages & Simulators Input considerations Point and click capability Importing file Exporting a file Syntax Interactive run controller (IRC) Interactive to other languages Input data analysis capabilities

Languages & Simulators Processing considerations Powerful constructs Speed Run-Time Flexibility Random variate generator Reset Independent replication Attributes and global variables Programming Portability

Languages & Simulators Output considerations Standardized report Customized report Business graphic Database maintenance Collection of Mathematical desired Custom performance Measures Write to file

Languages & Simulators Environment considerations Ease of use Ease of learning Quality of documentation Animation capability Run-only version Stability History Track record Support

Languages & Simulators 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.SLAMSIMAN

Languages & Simulators 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.ProModelTaylorIIDenebQuest

Languages & Simulators 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 partsArenaSIMAN

Languages & Simulators 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.

Languages & Simulators 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.

Languages & Simulators 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.

Languages & Simulators 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.

Languages & Simulators 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.Department of Trade and Industry (DTI)Simulation Study Group, 1991

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. SIMUL8 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 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

QUEUEDEPART MARK TABULATE A A B B A A B