University of Cincinnati Badminton Club Practice Session Simulation

Simulation Project
University of Cincinnati Badminton Club
Submitted by
Sarita Maharia
Masters in Business Analytics
M12430569

Simulation Project: University of Cincinnati Badminton Club Prepared By: Sarita Maharia
1
Table of Contents
Chapter 1 – Introduction...............................................................................................................................2
1.1 Introduction.......................................................................................................................................2
1.2 Problem Statement...........................................................................................................................2
1.3 Assumptions........................................................................................................................................2
Chapter 2 – Data Collection and Distribution...............................................................................................4
2.1 Data Collection....................................................................................................................................4
2.2 Fitting Distributions.............................................................................................................................4
Chapter 3 – Arena Model..............................................................................................................................6
3.1 Proposed Model Development...........................................................................................................6
3.2 Model Simulation..............................................................................................................................15
Chapter 4 – Results and Interpretation ......................................................................................................17
4.1 Results...............................................................................................................................................17
4.2 Interpretation....................................................................................................................................24
Chapter 5 – Alternate Scenarios and Improvements in The System ..........................................................25
5.1 Scenarios...........................................................................................................................................25
5.2 Output from Process Analyzer..........................................................................................................25
Chapter 6 – Conclusion...............................................................................................................................28

2
Chapter 1 – Introduction
1.1 Introduction
This project is developed as part of final submission for BANA 7030 Simulation Modeling and Methods
course. The aim of the project is to create a working model of the University of Cincinnati’s badminton
club operation during the practice sessions. Arena from Rockwell Software is used to develop this
model. The model layout is based on club practice sessions and players are the entities in the model.
The input data for this model is present in form of number of players attending the practice session in
half hour intervals. The practice and match duration timings are recorded and data is fed to Arena in
form of input distributions. Arena provides detailed output in terms of waiting time of players, total time
in system, resource utilizations etc. Based on the collected statistics and the scope for improvement,
modifications are done to the existing system and statistics are compared to provide recommendations.
1.2 Problem Statement
University of Cincinnati Badminton Club members participate in practice sessions on Friday, Saturday
and Sunday in Recreation Center. Currently, there are 76 registered members in the club. Badminton
rackets, shuttles and badminton nets are provided by the club. Club members are given chance to play
doubles match on first come first serve basis. Members are also allowed to practice for approx. 5
minutes before starting the doubles match.
Once, all badminton courts are full or badminton rackets are occupied, members must wait for any
ongoing match to finish. On Fridays, players usually have to wait more out of all 3 practice days. So, this
project is developed to simulate the club’s practice sessions to find better usage of club’s resources and
to find alternative scenario to reduce member’s waiting times.
Three models, each for a practice session, are developed for this project. All elements except member
arrival rates are same across three models.
Throughout this report, member or player will be used interchangeably to denote a person participating
in a practice session.
1.3 Assumptions
The model is based on certain assumptions and can’t simulate the system exactly. However, the model
doesn’t digress from the system and recommendations can be used for improvements. Following are
the assumptions for creating the model:
1. Members play only doubles matches in the practice sessions.
2. Members practice for approx. 5 minutes before beginning a new match.
3. Shuttle supply is unlimited.
4. This model doesn’t account for sudden increase or decrease in number of participating
members during tournament or holiday seasons.

3
5. Match duration and practice duration before each match are same on each practice session. So,
the distribution fitted using a single practice session is used for all three practice sessions.
6. The data for decision modules was taken from the club.
7. The practice sessions are 2.5 hours long each.

