Decision Science Programming

Decision Science: Programming Assignment

Haide College, Autumn Semester 2024

Due dates:

• Milestone (quiz): 7 November 2024, 23:59. [5% course mark]
• Submission (code): 14 November 2024, 23:59 [20% course mark]

Purpose

The purpose of this assessment is to create a fully functional simulation of a more complex system. Buildingsimulations is one of the key objectives of this course. You will need to be able to do this in an industry orgovernment job working in decision sciences. Building a simulation is also the best way to absorb and gain adeep understanding of the ideas and topics that are discussed in this course. Even if you are just managingsimulations projects, you should have some experience in creating the simulation itself.This is quite a large and difficult task, but the assessment will provide considerablestructure.Outcomes This Task addresses the following Course Learning Outcomes:communicate how randomness and controlled variation can be used to model complex systems in a rangeof application domains such as industry, health, and transportation;

• create a model of a real-world problem specified in words and implement it as a discrete-event simulation;
• validate results from a discrete-event simulation.

Scenario You will be simulating a passport (immigration) control queuing system at an airport. This is based on the

queuing system for foreign travelers arriving at Qingdao airport.Passengers get off their flight, walk to the passport checkpoint area and join a single primary queue. Whenthey get near the front of this queue they are organised into several short secondary queues. Each secondaryqueue leads to a counter staffed by an attendant, who checks the passenger’s passport and clears them to theirjourney.

Additional features. The airport uses some strategies to make this process more efficient. This includes:

1. extra counters open when the system is busy, and close when it is less busy
2. attendants regularly rotate so they can take breaks
3. passengers may be served at a counter not corresponding to their outside their allocated secondary queuein some circumstances

Assumptions You should assume the following:

• all queues operates in a First in First Out (FIFO) basis
• there are 2 counters open at the start of the simulationTimes: all times are independent and– The interarrival time between flights is exponential with an expected value of 45 minutes– The number of passengers on each flight who will pass through this passport control area is uniformlydistributed between 15 and 25 passengers (similar to the number of foreign arrivals on a plane toQingdao)– The transit time for a passenger to walk from the plane to the queueing system is uniformlydistributed between 5 and 30 minutes– The service time for passengers once they reach a counter is Pareto distributed with a minimum

time of 2 minutes and an expected value of 4 minutesThe following assumptions relate to the additional features of the system.1• Additional feature 1. Extra counters open when the system is busy, and close when it is less busy– Let ncounters be the number of counters currently open, and N be the total number of passengersin the queuing system (main queue, all secondary queues and in service). An extra counter willopen if N > 10 × ncounters. A counter will close if N < 10 × (ncounters − 2).– There are a minimum of 2 counters and a maximum of 5 counters– When a counter “closes” this mean that no more passengers are accepted into its secondary queue.Any passengers currently in the secondary queue will be served as usual.

• Additional feature 2. Attendants regularly rotate so they can take breaks– Some of the counter attendants rotate at an interval of 30 minutes, during which time service atthe counter is paused for 1 minute. This means that the service time for any passenger at a rotatingcounter will increase by 1 minute.– For odd numbered counters, the first rotation is at 30 minutes from the start of the simulation(and then every 2 × 30 = 60 minutes)– For even numbered counters, thefirst rotation is at 60 minutes from the start of the simulation(and then every 2 × 30 = 60 minutes)Additional feature 3. Passengersmay be served at a counter not corresponding to their allocatedsecondary queue in some circumstances.– A passenger at the front of their secondary queue, who has been in their secondary queue for morethan 20 minutes will be served next at any available open counter. In the case of multiple passengersin this situation, priority is given to the passenger who has spent the longest waiting time in theirsecondary queue.– If an open counter is available and its secondary queue is empty, they will serve a passenger fromanother secondary queue. Priority is given to the passenger with thelongest secondary queuwaiting time.

• The airport is open 24 hours, 7 days a week.– The behaviour of the system is not influenced by the time of day.

• The airport has specified that they consider a single simulation running for one day of simulated time(1440 minutes) to be sufficient for statistical relevance.

Questions The airport’s management would like to plan for an anticipated increase in passenger numbers, as the number

