1. Chapter 4. Modeling Complex Systems 4.1. Introduction 4.2. List Processing in Simulation 4.3. A Simple Simulation Language: simlib 4.4. Single-Server Queuing System with simlib 4.5. Time-Shared Computer Model 4.6. Multiteller Bank with Jockeying 4.7. Job-Shop Model 4.8. Efficient Event-list Manipulation 1

2. 4.1. Introduction In Chapter 1 we discussed simulation modeling in general, and showed how to model and program in the C programming language two simple systems. Most real-world systems, however, are quite complex, and programming them without supporting software can be a difficult and time-consuming task. 2

3. In this chapter we first discuss list processing, which is an activity that takes place in most simulations. We then introduce simlib, which is a set of C support routines, which provides capabilities for some standard list-processing tasks as well as some other common simulation activities, such as: 1.Processing the event list 2.Accumulating statistics 3.Generating random numbers 4.Observations from a few distributions 5.Computing and writing out results. 3

4. Our purpose in this chapter: 1.Illustrate how more complex systems can be modeled, 2.Show how list processing and the simlib routines can help in their programming. Our intention in using simlib is purely educational; it allows one to more quickly understand how to model complex systems and how commercial simulation-software packages handle lists and other data. 4

5. 4.2. List Processing in Simulation The simulation models discussed in Chapter 1 were quite simple in that they contained either one or no lists of records other than the event list. Furthermore, the records in these lists consisted of a single attribute and were always processed in a FIFO manner. 5

6. However, most complex simulations require many lists, each of which may contain a large number of records, consisting in turn of possibly many attributes each. Furthermore, it is often necessary to process these lists in a manner other than FIFO. For example, it might be necessary to remove the record in a list with the smallest value of some attribute. 6

7. We will store lists in a two-dimensional array, with rows corresponding to records and columns corresponding to attributes. 7

8. 4.2.1. Approaches to Storing Lists in a Computer In the sequential-allocation approach, which was used in Chapter 1, the records in a list are put into physically adjacent storage locations, one record after another. In the linked-allocation approach, each record in a list contains its usual attributes and, in addition, pointers (or links) giving the logical relationship of the record to other records in the list. Records in a list that follow each other logically need not be stored in physically adjacent locations. 8

9. Advantages of linked allocation of lists for simulation modeling:  Adding, deleting, and moving records is much faster, which is critical for event-list management.  For some models, computer memory requirements can be reduced without increasing the chance of list overflow.  It provides a general framework that allows one to easily store and manipulate many lists simultaneously. 9

10. 4.2.2. Linked Storage Allocation Suppose that a list of records is to be stored in an array, that the rows of the array correspond to the records, and that the columns correspond to the attributes that make up the records. A list of records is called a doubly linked list if each record has associated with it a predecessor link and a successor link. The successor link (SL) (or forward pointer) for a particular record gives the physical row number in the array of the record that logically succeeds the specified record (equal to zero if no such record). 10

11. The predecessor link (PL) (or backward pointer) for a particular record gives the physical row number in the array of the record that logically precedes the specified record (equal to zero if no such record). The physical row number in the array that contains the first logical record in the list is identified by a head pointer (HP) (equal to zero if list is empty). The physical row number in the array that contains the last logical record in the list is identified by a tail pointer (TP) (equal to zero if list is empty). 11

12. At any given time a list will probably occupy only a subset of the rows of the array, and the “empty” rows available for future use are linked together in a list of available space (LAS) that is processed in a LIFO manner. When a row is needed to store an additional record, it is taken from the head of the LAS; and when a row is no longer needed to store a record, the row is returned to the head of the LAS. 12

13. Since all operations are done at the head of the LAS, it requires neither a TP (Tail Pointer) nor PLs (Predecessor Link), and we call it a singly linked list. At time 0 in a simulation, all rows in the array are members of the LAS, the SL (Successor Link) of row i is set to i + 1 (set to 0 for last row), all PLs are set to 0, and the HP (Head Pointer) for the LAS is set to 1. 13

14. Example 4.1: For the queueing simulation of Section 1.4, consider the list for the customers waiting in queue, with each record in the list having the single attribute, “time of arrival.” Suppose that at time 25 in the simulation that there are three customers in queue, with times of arrival 10, 15, and 25, and that these records are stored in (physical) rows 2, 3, and 1 of an array with 5 rows and 1 column. Rows 4 and 5 are members of the LAS. The situation is shown in Figure 4.1. 14

