Agent-based modeling and simulation are some powerful techniques that are widely used with success for analyzing complex and emergent phenomena in many research and application areas. Many diferent reasons are behind the success of such techniques, among which an important mention goes to the availability of a great variety of software tools, that ease the development of models, as well as the execution of simulations and the analysis of results. This paper presents an actor software library, called ActoDeS, for the development of concurrent and distributed systems, and shows how it can be a suitable mean for building flexible and scalable epidemic forecasting simulations. In particular, the paper presents the first results of the experimentation of ActoDeS for defining a COVID-19 epidemic difusion model and for supporting the simulation in large populations.
Agent-based modeling and simulation (ABMS) has been and is widely used with success for studying complex and emergent phenomena in many research and application areas, including agriculture, biomedical analysis, ecology, engineering, sociology, market analysis, artificial life, social studies, and others fields. Such studies are possible thanks to the availability of several tools and libraries that support the development of ABMS applications. Moreover, the availability of large-scale, dynamic, and heterogeneous networks of computational resources and the advent of multi-cores computers allow the development of high performance and scalable computationally intensive ABMS applications. As a matter of fact, such applications are able to manage very large and dynamic models, whose computational needs (in space and time) can be dificult to satisfy by a single machine.
The success and the difusion of ABMS techniques is also due to the availability of software
tools that ease the development of models, the execution of simulations and the analysis of
results (see, for example, Mason [
In this paper we present an actor based software library, called ActoDeS, that provides the suitable features for simplifying the development of scalable and eficient agent based models and simulations. The next section introduces the actor model and discusses the advantages of using actors in ABMS applications. Section 3 introduces ActoDeS. Section 4 shows the advantages of using this software library for ABMS applications. Section 5 presents the COVID-19 difusion model that is used in the simulations. Section 6 presents the results of the experimentation on the population of Bergamo province. Section 7 introduces the work necessary to extend the simulation to all the population of Lombardia region. Finally, section 8 concludes the paper by discussing its main features and the directions for future work.
Actors [
Actors have the suitable features for defining agent models that can be used in ABMS
applications and for modeling the computational agents found in MAS and DAI systems [
Moreover, the use of messages for exchanging state information decouples the code of agents. In fact, agents do not need to access directly to the code of the other agents (i.e., their methods) to get information about them, and so the modification of the code of a type of agent should cause smaller modifications in the code of the other types of agent. Finally, the use of actors simplifies the development of real computational agents in domains where, for example, they need to coordinate themselves or cooperate through direct interactions.
Diferent researchers propose the use of actors for agent based simulation. For example, Jang
and Agha [
Cicirelli et al. [
Finally, de Berardinis et al. [
ActoDeS is an actor-based software framework that has the goal of both simplifying the
development of concurrent and distributed complex systems and guarantying an eficient execution
of applications [
ActoDeS has a layered architecture composed of an application and a runtime layer. The application layer provides the software components that an application developer needs to extend or directly use for implementing the specific actors of an application. The runtime layer provides the software components that implement the ActoDeS middleware infrastructures to support the development of standalone and distributed applications.
In ActoDeS an application is based on a set of interacting actors that perform tasks concurrently and interact with each other by exchanging asynchronous messages. Moreover, it can create new actors, update its local state, change its behavior and kill itself.
Depending on the complexity of the application and on the availability of computing and communication resources, one or more actor spaces can manage the actors of the application. An actor space acts as “container” for a set of actors and provides them the services necessary for their execution. An actor space contains a set of actors (application actors) that perform the specific tasks of the current application and two actors (runtime actors) that support the execution of the application actors. These two last actors are called executor and the service provider. The executor manages the concurrent execution of the actors of the actor space. The service provider enables the actors of an application to perform new kinds of action (e.g., to broadcast a message or to move from an actor space to another one).
Communication between actors is bufered: incoming messages are stored in a mailbox until the actor is ready to process them; moreover, an actor can set a timeout for waiting for a new message and then can execute some actions if the timeout fires. Each actor has a system-wide unique identifier called reference that allows it to be reached in a location transparent way independently of the location of the sender (i.e., their location can be the same or diferent). An actor can send messages only to the actors of which it knows the reference, that is, the actors it created and of which it received the references from other actors. After its creation, an actor can change several times its behavior until it kills itself. Each behavior has the main duty of processing a set of specific messages through a set of message handlers called cases. Therefore, if an unexpected message arrives, then the actor mailbox maintains it until a next behavior will be able to process it.
An actor can be viewed as a logical thread that implements an event loop [
ActoDeS supports the configuration of applications with diferent actor, scheduler ad service provider implementations. The type of the implementation of an actor is one of the factors that mainly influence the attributes of the execution of an application. In particular, actor implementations can be divided in two classes that allow to an actor either to have its own thread (from here named active actors) or to share a single thread with the other actors of the actor space (from here named passive actors). Moreover, the duties of a scheduler depend on the type of the actor implementation. Of course, a scheduler for passive actors is diferent from a scheduler for active actors, but for the same kind of actor can be useful to have diferent scheduler implementations. For example, it can allow the implementation of “cooperative” schedulers in which actors can cyclically perform tasks whose duties vary from the processing of the first message in the bufer to the processing of all the messages in it.
The most important decision that influences the quality of the execution of an application is
the choice of the actor and scheduler implementations. In fact, the use of one or another couple
of actor and scheduler causes large diferences in the performance and in the scalability of the
applications [
The features of the actor model and the flexibility of its implementation make ActoDeS suitable
for building agent-based modelling and simulation (ABMS) applications and for analyzing
the results of the related simulations. In fact, the use of active and passive actors allows the
development of applications involving large number of actors, and the availability of diferent
schedulers and the possibility of their specialization allow an eficient execution of simulations
in application domains that require diferent types of scheduling algorithms [
In particular, ActoDeS ofers a very simple scheduler that may be used in a large set of application domains and, in particular, in ABMS applications. Such a scheduler manages agents implemented as passive actors and its execution repeats until the end of the simulation the following operations: 1. Sends a “step” message to all the agents and increments the value of “step”; 2. Performs an execution step of all the agents.
In particular, the reception of a “step” message allows agents to understand that they have all the information (messages) for deciding their actions; therefore, they decide, perform some actions and, at the end, send information to other agents.
The modeling and simulation of complex problems can require the use of large number of agents that may determinate unacceptable simulation times, or the impossibility to run the simulation on a single computational node. In such cases, the availability of distributed algorithms and, of course, of an adequate number of computational nodes can help to perform simulations, partitioning the agents among the available computational nodes. Moreover, depending of kind of application, agents may need to communicate with some agents running on diferent computational nodes. In this case, the execution of the computational nodes must be synchronized to guaranty the processing of the messages in the correct order.
Therefore, a distributed simulation involves a set of computational nodes whose execution is driven by a set of schedulers and managers. In particular, each manager has the duty of creating the subset of agents of its computational node and synchronize the execution of the simulation with the execution of the other computational nodes. Moreover, one of such managers assumes the role of “master” and has the duties of partitioning the agents involved in the simulation and sends the information necessary for the creation of the agents to the other managers.
In particular, the execution of a distributed simulation can be described by the following steps: 1. Master manager partitions the agents and sends the information for creating a subset of agents to each scheduler (including itself). 2. Managers create all the actors of its subset. 3. Repeat until the end of the simulation: • Managers send a synchronization message to the other managers and wait for the corresponding messages from them. • Schedulers perform an execution step of all their actors.
• Scheduler send a “end step” message to all their actors and managers.
As introduced above, in diferent kinds of simulations the agents need to exchange data and often such an interaction is not localized, therefore, the partition of agents on several computational nodes may add an important communication cost. An important solution to reduce the cost of communication is to reduce the frequency of interactions, merging multiple interactions to one. In a conservative distributed simulation system, that synchronizes the simulation step of all the computational nodes involved in the simulation, a possible solution is to group all the messages directed to the agents of a specific computational node into the message that identifies the successive synchronization message.
In the last years, several computational models for the simulation of epidemic outbreaks have
been used with increased frequency, moreover, the current COVID-19 pandemic has increase
the interest and work on the definition and experimentation of such models [
The basic idea was to model people based on their social interactions, which can vary from person to person, estimated interactions with a particular rate. In our first model, people were identified on the basis of an interaction rate (high, medium and low) and in a random way these people came into contact, creating a network of interactions.
At the beginning, all the people are in a susceptible phase, in this phase each person can be infected by an infected person. When a person is infected, she/he passes from a susceptibility phase to an incubation phase; here she/he remains there for a certain period of time and then passes to another phase in which he is infectious. When a person is in this phase he could infect other people. Once this last phase is over, the infected changes to be positive. After a certain period of time, the person changes phase: heals or dies. When a person heals, she/he can no longer be infected. Moreover, the incubation phase is made to last from 7 to 14 days, that infectious from 3 to 7 and that of positivity from 14 to 30.
In our model, each person is defined by the following attributes: • Id of the person • Province of belonging • Degree of interaction • Number of people met • Current phase • Id of the people met
This model was used for simulating the COVID-19 propagation from January 30, 2020 to March 31, 2020. Of course, the interaction frequency varies for all the people during the simulation because some people become positive at the end of the phase in which they are infectious; therefore, their interactions should collapse enough sudden because they should stay in quarantine. Moreover, from March 8, 2020, people reduced their interaction frequency because of the lockdown rules.
In order to test the model for the Bergamo province, multiple tests were carried out. Thanks to them, it was gradually understood which parameters had to be modified to obtain a trend similar to that of the contagion curve in the real case of Bergamo province. In particular, we considered two "key" dates: March 8th (pre-lockdown date) and March 31st 2020. We focused on the parameter that represents the value of the positive swabs made. In summary, there were 997 positives on March 8 and 8803 positives on March 31. Initially, the parameter that regulates infections has been kept fixed at 0.7, given, found in the literature, which should represent the average value of infection without a mask. The use of such parameter allowed to get good results because the average number of positives obtained by ten simulations was 906. Of course Infection value 0.3 Positives number 563 such parameter value is not good for the lookdown period and so a quite good number of positives was obtained fixing the infection parameter at 0.3. In this case, average number of positives obtained by ten simulations was 8370. Table 1 shows the positives number in the two “key” dates for diferent infection parameters and compares them with the real number of positives.
The final goal of our work is the simulation of epidemic outbreaks in the entire Lombardia. However, the number of people living in Lombardia is more than ten million and so its simulation is feasible only with a distributed implementation. The simplest solution is to partition people on the basis of their province. This solution allows to use diferent parameters in diference provinces, but implies an unbalanced load among the diferent computational nodes and it can be a big problem if the simulation should require the synchronization of the execution steps.
Therefore, we decided to combine two kinds of partition: i) people is partitioned on the basis of their province and so each person uses the parameter values associated with her/his province, and ii) people is divided in subset of equivalent size by using the number of computational nodes involved in the simulation. While the management of Lombardia population should be possible without problems, thank to the availability of the computational nodes of the High Performance Computing lab of our university, some problems can be raised by the number of the messages necessary to create consistent sets of contacts in each step of the simulation (i.e., when a person A identifies a person B as her/his contact, then she/he needs to inform person B that she/he in her/his contacts).
Currently, we are evaluating several solutions to reduce the communication overhead, some solutions avoid the exchange of messages, by saving for each step, the data of the people of each computational node on a file and then merging the data of the diferent files associated with this step, other solutions requires the sending by messages, but at each step a computational node sends a message to all the other computational nodes. Each message contains all the contact information for the people of a specific computational node.
This paper presented ActoDeS, an actor software library for the development of concurrent and distributed systems, and shows how it can be a suitable mean for building flexible and scalable epidemic forecasting simulations. In particular, the paper presented the first results of the experimentation of ActoDeS for forecasting COVID-19 epidemic difusion in the Bergamo province and introduced the first work for defining a scalable distributed system able to forecast COVID-19 epidemic difusion for all the population of Lombardia region. Our current and future work will be dedicated to complete the design and the implementation of such a distributed system, to experiment diferent communication solutions for the updating of the contacts of each person, and finally, the definition of more accurate person model that replaces the use of the simple interaction frequency to create new contacts, with the use of the person age and the work sector.