to understand how best to manage their 代写Decision Science  Programming  staff, if additional counters need to be built, and whether their areany aspects of the queuing system that can be fine-tuned.Basedpassenger feedback, passengers areconcerned with total amount of time they must spend in this queuing system.The airport’s management wish to identifythe minimum number of counters that will ensure the expectedtotal time in the queuing system when the number of customers double is no worse than the current level.Airport management is also concerned with the well-being of their attendants, so would like to understand howthe frequency and length of their rotation impacts passenger experience.Note. You do not have to answer these questions as part of this assignment, but this motivates the use of parameters so we can vary the assumptions of our model. Your Task

This assessment is scaffolded into three parts:

Part 1: Modelling (Module 2)

• Part 2: Programming (Module 3)
• Part 3: Verification and testing (Module 4)

The details of each part are outlined in later in this brief. It is suggested you work through each of these inorder, although there may be some back and forth between Parts 2 & 3.2Requirements This assessment is worth 25% of your course mark. This is split between two partsMilestone online quiz (5%). Answer a series of short multiple choice/numerical answer questions todemonstrate your understanding of the queuing model and functionality of the simulation.Submission requirement: Submit onlinequiz via Cloudcampus.Julia code (20%). Write a simulation code in Julia according to the specification provided in this document.There are a total of 80 marks for this part of the assessment, broken down as follows:

• Basic functionality: code implements the basic functionality of this queuing system, as per the specification.

[40 marks]

• Additional feature 1: code implements this feature correctly. [12 marks]
• Additional feature 2: code implements this feature correctly. [12 marks]
• Additional feature 3: code implements this feature correctly. [12 marks]
• Code style: submission meets general style guidelines for good Julia code. [4 marks]

All the above are detailed in the rubric at the end of this document. Here you are required to submit a single

.jl file, which contains type definitions, data structures and functions to run the simulation.

• Submission requirement: Submit Julia file via Cloudcampus.
• Submission requirement: An include command on your file must not give an error, if it does give an

you will get 0 marks (since this prevents your code from being automatically tested).

If you need clarification about any of the above, please ask course staff during workshop, via email or via the

course discussion board.3Part 1: Modelling

In this part, you will model the system that you will be implementing.

The system You will be simulating a passport (immigration) control queuing system at an airport. This is based on thequeuing system for foreign travelers arriving at Qingdao airport.See page 1 (“Scenario”) of this document for a detailed description of the system.Tasks for Part 1 Before you commence coding you should perform a series of modelling tasks. These tasks will prepare you forPart 2, when you will implement a simulation in Julia. You should work through these tasks and complete theonline milestone quiz. Note you are not required tosubmitwritten responses to these points.Draw a schematic of the system. This can be a rough sketch on a piece of paper - this is a great way toet an initial understanding of the system.Describe the state(s) of the system.Hint: What state details are needed to answer supermarket owner’s questions?Describe the number of entities in the system in relation to the state(s).Hint: A simple equation may be helpful in this descriptionAssume there are four events in thesimulation:passengers leaves the aircraft after landing(FlightDisembarks), passenger arrives at queue (Arrival), passenger departs queue (Departure)and attendants rotating for a break (for additional feature 2, RotateAttendants). For each event:describe how each event changes the state of the system.describe the new events that may be created as a result of this eventDraw a state diagram, illustrating the possibly states of the system and how the state changes in responseto the variousevents.

6. Draw a flow chart illustrating your simulation structure.To be clear, you will not be asked to submit written responses to the above but your understanding of thesepoints will be assessed via the milestone quiz (worth 5% of your course mark).It is not possible to write a simulation code working through the above detail, so take your time here to geclear ideas about what you need to code before you start Part 2. 2: ProgrammingIn this part, you will start to program the model.

Reminder

The system to be modelled is described in page 1 of this document (“Scenario”)Tasks for Part 2

Before starting the process of coding up your simulation, go back to your work from Part 1 and think about ifthere are any further modelling details needed here. In particular you might like to carefully think about how toodel/implement the three “Additional features”.The main task here is to write code to implement a discrete-event simulation of the system.

• The code should follow the style of some other codes presented in this course. You might like to usethese as a starting point, or perhaps find it easier to start from an empty file.

• The process you need to follow is outlined below under the heading Specification.

By the end of this part, you should have a working simulation that can output results.In Part 3 you will test it and use it to create some data with a simulation harness.As part of your assessment, you will be required to submit one .jl file with your code for implementing thediscrete-event simulation.Specification This week you will start coding your simulation. A good deal of the structure of the code is provided.This is to help you! There is a lot written below, but by following itcarefully you will get a big starttowards developing your simulation.

