DrugURP - Final Draft

URP Simulating Drug Enforcement Efforts
Arena Modeling Macchi, Halter, Williams.
Property of Prof. Thomas Sharkey

Simulating Drug
Enforcement Efforts
ISYE Undergraduate Research Project Spring 2015

Ian Halter
Tyler Williams
Matthew Macchi

1


Table Of Contents
1. Abstract
2. Introduction
3. Arena Model
4. Simulation Results
5. Sensitivity Analysis
6. Conclusions
7. Future Considerations
8. References

2


Abstract

The objective of this research is to effectively model and determine resource allocation
decisions for law enforcement operations against illegal drug trafficking. The main difficulty in
modeling these operations is that they are often performed in dynamic environments and
require an investment of resources to various activities over time in order to successfully
identify and arrest criminals involved in the trafficking operations. In particular, law
enforcement agencies must monitor and target criminals in order to build cases against them
prior to arrest. Therefore, the resource allocation decisions will include scheduling both
‘intelligence operations’ to gain information about the drug trafficking and physical attacks in
order to arrest, or interdict, criminals. Law enforcement may not have complete information
about the drug trafficking operations and, therefore, the intelligence operations help to gain
information and guide future resource allocation decisions. For example, it may be better to
delay the arrest of an individual since performing surveillance on them instead would give
information about other criminals. The main method being utilized to model this simulation is
the ARENA software suite of applications. This will allow for accurate event simulations and
sensitivity analysis in order to validate our decisions or actions being taken. The software will
also allow for visual representations in order to communicate the simulation to a broader
audience. The expected results of this research are comprehensive models, and optimization
algorithms to solve them, that can determine these resource allocation decisions for law
enforcement. The resulting models can then be applied in order to identify the types of
policies that law enforcement could adopt for improved effectiveness in combating illegal drug
trafficking. Further detailed information can be obtained in “Collaborative Research: Dynamic
Resource Allocation Models for Law Enforcement Operations against Illegal Drug Trafficking”
[1].

3


Introduction

The goal of this project is to develop a preliminary model in which the allocation of
police officers to a crack cocaine modeling drug can be measured. Due to the exploratory
nature of this initial research, a classification of players other than police officers, specific
requirements within the model and an appropriate software program need to be identified.
After careful consideration, noted in [1] , the classification of players other than police officers
that needed to be included in the model would be the following: users, dealers, safehouses
and big guys.

Table 1: Criminal Class Definition
User A crack cocaine addict or first time user the primary source of money
into the crack cocaine industry and the most frequent and common
criminal class. This is the only criminal class that has the option to go
to Rehab after being arrested.
Dealer A person who sells crack cocaine in “teen” or dimebag amounts to
users and receives their supply from safehouses.
Safehouse An area that contains a drug supply used to distribute to a quantity of
drug dealers. Each safe house has one specific owner that is a “Big
Guy”.
Big Guy A big guy is a major criminal who enters the drug ring with lots of
money and a large amount of crack cocaine product which he then
distributes to safehouses.

Specific requirements within this goal include; measuring the impact of Rehabilitation,
modeling a drug supply, and modeling criminal class’s information on one another and
modeling how criminal classes reenter the system after prison or a drug deal. Finally, the
group and Professor Sharkey chose Arena, a discrete event modeling program, as the
medium for this research. Arena remains the best option for this project due to its ability to
capture the Markov Chain decision process and treat each interaction between criminal class
as an event with a distribution of time, utilization of resource and probability of occurrence.

4


Arena Model

In the final revision of the model, there are two main entities that move through the
system. There are people that interact with the drugs, and there are the drugs themselves.
The specific drug the model is concerned with tracking is not important, as long as the drug
flow is monitored correctly. As for the Criminal Entities, there are four entities the model is
concerned with: a drug user, dealer, safehouse, and big guy.

Dealers / Safehouses / Big Guys General Walkthrough

Annotation: This is an example of the “Big Guy” progression. Again, The branch off the
decision node “Big Guy After Prison” connects to the “Leave System” node. The branches for
“Dealers” and “Safehouses” are of identical structure and make, just with the word “Big Guy”
replaced by “Dealer” or “Safehouse”.  While the most recent model is more complex than
shown above, this basic model was the stepping stone for expansion. Be sure to take note of
this model to gain a basic understanding of the movement of information throughout the
system and simulation.