4
Chapter 2 – Data Collection and Distribution
2.1 Data Collection
Data is collected with permission of badminton club by attending practice sessions held in a week. The
club president shared information regarding number of registered members and cost of equipment.
2.2 Fitting Distributions
To feed member arrival timing, practice and match duration to Arena, we need to fit a distribution to
raw data. These distributions are given as input to Arena. Rockwell’s Input Analyzer is used to fit
distributions to raw data. The raw data is fed to Input Analyzer in form of a text file and the Input
Analyzer fits a suitable distribution. This project requires input distribution for following:
1. Member arrivals
2. Practice duration before each match
3. Match duration
Player arrivals
The data is collected in form of number of players arrived in a practice session in 30 minutes intervals.
Inter-arrival time between player arrivals is not available, so stationary Poisson process is assumed over
each interval. Arena accepts arrival rate for each interval in form of arrivals per hour. So, the 30 minutes
arrival rate is multiplied by 2 to compute arrival rate per hour. Since the arrival rate is different in each
interval, non-stationary Poisson process is required for this project. Table 1.1 shows the 30 minutes
interval timings and corresponding arrival rate (per hour) for different days:
Friday Saturday Sunday
Interval Rate (Arrivals
per hour)
per hour)
per hour)
18:00 - 18:30 12 08:00 – 08:30 0 10:00 – 10:30 2
18:30- 19:00 38 08:30 – 09:00 4 10:30 – 11:00 12
19:00 – 19:30 24 09:00 – 09:30 6 11:00 – 11:30 20
19:30 – 20:00 8 09:30 – 10:00 12 11:30 – 12:00 8
20:00 – 20:30 2 10:00 – 10:30 2 12:00 – 12:30 6
Table 1 Arrival Rates
Practice duration before each match
Players practice for some time before starting a match. Raw data of practice duration for a complete
practice session is fed to Rockwell’s Input Analyzer. Figure 1 is the fitted distribution:

5
Figure 1 Fitted distribution of practice duration before each match
Match duration
Raw data of match duration for a complete practice session is fed to Rockwell’s Input Analyzer. Below is
the fitted distribution:
Figure 2 Fitted distribution of match duration

6
Chapter 3 – Arena Model
3.1 Proposed Model Development
The badminton club practice session involves multiple steps. The sessions are held on Friday, Saturday
and Sunday. The flow remains same for all. Below is the logical flow of members in the system:
1. Players arrive for a practice session.
2. If a player doesn’t own a racket, he waits to seize a racket. If player owns personal racket,
directly go to step 3.
3. Check whether 4 players are available to play a doubles match. If not, wait till 4 players become
available.
4. Once 4 players are available, wait to seize a badminton court, practice and play a doubles match
and then release the badminton court.
5. Each of the 4 players release racket, if they seized any.
6. Player decides if he wants to exit the session. If player doesn’t want to exit, he goes back to step
2.
Below table 2 has the Arena modules used to build the model:
Arena
Module Type
Usage Comments
Create Create entity referred as player Created as per non-stationary Poisson
schedule
Decide Routes players to 2 different routes – for
player with personal racket and without
racket
2-Way by Chance with 16% probability to
have a player with personal racket
Assign Assign one of the below 2 entity types –
Player With Racket
Player Without Racket
2 Assign modules are placed in each
branch of above Decide module
Seize Seize badminton racket Required only if entity type is ‘Player
Without Racket’. There are 8 rackets in
playing condition currently in the club.
Batch Create a batch of 4 players so that
doubles match can be played
Entity name of the grouped players is
referred as ‘Player Batch’
Seize Seize badminton court There are 4 badminton court setups
available in the club.
Delay Block Store, delay and unstore for practice
and match duration
The delay is based on fitted distribution
for practice and match durations.
Release Release below –
Badminton Court
Badminton racket, if seized by a player
Separate Separate players batch After separate, players are treated as
individual entities
Decide Decide if player leaves the practice
session
Approx 10% players leave the practice
session after a match