• It ensure that everyone has a common starting point.
• It makes it easier to review and assess your progress by ensuring that everyone adopts the same basicstructure for their implementation.The last point is important. Your mark is be based on automated testing of your code. Hence you must set upyour code in the manner given, paying particular attentiontosetting up the data types exactly as describedbelow, otherwise these test will fail and you will lose marks.Here are the required specification details:

Filenames. Your code must be included in a single .jl files. These should be named:AirportOverseasPassports.jlThis should contain all of your data structures and functions. You will be provided with a file to runthis code AirportOverseasPassports_run.jl which will include the firstfileand run the simulation

 a set of parameters.

2. You should use the standard packages that you have been using in this course.These include:

• DataStructures
• Distributions
• StableRNGsCSV

You may wish to use a small set of additional packages such as Dates or Printf.Do not use any packages other than these or those that have been discussed in the course.

Your code must specify three data structures:

abstract type Event endmutable struct Passenger

...5mutable struct State ...Each will contain fields as required. The state structure should contain any queues or lists required, forinstance, the event list. More detail about each follows.

FlightDisembarks . . . an aircraft lands and unloads passengersArrival . . . a passenger arrives at the queuing system

• Departure . . . a passenger finish their passport check and leaves
• RotateAttendants . . . the counter attendants take a breakEach subtype of Event must be a mutable struct and must contain the following fields (with thetypes indicated):

• FlightDisembarks

– id . . . an integer valued event ID number (Int64)

– flight_id . . . the ID of the flight (Int64)

– no_passengers . . . the number of passengers from the flight that will be processed by thequeuing system, or nothing if the flight has not yetunloaded(Union{Nothing,Int64})Arrival– id . . . an integer valued event ID number (Int64)

– flight_id . . . the ID of the passenger’s flight– disembark_time . . . the time the passenger’s flight was unloaded (Float64)– passenger_id . . . an integervaluedpassengerID number, or nothing if the event does notyet have a customer allocated (Union{Nothing,Int64})Departure– id . . . an integer valued event ID number(Int64)– passenger_id . . . the ID of the departing passenger (Int64)– counter_id . . . the counter that serviced that serviced the passenger, or nothing if they

have not yet been served (Union{Nothing,Int64})RotateAttendants– id . . . an integer valued event ID number (Int64)– odd_attendants . . . true if odd numbered counters are rotating, false if even numberedcounters are rotating (Bool)You may optionally define constructor functions for each of these above subtypes (to initialise some fieldswith nothing or a particular value as appropriate).

5. The data structure Passenger should contain fields to record important event times in the lifetime ofthe passenger. These are

• id . . . an integer valued customer ID number (Int64)
• flight_id . . . the ID of the passenger’s flight (Int64)
• disembark_time . . . the time the passenger’s flight was unloaded (Float64)
• enter_primary_time . . . the time the passenger entered the primary queue (Float64)
• enter_secondary_time . . . the time the passenger entered the primary queue (Union{Float64Nothing})

• start_service_time . . . the time the passenger starts service (Union{Float64, Nothing})
• end_service_time . . . the time the passenger ends service (Union{Float64, Nothing})
• secondary_id . . . the ID of the passenger’s allocated secondary queue (Union{Int64, Nothing})
• counter_id . . . the ID of the counter the passenger was served by (Union{Int64, Nothing})
• attendant_rotated . . . true if the attendant rotated during service, false if not (Bool)

Initially unknown values above should be set to nothing when the Passenger is created. Similarly,

attendant_rotated should be initialised as false.

6. The data structure State will contain an event list (priority queue), queues for all resources in the system

and a few other details. These must be

• time . . . the current system time (Float64)
• event_list . . . the list of scheduled event (PriorityQueue{Event,Float64}, here priority is

the time of the event)

• primary_queue . . . queue of passengers waiting in the primary queue (Queue{Passenger})
• secondary_queues . . . vector of queues of passengers waiting in the secondary queues(Vector{Queue{Passenger}})6• in_service . . . vector of passengers currently being served, or nothing if there is no passengerat a given counter (Vector{Union{Passenger,Nothing}})

• n_entities . . . a counter of the number of entities in the simulation so far (Int64)
• n_events . . . a counter of the number of events in the simulation so far (Int64)
• n_flights . . . a counter of the number of flights that have unloaded passengers (Int64)
• n_open_counters . . . the number of currently open counter (Int64)The constructor function for State should initialise all queues with empty queues of the correct type,

