## Epidemy Simulation

In this exercise, you are going to write an epidemic simulator based on the simulation framework seen in lecture.

The scenario is as follows: the world (“Scalia”) consists of regular grid of 64 rooms, where each room is connected to four neighbouring rooms. Scaliosis – a vicious killer virus – rages among the population of the Scalia.

When a person becomes infected, she does not immediately get sick, but enters a phase of incubation in which she is infectious but not sick (so she looks safe to approach to other people). Citizens infected with the virus (whether visibly or not) quickly transmit it to other citizens in the same room.

In their attempt to avoid the diseased, Scalians often travel among rooms. Unfortunately, this helps the disease spread across the whole world.

The disease and behaviour of people is simulated according to the following rules.

### Rules

1. General:
• Scalia is a cyclic world: the first row is considered a neighbour of row eight (and vice versa); analogously, the first column is a neighbour of column eight (and vice versa). Each room may contain an arbitrary number of persons.

• Scalia’s initial population is 300. At the beginning of the simulation, each person is assigned a starting room uniformly at random. Additionally, 1% of the population is originally infected.

2. States of Scaliosis infection:
• When a person becomes infected by Scaliosis, she does not immediately get sick. Rather, she enters a phase of incubation, in which she is infectious but not sick (visibly infectious).

• After 6 days of becoming infected, a person becomes sick and is therefore visibly infectious.

• After 14 days of becoming infected, a person dies with a probability of 25%. Dead people do not move, but stay visibly infectious.

• After 16 days of becoming infected, a person becomes immune and is no longer visibly infectious, but remains infectious.

• After 18 days of becoming infected, a person turns healthy. He is now in the same state as he was before his infection, which means that he can get infected again.

3. Simulation and moves:

• Each step of the simulation corresponds to one simulated day.

• At the beginning of the simulation, each person decides when to move within the next 5 days. More precisely, she picks the moving day uniformly at random among the next 5 days. After moving, she repeats the same process.

For example, if on day 0 the person decides to move after 3 days, she will move from her current room on day 3. After that move, she will make another decision: for example, she may decide to move after 5 days this time, so her next move will be on day 8 etc.

• On the day of each move, a person will pick one of the rooms available to her with equal probability and will move to it. The set of available rooms is defined as the neighboring rooms that contain no visibly infectious people. A person avoids rooms with sick or dead (visibly infectious) people. This means that if a person is surrounded by visibly infectious people, she does not change position; however, she might change position the next time she tries to move (for example, if a visibly infectious person moved out of one of the neighbouring rooms or became immune).

• When a person moves into a room with an infectious person she might get infected according to the transmissibility rate of 40%, unless the person is already infected or immune. A person cannot get infected between moves (this is slightly unrealistic, but will simplify your implementation).

### Graphical display

To make the project more interesting, we provide you with a graphical display class (class `EpidemyDisplay`) that is used to visualize simulations. The display is automatically available to you when you complete the provided (partial) `EpidemySimulator` class. To start the graphical output (and the simulation), run the `simulations.gui.EpidemyDisplay` object.

Healthy persons are painted in green color. Persons that have their sick field set to true are painted in red color, suitable to indicate visibly infected people. Immune (i.e. infected but not sick) people are painted in yellow.

### Exercises

1. Implement an epidemy simulator according to the above rules by completing the partial `EpidemySimulator` class (available on the course web site). Make sure to first inspect the code of `EpidemyDisplay` and `Simulator`, and understand how the display uses the simulator’s agenda to perform the simulation (hint: the `afterDelay` method is the key to success!). Your task is to add the correct `WorkItem`s to the agenda.

2. Determine the average number of dead people after 150 days over a set of 5 experiment runs.

3. Extend your simulation with air traffic: when a person decides to move, she will choose to take the airplane with a probability of 1%, thereby moving to a random room in the grid (rooms with visibly infected people are not avoided). How does air traffic impact the epidemy? Determine the average number of dead people over 5 runs.

4. Pandemic Response. To reduce the number of casualties, the president of Scalia decides to enforce one of the following health policies:

• Reduce Mobility Act. The mobility of people is decreased by half. The mobility of a visibly infected person is further reduced by half.

• The Chosen Few Act. 5% of people (VIPs such as pop singers, football players, etc.) are given vaccines when first created. They never become infected.

Which of the health policies is more effective (use the version with air traffic for your tests)?

5. Use the `SimConfig` object to declare your configuration values for the simulations. When you submit, set them to the default values, and disable extensions (air traffic, reduced mobility and vaccination).

### Instructions

In the attached .zip file you will find an sbt project. You can unzip it and work on in with Eclipse or sbt, as you did with the previous assignments. Evaluating this exercise, however, will not proceed as before:

1. On next week’s exercise session (21th November), you will have to present your solutions to the course TAs. This will consist of a visual inspection of the graphic simulation, and some question on your code. This means you are expected to have a solution by next Friday morning!
2. Additionally, you will have to submit your code on moodle (details coming soon). Deadline for submission is also on Saturday, 22 November, 23:50h. This will give you some time to take our feedback from Friday into account.