The Routes & Rumours Model

We model the formation of migration routes and how it is affected by the availability and exchange of information. In our model agents attempt to traverse a - for them - mostly unknown landscape, having to rely on either local exploration or communication with other agents to find the best path across.

This document describes the full version of the model, including in particular risk and resources. Both of these aspects of the model remain unused in some of the publications that are based on it. Since they can be switched off completely (using model parameters) only the active parts of the model are documented in publications outside of this document.

We deliberately restrict this documentation to a technical description of the working of the model itself. This is very much a qualitative, not a predictive model (and should not be treated as such). Consequently purpose, parameterisation and analysis depend to a large degree on the context in which the model is used (Hinsch and Bijak, In Press). For a number of different applications of versions of the model see Bijak (In Press).

Any documentation of a computational model has to make a trade-off between accuracy and accessibility. A fully accurate and complete document will necessarily be as complex as the source code it describes and therefore at best only slightly easier to read.

Documentation therefore has to simplify. This can happen in two ways. One, by leaving out “obvious” details, that is by not describing technical implementation details that can be expected to be inferred by a reasonably competent reader. For example when we write that all cities that are closer than a given distance will be connected by a link we implicitly assume that the reader understands that this means that - if they were to replicate the model - they needed to implement a loop over all combinations of cities, calculate their Euclidean distance, test if that distance is lower than the given threshold, then, if so, create a new link object, initialise it accordingly, add the link to both cities, and so on. This does not necessarily mean that there is only one possible implementation of the mechanism we describe und the implicit assumption is that any implementation will produce the same result.

The second way to “abbreviate” is to not specify semantic details of the model itself that we assume will not affect its behaviour. We do for example not specify which random number generator we are using. Similarly we do not describe for each calculation the exact steps we are performing and their order. In both cases different interpretations will lead to different numerical results (due to different algorithms and different rounding errors, respectively), however, we assume that these are irrelevant for the behaviour of the model.

Ideally, this documentation should therefore be the minimum of information that would be required to recreate the model (without having access to the source code) while producing sufficiently similar results that the same conclusions would be reached as based on the original. In practice, even with best efforts, documentation of software is very rarely fully complete and accurate, ultimately making the source code the authoritative reference.

This leads us to the other purpose of documenting a model, which is to make the source code more accessible. Reading and understanding somebody else's program code is generally not easy, but knowing beforehand what the code is supposed to do can help substantially. To reduce the hurdle even further we have attempted to use a notation, layed out in the next section, that makes connections between description and implementation as obvious as possible.

Most of the time mathematical expressions are more concise and more accessible to a broader audience than program code. We therefore defaulted to using mathematical formulae as a formalism for expressing calculations in the model. On the other hand, the large number of variables and parameters in the model makes the mathematical convention to use single letter variable names unviable. Since we also wanted to make it as easy as possible to find and understand the source code belonging to a part of the documentation, we therefore attempted to use names exactly as they occur in the code wherever possible. To further clarify the relation between the text and the source code we use the following conventions.

Variable, type and function names that are copied verbatim from the source code are shown in sans serif font in mathematical formulae as well as in the text. Where the name is also a model parameter we additionally set it in bold face in the text (a full list of parameters also appears in the Appendix). Names that are used only in the documentation (for clarity or as abbreviations) are shown in italics in the text as well as in mathematical expressions, as are helper variables. Important model concepts are set in the standard font but underlined when mentioned for the first time or for emphasis. For example, there is a difference if we talk about the concept of an agent or the type Agent in the program code. Similarly we have to distinguish between the concept of an obstacle in the simulated landscape and the model parameter obstacle.

Source files or modules that contain the implementation of a given section are referenced in margin notes next to the section headings.

Entities directly represented in the model are agents, cities and transport links.

At any time agents are either present at a city or a transport link or they have arrived at an exit.

Each agent has a list of other agents that it stands in contact and can exchange information with (see Section 5.2).