15. 15 0 List Head 15 25 10 Tail 0 Head 0 LAS 2 3 1 4 5 Physical row Physical row Figure 4.1. State of the lists at time 25, queueing simulation.

16. Suppose that the next event in the simulation (after time 25) is a customer arrival at time 40 and we would like to add an appropriate record to the list. Since the HP for the LAS is equal to 4, the record for the arriving customer will be placed in physical row 4 of the array and the HP for the LAS is now set to 5. 16

17. Since the new record will be added to the tail of the list and its TP is now equal to 1, the following operations are done:  The SL for the record in row 1 is set to 4.  The PL for the new record is set to 1.  The SL for the new record is set to 0.  The TP for the list is set to 4. The state of both lists after these changes have been made is shown in Figure 4.2. 17

18. 18 0 List Head 15 25 10 Tail 0 Head 0 LAS 2 3 1 5 Physical row Physical row Figure 4.2. State of the lists at time 40, queueing simulation. 40 4

19. Suppose that the next event in the simulation (after time 40) is the service completion at time 50 of the customer who was being served (at least since time 25). We want to remove the record of the customer at the head of the list so that this customer can begin service. Since the HP for the list is equal to 2 and the SL for row 2 is equal to 3, the following calculations or operations are performed:  The time of arrival of the record in row 2 is used to compute the delay of the customer who will enter service (delay = 50 – 10). 19

20.  The HP for the list is set to 3.  The PL for the record in row 3 is set to 0.  Row 2, which is no longer needed, is placed at the head of the LAS by setting its HP to 2 and the SL for row 2 to 5. The state of both lists after these changes have been made is shown in Figure 4.3. Thus, removing a record from the head of the list always requires setting only four links or pointers. 20

21. 21 0 List Head 15 25 10 Tail 0 Head 0 LAS 2 3 1 5 Physical row Physical row Figure 4.4. State of the lists at time 40, queueing simulation. 40 4

22. 22 0 List Head 25 40 15 Tail 0 Head 0 LAS 3 1 4 2 5 Physical row Physical row Figure 4.3. State of the lists at time 50, queueing simulation.

23. Example 4.2: For the inventory simulation of Section 1.5, the event list was stored in an array with each of the four event types having a dedicated physical location. If an event was not currently scheduled to occur, its entry in the list was set to  (represented by 10 30 ). However, for simulation models written in commercial simulation-software packages, the event list is stored as a linked list ranked in increasing order on event time, with events having an event time of  simply not included. 23

24. Moreover, since the event list is kept ranked in increasing order on event times (attribute 1), the next event to occur will always be at the head of the list. We need only remove this record to determine the next event time (attribute 1) and its type (attribute 2). Suppose that the event list for the inventory model is to be stored in an array of 4 rows and 2 columns. Column 1 will be used for the attribute “event time” and column 2 for the attribute “event type” – 1, 2, 3, or 4. 24

25. Suppose that at time 0 we know the following:  The first demand for the product (event type 2) will occur at time 0.25.  The first inventory evaluation (event type 4) will occur immediately at time 0.  The simulation will end (event type 3) at time 120.  There is no outstanding order scheduled to arrive (event type 1). The state of the event list and the LAS just after initialization at time 0 is shown in Figure 4.4. 25

26. 26 0 4 0.252 120 3 0 0 Event List LAS Head Tail Head 0 Physical row 3 1 2 Physical row 4 Figure 4.3. State of the lists just after initialization at time 0, inventory simulation.

27. Note that event type 1 is not included in the event list, and that event type 2 is in (physical) row 1 of the array since it was the first event record to be placed in the event list. To determine the next (first) event to occur at time 0, the following operations are performed:  The first record is removed from the event list.  The simulation clock is updated to the first attribute of the record (i.e., 0).  The event type of the next event to occur is set to the second attribute of this record (i.e., 4). 27

28.  Row 3, which contained this record, is placed at the head of the LAS. Since the next event type is 4, an inventory-evaluation event will occur next (at time 0). Suppose that an order is placed at time 0 and that it will arrive from the supplier at time 0.6. To place this order-arrival event in the event list, the following operations are performed:  Place 0.6 and 1 in columns 1 and 2 of row 3 (the head of the LAS). 28