Criminal Entity Movement
The people flow through the model in the same manner. The Drug Dealer’s process
will be described. The only difference between each entity’s process flow is the numbers each
entity deals with. Each important set of values will be described in this report, through being
presented in Tables.
Dealers are created in a create node, titled “Dealer Arrival.” Dealer entities arrive into
the system at an exponential rate of one per every 60 hours. Each dealer entity represents
one dealer in real life. There is an infinite amount of dealer entities that can be in the system
at once. The dealer arrival node can be seen in Figure 1.

Figure 1: “Dealer Arrival” Create Node
5


Once the dealer is created, it is run through an assignment node, titled “Info.Dealer
Assign.” Here, three variables are assigned their initial value. If the variable already has a
value in it, additional value will be added. The variables of info.dealer, info.safehouse, and
info.user are altered. The variables have been labeled info.entity, for they represent the
amount of information that the police force have about that entity. The Info.Dealer Assign
node can be seen in Figure 2.

Figure 2: “Info.Dealer Assign” Assign Node

The dealers then enter a decision node, titled “Too Many Dealers Waiting?” It is a
twoway by condition decision node. It evaluates whether or not there is any space between
what the drug dealer queue currently has in it and what the dealer system limit is. If there is
any open capacity in the dealer queue, the dealer will enter the dealer queue. If the dealer
6


queue is at full capacity, the dealer will leave the system through a dispose node, titled
“Dealer Leave System.” The only function of the “Dealer Leave System” dispose node is to
dispose of any dealer entity that enters that node. The “Too Many Dealers Waiting?” decision
node can be seen in Figure 3 and the “Dealer Leave System” dispose node can be seen in
Figure 4.

Figure 3: “Too Many Dealers Waiting?” Decision Node

Figure 4: “Dealer Leave System” Dispose Node

The next node a dealer entity will enter is a match node, titled “D_DrugMeet.” This
stands for Dealer Drug Meet. Here, dealer entities are held until there is an available amount
of drugs for that entity to enter the drug trade with. Drug entities are created individually in a
separate create node. Once there is enough drugs for dealer entities to enter the system with,
the dealer entity physically enters the system, while the drugs get moved along up to user
entities. This match node can be found in Figure 5.

Figure 5: “D_DrugMeet” Match Node
7


This is the point of the process modeled where dealers are actually a part of a drug
exchange. Once a dealer entity has been matched with the correct amount of drug entities, it
will enter a process node, titled “Dealer Drug Exchange.” The purpose of this process node is
to delay the dealer some amount of time based off of a triangular distribution. “Dealer Drug
Exchange” has a triangular distribution of TRIA(10, 15, 20). This means that the minimum
amount of time a dealer will be delayed in this process node is 10 hours, the most likely value
the dealer entity will be delayed is 15 hours, and the maximum time a dealer will be delayed is
20 hours. This process node can be found in Figure 6.

Figure 6: “Dealer Drug Exchange” Process Node

8


After the dealer is delayed by the TRIA(10, 15, 20) distribution, it will enter a decision
node titled “Dealer Info Assessment.” This is an Nway by Condition decision node, with three
possible outcomes for each dealer entity. Here, the variable Info.Dealer is being evaluated,
which determines the dealer entity’s outcome. The threshold value in this decision node for
Info.Dealer is 20. If the Info.Dealer variable’s value is greater than or equal to 20, the dealer
entity will enter another decision node, titled “Dealer Enough Info.” If the Info.Dealer variable’s
value is less than 20, the dealer will enter another decision node titled “Dealer Not Enough
Info.” There should be no reason for a dealer entity to not enter one of these two decision
nodes. As a failsafe, the false node of the “Dealer Info Assessment” decision node takes the
dealer entity right back into the “Dealer Drug Exchange” process node, so the dealer will not
actually leave the system. The “Dealer Info Assessment” decision node can be seen in Figure
7.

Figure 7: “Dealer Info Assessment” Decision Node

If the value of Info.Dealer is greater than or equal to 20 when the dealer entity reaches
the “Dealer Info Assessment” decision node, the dealer entity enters the “Dealer Enough Info”
decision node. It is a 2way by Chance decision node. There is a 75% true chance that the
dealer entity gets arrested, bringing that entity to a delay node titled “Dealer Arrested.” There
is a 25% chance that the dealer does not get arrested. If the dealer entity does not get
arrested, it will enter a record node, titled “Record_Dealer.Return1.” This record node counts
by value of 1 all of the dealer entities that return to the “Too Many Dealers Waiting?” decision
node. The “Dealer Enough Info” decision node can be seen in Figure 8. The
“Record_Dealer.Return1” record node can be seen in Figure 9.