ime to 0.0 and the counters to 0.Float64waiting time for a passenger to go to the next available counterhelpful_attendantsBoolcounter will serve passenger from outside their secondary queueNote some of these parameters are important to implementing some of the additional features:Additional feature 1: min_counters and; feature switched off if these are equal.

Additional feature 2: attendant_rotation_interval and attendant_rotation_time; featurecan be switched off if the interval is set to be greater than the total simulationtime.Additional features 3: secondary_rush_time and helpful_attendants; feature switched off ifhelpful_attendants is false.Random number generatorsYour code will use three random number generators. Store these as functions in a data structure structRandomNGs. For convenience, also store here a function that returns theresolution time. The code toefine this data structure is as followsstruct RandomNGs

rng::StableRNGs.LehmerRNG

interflight_time::Function

no_passengers::Function

transit_times::Function

service_time::Function

endYou should define a constructor function withfunction RandomNGs(P::Parameters)that takes the parameters structure as input and returns the random number generator and the fourfunctions. Initialise the random number generator as followsrng = StableRNG( P.seed )The four functions should similarly use variables from the parameters structure, and be consistent withthe modelling assumptions given earlier in this document.

7 Initialisation functionYour code have an initialise function that takes as input the parameters of the system and returns

an initial system state and creates the random number generators you are going to use.The initialisation function should also create a new system state and inject an initialFlightDisembarksat time 0.0. If you are implementing additional feature 2 the function should add an initialFlightDisembarks at t=P.attendant_rotation_interval (this is 30 minutes in the example output).The function should return the system state and the random number structure.function initialise(P::Parameters)R = RandomNGs(P)

system = State(P)

# add an arrival at time 0.0

t0 = 0.0

system.n_events += 1

system.n_flights += 1

enqueue!( system.event_list, FlightDisembarks(system.n_events,system.n_flights),t0)

# add the first attendant rotationsystem.n_events += 1enqueue!( system.event_list, RotateAttendants(system.n_events,true),P.attendant_rotation_interval)return (system,R)endAll you need to do here is copy and paste the above function into your code.Update functions (overall)Your code must have a set of update! functions with signatures:function update!( S::State, P::Parameters, R::RandomNGs, E::SomeEvent )

Each update function should process one of your event types so you will need one function per eventtype.Each update! function should modify the state S appropriately, including

• update any state variables
• allocate a passenger to the event (if appropriate)
• add any new events created from this one to the event list
• move entities between the various queues as appropriate (for example, primary to secondary)These functions must not have side effects. That is, they should not write out any information to files,or interact with global variables. However, your functions may throw an error if the input is invalid.Some additional details of the behaviour of these function can be inferred from the provided exampleoutput files.

11. Update function (for Arrival)This function should process an Arrival event in a manner consistent with the system description andassumptions.As in example codes from the course, you may find it helpful to write an additional function to use hereto move a customers around the various queues or into service (common to this and the Departureupdate function).