Each agent has a potentially incomplete and inaccurate set of knowledge items concerning the world. Each item describes the properties and topology (i.e. connections to other entities) of a city or a transport link.

Agents maintain a list of cities they plan to move to on their way to the exit.

Each agent has properties slope and int that determine slope and intercept, respectively of its reaction to risk.

Cities are located at a specific position on the map and differ in quality and resources. Cities are connected amongst each other by randomly generated transport links (see Section 3). There are a number of designated entry and exit cities at which agents arrive and leave the world, respectively.

Links always connect two cities. In the basic version of the model the only property of links is friction which represents a combination of distance and difficulty of travel. In the risk version of the model links also have risk associated which is used to calculate the probability for an agent to die when crossing that link.

Newly created agents explore their current location with speed speed_expl_stay and indirect discovery (see Section 5.3). They know exit cities with probability p_know_target and regular cities/links (out of those that can be known to agents before setting off, see map creation above) with a probability p_know_city and p_know_link, respectively. They explore each known city using exploration speed speed_expl_ini and no indirect discovery. Finally they explore known links if they already know one of the end points (also with speed speed_expl_init).

The model is implemented as an event-based simulation. That means that updates to the model state do not happen in discrete time steps but instead as a result of asynchronous events (see Table 1). All events in the model are assumed to be Poisson processes in continuous time (Gillespie, 1976).

With the exception of the creation of new agents all changes of model state are the result of the actions of agents which are also the only entitites that change state. Which actions an agent can perform and their rates of occurence depends on its state, in particular on whether it is currently travelling on a link or staying in a city. Agents can exchange information with other agents either in their contact list or present at the same location as they are. They can travel along transport links and collect information on their current and neighbouring cities.

Most processes are changes of state in single agents. Whether they can apply is usually dependent on whether an agent is travelling (= present at a transport link) or not (= present at a city). It is important to note that every agent in the population at any time that it fulfills the respective conditions can potentially experience the event in question.

Agents are created with rate rate_dep. They enter the world at a randomly selected departure location. For details see Section 3.

During planning an agent decides where to go next, depending on its current knowledge. Agents plan with a rate rate_plan if their knowledge about the world has changed and 0 otherwise. During planning agents decide on where to go next, either based on local optimization or on finding the best route to an exit (see section 5.4 for details).

An exploring agent gains new knowledge about closeby cities and links. Agents that do not travel explore their current location at a fixed rate rate_explore_stay, using speed speed_expl_stay and employing indirect discovery (see Section 5.3 for details).

An agent adds a new agent that is currently situated in the same city to its list of contacts. Agents meet new contacts at a rate $\#otheragents\cdot p\_keep\_contact$ if their current number of contacts is below n_contacts_max. A randomly selected agent from the focal agent's current location is added to the contact list. If the other agent has space in its contact list as well the contact becomes mutual. Then both agents exchange information (see Section 5.2).

Agents lose contacts at a rate of $\#contacts\cdot p\_drop\_contact$. Forgotten contacts are only removed unilaterally, that is the other agents will keep its contact.

An agent communicates with one of its contacts and exchanges information about the world topology, i.e. the existence and connectedness of cities and links, as well as their properties. Agents communicate at rate $\#contacts\cdot p\_info\_contacts$. See Section 5.2 for details.

An agent departs from its current location and starts travelling to the next location in its plan. Departure rate is 1 unless the agents capital is lower than save_thresh and its expected income is greater than save_income.

On departure an agent leaves its current location and is now located on the link to the next location. It immediately explores the link with speed speed_expl_move (see Section 5.3). It also loses $costs\_move\cdot friction$ resources which are substracted from its capital.

A travelling agent arrives at its destination. Agents arrive at a rate $move\_rate+move\_speed/friction$. Arrived agents change their location to the destination.

Agents travelling on links can die. For a link with arrival rate $r_a$ the mortality rate of agents travelling on that link is $r_a\frac{risk}{1-risk}$. Therefore the probability for an agent to die before arrival is just the risk value associated with the link. Deaths can affect the perceived risk of other agents (see Section 5.5 for details).