Figure 8: “Dealer Enough Info” Decision Node
9


Figure 9: “Record_Dealer.Return1” Record Node

Once the dealer entity reaches the “Dealer Arrested” delay node, it is delayed a set
amount of time of five days. This delay node’s purpose is to simulate the amount of time a
dealer would spend in jail or prison after being arrested by the police for selling drugs. The
“Dealer Arrested” delay node can be seen in Figure 10.

Figure 10: “Dealer Arrested” Delay Node

10


After being in the “Dealer Arrested” delay node, each dealer entity will enter an assign
node titled “Dealer Arrest 1.” The purpose of this assign node is to alter the variables of
“Dealer.Arrests.Made,” “Info.Dealer,” and “Arrests.Made.” Here, two new variables are
introduced. “Dealer.Arrests.Made” is a simple numerical variable that increments up by value
of one every time a dealer entity is arrested in the simulated system. “Arrests.Made” is a
simple numerical value that increments up by value of one every time any of the four criminal
entities are arrested in the simulated system.
As each dealer entity passes through the “Dealer Arrest 1” assign node, the
Info.Dealer variable is set back to zero. This is because a dealer arrest is made, and all off the
information that the police had about dealers is reset, meaning that the police would have to
start from scratch each time a dealer arrest is made. In essence, it does not matter which
dealer entity is arrested, as long as one entity is arrested. This simulation model is not
concerned with specific dealer entities, but monitoring the flow of all of the dealer entities
collectively. The “Dealer Arrest 1” assign node can be seen in Figure 11.

Figure 11: “Dealer Arrest 1” Assign Node

If the value of Info.Dealer less than 20 when the dealer entity reaches the “Dealer Info
Assessment” decision node, the dealer entity enters the “Dealer Not Enough Info” decision
node. It is a 2way by Chance decision node. There is a 8% true chance that the dealer entity
gets arrested, bringing that entity to another decision node titled “Dealer Cooperate Decision.”
There is a 92% chance that the dealer does not get arrested. This means that there is a 92%
chance that a dealer entity will not get arrested if the police do not have enough information
about the collective dealer entity. The “Dealer Not Enough Info” decision node can be seen in
Figure 12.

Figure 12: “Dealer Not Enough Info” Decision Node
11


If the dealer entity does not get arrested, it will enter a record node, titled
“Record_Dealer.Return2.” This record node counts by value of 1 all of the dealer entities that
return to the “Too Many Dealers Waiting?” decision node. The “Record_Dealer.Return2”
record node can be seen in Figure 13.

Figure 13: “Record_Dealer.Return2” Record Node

If the dealer entity gets arrested while the police force does not have enough dealer
information, the entity is brought to a decision node titled “Dealer Cooperate Decision.” In this
decision node, the chance that the dealer reveals available information and cooperates with
the police is being modeled. This decision node is type 2way by Chance, with a 35% chance
that the dealer reveals information to the police force. The “Dealer Cooperate Decision”
decision node can be found in Figure 14.

Figure 14: “Dealer Cooperate Decision” Decision Node
12


In the event that a dealer entity cooperates when it reaches the “Dealer Cooperate
Decision” decision node, it will go to a delay node, titled “Dealer Cooperated.” This delay node
simulates the amount of jail time a dealer would receive after being arrested and cooperating
with the police. Here, a dealer entity is delayed for two days of time. This “Dealer Cooperated”
delay node can be found in Figure 15.

Figure 15: “Dealer Cooperated” Delay Node

In the event that a dealer entity does not cooperate when it reaches the “Dealer
Cooperate Decision” decision node, it will go to a different delay node, titled “Dealer No
Cooperation.” This delay node simulates the amount of jail time a dealer would receive after
being arrested and not cooperating with the police. Here, a dealer entity is delayed for five
days of time. Note that this delay node delays the dealer entities for three days longer than
the “Dealer Cooperated” delay node. This is showing how the police would be less harsh
when giving out jail time to entities that cooperate than to those that do not cooperate. This
“Dealer No Cooperation” delay node can be found in Figure 16.

Figure 16: “Dealer No Cooperation” Delay Node
13