12. Update function (DepartureThis function should process a Departure event in a manner consistent with the system description andassumptions.

Update function (FlightDisembarks)This function should process a FlightDisembarks event in a manner consistent with the systemdescription and assumptions.

14. Update function (RotateAttendant)This function should process a RotateAttendant event in a manner consistent with the system descriptionand assumptions.8 State-based and entity-based output filesYour code must output two CSV files. The files should both begin with some metadata and parameters(you can includecomments preceded with a #). These should be stored in subfolders named for therandom seed and some parameter values.

• The first file state.csv should contain a time-ordered list of all events that are processed in thesimulation.

This should be written from the point of view after the event. For instance, you should report the

system that an arriving passenger sees immediately after their arrival.The CSV file should have columns titled:event_ID,time,event,upcoming_arrivals,primary_length,secondary_lengths,in_service,n_total,n_open_countersHere upcoming_arrivals should be a count of Arrival events in the event_list, and n_total isthe total number of people checking out, including those in service and those with a problem. See theprovided example files for formatting of the vectors in secondary_lengths and in_service.

• The second file entities.csv should contain a list of all entities that have completed service. TheCSV file should have columns titled (note the header should be one line as in the example output):

```

passenger_id,flight_id,disembark_time,enter_primary,enter_secondary,start_service,end_service,secondary_id,...

counter_id,attendant_rotated

```You will need to write and construct these CSV files line by line. This is most easily done with printlnstatements, but you may use a package like CSV or Printf if you prefer.

16. Run function(s)You code should contain a top-level function run_checkout_sim with the signaturerun_checkout_sim(P::Parameters)This function should take the parameters structure as its input. It should then

• initialise the system state,
• create the output files (and subfolders)
• write metadata, parameters and the header to the output files
• run the simulation by calling the run! function (see below)
• close the output filesThe run! should have the signaturerun!(system::State, P::Parameters, R::RandomNGs, fid_state::IO, fid_entities::IO)This function should run the main simulation loop up to he final time given in the Parameters.Itshould write output to the state.csv file for all events and to the entities.csv for Departure eventsonly. It should also update the system time before theupdate! function is called.Code styleYour code must be written with good style. See Julia’s style guidelines for further information.In particular:

• use comments (in English) efficiently and effectively
• store commonly used code as functions9Further Julia hints on PriorityQueue When a problem occurs, the depature time of the customer will be extended. That is, you need to change thetime, i.e. the priority, of the corresponding departure event.You can modify the priority of an object in a priority queue in Julia as follows:

Output:

PriorityQueue{Any, Any, Base.Order.ForwardOrdering} with 2 entries:"a" => 0"b" => 5"c" => 7Note that the order of the items in the queue has now changed. However, be careful here since the aboveapproch would not update the time stored in the Event structure.Additionally, you may find it useful to iterate over the keys of a PriorityQueue as follows (continuing fromOutput: PriorityQueue{Any, Any, Base.Order.ForwardOrdering} with 2 entries:This last piece of code may seem overly complex for this example, but can be adapted for the purposes here.Additionally, you may find it helpful to use the dequeue_pair!, peek and delete! functions for priorityqueues. Try using these on the above example as follows:key, priority = dequeue_pair!(pq) # dequeue, return key and prioritypeek(pq) # look at the top of the queue,without removingdelete(pq, "c") # delete an item with a given key10Part 3: Verification and testing Note that no marks are directly associated with the activities described below. This is all about testing your code thoroughlytoensure it works as expected! In this part, you will test your implementation to make sure it can output results and is consistent with someprovided output.Tasks for Part 3 Although you might not need to modify the code in AirportOverseasPassports.jl, you may need to modifyit in response to bugs found in testing.The main tasks will be to verify that your code works correctly (as described in Module 3: Verification), and toconstruct a small simulation harness in which to run a set ofcomparison simulations (as described in Module 4:Tools to Automate Simulation). Following these steps willhelp to detect any issues/bugs and ensure you getthe maximum number of marks for the code you have written.

1. Test and verify your code.Compare the output of your code to the provided sample outputs:

• state_all.csv and entities_all.csv . . . output for the simulation with all additional featuresimplemented (parameters in metadata)

• state_basic.csvandentities_basic.csv‘ . . . output for simulation with no additional features (parameters in metadata)If you have implemented your code exactly as specified, and used the same seed and random numbergeneration, your output should look very, very similar (the only differences should be in details such asnumbers of decimal points, white-spacing or ID numbers).However, your code may result in some differences. Some are important and others less so. You need tobe quiteanalytical to understand which. That is, what differences occur because of a minor change inthe order of actions, and what differences are caused by bugs. If there are differences, you should createsome of your own tests to understand what is different from the code that produced the above results.

2. Create a test harness that will run your code for 100 different seed values ranging from 1–100. Thiscould simply be a script that looped over these values.This will create 100 versions of the simulation, so by selectively examining the output and/or computingsummary statistics you can get a better sense of how well yoursimulation functions. In particular,changing the seed can reveal “edge cases”, that is a situation that occurs rarely (and might not havebeen in the sample output), which may lead to an error in your code.Additionally, from these outputs, you could perform some statistical analysis to inform the airport’smanagement about their questions. Note you do not need to answer these questions as part of thisassessment (that process will be part of the Project Report for a different problem).11Detailed rubric You will be assessed on the following components of your work. [80 marks total]

• Basic functionality: code implements the basic functionality of this queuing system, as per the specification.[40 marks]

• Additional feature 1: code implements this feature correctly. [12 marks]
• Additional feature 2: code implements this feature correctly. [12 marks]
• Additional feature 3: code implements this feature correctly. [12 marks]
• Code style: submission meets general style guidelines for good Julia code. [4 marks]