7
Arena
Module Type
Usage Comments
Decide If player doesn’t leave practice session,
decide one of the below routes to circle
back the player –
Batch Module Queue, or
Seize Racket Queue
This decision is made on entity type –
Player With/Without Racket
Dispose Dispose players off the practice session Used only if player decides to exit the
session
Table 2 Arena modules used to build models
In addition to above, resources, queues, schedule, entity, storage and variable Arena processes are also
used. Figure 3 shows snapshot of the model developed using Arena:
Figure 3 Snapshot of Arena model for Friday practice session
All elements for each logical step along with details from Arena model developed for Friday practice
session are presented below:
1. Players arrive for a practice session
Players arrive as per below create module and schedule:

8
Figure 4 Player arrival setup in Arena
2. If a player doesn’t own a racket, he waits to seize a racket. If player owns personal racket,
directly go to step 3.
Decision module to route players (Figure 5):
Figure 5
Assign entity types as below in different routes taken as per the decide module (Figure 6):
Figure 6

9
Seize module to seize badminton racket if player doesn’t own one (Figure 7):
Figure 7
3. Check whether 4 players are available to play a doubles match. If not, wait till 4 players become
available.
Batch module Batch size variable are used as below (Figure 8):

10
Figure 8
4. Once 4 players are available, wait to seize a badminton court, practice and play a doubles match
and then release the badminton court.
First seize badminton court (Figure 9):
Figure 9

11
Practice and play duration delay with store/unstore functionality implemented through delay
block as below:
Figure 10
The duration expression in Figure 10 is used from distribution fitted on raw data by Rockwell’s
Input Analyzer.
Release badminton court:
Figure 11
Separate 4 players batch into individual player entity as per Figure 12:

12
Figure 12
5. Each of the 4 players release racket, if they seized any.
Decide if player owns racket based on entity type:
Figure 13
Based on above decide module in Figure 13, if player doesn’t own racket, release racket:
Figure 14

13
6. Player decides if he wants to exit the session. If player doesn’t want to exit, he goes back to step
2, else player exits.
Decide module to check if player exits session:
Figure 15
If player wants to exit based on Figure 15, dispose the player:
Figure 16
If player doesn’t exit system, decide route to circle back the player:
Figure 17

14
Entity pictures are assigned as per figure 18:
Figure 18 Entity picture assignment
Variable animation to record number of matches played and queue animations are as below:
Figure 19 Animations set up
Now, for Saturday practice session, the only parameter changed is arrival rate of players. Below is the
setup for arrival rate, rest of the model is same:
Figure 20 Saturday arrival schedule

15
Similarly, for Sunday practice session model, below is the updated arrival rate:
Figure 21 Sunday arrival schedule
3.2 Model Simulation
The run parameters are setup as in Figure 22 (Same for all 3 practice sessions):
Figure 22 Run parameter setup

16
Snapshot of animation while running the model presented in Figure 23:
Figure 23 Snapshot of animation from running the model

17
Chapter 4 – Results and Interpretation
4.1 Results
Arena provides detailed results for entities, queues and resources in the simulated system. The three
models for three practice sessions are run with same run parameters.
The first statistics presented by Arena is number of player who exited the system. Since in this model
the players are circulated back in the system most of the time, so we have very less number of players
exiting the system as shown in Table 3 and Figure 24.
5 2 3
Table 3 Count of players out of the model
Figure 24 Snapshot from Category Overview report
In following sections, results are presented from these simulations split by entity, queue and resource.
By Entity
As soon as player enters the system, the entity is changed to one of below based on whether he owns a
personal racket –
Player With Racket
Player Without Racket