29.  This new record is added to the event list by logically preceding down the event list (using the SLs) until the correct location is found. First, attribute 1 of the new record (0.6) is compared with attribute 1 of the record in row 1 (0.25). Since 0.6 > 0.25, the new record should be further down the list. Next, 0.6 is compared with attribute 1 of the record in row 2 (120). (Note that the SL of the record in row 1 is equal to 4.) 29

30. Since 0.6 < 120, the new record is placed between the records in physical rows 1 and 2 by adjusting the SLs and PLs for the three records.  Another inventory-evaluation event is scheduled at time 1 and placed in the event list. The state of both lists after all processing has been done at time 0 is shown in Figure 4.5. Note that multiple lists (in addition to the LAS) can be stored in the same physical array, potentially resulting in significant savings in storage space. 30

31. 31 0 4 0.252 120 3 0 0 Event List LAS Head Tail Head 0 Physical row 3 1 2 Physical row 4 Figure 4.4. State of the lists just after initialization at time 0, inventory simulation.

32. 32 0.25 2 0.61 120 3 0 0 Event List LAS Head Tail Head 0 Physical row 1 3 4 1 4 2 Figure 4.5. State of the lists after all processing has been done at time 0, inventory simulation.

33. 4.3. A Simple Simulation Language: simlib simlib is a C-based simulation “language,” which is designed to provide some insight into the operation of commercial simulation software and to provide a vehicle for understanding how to simulate systems more complex than in Chapter 1. simlib can do the following:  File a record in a list (first, last, or ranked on an attribute)  Remove a record from a list (first or last) 33

34.  Process the event list  Compute discrete-time statistics on variables of interest (e.g., average delay in queue)  Compute continuous-time statistics on variables of interest (e.g., time-average number of items in inventory)  Generate random values from the distributions used in Chapters 1 and 2  Provide output statistics in a “standard” format 34

35. The following are some of the characteristics of simlib:  It is a collection of doubly linked lists residing in dynamic memory, with space allocated as new records are filed into the lists, and space freed as records are removed from the lists.  There is a maximum of 25 lists.  Records in a list can have up to 10 attributes, with all data stored as type float. 35

36.  List 25 is reserved for the event list, with attribute 1 being the event time and attribute 2 being the event type. This list is kept sorted in increasing order on event time, so that the top record refers to the next event. 36

37. 4.5. Time-Shared Computer Model A company has a computer with a single CPU and n terminals, as shown in Figure 4.6. The operator of each terminal “thinks” for an amount of time that is exponentially distributed with mean 25 seconds, and then sends to the CPU a job having a service time that is exponentially distributed with mean 0.8 second. 37

38. 38 CPU 1 2 n Queue Unfinished jobs Finished jobs Terminals Computer Figure 4.6. Time-shared computer model.

39. Arriving jobs join a single queue for the CPU but are served in a round-robin rather than FIFO manner. This is, the CPU allocates to each job a maximum service quantum of length q = 0.1 second. If the (remaining) service time of a job, s seconds, is no more than q, the CPU spends s seconds, plus a swap time of second, processing the job, which then returns to its terminal. 39

40. However, if s > q, the CPU spends second processing the job, which then joins the end of the queue, and its remaining service time is decremented by q second. This process is repeated until a job’s service is eventually completed, at which point it returns to its terminal, whose operator begins another think time. 40

41. Let be the response time of the ith job to finish service, which is defined as the time elapsing between the instant the job leaves its terminal and the instant it is finished being processed at the CPU. For each of the cases n = 10, 20, …, 80, we use simlib to simulate the computer system for 1000 job completions and compute the average response time of a job, the time-average number of jobs waiting in the queue, and the CPU utilization. 41

42. Assume that all terminals are in the think state at time 0. The company would like to know how many terminals it can have on its system and still provide users with an average response time of no more than 30 seconds. The events for this model are: 42 Event descriptionEvent type Arrival of a job to the CPU from a terminal, at the end of a think time 1 End of a CPU run, when a job either completes its service requirement or has received the maximum processing quantum q 2 End of the simulation3

43. The following are the simlib lists and the attributes for their records: 43 ListAttribute 1Attribute 2 1, queueTime of arrival of job to computer Remaining service time 2, CPUTime of arrival of job to computer Remaining service time after the present CPU pass (negative if the present CPU pass is the last one needed for this job) 25, event listEvent timeEvent type