After passing through either the “Dealer Cooperated” or the “Dealer No Cooperation”
delay nodes, each dealer entity enters an assign node. There are two different assign nodes
at this stage, titled “Info.Dealer Reassign 1” and “Info.Dealer Reassign 2.” The Info.Dealer
variable is altered after sentencing a dealer entity with jail time, simulating the increase in
information the police force would have after questioning the entities and learning more about
the drug exchange system. If the dealer entity passes through “Info.Dealer Reassign 1,” the
Info.Dealer variable is increased by a value of (0.5*UNIF(0,1)). The UNIF(0,1) term represents
a number being uniformly generated between zero and one. That number is then multiplied by
0.5, for information reduction. If the dealer entity passes through “Info.Dealer Reassign 2,” the
Info.Dealer variable is increased by a value of (0.2*UNIF(0,1)). The “Info.Dealer Reassign 1”
assign node can be seen in Figure 17 and the “Info.Dealer Reassign 2” assign node can be
seen in Figure 18.

Figure 17: “Info.Dealer Reassign 1” Assign Node

Figure 18: “Info.Dealer Reassign 2” Assign Node
14


After the dealers pass through one of these assign nodes, it will then enter a process
node. If the dealer entity cooperated in “Dealer Cooperate Decision,” it will enter a process
node titled “Dealer Prison Short.” Here, the dealer is delayed based on a triangular distribution
of TRIA(15, 22, 25). If the dealer entity cooperated in “Dealer Cooperate Decision,” it will enter
a process node titled “Dealer Prison Long.” Here, the dealer is delayed based on a triangular
distribution of TRIA(20, 30, 40). The “Dealer Prison Short” process node can be found in
Figure 19 and the “Dealer Prison Long” process node can be found in Figure 20.

Figure 19: “Dealer Prison Short” Process Node

Figure 20: “Dealer Prison Long” Process Node
15


After being processed through either of these two process nodes, the dealer entity will
enter an assign node, titled “Dealer Arrest 2.” At this assign node, two variables are altered.
As a dealer entity passes through “Dealer Arrest 2,” the Dealer.Arrests.Made variable is
increased by one and the “Arrests.Made” variable is increased by one. This “Dealer Arrest 2”
assign node can be found in Figure 21.

Figure 21: “Dealer Arrest 2” Assign Node

After passing through the assign nodes of either “Dealer Arrest 1” or “Dealer Arrest 2,”
the dealer entity will reach another decision node, titled “Dealer Back to Drug Exchange?”
16


Here, the entity is faced with a 2way by Chance decision of either leaving the system or
reentering the drug exchange. The percent true of this decision node is 50%. If true, the
dealer enters the dispose node “Dealer Leave System,” where the dealer entity is simply
disposed of. If false, the dealer is brought back to the “Dealer Drug Exchange” process node.
The “Dealer Back to Drug Exchange?” decision node can be found in Figure 22.

Figure 22: “Dealer Back to Drug Exchange?” Decision Node

Drug Entity Movement
In this Arena simulation, the drugs being used by the criminal entities are modeled as
their own entity. This is so because the movement of how drugs effect the amount of criminal
entities inside of the system was to be studied. The drugs flow from the bottom of the model,
starting at the big guy entity, and move up to the top of the model, reaching the user entity.
Drug entities are created at a create node, titled “Drugs Entering System.” Each entity
created represents ten units of drug in real life application. These entities are created based
off of an exponential distribution with a value of 15 hours. Each arrival spawns one drug
entity, or ten real drug units, and there is an infinite amount of drug entities allowed in the
system. The “Drugs Entering System” create node can be found in Figure 23.

Figure 23: “Drugs Entering System” Create Node

17


Once a drug entity is created, it will enter a batch node titled
“BigGuy_Drugs_Required.” Drug entities are held here until the batch size is reached. That
means that drug entities are held together until there are enough accumulated drug entities to
send off to the next node. The batch size for “BigGuy_Drugs_Removed” is 48. This means
that in order for a big guy entity to be able to enter the drug exchange, there needs to be 48
drug entities available. The only entity this batch node is batching is “DrugUnit_Ten,” which is
the entity type that is created in the “Drugs Entering System” create node. The
“BigGuy_Drugs_Removed” batch node can be found in Figure 24.

Figure 24: “BigGuy_Drugs_Removed” Batch Node

After being reaching the batch size, the batched drug entities are sent to a match node
titled “BG_DrugMeet.” Here, a big guy and drug entity are matched together. There only
needs to be one big guy entity and one drug entity to satisfy this match node’s requirements.
The “BG_DrugMeet” match node can be found in Figure 25.