18
So, results by entity are split between these 2 entity types. Arena reports total and average time for
both entity types. Table 4 has the summary of average times (in minutes) from 50 replications of each
practice session:
Player With
Racket
Player
Without
Racket
Player With
Racket
Player
Without
Racket
Player With
Racket
Player
Without
Racket
Average
Total Time
45.3952 52.1879 17.3176 39.5264 27.3517 49.0561
Minimum
Average
Total Time
0 0 0 0 0 0
Maximum
Average
Total Time
94.1818 100.97 102.86 95.1297 27.1032 59.5666
Average
Wait Time
6.3539 22.4053 4.5937 10.9137 4.7153 15.5254
Minimum
Average
Wait Time
0 0 0 0 0 0
Maximum
Average
Wait Time
16.7988 67.8996 51.0214 48.7586 94.5913 133.49
Table 4 Summary of average times (in minutes) from 50 replications of each practice session
From Table 4, below are some of the interpretations:
On Friday, average total time of players with racket is approx. 45 minutes and without racket is 52
minutes. Similarly, average total time of players with racket on Saturday is 17 minutes and without
racket is 39 minutes. Then, players with racket on average spend 27 minutes on Sunday and without
racket spend 49 minutes.
Players have to wait more on Friday followed by Sunday. 22 minutes of wait time in 150 minutes
practice session is more from time perspective of players who are mostly students. (Numbers
highlighted in yellow in above table 4).
Usually players without racket have more average wait time than players with racket.
The maximum average wait time also provide some scope of improvement as it’s not desirable to have
maximum wait of 133 minutes.
The snapshots from Arena reports are given below for each practice session:

19
Friday snapshot of report published by Arena shown in Figure 25.
Figure 25 Category Overview Report - Friday
Saturday snapshot of report published by Arena:
Figure 26 Category Overview Report - Saturday

20
Sunday snapshot of report published by Arena:
Figure 27 Category Overview Report - Sunday
Other than entity time, Arena also gives number in, number out and time average number of players in
the system. On an average, 41 players attend Friday session, 11 attend Saturday session and 23 attend
Sunday session. The snapshots from Arena reports are given below for each practice session. Friday has
maximum numbers for all – number in, number out and time average number of players in the system.
The entity named Player Batch denotes number of times a group of 4 players is created to play a match.
Even though Friday has more players, the matches played are 12 in comparison to Sunday when 10
matches are played.
Friday snapshot of report published by Arena:

21
By Queue
Arena presents both waiting time in queue and number waiting in queue for all queues defined in the
system. We have 3 queues in model – seize badminton racket queue, seize badminton court queue and
create batch of 4 players queue.

22
As per below snapshots from Arena reports for each practice session, maximum average waiting time
(27 minutes) is in seize badminton racket queue on Friday than other 2 days. Also, Saturday has more
waiting in creating batch of 4 players due to less number of participants.
Figure 33 Category Overview Report – Sunday

23
By Resource
Arena resource utilization reports help to identify the overloaded resources or bottlenecks. Below are
the scheduled utilizations for each practice sessions. The rackets on Friday session have very high
utilization of approx. 85%. It can be reduced to avoid bottlenecks in system due to lack of rackets. Also,
the badminton court on Saturday is very underutilized (19%). Recreation center space can be freed up
for other sports by reducing number of court setups. Since, there are very less number of players on
Saturday, we will focus on Friday and Sunday sessions for improvement in waiting times and resource
utilizations.

24
4.2 Interpretation
Below is summary of interpretations derived from results presented in 4.1 section:
• Players have to wait more on Friday followed by Sunday.
• Usually players without racket have more average wait time than players with racket.
• The rackets on Friday session have very high utilization of approx. 85%. It can be reduced to
avoid bottlenecks in system due to lack of rackets.
• Also, the badminton court on Saturday is very underutilized (19%). Recreation center space can
be freed up for other sports by reducing number of court setups.
• Maximum average waiting time (27 minutes) is in seize badminton racket queue on Friday than
other 2 days. Also, Saturday has more waiting in creating batch of 4 players due to less number
of participants.
• Even though Friday has more players, the matches played are 12 in comparison to Sunday when
10 matches are played.
Improvements to be done in alternative model:
• Reduce waiting time of players without racket in Friday session
• Reduce utilization of rackets on Friday by adding more rackets.
• Reduce waiting time in seize badminton racket queue.