44. The simlib program and explanatory flowcharts are given in Figures 4.15 through 4.23 in the book. The following numerical results were obtained from running the simulation: 44 Number of terminals Average response time (seconds) Average number in queue Utilization of CPU 101.3240.1560.358 204.1650.9290.658 305.5054.4530.914 4014.69814.9040.998 5024.59323.8710.998 6031.71234.9581.000 7044.31044.6660.999 8047.54751.1581.000

45. As expected congestion in the computer gets worse as the number of terminals increases. It appears that the system could handle about 60 terminals without the average response time getting much larger than 30 seconds. However, at this number the CPU would be busy nearly all of the time. It should be kept in mind that the results for each number of terminals are based on a single run of the simulation (of somewhat arbitrary length) and are thus of unknown precision. 45

46. 4.6. Multiteller Bank with Jockeying A bank with five tellers opens at 9 A.M. (no customers present) and closes at 5 P.M., but operates until all customers in the bank by 5 P.M. have been served. Interarrival times of customers are IID exponential random variables with mean 1 minute and service times are IID exponential random variables with mean 4.5 minutes. Each teller has a separate queue. An arriving customer joins the shortest queue (leftmost in case of ties). 46

47. Let n i be the total number of customers in front of teller i (in service plus in queue) at a particular instant. If the completion of a customer’s service at teller i causes n j > n i + 1 for some other teller j, then the customer from the tail of queue j jockeys to the tail of queue i (closest, leftmost queue jockeys if several such customers). If teller i is idle, the jockeying customer begins service at teller i (see Figure 4.7). 47

48. 48 1 2 34 5 Figure 4.7. The customer being served by teller i = 3 completes service, causing the customer from the tail of queue j = 2 to jockey.

49. The bank’s management is concerned with operating costs, as well as the quality of service currently being provided to customers, and is thinking of changing the number of tellers. For each of the cases n = 4, 5, 6, and 7 tellers, we use simlib to simulate the bank and compute the time-average total number of customers in queue, the average delay in queue, and the maximum delay in queue. 49

50. The events for this model are as follows: The following are the simlib lists: 50 Event descriptionEvent type Arrival of a customer to the bank1 Departure of a customer after completion of his/her service 2 Bank closes its doors at 5 P.M.3 ListAttribute 1Attribute 2Attribute 3 1 through n, queues Time of arrival to queue --- n + 1 through 2n, tellers --- 25, event listEvent timeEvent typeTeller number if event type = 2

51. We need only a single sampst variable for this model: The following are the random-number stream assignments: 51 sampst variable numberMeaning 1Delay in queue (or queues) StreamPurpose 1Interarrival times 2Service times The simlib program and explanatory flowcharts are given in Figures 4.27 through 4.35 in the book. The following numerical results were obtained from running the simulation:

52. 4 tellers Average number in queue = 51.319 Delay in queue (minutes): 5 tellers Average number in queue = 4.441 Delay in queue (minutes): 52 AverageNumber of values MaximumMinimum 63.223501156.3630.000 AverageNumber of values MaximumMinimum 4.48148321.8870.000

53. 6 tellers Average number in queue = 0.718 Delay in queue (minutes): 7 tellers Average number in queue = 0.179 Delay in queue (minutes): 53 AverageNumber of values MaximumMinimum 0.76446716.5100.000 AverageNumber of values MaximumMinimum 0.1764936.9710.000

54. It is definitely not advisable for the bank to reduce the number of tellers from five to four, since the average delay in queue would then be approximately 1 hour. Increasing the number of tellers from five to six will provide a modest (the book says significant) improvement in customer service. For example, the average delay in queue would only be reduced from 4.48 minutes to 0.76 minute. 54

55. Whether this is economically advisable would depend on how management values this improvement in customer service relative to the cost of an additional teller. Adding a seventh teller definitely does not seem advisable. 55

56. 4.7. Job-Shop Model A manufacturing system consists of five workstations, and at present stations 1, 2, …, 5 consist of 3, 2, 4, 3, and 1 identical machine(s), as shown in Figure 4.8. Jobs arrive at the system with interarrival times that are IID exponential random variables with mean 0.25 hour. Jobs are of type 1, 2, and 3 with respective probabilities 0.3, 0.5, and 0.4. 56