Figure 25: “BG_DrugMeet” Match Node

After this match node, the big guy and drug entities that were just matched are
separated. Each entity goes its own separate way. The big guy entity enters the “Big Guy
18


Drug Exchange” process node. The drug entity enters a separate node, titled “Disperse to
Safehouse.” The one batch of drug entities are separated into 48 single drug entities again,
while retaining their original entity values. The “Disperse to Safehouse” separate node can be
seen in Figure 26.

Figure 26: “Disperse to Safehouse” Separate Node

Once separated, each of the drug entities enters a different batch node, titled
“Safehouse_Drugs_Required.” The same drug entities are rebatched during this part of the
simulation. This time, the batch size is 16. This means that in order for a safehouse entity to
be able to enter the drug exchange, there must be 16 drug entities available. This number is
less than the big guy entity’s batch size because the safehouse entities deal with less drug
entities than the big guy entities do. The “Safehouse_Drugs_Required” batch node can be
seen in Figure 27.

Figure 27: “Safehouse_Drugs_Required” Batch Node

19


After 16 drug entities have been batched, that batch is sent to a match node titled
“S_DrugMeet.” This match node pairs a batch of 16 drug entities with one safehouse entity.
After the match has happened, the safehouse entity enters the “Safehouse Drug Exchange”
process node, and the batch of 16 drug entities enters another separate node, titled “Dispose
to Dealer.” The “S_DrugMeet” match node can be seen in Figure 28.

Figure 28: “S_DrugMeet” Match Node

After a safehouse entity has been matched with a batch of 16 drug entities, the
batched drug entities continue on to a separate node, titled “Disperse to Dealer.” Here, the
batch is split up into single drug entities. The split drug entities retain their original entity
values. The “Disperse to Dealer” separate node can be seen in Figure 29.

Figure 29: “Disperse to Dealer” Separate Node

From here, the drug entities enter yet another batch node, which is titled
“Dealer_Drugs_Required.” Drug entities are batched by a batch size of eight. The
“Dealer_Drugs_Required” batch node can be found in Figure 30.

Figure 30: “Dealer_Drugs_Required” Batch Node
20


The eight batched drugs are then moved to a match node where they connect with a
drug dealer entity. This match node is titled “D_DrugMeet,” and can be found in Figure 5.
After leaving “D_DrugMeet,” the eight batched drug entities enter a separate node titled
“Disperse to User.” The batched drug entities are separated into individual drug entities again,
retaining the original entity values. The “Disperse to User” separate node can be found in
Figure 31.

Figure 31: “Disperse to User” Separate Node

From here, the drug entities enter one last batch node, titled “User_Drugs_Required.”
The drugs are batched into a batch size of one. Though it seems unnecessary to batch a
single entity at this stage, the batch size for users could increase in future use of this model.
The “User_Drugs_Required” Batch node can be seen in Figure 32.

Figure 32: “User_Drugs_Required” Batch Node
21


The batched set of drug entities moves to one last match node, titled “U_DrugMeet.” A
user entity is paired with the correct amount of drug entities it needs to enter the drug
exchange, and then proceeds to enter the drug exchange. The “U_DrugMeet” match node
can be seen in Figure 33.

Figure 33: “U_DrugMeet” Match Node

Once the drug entities have been paired with a user entity, they are no longer needed
by the simulation model. The drug entities move to a dispose node, titled “Drugs Leave
System,” that dispose of the drug entities and record the amount of drug entities disposed of.
The “Drugs Leave System” dispose node can be found in Figure 34.

Figure 34: “Drugs Leave System” Dispose Node

22


Simulation Results

The simulation results showed that the simulation needed to be run for a longer
amount of time. The NumberOut of DrugUnit returned the value zero, which mean none of the
drugs had left the system. Therefore the drug supply did not have enough time to make its
way to all of the criminal classes before the end of one replication. While the zero values for
“time” of each criminal class is expected, zero values for Queues or NumberOut are an issue.
These results indicate that the entity error restriction needs to be removed with the better
version of Arena or the arrival rate of the DrugUnit needs to be scaled back even further. The
simulation output results from the Arena model can be seen below in Figures 3539.

23


Figure 35: Report Page 1

24



25



26



27



28


Sensitivity Analysis