25
Chapter 5 – Alternate Scenarios and Improvements in The System
Rockwell’s Process Analyzer is used to evaluate alternative scenarios. The input to process analyzer is
the file generated by Arena while running the model. After giving the input file, controls and required
responses are defined. The alternate scenarios for this project include number of badminton rackets and
badminton courts as controls. The response variable to evaluate here is player’s waiting time and
scheduled utilization of resources given in controls. The Process Analyzer usage to find best alternate
scenario is done only for Friday model as it has worst waiting times.
5.1 Scenarios
Base Scenario
It is from the base model with no modifications to controls.
Alternate Scenarios with modified controls (Table 5)
Scenario Name Badminton Courts Badminton Rackets
Alternate Scenario 1 4 10
Table 5 Alternate Scenarios
5.2 Output from Process Analyzer
The Process Analyzer fills responses after running 50 replications for each scenario shown in Figure 37.
Figure 37 Output from Process Analyzer

26
Box and whisker plot from Process Analyzer comparing the waiting time of players without racket.
Figure 38 Box and whisker plot from Process Analyzer
It shows the best scenario to be alternate scenario 5. This scenario has reduced waiting time of players
without racket from 22 minutes in base model to 12 minutes. Comparing two alternate scenarios 3 and
6, the waiting time is reduced in later one by 5 minutes. Setting up 2 extra badminton courts doesn’t
incur any extra cost to club as the club area has open space between 4 court setups. Thus, we will
consider alternate scenario 5 over alternate scenario 3. Process Analyzer provides best scenario based
on statistical significance. Table 6 shows the data provided by Process Analyzer for the response variable
in Figure. The best scenario 5 has minimum 95% confidence interval.
Table 6 Output from Process Analyzer
The number of rackets can be increased further to reduce the waiting time, but this is not considered
due to limited club budget for purchasing new rackets and repairing existing rackets.
In alternate scenario 5, the number of games played (21) is also maximum (Figure 37). It’s also an
improvement in the system given this alternate scenario is adopted.
Scenario Min Max Low High 95% CI
Base 0 67.9 18.88 25.93 3.528
Alternate 1 0 73.04 19.84 27.16 3.659
Alternate 2 0 52.87 13.8 18.37 2.286
Alternate 3 0 60.8 15.79 19.64 1.924
Alternate 4 0 44.95 13.4 16.78 1.693
Alternate 5 0 51.26 10.63 13.44 1.406

27
To verify resource utilizations for recommended alternate scenario, draw below column chart in process
analyzer:
Figure 39 Resource Scheduled Utilizations
This chart shows that alternate scenario 5 has reduced scheduled utilization for rackets. This is one of
the improvements desired in the base model. The recommended alternate scenario 5 has approx. 75%
scheduled utilization of rackets and 66% scheduled utilization of badminton courts.

28
Chapter 6 – Conclusion
The model is developed for University of Cincinnati’s Badminton Club practice sessions on 3 days a week
using Arena. The output provided by Arena is analyzed to find scope of improvement in terms of player’s
waiting time for seizing a racket. The average waiting time is maximum for Friday’s practice session for
players who don’t own a racket. Based on these findings, various alternate scenarios are simulated in
Rockwell’s Process Analyzer. The best scenario given is statistically significant and has lesser waiting
time for seizing racket over the base model. The number of games played has also increased with the
recommended alternate scenario. With the recommended approach, reducing the waiting time of
players will be beneficial to club as members will tend to renew the membership and will attract new
members as well.
References
1. Simulation with Arena-David Kelton W., Randall P. Sadowski, Nancy B. Zupick
2. Data collected from visiting practice sessions of the club

University of Cincinnati Badminton Club Practice Session Simulation

Recommended

Recommended

More Related Content

Similar to University of Cincinnati Badminton Club Practice Session Simulation

Similar to University of Cincinnati Badminton Club Practice Session Simulation (20)

Recently uploaded

Recently uploaded (20)

University of Cincinnati Badminton Club Practice Session Simulation