57. 57 1 2 3 5 4 Type 1 job Figure 4.8. Manufacturing system showing the route of type 1 jobs.

58. Job types 1, 2, and 3 require 4, 3, and 5 tasks to be done, and each task must be done at a specified station and in a prescribed order. The routings for the different job types are: There is a single FIFO queue at each workstation. 58 Job typeWorkstations in routing 13, 1, 2, 5 24, 1, 3 32, 5, 1, 4, 3

59. The time to perform a task at a particular machine is an independent 2-Erlang (Probability distribution) random variable whose mean depends on the job type and the station to which the machine belongs. (If X is a 2-Erlang random variable with mean r, then X = Y 1 + Y 2, where Y 1 and Y 2 are independent exponential random variables each with mean r / 4. 59

60. The mean service times for each job type and each task are: We will simulate the system for 365 eight-hour days (with no loss of continuity between days) and compute the average total delay in queue for each job type and the overall average job total delay. 60 Job typeMean service times for successive tasks (hours) 10.50, 0.60, 0.85, 0.50 21.10, 0.80, 0.75 31.20, 0.25, 0.70, 0.90, 1.00

61. We use the true job-type probabilities 0.3, 0.2, and 0.5 as weights in computing the latter quantity. In addition, we will compute the average number in queue, the utilization, and average delay in queue for each station. Suppose that all machines cost approximately the same and that the company can purchase one new machine to improve system efficiency. We will use the results of the above simulation to decide what additional simulation runs should be made. 61

62. From these additional runs, we will use the overall average job total delay to help decide what type of machine the company should buy. The events for this model are: 62 Event descriptionEvent type Arrival of a job to the system1 Departure of a job from a particular station2 End of the simulation3

63. We will use the following list structure: 63 ListAttribute 1Attribute 2Attribute 3Attribute 4 1 to 5, queues Time of arrival to station Job typeTask number--- 25, event list Event timeEvent typeJob typeTask number

64. We will use the following sampstat variables: 64 sampst variable numberMeaning 1Delay in queue at station 1 2Delay in queue at station 2 3Delay in queue at station 3 4Delay in queue at station 4 5Delay in queue at station 5 6Delay in queues for job type 1 7Delay in queues for job type 2 8Delay in queues for job type 3

65. We will use the following timestat variables: The random-number stream assignments are: 65 timestat variable numberMeaning 1Number of machines busy in station 1 2Number of machines busy in station 2 3Number of machines busy in station 3 4Number of machines busy in station 4 5Number of machines busy in station 5 StreamPurpose 1Interarrival times 2Job types 3Service times

66. The simlib program and explanatory flowcharts are given in Figures 4.39 through 4.45 in the book. The following are the results from running the simulation: Overall average job total delay = 10.870 66 Job typeAverage total delay in queue 110.022 29.403 315.808

67. WorkstationAverage number in queue Average utilization Average delay in queue 114.3100.9693.055 211.4040.9785.677 30.7110.7190.177 417.0980.9616.110 54.0950.7971.043 67 Weighted by job type, the average time spent by jobs waiting in queues was almost 11 hours. This is not the average time in the system, since it does not include processing times at the stations.

68. Looking at the statistics by station, it appears that the bottlenecks are at stations 1, 2, and 4, with station 4 perhaps being the worst. Thus, we made three additional runs, adding a machine to each of these stations to see which type of new machine would improve system performance the most. (Stations 3 and 5 appear to be relatively uncongested, so we did not consider them for a new machine.) 68

69. Using the overall average job total delay as the measure of performance, the results from these additional simulations are given in the following table. From simply looking at these numbers, we see that a machine should apparently be added to station 4 to obtain the greatest reduction in overall average job total delay. As usual, this conclusion is rather tentative, since we have only made a single simulation run of each system variant and the results are quite close. 69

70. Overall average job total delays for current and proposed system configurations: 70 Number of machines in stationsOverall average job total delay (in hours) 3, 2, 4, 3, 1 (current configuration)10.9 4, 2, 4, 3, 1 (add a machine to station 1)8.1 3, 3, 4, 3, 1 (add a machine to station 2)7.6 3, 2, 4, 4, 1 (add a machine to station 4)7.5