In order to gain more knowledge on the inputs of our model, it is essential to modify
the inputs. The parameters modified are in regards to the distribution values of the inputs of
the model, users, dealers, safehouses, and big guys. As previously discussed, each of these
entities is assigned an information value (ex. info.user.assign) which is meant to represent the
amount of information that particular entity has about the next level of entity. In order to
perform sensitivity analysis, the probabilities used in these distributions are altered. These
alterations were performed at random values of probability while making sure to keep the
probabilities equalling to 1. The following screenshots show the initial outputs of the models
followed by variations in the probability values for each entity. The values represent how
much information is recorded when an arrest is made. Notice the trend in values for each
entity. As the probabilities are altered, the output values for the info.[entity] are changing. This
is an inverse relationship showing as the probabilities increase the amount of information on
that entity decreases. For reference sake, the first number listed will represent the first
probability seen, the second number the second probability, and so on.

Figure 40: User Info Initial Probabilities 30/70

Figure 41: Initial Outputs with Initial Probabilities

29


Figure 42: Outputs with ‘User’ distributed 50/50

Figure 43: Outputs with ‘User’ distributed 90/10

Figure 44: DealerInfo Initial Probabilities 40/25/35

30


Figure 45: Outputs with ‘Dealer’ distributed 25/50/25

Figure 46: Outputs with ‘Dealer’ distributed 10/80/10

Figure 47: Safehouse Initial Probabilities 45/10/45


31



Figure 50: Safehouse Initial Probabilities 70/30


32



This is just the beginning of the plethora of sensitivity analyses that can be applied to
this model. In future practices, it could be beneficial to examine the probability distributions at
the decision nodes in the model or potentially the arrival rates of the entities. By doing this,
potential bottlenecks in the system can be identified and appropriate action can be taken to
minimize the hold up.

One tool of Arena that was not able to be utilized is Optquest. Optquest is an addin
that enables the creation of objective function(s) along with constraints that can be applied to
the running model. This bit of software is perfect for the purposes of this project. A major
explanation will not be discussed of the complete capabilities of Optquest, however, it should
be noted that for future work, to utilize this addin. Since all versions of the model up to this
point have been created in a limited licensed version of Arena, the Optquest functionality was
not available. It was only able to run in ‘demo mode’ where the user could just see the
interface of the software, seen here:

33


Figure 53: Optquest ‘Data Optimization’ Interface

Although the interface might look complicated, with some online tutorials the software
becomes easy to use and beneficial. The software also outputs graphs and figures that
represent a visual representation of sensitivity analysis depending on which objectives are of
higher priority. It is highly recommended that the license for the full version of Optquest be
obtained to gain real insight to the sensitivity of this model and its inputs.

34


Conclusions

A large contributing factor in the structure of the current model and past models was
replication length limits and entity limits within the Software. The replication length limit was
encountered in the attempt to mimic a real life prison term. If a criminal class went to prison, it
would be stuck there for a unit of time longer than the replication length. This problematic for
recording prison data, rehab data and total criminals leaving the system. It also added to the
entity limit issue. In the student version, Arena has an entity cap of 150 entities: at any given
point during a replication Arena cannot have the total entities within the system (drugs, users,
dealers, safehouses and big guys) exceed 150. The entity cap remained the largest issue
within the project scope. If it the error occured the simulation stopped and [Figure 54] was
generated. The 150 entity limit caused the group to scale back arrival rates and other discrete
events, which reduced the overall accuracy and realistic nature of outputs. Beyond a
numerical entity limit, Arena lacks individual entity statistic capabilities. While not directly
affecting the outputs, that level of granularity would be ideal for capturing the length of time a
specific criminal class in the system. To summarize, the replication time, 150 entity limit and
lack of individual entity capabilities of the Arena student version had a significant impact on
the final model and all outputs. Further endeavors on this project should include the
acquisition of a full version of Arena, adding a police office variable to affect the probability of
arrest, information and/or drug supply, and implementing an OptQuest linear program to
maximize the police officer variable. (only runs Demo mode in Student Version).

Figure 54: Entity Error Image

35


Future Considerations for Further Research

