BESSIE: A Behavior and Epidemic Simulator for Use With Synthetic Populations

In this paper, we present BESSIE (Behavior and Epidemic Simulator for Synthetic Information Environments), an open source, agent-based simulator for COVID-type epidemics. BESSIE uses a synthetic population where each person has demographic attributes, belong to a household, and has a base activity- and visit schedule covering seven days. The simulated disease spreads through contacts that arise from joint visits to the locations where activities take place. The simulation model has a plugin-type programmable behavioral model where, based on the dynamics and observables tracked by the simulator, agents decide on actions such as wearing a mask, engaging in social distancing, or refraining from certain activity types by staying at home instead. The plugins are supplied as Python code. To the best of our knowledge, BESSIE is a unique simulator supporting this feature set, and most certainly as open software. To illustrate the use of BESSIE, we provide a COVID-relevant example demonstrating some of its capabilities. The example uses a synthetic population for the City of Charlottesville, Virginia. Both this population and the Python plugin modules used in the example are made available. The Python implementation, which can run on anything from a laptop to a cluster, is made available under the Apache 2.0 license ( The example population accompanying this publication is made available under the CC BY 4.0 license (



page 1

page 2

page 3

page 4


City-Scale Agent-Based Simulators for the Study of Non-Pharmaceutical Interventions in the Context of the COVID-19 Epidemic

We highlight the usefulness of city-scale agent-based simulators in stud...

An Activity-Based Model of Transport Demand for Greater Melbourne

In this paper, we present an algorithm for creating a synthetic populati...

Deep Learning-based Spatially Explicit Emulation of an Agent-Based Simulator for Pandemic in a City

Agent-Based Models are very useful for simulation of physical or social ...

COVID-19 Epidemic Study II: Phased Emergence From the Lockdown in Mumbai

The nation-wide lockdown starting 25 March 2020, aimed at suppressing th...

Herd Behaviors in Epidemics: A Dynamics-Coupled Evolutionary Games Approach

The recent COVID-19 pandemic has led to an increasing interest in the mo...

Building a large synthetic population from Australian census data

We present work on creating a synthetic population from census data for ...

Collecting big behavioral data for measuring behavior against obesity

Obesity is currently affecting very large portions of the global populat...
This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1. Introduction

Pandemics, such as COVID-19, are complex, behavior-driven phenomena [22]. Governments and other authorities all over the world have relied on many non-pharmaceutical interventions (NPIs) for controlling the spread of diseases, especially before vaccines became available. These interventions have included mandating business and school closures (or reduced capacities), and promoting mask wearing, physical distancing, and working from home [7]

. Broadly, the goal is to restrict interactions between people by restricting mobility and to reduce the probability of transmission when people do interact.

In the agent-based modeling and simulation community, many models and platforms have been developed, with goals including understanding the spread of the epidemic, forecasting, guiding policy-making, and evaluating counterfactuals [23, 10]. While different goals may require different kinds of models, doing a detailed analysis of the effects of NPIs requires two main ingredients or components: adequate detail based on real data [24] and true agency (adaptive coupling with the environment, normativity, etc. [1]). This is because interactions in a population are contingent on, on the one hand, the demographics, activity patterns, and built environment of a region, and on the other hand on human behavioral decisions, which depend on descriptive and injunctive norms [2], perceptions of risk and severity, as well as perceptions of the efficacy of behaviors in risk-reduction [16]. In [23] human behavioral modeling is also identified as one of the main challenges in agent-based modeling of the COVID-19 pandemic, as does the NSF in a recent Dear Colleague Letter [19].

While many epidemic simulation models exist (see the Related Work Section), all the ones we know fail to satisfy at least one of the following aspects:

  1. the model is agent-based;

  2. it supports incorporating human behaviors through the notion of actions;

  3. uses a detailed visit schedule that the agent may dynamically update;

  4. the simulator and its source are made available and accessible for download under a suitable license;

  5. has made input data available and accessible for at least one non-trivial case under some suitable license;

While there are many reasons why other research and development efforts omit one or more of these elements, we remark that doing so certainly presents real challenges for peer review, reproducibility, and independent validation of models.

Contributions. Here we present the integrated epidemic/behavior simulator BESSIE. This computational tool integrates (i) detailed synthetic populations, with (ii) a completely configurable behavioral model governing the use of personal protective equipment (PPE), social distancing, and options for abstaining from certain activity types (e.g., non-essential activities), and (iii) a COVID-like epidemic process where transmission may occur upon contact arising when people simultaneously visit a common location. Since agents in our model can base their behavior on observations of other agents and parts of their state (through the notion of local observables) as they visit locations, this can clearly give rise to “clustered behaviors”. As far as we know, this is a unique feature of BESSIE not present in any other simulator as outlined in the Related Work section. We remark that BESSIE

was developed to support a machine learning (ML) environment, and incorporating local observables in the actions decisions of agents was central to the model design. The

BESSIE simulator is implemented as a multi-process, shared memory, Python package that can run on desktops and laptops, as well as on clusters. Along with this tool, two synthetic population data sets are provided: the hypothetical “Smallville” with its three inhabitants that can be used for testing, and the City of Charlottesville population which has about 41,000 people. Both populations include a weekly visit schedule specifying what activities the citizens conduct, when they do them, as well as where they take place.

Our intention is to provide the scientific community with an open simulator integrating a completely configurable human behavioral model and an individual-based, location-based, extended SEIR model whose parameters are configurable. BESSIE can run on a desktop, laptop or a cluster taking advantage of the number of available cores. We think this can provide a model for publishing that supports both reproducibility and peer review. BESSIE is available for download under the Apache 2.0 license through its git repository, see [17]. Its accompanying data, the synthetic population of the City of Charlottesville (CoC), is available for download under the CC-BY-4.0 license, see [18].

Paper organization. In the next section, we give background and an overview of related work. This is followed by an overview of BESSIE, including the synthetic populations, the epidemic model, as well as the behavioral model. We then describe the usage at a high level, illustrate its use through several application examples, and close with a discussion of applications and possible extensions. The appendix sections contain a detailed description of the design of BESSIE, including plugin interfaces, input and output data formats, and the details of the synthetic population structure.

2. Related Work

There have been many simulations that have been developed and published since the early days of the COVID-19 epidemic, including a large number of agent-based simulations. [15] provide a recent review. They point out that, of the 126 models they review, only 6 include adaptive human behavior. While several include detailed synthetic populations, none include both detailed synthetic populations and adaptive human behavioral models. Thus, BESSIE occupies a unique niche in the space of agent-based simulators for COVID-19 (and for infectious disease epidemics in general). Our synthetic population is also the most detailed of its kind, as it includes several demographic variables, household structure, data-derived weekly activity schedules for all agents, and comprehensive activity location data [adiga15US]. Here we briefly describe some of the more popular agent-based simulators that are comparable to our work, while also highlighting the differences.

The IDM Covasim simulator [14] is a widely used agent-based simulation of COVID-19. It uses synthetic populations from, but works mainly on the agent interaction networks induced by the synthetic population. These synthetic populations are also relatively simple, in that they do not model activity and mobility patterns in the population or actual locations. They rely on data about age-stratified mixing in the population to generate modeled contact networks for the simulation. This is, in fact, a micro-simulation model as opposed to an agent-based model, since the “agents” in this simulation do not make observations, or do any decision-making. Many kinds of interventions can be scripted, however, allowing simulation of many kinds of programmed scenarios.

The OpenABM-Covid19 simulator [13] is another open source COVID-19 simulator that has been widely used. It is also Python-based, though the core components of the model are written in the C language for speed. It thus claims to simulate a population of 1 million interacting people in seconds for each day of the simulation. It is designed primarily to support policy-making in the UK, by simulating a default population of one million agents generated from demographic data from the UK Census. In this case, the model of interaction in the population is somewhat stylized, as individuals move between networks representing households, public transport, workplaces, schools, transient social gatherings, etc. These locations do not appear to be based on data, though the average numbers of interactions are set to match age-stratified mixing data. Once again, this is a micro-simulation, not a true agent-based simulation, capable of evaluating various non-pharmaceutical interventions, including manual and digital contact tracing.

ComoKit [9] is also a well-known COVID-19 simulator based on the GAMA platform. It uses more sophisticated synthetic populations than the previous two simulators, e.g., populations created by the Gen* [4] synthetic population generator. [9] present a simulation of the Son Loi Commune in Vietnam, which has about 10,600 people and 3000 buildings. In their model, agents have week-long, hourly activity schedules, at various locations, which is similar to our synthetic populations. They can also evaluate various policies such as social distancing, and the simulator allows script-based editing of the types of agents, policies, and activities that are included in the simulation. However, they also do not allow the individual agents to do their own decision-making, thus making this essentially a micro-simulation.

While there are several other simulations (and simulators) that have been widely used (see [15] for many examples), they largely share the characteristics of the ones described above. BESSIE is thus different from all of these in allowing for decision-making by individual agents in a richly detailed environmental context. It thus opens the door to connecting agent-based modeling efforts in computational epidemiology with research in behavior and decision-making from domains such as psychology, sociology, and public health.

3. Bessie: Overview

The BESSIE tool implements an agent-based, time-stepped model for epidemic spread that integrates the following features:

  • A synthetic population with a visit schedule as detailed in the Synthetic Populations sub-section below. Such a population has a set of people with demographic attributes, and is partitioned into households. Each member of the population has an activity sequence where each activity is mapped to a location. By executing their activity sequence, people come into contact.

  • An epidemic process taking place over the population, see the Epidemic Model sub-section. Transmission can occur when susceptible persons come in contact with infectious person(s) at one or more locations.

  • A customizable behavioral model allowing each person to adopt a set of measures. These include wearing a mask, engage in social distancing, and modifying their visit schedule modifications to refrain from selected activities. Activities that are omitted are replaced by staying-at-home. The behavioral model can use demographic information about the person, as well as information about global observables (e.g., total number symptomatic people), or local observables capturing things they have seen at previous visits (e.g., number of symptomatic cases observed when shopping).

The following sub-sections provide details on the major BESSIE components.

3.1. Synthetic Populations

BESSIE uses the notion of a synthetic population (SP) which is a statistically accurate representation of a population of a given region, see [6, 8] for a detailed account. An SP for a given region  has the following components:

  • The set of individuals  of  grouped into households. Each person is equipped with demographic attributes such as age, gender, household income, and a simplified version of the NAICS classification.

  • Each person has an activity sequence specifying what activity they perform and when. The activity sequence covers a complete week and include the activity types covered are home, work, shopping, other, school, college and religion.

  • A set of locations  consisting of residence locations and general activity locations. Each household is assigned a residence location.

  • A location assignment  that for each person  and for each activity  of  assigns a location .

As one can see, the synthetic population allows one to deduce precisely who visits a location at the same time at any point throughout the week. For BESSIE, this information is assimilated into a person file and a visit file, see the appendix section on usage for a detailed description of the data records.

3.2. Epidemic Model

The epidemic model used in BESSIE is an extended model that includes the following states:

  • – susceptible;

  • – exposed;

  • – infectious and symptomatic;

  • – infectious and asymptomatic;

  • – recovered;

We write for the set of health states. The dynamics of the disease are split into two components: (i) disease transmission in which a susceptible person becomes exposed when in contact with an infectious person, and (ii) disease progression covering all other health state changes. One may regard transmission as the “between people” and progression as the “within a person.”

Disease transmission. Transmissions may only occur when a susceptible person is in contact with an infectious person. In general, we use the notion of a transmission configuration to capture the situation where a susceptible person changes his/her state from (the entry state) to  (the exit state) in contact with a person  in an infectious state  (the contact state), and denote this configuration by the triple . For our disease model there are only two transmission configurations:

For a general disease model, any entry state is called a susceptible state, any exit state an exposed state, and any contact state an infectious state. Each transmission configuration has an associated transmission weight that represents the relative weight of this particular transition. It assumes the default value 1.0. We remark that the transmission configurations are disease properties independent of people. Each state  has an inherent infectivity  and susceptibility . Note again that these are person-independent disease parameters. To capture individual factors (e.g., due to vaccinations and/or wearing a mask), each person  is assigned an infectivity and a susceptibility scaling factor, and  respectively. These have a default value of 1.0 but are generally time-varying. The effective susceptibility and infectivity of a person  in state  are modeled as,


Finally, a disease model will have a transmissibility that we denote by . It may be regarded as a scaling factor. With this, we can now define the propensity  of a contact configuration where persons  and  are in contact at a location  for a duration :


We use the Direct Gillespie Method [12, 11] to determine if a disease transmission takes place when visiting a location, and, if there are transmission configurations for a susceptible person, which of the contact persons at that location to whom one attributes the transmission. Specifically, for each person  in state  we set,


where the sum extends over all neighbors of and indices and for which a transition may have taken place. Without loss of generality, the index set of triples is well ordered. To determine whether we have a transition we sample a random number,

and if the inequality (the duration of the time step) holds, we select the actual transition by sampling a uniform random number and determine the index for which,


Finally, for each time step, all such candidate transitions from all locations are collected for each person , and the final infector person  is determined using uniform random sampling proportional to the single propensity returned for each location. The state transition for  will take place at the end of the each time step (and will override any disease progression that may have been scheduled for the current time step, see below.)

Disease Progression. We use a disease progression diagram to capture all possible health state transitions that take place within a person in the absence of transmission processes and interventions. The diagram has nodes all possible health states  and directed edges  with assigned probability  and a dwell time distribution . For each state it is required that . The dwell time distribution  is the probability density for the dwell time in health state  given that the transition  will take place.

Algorithmically, the disease progression is determined upon entry to a new state: as a person  enters a state , the next state is sampled according to the next state distribution induced by the probabilities . Once the next state is determined, the dwell time  (unit is simulation time steps) is computed by sampling from the associated dwell time distribution , rounded to the nearest integer if necessary, and bounded below by 0. If the current time step is , the state transition is scheduled to take place at the end of time step . Note that in particular, this means the transition can take place with the current time step.

Example. For the SEIR model of BESSIE, we have shown the combined transmission and progression diagram in Figure 1. Note that transitions corresponding to transmissions are shown using dashed edges; edges corresponding to progression are shown as regular edges. Disease parameters can be found in the git repository in the file ./src/, disease parameters are not exposed in the configuration file, see the appendix sections.

Figure 1. The combined transmission- and propagation diagram of the model used by BESSIE. Dashed edges are for transmissions; solid edges are for propagation. The edges for transmission are decorated by the respective contact states.

3.3. Behavioral Model

The behavioral model is formulated using the notion of actions. Users may use the default model that is contained in, or may supply their own model as specified in Appendix B. Either way, at the beginning of each time step, each person  will decide on what action(s) to take in that time step for each of the following choices:

  • Wear a mask ();

  • Social-distance ();

  • For each of the activity types other (), college (), shopping (), religion (), school (), and work () decide whether or not each visit of that type for the given time step should be replaced by staying at home;

Thus, for each person and for each time step , an action is selected. To decide on the actions to take, the following information is available for each person:

  • the current time step ;

  • their own current health state ;

  • the static list of demographic variables of  (see the Usage section);

  • the list of global observables containing the current total count and fractions of people in each of the disease states (e.g.,  and  for state );

  • the current local observables for . These capture the following information for each activity type , recorded at the beginning of the most recent of visit for to a location to conduct an activity  of type :

    • the time step when took place;

    • the person ID (pid), the location ID (lid) , and the activity type ;

    • the total number of people present at at the start of that visit;

    • the total count and fraction of people present at at the start of that visit of that are (i) symptomatic, (ii) are wearing a mask, and/or (iii) are engaging in social distancing.

We remark that the actions of wearing a mask and social distancing will be applied to all activities of the given time step. One may argue that a person may decide that on an activity-by-activity basis; we may add this in a future version of BESSIE. Clearly, refraining from the activities of a given type will limit the exposure in that context, but one may still be exposed to one’s own household members. Wearing a mask or engaging in social distancing will cause the person’s infectivity and susceptibility scaling factors to be reduced, currently as follows:

Scaling factor Value Scaling factor Value
mask_inf_scale 0.8 mask_susc_scale 0.8,
distancing_inf_scale 0.8 distancing_susc_scale 0.8

4. Usage Overview

The git repository contains a file with up-to-date instructions for how to invoke BESSIE. For completeness, we include a terse version here with section pointers to files and their precise formats. Running the BESSIE simulation tool requires having Python version 3.8 or greater installed on the system. Assuming the computing environment is appropriately configured, an invocation of BESSIE will need the following components, all of which are detailed in the appendix sections:

  • a configuration file;

  • a schema file;

  • a person file and a visit file; and

  • a Python action file containing a behavioral model.

The source distribution comes with a schema file, see the git repository and the file ./schema/schema.json. Using the provided example of Smallville, which has a configuration file ./config/smallville_config_1_0_0.json, one may invoke BESSIE from the terminal as follows:

python -c smallville_config_1_0_0.json -s schema.json

If the user is computing on a cluster using a job submission system (e.g., qsub or slurm), they may have to specify full paths for the command-line arguments. BESSIE accepts an additional commandline argument -l <level> where level is one of info, debug, warning, and error. This may be useful if there are problems running the code with a custom action file.

The person- and visit files are specified in the configuration file, as is the Python file implementing the behavioral/action model. The distribution comes with a basic behavioral model:


This may be a convenient starting point for constructing custom versions. The user will most likely have to edit a copy of smallville_config_1_0_0.json to specify correct filenames and paths for their system. We recommend using full paths in all cases. The output will be generated in a directory specified in the configuration file (output_directory).

5. Application Examples

We provide two example populations along with the BESSIE simulator: (a) Smallville, and (b) City of Charlottesville (or CoC). Smallville is provided as an example that one should be able to run quickly on any machine. In this paper, we do not run analyses on Smallville, but we give hints of parameter values that may be interesting for exploration and testing of action modules.

5.1. Smallville

In Smallville, everything is small-scale. On the other hand, its citizens only work and stay at home, so presumably they get a lot done. The person and visit files are constructed from the following information:

  • People: there are three citizens labeled 1, 2 and 3;

  • Locations: there are three residences with location ID (or lid) of 11, 12 and 13. Additionally, there are three work locations whose lids are 1, 2 and 3;

  • Residence assignment: person i lives in the residence location with lid = i+10;

  • Activity sequences: each person has the same weekly activity sequence, and every day looks the same. Each person goes to work at midnight, work for one hour, and then returns to their home where they spend the remaining 23 hours of the day. People thus have only two activity types: home and work.

  • Activity location assignment. The only part that varies from day to day is the location where the citizens go for work:

    • person 1: works at location 1 on Monday (day 0) through Sunday (day 6).

    • person 2: works at location 1 on Monday through Wednesday. The remainder of the week, they go to location 2 for work.

    • person 3: works at location 1 on Mondays, location 3 on Tuesdays and Wednesdays, and at location 2 on the remaining weekdays.

Thus the most mixing that happens is at location 1. The weekly contact network for the three citizens of Smallville is a complete graph.444Despite the somewhat monotonous daily routines, Smallville consistently rates high in best-places-to-live reports. Parameters: for the verification and validation runs using Smallville, we used the model parameters tau = 0.05 (transmissibility) and contact_probability = 1.0. That way, simultaneous visits to the same location will imply that the corresponding people are in contact (or are connected by an edge in the induced contact network).

5.2. City of Charlottesville (CoC)

This example demonstrates the use of BESSIE using a synthetic population for the City of Charlottesville, Virginia. The accompanying action- and configuration files can be provided upon request (see [17]) as can the person- and visit files [18].

Model parameters. Here we use tau = 0.0000015 and contact_probability = 0.33. These particular values were set to generate an unmitigated attack rate in the range 60–70%, see [3]. We remark that there are several BESSIE parameters in addition to transmissibility and contact probability that can be used for calibration, and there are also other metrics than attack rate that can be used on the dynamics, examples including time-to-peak, and width-of-peak. Other calibration parameters include:

  • State infectivity and state susceptibility, iota and sigma: each health state , , , , and has associated a pair of such values. These disease parameters are set to either 0 or 1 in BESSIE, but could potentially be any positive number. Currently, these disease parameters are not exposed in the configuration file.

  • Dwell time distributions associated to the transitions , , and . These are set in the file ./src/ and are currently not exposed in the configuration file, but see the appendix section.

  • When wearing a mask, infectivity and susceptibility are scaled by mask_inf_scale and mask_susc_scale which are both set to 0.8 (parameters are not exposed).

  • When doing social distancing, infectivity and susceptibility are scaled by distancing_inf_scale and distancing_susc_scale which are both set to 0.8 (parameters are not exposed).

We consider four scenarios that demonstrate the capabilities of BESSIE, and that may also give some insight into what it takes to construct successful interventions from a public policy perspective. More complex examples can easily be constructed using the ones provided here as templates or starting points. The action and configuration files used for these examples are listed in Section 10.6.

Scenario 1. In this base scenario, everyone goes about their visits as if nothing happened, not wearing masks nor doing any social distancing. As can be seen in the diagram of Figure 2, the end result for this simulation instance is that  people contract COVID during the course of this outbreak, corresponding to about 65% of the population of CoC.

Figure 2. Scenario 1 (base): in the base scenario, people go about their lives as if nothing happened. In this case, about 65% of the population get COVID (black curve, recovered), comparable to values reported in [3].

Scenario 2. The second scenario demonstrates the case of wearing masks and doing social distancing. In sub-scenario (a), a subset of size 70% of the population is chosen randomly at each iteration , and members of this set will wear a mask and do social distancing. In sub-scenario (b), a fixed but random subset of the population is chosen. The members of will use a mask and do social distancing at each iteration. Epidemic trajectories for each case are shown in Figure 3. We see that the epidemic is completely prevented for this particular simulation instance in sub-scenario (b).

Figure 3. Scenario 2: the diagram on the left shows the case where the subset is chosen at random at each iteration whereas the diagram on the right shows the case where a fixed random subset is chosen initially and used in every iteration. The difference is quite dramatic.

Scenario 3. In this case, we consider mandated drops of activities. Starting at day 8, 75% of people will re-route any visit where the activity type is not home or work to their residence. In addition, people with household income greater than or equal to 100,000 will conduct any work activity from their home. As for Scenario 2, we have two sub-scenarios where (a) the subset is chosen randomly at each iteration and (b) is chosen as a fixed subset that is used in each iteration. In none of the cases do people wear masks or do social distancing. The epidemic curves are shown in Figure 4. The main difference that emerges between these two sub-scenarios is that there is a delay in the onset of the epidemic in sub-scenario (b). This is not unexpected: since there is no coordination among household members, the disease can still propagate at people’s homes.

Figure 4. Scenario 3: the left diagram shows the case where a random subset of size 75% is chosen at every iteration starting on day 8 and refrains from activities as explained, whereas the diagram on the right shows the case with a fixed random subset being used across all iterations. As can be seen, case (b) is virtually the same as case (a), except for a delay in the onsets.

Scenario 4. This scenario demonstrates a case where actions are based on a person’s local observables. For this, each person, at each iteration will consider their local observables for all non-home activities. For shopping, other, school, college and religion, if any of these observables is (1) less than 7 days old and (2) contains at least 1 symptomatic case (including themselves), then the person will re-route any visit to such activity locations to their own residence. Additionally, a person whose household income is at least 100,000 will conduct their work activity at their residence. For the latter, they also take into account the local observable for activity work. Here the epidemic evolution is shown in Figure 5.

Figure 5. Scenario 4 covers the case where people choose to remap certain visits based on their recent observables. The outcome is quite similar to the base case (Scenario 1).

Summary. While some of the observed dynamics may appear surprising at first glance, there are many causes. For example, in the case of Scenario 4, while dropping activities and staying at home may seem like it should have an impact, it does require coordination across the household: unless all members of the household consistently stay home, it is easy to see that even when one member does not observe symptomatic cases and do not modify their visits, then that can easily cause the entire household to fall sick. Moreover, if somebody records symptomatic cases in their observables, then very likely there are asymptomatic cases which are not detected. Basing one’s actions on the cases one has observed in person may be a bad idea.

While the point of the scenarios is to demonstrate the capabilities of the BESSIE simulator (and these outcomes should certainly not be used to inform behavior or policy!), it does point to the fact that for interventions to be effective they require global planning and coordination. Finally, we again want to emphasize that the epidemic parameters are not set by experts, and do not correspond to carefully calibrated values. If this was used to advise on policy formation then this step definitely would be included. The goal of showing these scenarios is to demonstrate some of the range and flexibility of the scenarios that can be handled by BESSIE.

6. Discussion

In this paper we have introduced the BESSIE simulator and demonstrated some of its capabilities of several scenarios related to COVID and its intervention for a detailed synthetic population. As already alluded to in the Introduction, for a simulator to be able to address the example scenarios of Section 5 at that level of detail, it would have to:

  • use agents in the representation;

  • have an explicit representation of the locations where transmission occurs;

  • have a visit schedule for each person, and support dynamic changes to this visit schedule based on conditions on local observables, global observables, and a person’s demographic attributes; and

  • track per-person local observables by activity across visits.

To the best of our knowledge, we are not aware of any tool that supports this, let alone offers up the code and the population data for download.

6.1. Validation

For the examples, we set contact probability and transmissibility to obtain an unmitigated attack rate near 60–70%. While the focus of this work is to provide the BESSIE simulator, we remark that BESSIE has several parameters for the epidemics that can be used to calibrate to specific scenarios. In addition, the user can also introduce parameters in the action files they generate for the behavior models.

6.2. Future directions

Speed and scaling. BESSIE was implemented using Python. A main reason for this was to permit users to easily add action modules on their own through the BESSIE plugin interface. The complexity of this would be quite different with a language like C++. The architecture design for BESSIE is as a shared memory application running on multiple cores on a single compute node. This solution was used to work around the Global Interpreter Lock (GIL) in Python: a threaded approach would have been used in a language supporting concurrent threads. The current solution also targets laptops and desktops which nowadays have at least two cores, and typically many more. If scaling and speed become a focus, a re-design and re-implementation in C++ using, e.g., MPI [21] and/or OpenMP [20] is a natural way to go. However, such a solution would effectively only cater to those who have access to a computing cluster or similar architectures.

Intervention features. As demonstrated in Application Examples section, it would be useful to be able to coordinate interventions efforts within a household, or more broadly, introduce actions for groups of agents based on their collective state. This, while certainly useful for epidemic simulations, would significantly change the scope of BESSIE which was to support learning for individual agents. In related work, the authors have built the EpiHiper C++/OpenMP/MPI network-based, epidemics simulator [5] has an intervention language that supports quite flexible construction of sets of people using predicates on their demographics and health state, and can then apply actions (i.e., state changes) to the members of these set. Quarantining or self-isolation of all members of selected households is therefore directly supported. If BESSIE were to be generalized in this direction, a similar approach will be used.

Disease models. Currently, the BESSIE disease model is limited to an extended SEIR model. While flexible, there are certainly other or more refined models that can be considered. If this is needed in the future, it will be approached using a plugin design similar to that of the action/behavioral model that is already there.

Calibration support. Due to the scope of the design, several parameters are currently not exposed in the configuration file. Depending on future needs, a calibration framework can be added that and that (a) would expose relevant BESSIE parameters, and (b) would allow for efficient user declaration and exposure of custom parameters defined in their behavior models (and possibly custom disease models).

6.3. Current limitations

For a list of limitations and updates, we refer to the git repository and the files and ./src/notes.txt. The following are some known limitations that can cause issues if the user pushes boundaries and/or has complex computing environments.

  • BESSIE requires Python version >=3.8 due to the use of the shared memory manager functionality.

  • The BESSIE simulator uses a fixed port number (i.e., 50000) for its shared memory manager. If multiple instances of BESSIE are run on the same compute node (not unlikely if you use a cluster), a port conflict will arise. In this case, the behavior of BESSIE is undefined. It can easily be avoided through suitable queuing instructions under job submission systems such as slurm and qsub. Similarly, there is a small risk that a different application is already running on one’s computer and that also uses port 50000. This somewhat technical parameter may be exposed in the configuration file in a future version of BESSIE.

  • Since the location assignment is dynamic (it depends on people’s actions), the size of the shared memory buffers used by the sub-processes to report observables back to the main process are not known ahead of time (see Figure 7

    ). While it would be nice to auto-determine these buffer sizes, this is currently done manually and specified in the configuration file. The current values were set of CoC and were specified to permit even very skewed loads of people onto locations. If the user introduces other populations with visit schedules, they may have to adjust these memory buffer sizes accordingly. The buffer size for the local observables, for example, will equal the maximal number of observables reported back from each sub-process during any iteration of the simulation: this number will depend on (a) the locations assigned to each sub-process, and (b) the visitors to those locations, where the latter number generally depends on the actions taken by all the members of the population.

6.4. Disclaimer

The BESSIE simulator, the code, and the synthetic populations are provided as is, and the user assumes all responsibility for any use thereof. BESSIE is provided under the Apache 2.0 license while the CoC synthetic populations is made available under CC-BY-4.0.

7. Acknowledgments

The authors thank their collaborators in Network Systems Science and Advanced Computing Division (BII) and in the Department of Engineering Systems and Environment for many discussions. In particular we thank Stefan Hoops for discussions and advice related to the software design and technologies used for BESSIE. This work was funded in part by the grant FI00026 “Machine Learning Efficient Behavioral Interventions for Novel Epidemics” awarded by the the Global Infectious Diseases Institute at the University of Virginia.

8. Appendix A: BESSIE Design Details

In this section we describe details of the agent based model and the design of its implementation (i.e., the BESSIE simulator.) When preparing a detailed behavioral- or action model, knowing the precise order of the model components will be important.

8.1. Organization of input data

In Figure 6, the input data and its organization is shown. For the details of formats for the person file and the visit file, see the Person and Visit sub-section of Appendix B. The configuration file and the schema file are described in the Configuration File Format sub-section of Appendix B, while the requirements for the action file are given in the Action File sub-section of Appendix B.

Figure 6. An overview of the input data to BESSIE and their organization, including the configuration file and the configuration schema file.

8.2. Architecture design

A high level design of the simulator is given in Figure 7. Some notable points include the following:

  • Initialization: Currently, one can only specify the number of people initially set to be in the exposed state . All others will have their state set to susceptible, or . This subset of the population is chosen at random. More elaborate methods for specifying the initial set of exposed people may be added later.

  • Sub-process buffer sizes. The shared memory manager has one buffer for each sub-process that is used for reporting back local observables. The minimal size of this buffer depends on the assignment of people to locations, and the partition of locations onto sub-processes. Since people may choose actions that re-map their visits to new locations, assessing a precise bound for this size is not straightforward. The current solution is to specify this through the configuration keys observable_max_items_per_iteration. The value found in the example files for CoC are generously to make sure they work with 2 cores. A future version of BESSIE

    may include auto-estimation of this quantity. The same applies to the buffer that holds transmission events whose sizes are set by the key


  • All arrays in shared memory use numpy and user defined types as specified in ./src/ When developing custom action plugins, you will need to import this file. Examples are provided with the sources in the directory ./models.

Figure 7. An overview of the components in the design and the flow of computation for BESSIE. Dashed gray arrows indicate data dependencies as well as points where shared memory is being used as a data exchange point between the main BESSIE process and the sub-processes.

8.3. Notes about implementation

The following is a list or simulator notes requirements.

  • BESSIE requires Python version >= 3.8 since it uses the SharedMemoryManager component of multiprocessing.

  • BESSIE has been tested on macOS Catalina, MS Windows, and on a Linux cluster environment, including under slurm.

9. Appendix B: Description of Bessie Usage and Data Formats

The input data and parameters to the BESSIE simulator are specified through a JSON configuration file. A JSON schema is used for validation, and is supplied with the source code of BESSIE. The syntax for invoking BESSIE is as follows:

python -c <config-filename> -s <schema-filename> [-l <info-level>]

Where info-level is one of critical, error, warning, info, and debug. The schema and configuration file formats are described next.

9.1. Configuration File Format

BESSIE is designed to use a JSON configuration file with a matching schema file as described in the Usage Overview section. In the case of the supplied Smallville example, a configuration file may look like the one below.


  • The num_procs parameter should be set based on your machine’s specifics and its number of cores. For a laptop and desktop, you may want to start modestly (e.g., using 2 cores) as fully loading your cores can really tax your computer.

  • You will have to update the paths (base_dir and pop_base_dir) of the examples to match your computing environment.

    "log_level" : "info",
    "platform": "rivanna",
    "version": "1_0_0",
    "config": {
        "run_parameters": {
            "executable": "",
            "source_directory" : "{base_dir}/src",
            "logging_filename": "smallville.log",
            "output_directory": "./logs_smallville",
            "input" : {
                "person_filename" : "{pop_base_dir}/smallville/smallville_person_gidi.csv",
                "visit_filename" : "{pop_base_dir}/smallville/smallville_visits_gidi.csv"
            "output" : {
                "action_logfile" : "log_action_logfile.txt",
                "modelclass_logfile" : "log_model_class.csv",
                "local_observable_logfile" : "log_local_observable_logfile.txt",
                "global_observable_logfile" : "log_global_observable_logfile.txt",
                "epidemics_logfile" : "log_epidemics_logfile.txt"
            "observable_max_items_per_iteration": 1000,
            "transmission_event_max_items_per_iteration" : 1000,
            "num_procs" : 2
        "model_parameters": {
            "random_seed": 1235,
            "num_initial_exposed" : 2,
            "num_days" : 5,
     "tau" : 0.05,
     "contact_probability" : 1.0,
            "user_defined_action_filename" : "jasss_example_base_v_1_0",
     "user_defined_action_directory" : "{base_dir}/models/",
            "schedule_choice" : "week"

9.2. Schema File Format

The JSON schema used with BESSIE can be found in the git repository as ./schema/schema.json. Please use the git schema for the most up-to-date version. We have omitted the listing since it is nearly two pages long.

9.3. Action File

The action file is a BESSIE mechanism that permits the construction and addition of custom action/behavioral models without any changes to the BESSIE core. It functions as a plugin in a manner quite similar to, e.g., a MS Windows DLL except that is is written in Python. The requirements for a plugin is that must contain the following two functions with the specified signatures:

    CreateModelClassFile(filename, person_np_rep, person_class_np_rep)


Arguments to the two functions rely on type definitions contained in typedefs_v_1_0 which corresponds to the BESSIE file ./src/ Thus you likely will want to add

    import typedefs_v_1_0 as typedefs

near the beginning of your action action file. Your file may reference other files from your action file as long as they are present in the same directory as the action file (BESSIE will add the directory you specify for your action file to the search path – recommended) or if you update your Python path accordingly.

CreateModelClassFile. This function provides the option to accomplish two things: (i) it can assign a person class (integer) to each person based on their demographic attributes as specified in the person file (provided in the person_np_rep argument), and (ii) it can write out this person class to a CSV file as specified in the Output Data section. This file is not used by BESSIE, but may be useful for analyzing the outcome. The generated person class, however, will be passed to the ActionSelection (see below). This aspect may be useful, since the plugin cannot (at least not easily) retain state across iterations. We refer to the examples for use cases.

  • filename: name of CSV file to construct (type: string)

  • person_np_rep: a numpy array with elements of type person_dtype as defined in the repository file ./src/ The order is exactly the same as in the supplied person file.

  • person_class_np_rep: a numpy array with elements of type person_class_dtype as defined in the repository file ./src/ The order is exactly the same as in the supplied person file.

ActionSelection. The action selection function is called at every iteration for each person in the course of the simulation. This provides the mechanism that one can use to specify which of the actions a person should (or should not) adopt at each iteration. Its argument are as follows:

  • action_np_rep_i: a single element of type action_dtype as defined in ./src/ The function will set each element of this variable (they correspond to the list of possible actions). These values will be passed back to BESSIE.

  • time_step: the current time step (or iteration) starting at t=0.

  • weekday: the current weekday. Here Monday corresponds to 0, Tuesday to , and so on.

  • person_np_rep_i: as single element of type person_dtype holding the demographic attributes of the person as specified in the person file.

  • state_np_rep_i: the health state of the person.

  • visits_np_rep: the complete array of visits for all people and all days. Each entry is of type visit_dtype as defined in ./src/

  • observables_np_rep_i: the local observable array for person i. To reference for example the current local observable for work, use observables_np_rep_i[ typedefs.obs_work_index ].

  • global_observables_np_rep: the global observables array. To access for example the current number of symptomatic cases, use global_observables_np_rep[time_step][’obs_Is_abs’]

  • person_class_np_rep_i: the person class of person i as assigned in the CreateModelClassFile function.

We recommend looking at the example file ./src/ from the BESSIE repository.

9.4. Person and Visit Files

The representation of the synthetic population is captured by two files, a person file and a visit file.

Person file. The person file contains demographic and household information for each person, including details about their residence.555Note that in the accompanying data for CoC, coordinates are all set to (0.0, 0.0) due to license terms that apply to the data that was used to construct this instance. The person file is a CSV file with the following header, shown with two example rows of data.


Data dictionary. Records with reference to PUMS have details described in [25].   hid: the household ID of the person (type: integer)   pid: the person ID of the person (type: unsigned integer)   age: the age of the person in years (type: integer)   sex: the sex of the person (type: enumeration { 1: male, 2: female})   employment_status: employed or not, civilian or armed forces (PUMS:ESR)   race: race of householder (PUMS RAC1P variable)   hispanic: a Boolean (PUMS HISP variable) (type: Boolean {0,1})   designation: a person designation derived from the PUMS NAICSP variable (type: string)   hh_size: number of persons in family (PUMS NPF variable);   hh_income: household income in the past 12 months in local currency (PUMS HINCP variable);   workers_in_family: Workers in the family in the past 12 months (PUMS WIF variable)   lid: location ID of assigned residence (type: integer)   longitude: the longitude of the residence (type: float; see footnote)   latitude: the latitude of the residence (type: float; see footnote)   admin1: 2-digit US FIPS code for the state   admin2: 3-digit US FIPS code for the county   admin3: 6-digit US FIPS code for the census track   admin4: 1-digit US FIPS code for the block group

Visit file. The visit file captures the activity sequence and the baseline locations of visit for each person. We say baseline since the locations of visit may change during the simulation based on the actions chosen. In the case of CoC, the sequence spans a week, starting at midnight Sunday/Monday, a time point we will refer of as . The visit file uses the CSV format with columns as follows, including two example rows:


Data dictionary.   daynum: the weekday on which the contact started (type: enumeration {0: Monday, 1: Tuesday, …, 6: Sunday})   pid: pid of person (see above)   activity_number: the activity number in the person’s activity sequence (type: integer)   activity_type: the activity conducted during the visit (type: enumeration {home: 1, work: 2, shopping: 3, other: 4, school: 5, college: 6, religion: 7, transit: 0}; note that all transit activities are omitted in the distributed data);   start_time: activity start time measured in seconds since  (type: integer)   end_time: activity end time measured in seconds since  (type: integer)   duration: activity duration measured in seconds (type: integer)   lid: ID of location visited (type: integer)

10. Output data

The BESSIE simulator generates five output files. These are all CSV files with column headers and data dictionaries as described in the following.

10.1. Model class file

This is a classification of people into model classes. The precise semantics of this will depend on the behavioral model that you implement.


Data dictionary.   index: the index used in the simulation for the numpy structures. It will equal the line number of the person’s entry in the person file, not counting the header line (type: integer)   pid: the matching pid field from the person file (see above)   model_class: the model class assigned to the person under the given behavioral model specified in the action file (type: integer)

10.2. Local observables file

This file contains one record for each person for each non-home activity type for each iteration. In the case where there are multiple local observations for the same activity type within an iteration, this will contain the most recent local observable that was reported. This is a CSV file with the following structure:


Data dictionary.   iteration: the iteration for the recorded observable (type: integer)   obs_iteration: the iteration for which the recorded observable took place (type: integer)   pid: see above   lid: see above   activity_type: see above   n_total: total number of people present at the location, including the person him/herself, at the start of their visit (type: integer)   symp_abs: total number of people present at the location whose health state was Is, including the person him/herself, at the start of their visit (type: integer)   symp_rel: the ratio at the start of the visit (type: float)   mask_abs: total number of people present at the location wearing a mask, including the person him/herself, at the start of their visit (type: integer)   mask_rel: the ratio at the start of the visit (type: float)   distancing_abs: total number of people including the person him/herself) present at the location that are social distancing (keeping a distance of 6ft to others), at the start of their visit (type: integer)   distancing_rel: the ratio , at the start of their visit (type float)

10.3. Global observables file

The file contains the list of global observables tracked at each iteration, represented as a CSV file with the following structure:


Data dictionary.   iteration: see above   S_abs: total number of people in health state S (type: integer)   S_rel: fraction of of people in health state S (type: float)   E_abs: total number of people in health state E (type: integer))   E_rel: fraction of of people in health state E (type: float)   Is_abs: total number of people in health state Is (type: integer)   Is_rel: fraction of of people in health state Is (type: float)   Ia_abs: total number of people in health state Ia (type: integer)   Ia_rel: fraction of of people in health state Ia (type: float)   R_abs: total number of people in health state R (type: integer)   R_rel: fraction of of people in health state R (type: float)

10.4. Action file

The action log tracks the actions chosen by each person at every iteration across the possible actions described in Section 3.3. It is a CSV file with the following structure:


Data dictionary.   iteration: see above   pid: see above   mask: wear a mask at all locations visited during the iteration (type: {0,1})   distancing: do social distancing (keep 6ft distance to all others) at all locations visited during the iteration (type: {0,1})   no_other: replace each activity of type other by a visit to their residence for the given iteration (type: {0,1})   no_college: replace each activity of type college by a visit to their residence for the given iteration (type: {0,1})   no_shopping: replace each activity of type shopping by a visit to their residence for the given iteration (type: {0,1})   no_religion: replace each activity of type religion by a visit to their residence for the given iteration (type: {0,1})   no_school: replace each activity of type school by a visit to their residence for the given iteration (type: {0,1})   no_work: replace each activity of type work by a visit to their residence for the given iteration (type: {0,1})

10.5. Health state dynamics trajectory

This CSV log file contains a record of each health state transition that took place for each person of the population in the course of the simulation. Note that initialization is also considered as a state change event. As explained in Section 3.2, there are transmission- and progression transitions. In the case of a transmission, the pid of the infector (i.e., p2_pid) is included in the entry. For disease progression, we have always have . This CSV file has the following header:


Data dictionary.   iteration: see above; note that -1 means initialization   state: the new health state (type: integer)   p1_pid: the pid of the person whose health state changed (type: same as pid)   p2_pid: the pid of the person deemed to have caused the state transition in the case of a transmission (type: same as pid)

10.6. Example action files and their configurations

The following is the list of files that were used as examples in this paper. We have listed both the action files (Python) and the corresponding configuration files (JSON). Note that you will have to adapt paths to fit your computing environment before trying the examples. Generally, you will find that the action file is the same across platforms; only the configuration file will need to be updated. In all the examples below, the configuration files are located in the directory ./config/, the the action files inside the directory ./models/. This part of the filenames have therefore been omitted in the listing of Table 1.

Example 1 (base) {ex}
Example 2a (mask/dist) {ex}
Example 2b {ex}
Example 3a (visit drop) {ex}
Example 3b {ex}
Example 4 (observables) {ex}
Smallville (default)
Table 1. The listing of example action files used in this paper along with matching configuration files. Here {ex} is short-hand for jasss_example.


  • [1] Xabier E. Barandiaran, Ezequiel Di Paolo, and Marieke Rohde. Defining agency: Individuality, normativity, asymmetry, and spatio-temporality in action. Adaptive Behavior, 17(5):367–386, 2009.
  • [2] Cristina Bicchieri, Enrique Fatas, Abraham Aldama, Andres Casas, Ishwari Deshpande, Mariagiulia Lauro, Cristina Parilli, Max Spohn, Paula Pereira, and Ruiling Wen. In science we (should) trust: Expectations and compliance during the COVID-19 pandemic, 2020. Preprint - Available from Research Square.
  • [3] Lewis F. Buss, Carlos A. Prete, Claudia M. M. Abrahim, Alfredo Mendrone, Tassila Salomon, Cesar de Almeida-Neto, Rafael F. O. França, Maria C. Belotti, Maria P. S. S. Carvalho, Allyson G. Costa, Myuki A. E. Crispim, Suzete C. Ferreira, Nelson A. Fraiji, Susie Gurzenda, Charles Whittaker, Leonardo T. Kamaura, Pedro L. Takecian, Pedro da Silva Peixoto, Marcio K. Oikawa, Anna S. Nishiya, Vanderson Rocha, Nanci A. Salles, Andreza Aruska de Souza Santos, Martirene A. da Silva, Brian Custer, Kris V. Parag, Manoel Barral-Netto, Moritz U. G. Kraemer, Rafael H. M. Pereira, Oliver G. Pybus, Michael P. Busch, Márcia C. Castro, Christopher Dye, Vítor H. Nascimento, Nuno R. Faria, and Ester C. Sabino. Three-quarters attack rate of SARS-CoV-2 in the Brazilian Amazon during a largely unmitigated epidemic. Science, 371(6526):288–292, 2021.
  • [4] Kevin Chapuis, Patrick Taillandier, Misslin Renaud, and Alexis Drogoul. Gen*: a generic toolkit to generate spatially explicit synthetic populations. International Journal of Geographical Information Science, 32(6):1194–1210, 2018.
  • [5] Jiangzhuo Chen, Stefan Hoops, Bryan L. Lewis, Henning S. Mortveit, Srini Venkatramanan, and Amanda Wilson. EpiHiper: Modeling and implementation, 2019. NSSAC Technical Report Series: No. 2019–003.
  • [6] Jiangzhuo Chen, Anil Vullikanti, Stefan Hoops, Henning Mortveit, Bryan Lewis, Srinivasan Venkatramanan, Wen You, Stephen Eubank, Madhav Marathe, Chris Barrett, and Achla Marathe. Medical costs of keeping the US economy open during COVID–19. Nature Scientific Reports, 10:18422, 2020.
  • [7] Amélie Desvars-Larrive, Elma Dervic, Nils Haug, Thomas Niederkrotenthaler, Jiaying Chen, Anna Di Natale, Jana Lasser, Diana S. Gliga, Alexandra Roux, Johannes Sorger, Abhijit Chakraborty, Alexandr Ten, Alija Dervic, Andrea Pacheco, Ania Jurczak, David Cserjan, Diana Lederhilger, Dominika Bulska, Dorontinë Berishaj, Erwin Flores Tames, Francisco S. Álvarez, Huda Takriti, Jan Korbel, Jenny Reddish, Joanna Grzymała-Moszczyńska, Johannes Stangl, Lamija Hadziavdic, Laura Stoeger, Leana Gooriah, Lukas Geyrhofer, Marcia R. Ferreira, Marta Bartoszek, Rainer Vierlinger, Samantha Holder, Simon Haberfellner, Verena Ahne, Viktoria Reisch, Vito D. P. Servedio, Xiao Chen, Xochilt María Pocasangre-Orellana, Zuzanna Garncarek, David Garcia, and Stefan Thurner. A structured open dataset of government interventions in response to COVID-19. Scientific Data, 7(1), 2020.
  • [8] S. Eubank, H. Guclu, V. S. A. Kumar, M. V. Marathe, Srinivasan A., Z. Toroczkai, and N. Wang. Modelling disease outbreaks in realistic urban social networks. Nature, 429(6988):180–184, May 13, 2004.
  • [9] Benoit Gaudou, Nghi Quang Huynh, Damien Philippon, Arthur Brugière, Kevin Chapuis, Patrick Taillandier, Pierre Larmande, and Alexis Drogoul. COMOKIT: A modeling kit to understand, analyze, and compare the impacts of mitigation policies against the COVID-19 epidemic at the scale of a city. Frontiers in Public Health, 8:563247, 2020.
  • [10] Philippe J. Giabbanelli, Jennifer Badham, Brian Castellani, Hamdi Kavak, Vijay Mago, Ashkan Negahban, and Samarth Swarup. Opportunities and challenges in developing COVID-19 computational models: Lessons from six funded projects. In Proceedings of the Annual Simulation Symposium, Fairfax, VA, USA, 2021.
  • [11] Daniel T. Gillespie. Exact stochastic simulation of coupled chemical reactions. Journal of Physical Chemistry, 81(25):2340–2361, 1977.
  • [12] D.T. Gillespie. A general method for numerically simulating the stochastic time evolution of coupled chemical reactions. Journal of Computational Physics, 22:403–434, 1976.
  • [13] Robert Hinch, William J M Probert, Anel Nurtay, Michelle Kendall, Chris Wymant, Matthew Hall, Katrina Lythgoe, Ana Bulas Cruz, Lele Zhao, Andrea Stewart, Luca Ferretti, Daniel Montero, James Warren, Nicole Mather, Matthew Abueg, Neo Wu, Anthony Finkelstein, David G Bonsall, Lucie Abeler-Dörner, and Christophe Fraser. OpenABM-Covid19 - an agent-based model for non-pharmaceutical interventions against COVID-19 including contact tracing. medRxiv, 2020.
  • [14] Cliff C. Kerr, Robyn M. Stuart, Dina Mistry, Romesh G. Abeysuriya, Katherine Rosenfeld, Gregory R. Hart, Rafael C. Núñez, Jamie A. Cohen, Prashanth Selvaraj, Brittany Hagedorn, Lauren George, Michał Jastrzebski, Amanda Izzo, Greer Fowler, Anna Palmer, Dominic Delport, Nick Scott, Sherrie Kelly, Caroline S. Bennette, Bradley Wagner, Stewart Chang, Assaf P. Oron, Edward Wenger, Jasmina Panovska-Griffiths, Michael Famulare, and Daniel J. Klein. Covasim: an agent-based model of COVID-19 dynamics and interventions. medRxiv, 2021.
  • [15] Fabian Lorig, Emil Johansson, and Paul Davidsson. Agent-based social simulation of the covid-19 pandemic: A systematic review. Journal of Artificial Societies and Social Simulation, 24(3):5, 2021.
  • [16] Daniel E. Montaño and Danuta Kasprzyk. Theory of reasoned action, theory of planned behavior, and the integrated behavior model. In Karen Glanz, Barbara K. Rimer, and Kasisomayajula Viswanath, editors, Health Behavior: Theory, Research, and Practice, chapter 6. Jossey-Bass, fifth edition, 2015.
  • [17] Henning. S Mortveit. BESSIE source code, 2021. Source can be provided upon request.
  • [18] Henning S. Mortveit. Synthetic City of Charlottesville (CoC), 2021. Data can be provided upon request.
  • [19] NSF. Nsf 22-054 dear colleague letter: Incorporating human behavior in epidemiological models (IHBEM), 2022. Last accessed: 06 Mar 2022.
  • [20] OpenMP, 2021. Last accessed: 12 May 2021.
  • [21] Open MPI, 2021. Last accessed: 12 May 2021.
  • [22] Surya Singh, Mujaheed Shaikh, Katharina Hauck, and Marisa Miraldo. Impacts of introducing and lifting nonpharmaceutical interventions on COVID-19 daily growth rate and compliance in the united states. Proceedings of the National Academy of Sciences, 118(12):e2021359118, 2021.
  • [23] Flaminio Squazzoni, J Gareth Polhill, Bruce Edmonds, Petra Ahrweiler, Patrycja Antosz, Geeske Scholz, àChappin, Melania Borit, Harko Verhagen, Francesca Giardini, et al. Computational models that matter during a global pandemic outbreak: A call to action. Journal of Artificial Societies and Social Simulation, 23(2), 2020.
  • [24] Samarth Swarup. Adequacy: What makes a simulation good enough? In Proceedings of the Spring Simulation Conference (SpringSim), Tucson, AZ, 2019.
  • [25] US Census. Public Use Microdata Sample (PUMS), 2021. Last accessed: 24 May 2021.