When staying at a location agents can lose or gain resources. The change in resources happens at a rate rate_costs_stay and is calculated as $$ben\_resources\cdot resources-rate\_costs\_stay$$ (with resources the resource availability at the current location).

We based our information model on the well-known mass action dynamics. To understand the model it is best to imagine that an agent's belief consists of two “substances”, certainty and doubt, in proportions $t$ (trust) and $d=1-t$, respectively. When two agents interact a “reaction” between their respective belief components takes place, potentially transforming them (see Table 2). Doubt reacting with doubt produces doubt. Certainty of one agent interacting with the other agent's doubt can “convince” the latter, changing parts of its doubt into certainty. Depending on the difference in estimate certainty interacting with certainty can lead to confusion and increased doubt or just change the estimate.

During exploration agents discover new cities and links and refine their knowledge about those they are already aware of. There are several situations in the model that let agents explore their environment (see Section 4), the basic mechanics are identical, however.

Unless mentioned otherwise the properties of newly discovered links and cities are initialized with “expected” default values risk_exp, res_exp, etc.

When exploring links or cities an agent always improves its estimate of the respective entities' properties. An agent's belief is updated by calculating the new value $v\text{'}$ and trust $t\text{'}$ as simple weighted means using a learning speed $s$ (which can differ dependent on situation) and target or true value $v_t$ (the target value for trust is $1$):

When exploring a city with indirect discovery enabled then it finds and immediately explores links connected to that city with a probability p_find_links. Neighbouring cities connected through these links are always discovered (i.e. known and properties set to default values) and with a probability p_find_dest also explored (with half learning speed and no indirect discovery enabled).

Using agent-specific parameters int and slope (see Section 3.2) we can then calculate a safety score $s$ (strictly speaking the probability for an agent to decide in favour of a potentially unsafe action):$$s=\frac{e^{int+100p_{s}slope}}{1+e^{int+100p_{s}slope}}$$

If agents are not able to find a route to an exit they will pick a destination at random from all immediately reachable cities (i.e. the current location and all its known neighbours). The probability to pick a location $i$, $p_i$ is its relative suitability modified by qual_bias: $p_i=(l_i/\sum l{)}^{qual\_bias}$. Suitability of a location $j$, reachable by link $i$ depends on proximity to the exit x, attractiveness $a$ and the difficulty of reaching it due to friction and risk (both of which are assumed to be $0$ for the current location):

If an agent knows enough to find a complete route it will attempt to travel the route with the lowest costs. The cost of a route is simply the sum of the costs of all its segments which again are a function of travel effort and properties of the waypoints. Specifically, the costs of a segment consisting of a link $i$ leading to a city $j$ are calculated from effective friction $f_{eff}$ and safety score $s$ of the link (see above), and (quality dependent) cost of the destination as $$e_i=f_{eff,i}{e}_{q,j}+path\_penalty\_risk\cdot \left(1-s_i\right)\mathrm{.}$$

The cost of a waypoint then decreases with increasing attractiveness:

Travel in the model can be risky and agents can perceive and react to that risk. Risk is perceived and communicated by agents in the same way as other properties of the world. In addition, however, perceived risk can be directly affected by deaths either of contacts or by nearby agents. Every death has a chance of being noticed by contacts of the dead agent as well as agents travelling on the same link with probabilities p_notice_death_c and p_notice_death_o, respectively. If an agent noticing a death knows the link it has occured on, it adjusts its risk estimate for that link towards 1 with learning speeds speed_risk_obs and speed_risk_indir (for direct observation and contacts, respectively), following the same rules as knowledge updates during exploration (see Section 5.3).

For the effects of risk on decision making see Section 5.4.

This work was funded by the European Research Council (ERC) under the European Union's Horizon 2020 research and innovation programme (grant no. 725232) for 2017-2022, and executed by the University of Southampton, with the University of Rostock.