Maximum Entity Limitation
The Arena simulation model produced throughout the duration of this semester was
built around a major constraint the student version of Arena has in it. The mentioned
constraint is that there is a maximum limitation of 150 entities on all entities being processed
in the simulation at one time. If entities are created and disposed of, the number of entities the
student version of Arena can handle does not have a limit. However, if the number of entities
being processed by the simulation exceeds 150, Arena displays an error message about the
entity limitation and the simulation cannot continue.
Once all of the model’s parameters were decided upon being the most effective and
realistic, the realization was made that the simulation ran for too long of a time period. This is
because too many entities were being generated too close to each other. The temporary fix to
this issue was to dial back the amount of time the model ran for. Scaling back the parameters
of a realistic model is not a robust solution to an issue.
Often times, a simulation model’s input parameters, scheduling situations, queueing
process times, and many other components are dialed back. This allows the model to be able
to run until completion, without experiencing an entity limitation error. A viable way to avoid
this crucial limitation is to purchase a full Arena license. With a full Arena license, the program
can handle as many entities as the simulation calls for. A full license helps simulation models
represent realistic outcomes more accurately.

Police Force Entity
As the model currently stands, there is no sort of “Police” entity. The model’s
processes and characteristics are the only means of mediating how, when, and where the
people and drug entities move through the simulation. If the model were able to allow more
entities, the police entities would be able to arrive at a lesser rate than the people and drug
entities. Adding a police force entity would add more variability into how frequently all levels of
the criminal entities are arrested. This variability would not only increase the amount of arrests
made, but the rate of arrests would be much more realistic. Adding a police force would also
add essential variability to the manner in which the drug entities flow through the system.
Drug entities may not be able to arrive at such a steady rate as in the current version of the
model. Drug entities may also not move through the model at a steady rate, and scenarios of
high, medium, and low drug trafficking analyses would be able to be taken and understood.
Given more time, this is one thing the project group would have undoubtedly added into the
simulation model.

Individual Entity Statistics
Throughout the entire simulation, any results obtained were based on each aggregate
set of entities. No individual entity statistics were recorded. To be clear, if there were n
individual entities of one entity type, results will not show for each of the n entities. Results will
be displayed for the average results of n entities. If a method were to be discovered where the
36


model would display individual entity statistics, the results would be much more useful. More
statistical analysis could be done on the simulation, proving where the most vital parts of the
simulation are.

37


References

There were two main reference in this research, as the primary function of this research was
to conduct preliminary modeling and exploratory analysis.

1. “Collaborative Research: Dynamic Resource Allocation Models for Law Enforcement
Operations against Illegal Drug Trafficking” Drug Proposal provided by Professor
Thomas Sharkey.
2. "Arena User's Guide." Rockwell Software. Rockwell Software, 1 Nov. 2007. Web. 1
May 2015.
<http://literature.rockwellautomation.com/idc/groups/literature/documents/um/arenau
m001_enp.pdf>.

38


Appendix

Exhibit A Information Threshold Application

Goal:
To change the current Triangular Distribution Method of an overall Information value to a
specific Uniform Distribution Method manipulated to identify Information by entity group as a
total throughout the system. This will therefore add a random aspect to prison captures
beyond the current scope of multiple nway by chance nodes.

Variable Overviews and Assumptions:
❏ Info on Dealer
❏ Info on Safe house
❏ Info on Big Guy
❏ Info on other users

1. Variable that are added throughout the entire system
2. “Running Sum” that resets when it hits a certain point
a. Compared to a threshold
3. These values will be percents multiplied by our Triangular Distribution

As each entity enters the system dealer, user, safehouse, or big guy; they each will generate
(instead of one random information value I) a set of values according to the types of
information each entity will have and increment the system Values Accordingly.

Defining the Variables
● U set of Info containing [Info.User, Info.Dealer]
● D [Info.User, Info.Dealer, Info.Safehouse]
● S [Info.BigGuy, Info.Dealer, Info.Safehouse]
● B [Info.Safehouse, Info.BigGuy]
● Info_Prison_Threshold = 10 This is the level we set, to where if any entity gets
information larger than this threshold they go to prison

As U enters:
Info.User = Info.User + 0.70*U(0,1)
Info.Dealer = Info.Dealer + 0.30*U(0,1)

As D enters:
Info.User = Info.User + 0.35*U(0,1)
Info.Safehouse = Info.Safehouse + 0.25*U(0,1)
39


As S enters:
Info.BigGuy = Info.BigGuy + 0.10*U(0,1)

As B enters**:
Info.BigGuy = Info.BigGuy + 0.30*U(0,1)

**This is saying that a User has a 50% chance of knowing other users, a 50% chance of
knowing other dealers. By this argument, the IPT [List 1 Info_Prison_Threshold], can be the
same for each entity because we are controlling the threshold by multiplying a super small
percentage by a consistent Uniform Distribution.

