Practical 6 - Full Version

Practical 6 - Call Security

In this final practical, the festival organisers have called in a security company to try to stop people from mugging each other. The company have agreed to position some security booths around the festival site and can guarantee that no muggings will happen within a certain distance of these booths. It is up to you to find the optimal locations for the booths

Creating Security Booths

The security company have proposed to put some booths around the festival site. These will be operated by a guard and the company guarantee that if a guard is on duty then no crime will take place in the vicinity of the booth. In our model, we can simply represent these booths as patches with a unique colour (black in this case) and we can change the behaviour of the muggers so that if they are within the vicinity of a security booth and a guard is in the booth then they wont attempt to commit a crime.

First, we will add a switch that turns the security booths on and off. This makes it easier to run experiments as you can easily see what difference the booths make versus having no security.

1. Make a copy of your model from last week ('festival2.nlogo') that you will use for this practical work. Give it a name so you can distinguish it from last week's work (e.g. I called mine 'festival3.nlogo').

2. Create a new switch called 'security-guards'. Later this switch will be used to turn guards on or off (the booths are always present, but sometimes there might not actually be someone operating them, in which case they will not prevent a crime from happening).

Creating the booths is as simple as changing the colour of the designated patches to black. This can be done using the the ask command. There is a special way to use ask such that instead of asking all the patches in the model, we can ask a particular one. For example: ask patch 25 10 [ set pcolor black ] will change the colour of the patch with coordinates (25,10) to black. (To work out what the coordinates of the different patches are, you can right-click on a location in the model window).

3. Create a new procedure called 'setup-security' that changes the colours of three patches to black. You can chose any patches you like for now; I chose three roughly in the middle of the festival ground (see the right image).
4. Add a call to setup-security in your normal setup procedure. After this, your setup procedure will look similar to the following: to setup
  __clear-all-and-reset-ticks
  setup-patches
  setup-people
  setup-muggers
  setup-security
end
5. Run the model to check that it still works. You should see three black patches in the environment, but at the moment the security booths wont have any impact on the model outcomes. This is because we have not changed the behaviour of the muggers so that they take the locations of the security booths into account when deciding whether or not to commit a crime.

Updating Behaviour



In this part we will update the behaviour of the mugger agents so that they take the security booths into account before deciding whether or not to commit a crime. Their new decision process is illustrated by the right figure.

After moving, the muggers look around to see if there are any security booths close by (in this example they look around a radius of 4 units). They will not try to commit a mugging if:

• There are booths within 4 units
and
• The security guards are in their booths (security-guards = True).

If either of these conditions are false (i.e. there are no booths in the vicinity or there are no guards in the booths) then the agent will go on to see if there is a visitor on the same patch who they can mug.

To make these changes to the move-and-mug function, we need to add a bit of new code around the existing commands that cause the muggers to actually mug a visitor. There are lots of ways to program this behaviour, the table below gives one example.

Code	Explanation
to move-and-mug	The procedure that controls the muggers.
rt (random 360) fd 1	Muggers wander around randomly.
let security-booths ( patches with [ pcolor = black ] )	Find out which patches represent the security booths (have black colour). We do this by creating a new, temporary, variable called security-booths. This variable holds a list of all the black patches.
let close-booths ( security-booths in-radius 4 )	Find the booths that are within a distance of four units to this mugger. A new variable, called close-booths, is created to temporarily store this new list of patches (i.e. all patches that are black and within four units).
let num-close-booths ( count close-booths )	Find the number of nearby booths (i.e. the number of patches in the close-booths list).
let try-to-mug True	Now work out whether or not the mugger should attempt a robbery. We will use a temporary variable called try-to-mug to store the decision. This variable will either hold a value of True if the a mugging should take place, or False otherwise. To begin with, we assume that they will do a mugging.
if ( security-guards = True ) and ( num-close-booths > 0 ) [   set try-to-mug False ]	Now, if security guards are at work and the mugger is close to a security booth then change the decision to mug from True to False.
if try-to-mug [    ... code to mug victim and      add a 'C' label goes here ... ]	If try-to-mug is true, the go ahead and do the mugging. We already have the code required to do this (from the last practical). Of course, if there is no victim on the same patch as the mugger then no mugging will take place.


6. Add the new functionality (above) to the existing move-and-mug procedure. This will make the muggers think about the locations of security booths before seeing if there is a victim available to mug.
7. Run the model. When the security-guards switch is on you should see the muggers avoid committing crimes in the vicinity of the security booths. Also, the rate of muggings (as depicted by the plot) will probably go down a bit.

The model is basically complete now. The one thing remaining to do is improve it slightly so that it is easier to set up the simulation to run experiments.

Setting up An Experiment

Now that your model is ready, you are able to start changing the locations of the security booths and observe the impact of the changes on the number (or rate) of crimes that take place. However, we need to make sure that the model runs for the same number of iterations each time the security locations are changed, otherwise the results will not be consistent.

To make things easier, we will create a button that runs the model for a fixed amount of time.

8. Create a new button.
9. Give the button an appropriate display name. In my example, the button is going to run the model for 5,000 iterations so the display name is "Run 5,000 iterations". Of course, you could choose a different number of iterations (in your projects you might want to provide some rationale for the number of iterations chosen).
10. In the 'Commands' box we will add some code to call the go procedure a number of times, rather than going on forever. Add the following code: let counter 0
while [ counter < 5000 ] [
  go
  set counter ( counter + 1 )
]
11. Try running the model again, this time using the new button you have just created. The model should run for a set number of iterations and then stop.
12. You should also add two new monitors to show the number of muggings that have taken place and the rate of muggings per iteration. It can be easier to read numbers directly from a monitor than it is to interrogate a graph.
    The code to count the total number of crimes (i.e. add up all the values of the victims variable of all muggers) is: sum [victims] of muggers And to calculate the rate, you can just divide by the number of iterations (remember to do ticks + 1 to prevent divide by 0 problems). ( sum [ victims ] of muggers ) / ( ticks + 1) Those commands can be added directly to a monitor when it is created.

Documenting the Model

13. The very last thing to do is document the model. This is vital so that other people can understand what it does, how to use it, and what is advantages/disadvantages are. To edit the documentation, click on the Information tab and fill in all the details. If you're not sure what to write, have a look at some example models in the models library. They should all have comprehensive documentation.

That's it! The festival model is now ready. Complete the activities below to begin experimenting with different model configuration.

Activity - Experimenting with the Model

Now that the simulation is complete, you can run some experiments to test different locations for the security booths and see what impact the location will have on the number (or rate) of crimes that take place during the festival.

Create a table like the one below, and begin to populate it. Try changing the locations of security booths to see which are the best locations.

Can you find the optimal location for security booths?.

Experiment number	Security Booth Locations	Security (on or off)	Crime rate	Total crime
Control	-	Off	0.81	5217
1	(25,10) (25,25) (25,40)	On	0.65	3527
2	(25,10) (23,30) (25,50)	On	0.73	4219
3	(30,10) (30,25) (30,40)	On	0.79	4532