Exhibit B Version Control Current: 8.6 (see zip file)
Table 1: Meeting Minutes
Date of
Meeting
Work Discussed Requirements for
Next meeting
3/10/2015 Possibility to Arrest another dealer if first dealer
gives information / cooperate (Snitch Node)

Short prison (snitch) or long prison (arrest then
talk)

if short prison is chosen, automatically pick dealer
from arrival and place in prison
Get rehab aspect
completely functional
3/30/2015 make more appropriate values for distributions
(rehab processes)

resources, resources, resources!

rates and capacities for resources and nodes
Get rehab aspect
completely functional

Define resources

update arena model
4/7/2015 Tyler improved model,
Ian explored ways to implement signaling and
matching techniques
Make a small
4/14/2015 Questions:
● Optquest? Tools?
● Report Format?

40


● Define the purpose of this URP in a few
main bullet points

Assumptions / Key Points:
∙         Run Setup -> 8 hours a day/10 days (not realistic)
∙         Arbitrary rate of Incoming drugs = (1 drug value
per half hour)
∙         The drugs leave the system a deal is made – I am
assuming that they are consumed and used almost
immediately after the deal.
o   The caveat is that this doesn’t capture police
raiding drug stashes or acquiring crack cocaine – but
let’s leave that out of scope for now.
∙         The police arrive at an arbitrary rate
o   For future efforts - I am unsure how to restrict the
total amount of police in the system
∙         Decision nodes are 50/50 – which are incorrect,
these were just the default values.
4/21/2015 April 21

To add: Info levels on other entities, depending
whether the entity “cooperates” or not
● If a user cooperates, info levels of the user
will increase, along with a small amount of
increase for the dealer’s info levels
● If a user does not cooperate, info levels of
the user will only slightly increase
● Apply the same principle to each entity
● make note of the fact we used student
version of arena and how we would scale it
up for licensed version of software (save a
test version with all the ideal numbers)
● implement the arrival capacity of users and
drugs to monitor how they leave if not
through arrest or rehab (Disposal)
● Record if users reached the “arrest” node
and then how many are returning into the
system

Functions to Look at:
There are no costs involved in this system

41


● Maximize arrests
○ breakdown of arrest types
● Maximize Users entering rehab

IDENTIFY BOTTLENECK

Constraints:

● All info.x >= 0
● Dealer.arrests + user.arrests +
safehouse.arrests + BigGuy.arrests <=
Arrests.made
● Set capacities of drugs at each level
● Set capacity of dealers for when then
reload drugs
● Force the big guy to arrive first so
bottleneck chance decreases (lower and
quicker)
● Drugs arrival >= 0
4/28/2015 Begin to Format
Added Table of Contents

Need to obtain a license for optquest, future
recommendation

at this point, we can construct an optquest(not
difficult), but without the appropriate license,
optquest just runs in demo mode which is useless
for us

Working on pushing outputs, but editing arrivals is
the only thing that changes any output given, other
than probabilities in the info.x, but only affects the
‘user specified’ report (not sure why this is the
case)

might need to look at tweaking the model, but with
time considerations, might be best to just output
our report with the model as is and make note of
some fixes/goals to accomplish for the next group.
(none)

42


Exhibit C Arena Screen Shots 3/10/15

1. Entire Model

2. User Model

Annotation: The decision node and rehab process deposit into a “Leave System” node.

3. Dealers / Safehouses / Big Guys

Annotation: This is an example of the “Big Guy” progression. Again, The branch off the
decision node “Big Guy After Prison” connects to the “Leave System” node. The branches for
“Dealers” and “Safehouses” are of identical structure and make, just with the word “Big Guy”
replaced by “Dealer” or “Safehouse”.
43


Exhibit D Arena Model 4/14/2015:
1. Current Total Arena Model

Annotation: Above is a screenshot of the current Arena model. In it, Users, Dealers,
Safehouses, and Big Guys’ drug activities are modeled. Dealers, Safehouses, and Big Guys
are all modeled in the same fashion, except with different numbers.

2. Batch and Match Modeling Drug Supply in Drug Deals

Annotation: Above is what an initial example of a model that captures the discrete event of
arrests and drug deals with Batch and Match models. This is supposed to represent
44


everything that happens before a User, Dealer, Safehouse, Big Boss goes into the ‘Drug
Exchange Module’
45

DrugURP - Final Draft

Recommended

Recommended

More Related Content

Similar to DrugURP - Final Draft

Similar to DrugURP - Final Draft (18)

DrugURP - Final Draft