Asymmetric Cell-DEVS Models with the Cadmium Simulator

Cellular models provide a natural approach for describing the behavior, dynamics, and structure of natural systems with spatial features. The classic Cell-DEVS formalism allows us to define discrete-event cellular models as a lattice of cells in which cell states are updated asynchronously over a continuous time base with explicit timing delays. However, it cannot define scenarios with irregular cell shapes. Here we present asymmetric Cell-DEVS, a formalism that supports the definition of cellular models with irregular topologies and complex relationships between cells, allowing us to model more realistic scenarios. We also include a prototype implementation of this formalism using the Cadmium simulator and illustrate the use of this formalism and tools by presenting different cellular models combined with geographical data to provide realistic results.


Introduction
Numerous natural systems show great complexity in their behavior, dynamics, and structure, making it difficult to describe them mathematically (Wolfram, 1984). Cellular models provide simple abstractions of these systems, enabling the study of geographical and temporal changes on them (Janelle, 2005). Among the different approaches for implementing cellular models, Cellular Automata (CA) (Toffoli and Margolus, 1987) is one of the most popular methods. CA is a discrete-time formalism that is typically conceived as a lattice of cells. Each cell behaves as a Finite State Machine (FSM) and computes its next state according to its previous state and the previous state of nearby cells (i.e., the cell neighborhood). CA has been successfully used in multiple disciplines, such as chemistry (Gerhardt and Schuster, 1989), biology (Hatzikirou et al., 2012), or generative arts (Ashlock and Kreitzer, 2020).
In CA, cells state transitions are computed synchronously in a discrete-time base, constraining the precision of the simulations. Furthermore, multiple cells do not transition to new states in every step, compromising the computation efficiency of the simulated models. Additionally, the CA formalism is not easy to combine with other approaches (Wainer and Giambiasi, 2001). The Cell-DEVS formalism (Wainer, 2009) combines CA with the Parallel Discrete Event System Specification (PDEVS) (Zeigler et al., 2000) to overcome these issues. PDEVS is a revision of the original Discrete Event System Specification (DEVS). PDEVS is currently the prevailing DEVS variant. In the following, the use of the DEVS word implies PDEVS formal specifications.
Cell-DEVS allows us to define discrete-event cellular models in which cell states are updated asynchronously over a continuous time base, removing unnecessary computations and increasing the accuracy of the results. Furthermore, as Cell-DEVS is defined on top of the DEVS formalism, it is easy to integrate with models described with DEVS or other formalisms (Vangheluwe, 2000). The CD++ toolkit (Wainer, 2002) is a simple framework for implementing Cell-DEVS models. These models are executed asynchronously and provide a continuous time base for improving the accuracy of the simulations. CD++ has been successfully used in different research areas (e.g., building evacuation protocols (Wang et al., 2012), CO2 diffusion models (Khalil et al., 2020), or epidemics (Cárdenas et al., 2020)).
Nonetheless, current tools for simulating Cell-DEVS models present some limitations. For example, they only support typical CA models that divide the scenario in a regular grid of cells. This approach hinders the integration with spatial systems with irregular topologies, for instance Geographic Information Systems (GISs), which follow a vectorial approach to describe spaces with irregular topologies (Chang, 2019). In these scenarios, alternative modeling approaches show better results. For instance, metapopulation models (Hanski, 1994) divide the system into multiple populations with different characteristics that interact with each other. The relationship between every pair of groups is defined separately. Furthermore, current Cell-DEVS tools integrate a lowlevel interface for describing aspects of the Cell-DEVS models (e.g., cells state transition functions or neighborhoods). This interface makes defining different scenarios for exploring the search space of the system under study cumbersome. Finally, current Cell-DEVS tools cannot easily use third-party software for more advanced models (e.g., TensorFlow (Abadi et al., 2016) for representing the cells state transitions using complex machine learning models).
In this paper, we present the asymmetric Cell-DEVS formalism, a new flavor of Cell-DEVS. While the classic Cell-DEVS formalism has been used for scenarios with regular topologies, it relies heavily on isotropic geometries. Asymmetric Cell-DEVS is a generalization of classic Cell-DEVS that integrates concepts of CA and metapopulation models to define cellular models with complex topologies and dynamics. It uses a continuous time base and avoids unnecessary state transition computations. Moreover, as it relies on the DEVS formalism, we can easily combine asymmetric Cell-DEVS models with other DEVS models.
In addition, we present a new version of the Cadmium simulator (Belloli et al., 2019) that supports the implementation of asymmetric and classic Cell-DEVS scenarios. This new implementation is a flexible, header-only C++ (Stroustrup, 2013) library that allows users to implement custom cellular models with complex state transitions and timing behaviors. It also integrates a high-level interface for configuring Cell-DEVS scenarios using JavaScript Object Notation (JSON) files (Bray, 2017). This interface allows reusing a base Cell-DEVS model to execute different setups effortlessly. Furthermore, using JSON instead of any other notation format eases the integration with web-based tools and the readability of the scenario setup. It also simplifies the integration with GIS models that use the GeoJSON format (Butler et al., 2016). Cadmium eases the development and simulation of computational models based on the asymmetric Cell-DEVS formalism, as modelers do not have to worry about simulation details, and they can focus on implementing the logic of their conceptual models only.
The remainder of this paper is organized as follows. Section 2 presents related work. In Section 3, we present the asymmetric Cell-DEVS formalism, an extension of the classic Cell-DEVS formalism to support scenarios with irregular shapes. Section 4 describes the new version of the Cadmium simulator. We focus on its new Application Programming Interface (API) and the semantics supported by JSON configuration files for defining asymmetric and classic Cell-DEVS models. We illustrate how the asymmetric Cell-DEVS formalism and Cadmium can assist modelers in developing cellular models in Section 5. We also enumerate a set of successful use cases that follow this approach. Section 6 draws the main conclusions of this work.

Related Work
The modeling of natural systems aims to capture the behavior of biological processes to understand the relationships and dynamics of these systems (Wolfram, 1984). For example, models for pandemic spread may assist us with the definition of effective contention policies to reduce the impact of the disease. The COVID-19 outbreak has shown that modeling and simulation methodologies are valuable for understanding the disease and assessing the effect of different approaches to diminish its propagation speed (Adiga et al., 2020). Numerous proposals follow the approach presented by Kermack & McKendrick (1927), which classifies the population into three compartments: susceptible (S), infected (I), and can recovered (R). This model is known as the SIR compartmental model. Figure 1 shows a schematic of the SIR model. People that have never been infected remain in the S compartment. Infected individuals are assigned to the I group. People in this compartment can infect the susceptible population. Once infected individuals recover from the disease, they transition to the R compartment. The SIR model describes the dynamics between compartments with a set of Ordinary Differential Equations (ODEs). Different works extended this model with new compartments (e.g., deceased (D)) and new dynamics between compartments (e.g., immunity loss) (Tang et al., 2020). However, these models rely on the law of large numbers and cannot capture interactions between groups across both time and space. Several state-of-the-art works combine SIR-based compartmental models with cellular models to integrate the spatial aspects of the spread of the disease (Bin et al., 2019).
CA is one of the most popular approaches to define cellular models. CA is a discrete space-time formalism built as a lattice network of cells (Wolfram, 2002). In classic cellular models, cells are arranged uniformly in an n-dimensional lattice. A grid cellular scenario is characterized by the following parameters: • Shape: n-tuple that defines the dimension of the scenario. Usually, n ∈ {1, 2, 3}.
• Origin cell: it indicates which cell is considered the first cell of the scenario. The other cells are numbered according to their position with respect to the origin cell. • Wrap: wrapped scenarios connect the scenario boundaries with their opposite boundary. For instance, a wrapped 2-dimensional scenario connects cells in the left boundary with the cells in the right boundary, and uppermost cells are connected to lowermost cells. Wrapped scenarios can be thought of as n-cubes. Figure 2 shows an example of a classic cellular model. In this example, the shape of the scenario is ⟨3,4⟩ (i.e., a 3 by 4 2-dimensional cell grid). The origin cell is (1,1). Therefore, cell (2,1) is below the origin cell, and the cell (1,2) is to the right of cell (1,1). The shown scenario is wrapped. Thus, even though cell (1,4) corresponds to the upper-right corner of the scenario, cell (1,1) is to its right, and cell (3,4) is above it. where: • S n is the n-dimensional working space. Usually, n ∈ {1, 2, 3}.
• Θ is the set of states. At time step t, the state of any cell corresponds to one of these states: ∀t, ∀i ∈ S n , θ i (t) ∈ Θ. (2) • N is the neighborhood set. It contains relative positions of the neighboring cells concerning a given cell. • τ: Θ | | → Θ is the local computation function. It comprises a set of rules to obtain the new state of all the cells at every time step: The neighborhood set in CA models is defined as a set of distance vectors. Every cell of the scenario can compute its neighboring cells by summing its location and each distance vector in the neighborhood set. For example, in a 2-dimensional scenario, if the neighborhood set is N = {(1,0), (0,0), (0,1), (−1,0), (0, −1)}, the neighboring cells of cell (i, j) are (i + 1, j), (i, j), (i, j + 1), (i − 1, j), and (i, j − 1). This neighborhood set is common in the literature and is known as the von Neumann neighborhood of range 1, or simply the von Neumann neighborhood. For a given cell, the von Neumann neighborhood of range r ∈ ℕ is the set of cells in the scenario which Manhattan distance is less than or equal to r. Another popular cellular neighborhood is the Moore neighborhood. For a given cell, the Moore neighborhood of range r ∈ ℕ is formally described as the cells in the scenario which Chebyshev distance is less than or equal to r. Figure 3 represents these popular neighborhoods for 2-dimensional scenarios.  Usually, the cell space uses a rectangular topology, in which each cell is represented as a rectangle. However, previous works proposed alternative lattice patterns like hexagons (Tariq and Kumaravel, 2016). Furthermore, Baetens & De Baets (2012) extend the CA formalism to support irregular tessellations. CA has been successfully used to describe the dynamics in natural systems, such as the course of braided rivers (Murray and Paola, 1994) or urban development (Ward et al., 2000). In CA, the state of all the cells in the cell space are recomputed at every time step in synchronous fashion. However, usually, only a few cells update their state at a given time step. Thus, cells whose state remains unchanged add an unnecessary computation overhead. This overhead is greater for simulations that need shorter time steps for better time precision.
Different research have defined asynchronous CA (Ingerson & Buvel, 1984, Fatès, 2013, Dennunzio et al., 2017 to avoid these problems. However, these approaches still present some limitations inherent to the CA formalism (e.g., limited model complexity and closure to external events (Muzy et al., 2005)). Combining CA with the DEVS formalism has shown success in addressing these issues. DEVS (Zeigler et al., 2000) is a hierarchical and modular approach to describe discrete-event systems. The DEVS formalism describes systems at two levels: atomic models, which define the behavior of a system as transitions between states and response to external events; and (i-1,j-1) (i-1,j) (i-1,j+1) coupled models, which specify how subcomponents of the system interconnect. The formal definition of an atomic model is described as the following: A = 〈X, Y, S, δ int , δ ext , δ con , λ, ta〉, where: • X is the set of input events. Each element corresponds to a possible input event that may trigger the atomic model's external transition function. • Y is the set of output events. Each element corresponds to a possible output event that may be triggered by the atomic model's output function. • S is the states set. At any given time, the state of the atomic model is s ∈ S.
• ta: S → ℝ ≥0 ∪ ∞ is the time advance function. When the atomic model transitions to the state s, it will remain in this state for ta(s) time units or until the model receives one or more inputs. • δ int : S → S is the internal transition function. After spending ta(s) time units in the state s without receiving any input event, the atomic model transitions to the state s′ = δ int (s). • λ: S → Y is the output function. When the atomic is about to change its state due to an internal transition, the atomic model generates λ(s) ⊆ Y output events. This function is triggered right before calling the internal transition function. • δ ext : S × ℝ ≥0 × X → S is the external transition function. It is triggered when the atomic model receives a bag of inputs x ⊆ X after e time units since the atomic model transitioned to its current state s (i.e., 0 ≤ e ≤ ta(s)). When triggered, δ ext (s, e, x) determines the new state of the atomic model. • δ con : S × ℝ ≥0 × X → S is the confluent transition function. This transition function decides the next state in cases of collision between external and internal events (i.e., e = ta(s)). Typically, δ con (s, ta(s), x) = δ ext (δ int (s),0, x).
The formal definition of a coupled model is described as follows: where X is the set of inputs; Y is the set of outputs; C is the set of DEVS subcomponents; EIC is the external input coupling relation, from external inputs of M to component inputs of c i ∈ C; IC is the internal coupling relation, from components outputs of c i ∈ C to component inputs of c j ∈ C; and EOC is the external output coupling relation, from component outputs of c i ∈ C to external outputs of M.
In most cases, cellular models described with DEVS require expertise in programming, leading to multiple specific single-use programs which are difficult to reuse for related experiments (Wainer, 2006). The Cell-DEVS formalism (Wainer, 2009) proposes a simple and generic way of defining discrete-event cellular models with advanced timing behavior. Each cell is a continuous-time model in which state transitions are defined by a local computation function, as in CA. It also provides different delay functions that simplify complex timing definitions. This approach allows us to define CA models with advanced timing behavior while using the formal specifications of DEVS. Section 3 provides an in-depth description of the Cell-DEVS formalism.
Cellular models usually divide the space into uniform cells with the same behavior. Additionally, the relationship between these cells is described implicitly with the neighborhood set. However, even though these assumptions are an advantage for formal analysis, they are sometimes overly simplistic (Hanski and Simberloff, 1997).
Metapopulation models propose a different approach to study the dynamics of groups that interact at some level (Hanski, 1994). These models divide the system into multiple populations. Each population has a different location and different characteristics (e.g., number of inhabitants). Additionally, metapopulation models describe the relationship between every pair of groups separately. Thus, the interaction between groups is heterogeneous and is more accurate than in cellular models. Metapopulation models have shown success in describing epidemics (Watts et al., 2005), biodiversity in natural areas (Muneepeerakul et al., 2007), and demographics of species (Heide-Jørgensen et al., 2013).
Some works aim to integrate aspects of metapopulation models to CA. For example, Sonnenschein & Vogel (2001) propose the Asymmetric Cellular Automaton (ACA) formalism. ACA substitutes the neighborhood of CA with a topology matrix, which describes the neighborhood degree of two cells. The neighborhood degree represents how strongly a neighboring cell influences another cell. Every cell in the scenario assigns a different neighborhood degree to each neighboring cell, allowing asymmetric neighborhood relations. Additionally, the ACA formalism includes a global state. The global state describes the characteristics of the scenario that affect all cells in the model but, in contrast to the cell state, cells cannot modify directly (e.g., wind direction for fire spreading models). The variables that make up the global state evolve independently of the scenario cells. Zhong et al. (2009) employ this formalism to define a CA model for the spread of infectious diseases where cells are irregular regions of a city, and the neighborhood degree is computed as a function of the shared border width and the number of roads that interconnect these regions. In this paper, we present the asymmetric Cell-DEVS formalism to support discrete-event cellular models based on metapopulation systems. This new formalism is compatible with conventional cellular models and provides mechanisms to define global states for all the cells in the scenario.

The Asymmetric Cell-DEVS Formalism
This section defines the asymmetric Cell-DEVS formalism. Then, we illustrate how this formalism contains the classic Cell-DEVS approach based on a uniform lattice of cells.

Formal Definition of the Asymmetric Cell-DEVS Formalism
In the asymmetric Cell-DEVS formalism, each cell may have different behavior, and they are not necessarily arranged in a regular lattice. Thus, unlike traditional cellular models, neighborhoods can be diverse for every cell. Next, we describe all the elements that comprise the Cell-DEVS formalism. We use the example shown in Figure 4 to illustrate the principal concepts of the proposed asymmetric Cell-DEVS formalism.  Let us assume we want to study the movement of individuals between the five Regions of Denmark presented in Figure 4a (identified as C1-C5). We also want to assess the influence of the connections with bordering countries (namely, Germany and Sweden). Figure 4b shows the structure of an asymmetric Cell-DEVS coupled model representing the system under study. Asymmetric Cell-DEVS models are regular coupled DEVS models that are formally described as follows: To/From Germany To/From Sweden To Sweden low (e.g., 0.2) medium (e.g., 0.4) high (e.g., 0.8) where: • X is the input set. It defines the possible inputs that the Cell-DEVS model may receive. • Y is the model output set. It describes every potential output that the Cell-DEVS model may generate. • C is the subcomponent set. It defines all the cells in the model. • EIC is the external input coupling set. It maps inputs of X with inputs in each cell C i ∈ C in the model. • IC is the internal coupling set. It defines the interconnections between the cells in the model. We say that cell C i ∈ C is influenced by cell C j ∈ C if the IC set maps outputs in cell C j to inputs of cell C i . Alternatively, we say that cell C i is a neighbor of C j if the IC set maps outputs of C i to inputs of cell C j .
• EOC is the external output coupling set. It maps outputs of cells to the Y set. It allows us to forward information about the scenario to other DEVS models.
In the example of Figure 4, there is one cell per Region of Denmark (i.e. C = {C 1 , C 2 , C 3 , C 4 , C 5 }). Figure 4b represents the EIC set by the dashed edges that link inputs from Sweden and Germany to the cells C 5 and C 3 ; and the EOC set is depicted with dashed edges that link cells C 3 and C 5 to Germany and Sweden. Finally, Figure 4b represents the IC set with solid edges that link the cells. For instance, cell C 2 is influenced by C 1 , C 2 , C 3 , and C 4 . On the other hand, C 3 , C 4 , and C 5 are neighbor cells of C 4 . Each cell C i ∈ C of the scenario is formally defined as follows: where: • X i N is the neighborhood input set. It defines the possible inputs that the cell may receive from neighboring cells in the Cell-DEVS model. • X i E is the external input set. It enumerates inputs that the cell may receive not from neighboring cells (e.g., inputs from a different DEVS or Cell-DEVS model). We use the cell input set X i = X i N ∪ X i E to refer to the neighborhood and external input sets together. It represents all the potential inputs that the cell may receive. • Y i is the cell output set. It describes all the possible output events of the cell. • S i is the cell state set. It enumerates the possible states of the cell. • N i is the cell neighborhood set. It enumerates all the neighboring cells of the cell. • τ i : S i × N i × X i → S i is the local computation function of the cell. When triggered, it computes the new state of cell C i from its previous state, the neighborhood set, and inputs. • d i : S i → ℝ ≥0 is the cell delay function. When the cell transitions to a new state s i ∈ S i , it waits for d i (s i ) time units before sharing with other cells this change.
• delay i is the cell delay type function. These functions allow us to define complex timing behavior effortlessly. We provide more details about these functions later.
The external input set X i E , enables modelers to use state variables that provide global information. For example, in forest fire spread models, an external DEVS model can be used to model the wind flow, and cells in the scenario could use X i E to receive inputs notifying wind direction changes. In cellular models, the state of neighboring cells has an influence on the cell state. In asymmetric Cell-DEVS, the neighboring cells are not necessarily the immediate nearby cells (for instance, C5 could be connected to C1), and not all the neighbor cells affect the cell behavior in the same way. For example, when modeling a geography-based cellular model like the one in Figure 4, the length of the border shared with each neighboring cell varies. Asymmetric Cell-DEVS represents this by associating the vicinity factor V i j , which describes how the state of the neighboring cell C j affects the state of cell C i . The neighborhood set N i is defined as a set of pairs ⟨cell ID, vicinity factor⟩ for each of the neighboring cells of cell C i : Figure 4b shows the vicinity factor using different colors for each of the solid edges from neighboring cells. For instance, if an edge from a neighboring cell to the origin cell is black, this represents a high vicinity factor. On the other hand, dark and light gray edges correspond to medium and low vicinity factors, respectively. In this example, high, medium, and low vicinity factors correspond to 0.8, 0.4, and 0.2, respectively. In this way, a cell can use the vicinity factor to ponder the effect of each neighboring cell. For instance, the neighborhood set of the cell C4 is N4 = {⟨C3, 0.2⟩, ⟨C4, 0.8⟩, ⟨C5, 0.4⟩}. This means that the state of cell C4 has a high influence on itself (e.g., most of its inhabitants do not leave this cell), while the state of cells C3 and C5 have a low and medium influence, respectively (e.g., it is more usual to have individuals moving from cell C5 to C4 than from cell C3). Thus, when transitioning to a new state, cells will pay more attention to the status of neighboring cells with higher associated vicinity factors. Vicinity factors allow modelers to define more complex dynamics between cells, which can potentially increase the accuracy of the simulation results. Asymmetric Cell-DEVS models can be thought of as directed graphs with weighted edges (Gansner et al., 1993) in which cells are the nodes and the edges connect neighboring cells with influenced cells. The weight of an edge from C j to C i corresponds to the vicinity factor V i j . Figure 5 represents the behavior of a cell in asymmetric Cell-DEVS. At any given time, the state of cell C i is s i ∈ S i . When C i receives input messages x ⊂ X i , it executes the local computation function τ i (s i , N i , x) = s i ′ . The cell new state s i ′ depends on its previous state, its neighborhood set, and the received input messages. If the new state is equal to the previous state (i.e., s i = s i ′ ), the cell passivates and stops computing.
Otherwise, it schedules an output of the new state value after the time specified by the cell delay function d i (s i ′ ). To do so, we might need to use an output queue q i , which is updated according to the cell delay type function, delay i . Delay type functions allow us to define complex timing behavior effortlessly. These functions have three input parameters: the previous output queue q i , the state change to be scheduled s i ′ , and the delay to wait before sending the corresponding message d i (s i ′ ); and return a new output queue with the new scheduled message: The output queue q i contains tuples 〈ϑ, σ〉, where ϑ ∈ S i is a previously scheduled output and σ is the time to wait before sending it. If q i is empty, the cell passivates. Otherwise, it waits until one or more scheduled messages expire and sends them. The original Cell-DEVS formalism defines two types of delay type functions, both based on logical circuit theory ): • Transport delay. It is based on ideal digital devices with infinite frequency response, in which any input pulse, no matter how short it is, produces an output pulse. It adds to the output queue a new message for every cell phase change: • Inertial delay. It is based on more realistic electronic circuits which do not have infinite frequency response, so very short input stimuli are ignored. The inertial delay function presents a preemptive behavior, as the output queue can only contain one message at a given time. Therefore, if the cell changes its state, all the previously scheduled messages are dropped from the queue: Figure 6 illustrates the difference between these delay type functions. The abscissae represent the simulation time. In this example, the cell state keeps track of the number of external transitions triggered by the cell. The delay function returns the value of the cell new state (i.e., d(s i ′ ) = s i ′ ).
(a) Transport delay function.
(b) Inertial delay function. In both cases, the initial cell state is s i = 0, and its output queue contains a scheduled message with a delay of 0 (i.e., q i = {〈0,0〉}). At t = 0, the cell outputs the scheduled message and receives input messages with the initial state of its neighboring cells. The local computation function sets s i to 1, and the output queue schedules a new message with a delay of d i (1) = 1. The cell outputs it at t = 1, leaving the output queue empty. At t = 2, the cell receives a new message and transitions to s i = 2. The output queue schedules a message with a delay of d i (2) = 2. At t = 4 the scheduled message expires, and the cell outputs it. At the same time, it receives new inputs. Thus, the cell transitions to the phase s i = 3. The delay to be applied is d i (3) = 3. Thus, the cell schedules an output message at t = 4 + 3 = 7.
At t = 6 (i.e., before outputting the scheduled message), the cell receives new inputs, transitions to a new state s i = 4. The cell must wait for d i (4) = 4 time units. Therefore, the output queue schedules a new message at t = 6 + 4 = 10. Here, we can observe the difference between the transport and inertial delay functions. The transport delay function updates the delay to be applied to the message previously scheduled in the queue (i.e., q i = {〈3,1〉, 〈4,4〉}). On the other hand, the inertial delay function drops it (i.e., q i = {〈4,4〉}).
The transport delay function can schedule new events before previously queued messages. For example, if output messages represent individuals moving from one cell to another, people may move at different speeds, and a fast person can overtake a slow person that started moving before. However, in other cases (e.g., epidemic models), messages normally include the sender cell state value. For these models, receiving messages in reverse order may lead to inconsistencies, as cells might receive outdated copies of the state of their neighboring cells.
To avoid these issues, we now include a hybrid delay function. This function behaves as the transport delay, however, when scheduling a new phase change, it preempts all the previously scheduled messages which σ is equal to or greater than the delay to be applied to the new message. By doing so, the hybrid delay function guarantees that the latest scheduled message is always the last message in the queue:

Defining a Cell as an Atomic DEVS Model
In the asymmetric Cell-DEVS formalism, cells are atomic DEVS models. As discussed in Section 2, an atomic DEVS model is formally defined with the tuple shown in Eq. (4). The input set of the atomic DEVS model corresponding to cell C i is the union of its neighborhood and external inputs sets, while the output set of the DEVS model is the output set of the cell: The input neighborhood and output sets are typically composed of tuples {cell ID, cell state}. In this way, it is straightforward to deduce which cell generated the event and the state change associated with the event. The state of the atomic DEVS model includes the current cell state, its output queue, and its neighborhood set (i.e., s = 〈s i , q i , N i 〉). The time advance function of the atomic model returns the minimum delay of the output messages scheduled in the cell output queue: After waiting this time, the cell outputs those scheduled messages for which σ expires. Eq. (15) displays the DEVS output function for the cell C i : The internal transition function of the atomic model leaves the cell state as is, updates the σ of queued messages, and removes those already sent by the previous λ function: δ int (s) = 〈s i , {〈ϑ, σ − ta(s)〉 | 〈ϑ, σ〉 ∈ q i ∧ σ > ta(s)}, N i 〉.
When the output queue is empty, the cell passivates. Otherwise, it schedules the next internal transition using the first element of the queue. If C i receives inputs x ⊂ X , the external transition function δ ext (s, e, x) is activated, and it executes the τ function, and computes s i ′ = τ i (s i , N i , x). Only if the new state is different from the previous state (i.e., s i ≠ s i ′ ), will the cell schedule a new output.
Eq. (17) shows the external transition function of the cell.
Note that it also updates the σ of messages queued in q i by subtracting the time elapsed since the previous state transition of the model, and schedules an internal event using the first element in the queue: The confluent transition function is defined as δ con (s, e, x) = δ ext (δ int (s), 0, x). At time t = 0, the state of cell C i is set to its initial value, s i 0 , and the output queue schedules a message with a delay of 0 so all the cells being influenced by C i are aware of its initial state. In the same way, cell C i receives messages with the initial state of its neighboring cells and triggers its local computation function τ i . If the cell transitions to a new state, it schedules a new message with the delay provided by the delay function d i . Otherwise, it passivates and waits for any input. Figure 7 shows a flow chart of the behavior of cells in the asymmetric Cell-DEVS formalism.

Defining Classic Cellular Models with Asymmetric Cell-DEVS
Asymmetric Cell-DEVS can model classic grid scenarios as follows: first, each cell in the scenario is uniquely identified by its position in the lattice. Then, the vicinity factor of neighboring cells corresponds to the distance vector from the cell to the neighboring cell. Thus, in the asymmetric Cell-DEVS formalism, a 2-dimensional von Neumann neighborhood of range 1 (see Figure 3a)

Simulation of Asymmetric Cell-DEVS Scenarios with Cadmium
This section presents a new version of the Cadmium simulator that supports both classic and asymmetric Cell-DEVS models. Cadmium is a header-only library written in C++ that allows the modeling and simulation of computational models based on the DEVS formalism. In this new version of Cadmium, cells are implemented in C++ and the cell space is defined using a JSON configuration file. This approach allows us to study multiple setups by simply modifying the configuration file, thus avoiding recompilations and reducing the overall time required for exploring a scenario. Furthermore, modelers can integrate Cell-DEVS models with other DEVS models implemented with Cadmium. This new version of Cadmium is publicly available on GitHub (Cárdenas and Trabes, 2022). Figure 8 shows the simulation lifecycle to explore cellular models with the asymmetric Cell-DEVS formalism and the Cadmium simulator.
First, we need to define a conceptual cellular model describing the system under study following the asymmetric Cell-DEVS formalism. The conceptual model is then translated into a computational model using the tools provided by the Cadmium library. Once we have implemented the corresponding computational model, we can run simulations over different scenarios by modifying the JSON configuration file. Then, we analyze the simulation results to gain insight into the system under study. Here we present the most important features of the API of Cadmium to implement computational models of Cell-DEVS scenarios. We also describe the notation used by JSON configuration files to define a simulation scenario. In Section 5, we present a use case scenario to illustrate how to use Cadmium for developing asymmetric Cell-DEVS models. The GitHub repository of the new version of Cadmium contains detailed documentation about the API of Cadmium and its implementation details.

Modeling Cell-DEVS Scenarios with the Cadmium Library
Figure 9 displays a simplified UML class diagram of all the elements related to the implementation of cells in the Cadmium Cell-DEVS library. The Cell<C,S,V> class is an abstract implementation of the behavior of cells as regular DEVS models that follows the flowchart shown in Figure 7. The localComputation and outputDelay functions are virtual methods and must be overwritten according to the desired behavior of the cell. Both methods are constant and cannot modify any field of the cells when they are triggered. Instead, the localComputation function receives a copy of the latest state of the cell and returns its new state. If the new state is not equal to the previous state, the Cadmium library adds this new state to its output queue for further sending to influenced cells.
The Cadmium Library uses a port-based approach to propagate events from one model to another. Cadmium DEVS models have a set of input and output ports. A model can send output events by adding a message to one of its output ports. Alternatively, models receive input events by reading the messages in its input ports. Cells send scheduled state changes to influenced cells via the outputNeighborhood output port. On the other hand, cells receive state changes of their neighboring cells via the inputNeighborhood port. It is possible to add extra input ports for receiving external input events from other DEVS models using the addInPort<T> method, where T corresponds to Define conceptual cellular model

Cell(s) logic
Coupled Cell-DEVS model Main function

Implement computational model with Cadmium
Define JSON config. file Run simulation Analyze results

Explore different scenarios
the data type of the messages supported by the port. When creating a new port, you need to provide a unique port ID. Cell-DEVS models cannot add additional output ports, as their behavior is constrained to only sending cell state messages. The AsymmCell<S,V> and GridCell<S,V> classes are class specializations of the Cell<C,S,V> class for asymmetric and symmetric Cell-DEVS cells, respectively. Note that the GridCell<S,V> has a pointer to a GridScenario structure. GridScenario structures implement auxiliary methods for scenario-related algebraic functions (e.g., computing distances between cells). In the Cadmium Cell-DEVS library, coupled Cell-DEVS models are defined in a JSON configuration file that is used to create all the cells and couple them according to the neighborhood described in the scenario. CellDEVSCoupled<C,S,V> is an abstract implementation of coupled Cell-DEVS models. When a new object of the class CellDEVSCoupled<C,S,V> is created, it reads the JSON configuration file and creates every cell in the scenario. AsymmCellDEVSCoupled<S,V> and GridCellDEVSCoupled<S,V> are class specializations of the CellDEVSCoupled<C,S,V> class for asymmetric and symmetric Cell-DEVS coupled models, respectively. If required, modelers can add additional input and output ports to the coupled Cell-DEVS model to integrate other DEVS models using the addInPort<T> and addOutPort methods. Note that the addOutPort method does not have a template argument T. This is because the output message type of coupled cell DEVS models is constrained to cell state messages only.

Configuring Different Scenarios with the JSON Configuration File
Once the main program is compiled, we can run multiple simulations for different scenarios by modifying the input configuration file, without re-compiling the entire project. The configuration of the scenario to be simulated is provided via a JSON file. The structure of this file depends on whether it defines an asymmetric or classic Cell-DEVS scenario.
We provide examples of how to define Cell-DEVS scenarios with JSON configuration files in Section 5. The JSON object named cells is used to configure all the cells in the scenario. The default object defines a default configuration for all the cells. Inside default, modelers select the configuration of all the cells (e.g., delay type function or initial state). Each key inside the cells object (except from default) corresponds to an asymmetric cell in the scenario, and its value is a modification to the default configuration. Table 1 presents all the fields that cell configuration objects may contain in the JSON file for asymmetric Cell-DEVS scenarios. Table 1. Cell configuration fields in the JSON file for asymmetric Cell-DEVS models.

Field name Description delay
String indicating the cell delay type function. It only can be set to "inertial", "transport", or "hybrid". model Cell model identifier. It determines the logic implemented by the cell.
The accepted values depend on the use case.
state Initial cell state. Modelers must provide a function to parse the JSON object to a data structure of the corresponding type in C++.

neighborhood
Cell neighborhood. Cell neighborhoods are defined in a key-value fashion. The key identifies the neighboring cell ID, and the value defines the vicinity factor of the neighboring cell over the cell. Modelers must provide a function to parse the JSON object to a data structure of the corresponding type in C++. This field is optional. config JSON object with any additional configuration parameters for the cell model. This field is optional, and modelers are responsible for parsing its content in the cell model constructor method. eic JSON array that describes EICs. It contains tuples of strings that specify these couplings. If eic is [["coupled_p1","cell_p1"]], Cadmium will generate an EIC from the input port of the Cell-DEVS coupled model with ID coupled_p1 to the input port of the cells affected by this configuration with ID cell_p1. This field is optional. If Cadmium does not find the ports, it will throw an exception. eoc JSON array of strings that describes EOCs. These connect the cell state output port to the output port of the Cell-DEVS coupled model specified in eoc. For instance, if eoc is ["coupled_p2"], the Cadmium library will generate an EOC from the cell output port of the cells affected by this configuration to the coupled_p2 port of the Cell-DEVS coupled model. This field is optional. If Cadmium does not find the ports, it will throw an exception.
For symmetric Cell-DEVS models, the JSON file also describes the spatial properties of the scenario. Code 1 shows an example for symmetric Cell-DEVS models.
Code 1. Example of a JSON configuration file for a symmetric Cell-DEVS scenario. The scenario object defines the shape of the scenario, as well as the origin cell. It is also possible to define whether a scenario is wrapped or not. Table 2 presents all the fields that scenario configuration objects may present for symmetric Cell-DEVS scenarios. Table 2. Scenario configuration fields in the JSON file for classic Cell-DEVS models.

Field name Description
shape JSON array of integers representing the shape of the scenario. All the numbers in shape must be greater than zero. In the example shown in Code 1, the scenario if a lattice of 25 by 25 cells. origin JSON array of integers representing the origin cell of the Cell-DEVS scenario. It must contain the same number of integers as the shape array. In the example shown in Code 1, the origin cell is located at (-12, -12).
If not specified, all the coordinates of the origin cell are set to zero. wrapped Boolean that indicates whether the cellular model is wrapped or not. If not specified, it is set to false.
Again, the default JSON object inside cells defines the default configuration for all the cells in the scenario. If no configuration modifications are provided, all the cells in the lattice will be configured with the default values. The rest of the keys inside the cells JSON object are also modifications to the default configuration. However, they do not correspond directly to any cell. Instead, the cell_map key determines which cells in the scenario implement the alternative configuration. In the example shown in Code 1, only cells (-12, -12), (-12, 12), (12, -12), and (12, 12) (i.e., the cells at the corners of the scenario) are affected by the custom configuration modification. All the remaining cells implement the default configuration.
In symmetric Cell-DEVS scenarios, neighborhoods are described as a list of JSON objects. Cadmium provides additional tools to describe different types of neighborhoods. Table 3 describes all these neighborhood types, as well as all the configuration parameters that modelers can use to describe the neighborhoods. Neighborhoods are parsed in the same order as the neighborhood list. Thus, if a cell is part of more than one neighborhood in this list, Cadmium will only use the latest vicinity and ignore the previous configuration for that neighboring cell. Table 3. Neighborhood fields in the JSON file for classic Cell-DEVS models.

Field name Description type
String that determines the neighborhood type under description. Other fields of the neighborhood configuration depend on the neighborhood type. Supported neighborhood types are described below. vicinity Vicinity factor of neighboring cells over the cell under configuration. Modelers must provide a function to parse the JSON object to a data structure of the corresponding vicinity type in C++.
Only for neighborhoods with "relative" or "absolute" type neighbors JSON array with coordinates of all the neighboring cells. In relative neighborhood types, these coordinates are relative to the cell under configuration. On the other hand, if the neighborhood type is absolute, these coordinates refer to the exact location of neighboring cells in the scenario. Let us assume that neighbors is set to [[0,0]]. In relative neighborhood types, the cell being configured will be neighbor of itself. In contrast, in absolute neighborhood types, the cell located at the coordinates (0, 0) will be a neighbor of the cell under configuration, regardless of the location of the later.
Only for neighborhoods with "von_neumann" or "moore" type range Integer indicating the range of the neighborhood. See Figure 3 for more details about von Neumann and Moore neighborhoods.
Only for neighborhoods with "minkowski" type p Integer indicating which Minkowski distance is used when defining the neighborhood. For example, if p is set to 2, the neighborhood uses the Euclidean distance to identify neighboring cells.
range Double-precision floating-point number indicating the maximum distance between one cell to another to consider the prior a neighbor of the later. If p is set to 2 and range is set to 2.5, all the cells of the scenario which Euclidean distance to the cell under configuration is less than or equal to 2.5 will be considered neighbors.

Using Cadmium to Execute Cell-DEVS Models
This section illustrates how the Cadmium simulator can be used to define asymmetric and classic Cell-DEVS models. In addition, we discuss how to combine Cell-DEVS models with other tools for the visualization of the results or the automatic generation of scenarios. Here we show how modelers can follow the workflow shown in Figure 8 to develop a simple asymmetric Cell-DEVS model of communicable disease. We adapt the SIR compartmental model presented in Figure 1 and represent it using the asymmetric Cell-DEVS formalism to include spatial considerations in the dynamics of the disease. Then, we translate the resulting conceptual model to an equivalent computational model implemented with the new version of Cadmium. Finally, we define different JSON configuration files to explore different pandemic scenarios. The implementation of the presented use cases are included in GitHub (Cárdenas and Trabes, 2022).

Conceptual SIR Model Using the Asymmetric Cell-DEVS Formalism
The state for each cell C i is represented by the following 4-tuple: where P i represents the population inhabiting the cell and S i , I i , and R i correspond to the ratio (from zero to one) of susceptible, infected, and recovered people, respectively. The sum of all the compartments must be equal to 1: Every time the local computation function of a cell is triggered, it transitions to a new state s′ i = τ i (s i , N i , X i ) = 〈P i , S′ i , I′ i , R′ i 〉. The population of the cell remains the same, but people transition from one compartment to another as described in Equation (21): where γ corresponds to the recovery factor (i.e., the probability of an infected person recovering from the disease) and i i represents the ratio of susceptible people that got infected since the last time the local computing function was triggered: where σ is the susceptibility factor (i.e., the probability of a susceptible individual getting infected if exposed) and υ is the virulence factor (i.e., the probability of an infected person exposing others to the illness). In this model, the vicinity factor V i j corresponds to a real number between 0 and 1 that weights how the state of cell C j influences over the state of cell C i . The way we compute the correlation factor is a configuration parameter of the model. In this example, we compute V i j as the length of the shared border divided by the perimeter of the region represented by cell C i . Finally, we set the output delay function to one day (i.e., cells wait for one day before sending their new state to influenced cells).

Implementing the Corresponding Computational Model with Cadmium
After describing the conceptual model under study, we develop a computational model with the help of the new version of Cadmium. First, we define the data structure used to represent a cell state. Code 2 shows how to implement a data structure for the SIR model.
Code 2. Definition of cells state data structure. The structure is defined from lines 7 to 13. It contains all the fields of the 4-tuple shown in Equation (19). We need to define a default constructor (see line 12). We also must implement the inequality operator (!=) for two cell states (see lines 15 to 17). Cadmium uses this inequality operator to check whether the local computation function returned a different state. We define the insertion operator (<<) in lines 19 to 22 to configure how Cadmium outputs the cell states in the simulation results. Finally, we implement the from_json function for our structure (lines 24 to 29). In this way, Cadmium will be able to parse the JSON configuration file to create simulation scenarios.
If we used a complex data structure to represent the vicinity factor between cells, we would have to do a similar process as with the cell state structure. However, in this example the vicinity factor is represented by a double-precision floating-point number. C++ already provides all the required functionalities for this data type. Now, we define the cell logic. Code 3 shows how to implement the model with Cadmium. As this is an asymmetric Cell-DEVS scenario, our cell model will inherit from the AsymmCell class (see Figure 9). In line 6, we select SIR and double data structures as the cell state and vicinity factor data types, respectively. In line 7 to 9, we add the attributes rec, susc, and vir for the recovery, susceptibility, and virulence factors. These are not part of the cell state. However, we want them to be configurable from the JSON file. To do so, we parse the config JSON parameter (see Table 1) in the constructor function (lines 13 to 15).
Code 3. Logic of an asymmetric Cell-DEVS cell for a pandemic spread model. Modelers only need to implement the local computation and output delay functions. The local computation function corresponds to lines 18 to 34. In lines 21 to 27, we compute the ratio of new infections in the cell as defined in Equation (22). We iterate over all the neighboring cells as shown in line 22. The neighboring cell ID is nId, and nData contains its latest known state and the vicinity factor. Cadmium also allows you to easily access the latest known state of neighboring cells, as shown in line 23. This implementation feature eases the process of processing incoming messages from neighboring cells. The ratio of new recoveries is computed in line 28. Lines 30 to 32 updates the cell state. Note that we discretize the compartments to three decimal numbers. The reason for this discretization is that we considerably reduce the number of possible states. By discretizing the compartments, we disregard small changes, and the cells reach their final state faster. Thus, state discretization contributes to shorter (but less precise) simulations. However, this discretization is optional. Finally, the output delay function is set to 1 day regardless of the input cell state (lines 36 to 38). In this use case scenario, all the cells implement the same logic. If we want to describe a special behavior for certain cells, we just need to repeat the cell implementation process. Now, modelers must implement the coupled Cell-DEVS model. Code 4 shows how to implement the model under study using Cadmium. As this is an asymmetric Cell-DEVS scenario, our Coupled Cell-DEVS model will inherit from the AsymmCellDEVSCoupled class (see Figure 9).
Code 4. Coupled Cell-DEVS model for pandemic spread scenarios. In line 3, we select SIR and double data structures as the cell state and vicinity factor data types, respectively. These must be the same for the coupled Cell-DEVS model and for all the cell models. Coupled Cell-DEVS models only must map a given cell model ID to its corresponding cell model. In our use case, there is only one cell model (the SIR cell class). Thus, we only expect the cell model ID to be SIR (see line 11). If so, we add a cell of the SIRCell class to the scenario, as shown in line 12. Otherwise, the coupled Cell-DEVS model will throw an exception (line 14).
After implementing all the cell models and the coupled Cell-DEVS model for a given scenario, modelers must implement the main function for executing simulations. Code 5 shows an example of a main function. When creating a coupled Cell-DEVS model, we need to provide a file path to the JSON file with the scenario configuration. In this example, this file is in ./scenario_config.json (see line 5). After building the model in lines 8 and 9, a Cadmium coordinator is created in line 10 to run the simulations. Additionally, it is possible to set a logger to the coordinator to store simulation results in a CSV file, as shown in lines 11 and 12. To simulate a scenario, we must execute the start, simulate, and stop methods of the coordinator (see lines 13 to 15). It is possible to set a maximum simulation time executed by the coordinator. In line 4, we set simTime to 1000. When calling the simulate method of the coordinator, we provide this value to limit the simulated time to 1000 days.
The new version of Cadmium eases the development and simulation of computational models based on the asymmetric Cell-DEVS formalism. Modelers do not have to worry about most of the simulation details, and they can focus on implementing the logic of their conceptual models only. The repository of the new Cadmium library includes template projects with instructions to implement classic and asymmetric Cell-DEVS models. Thus, modelers can successfully implement asymmetric Cell-DEVS models with basic programming knowledge.
Code 5. Main program for simulating pandemic spread models in Cadmium.

Exploring Different Scenarios with JSON Configuration Files
Once the main program is compiled, we can run multiple simulations for different scenarios by modifying the input configuration file, without re-compiling the entire project. Let us assume that we want to simulate an asymmetric scenario with three regions as shown in Figure 10. All the cells have shared borders with each other. In this example, we compute V i j as the length of the shared border divided by the perimeter of the region represented by cell C i . Thus, all the vicinity factor of every cell over themselves is 1. The vicinity factor of C 2 and C 3 over C 1 is 0.25. The vicinity factor of C 1 and C 3 over C 2 is 0.125. Finally, the vicinity factor of C 1 and C 2 over C 3 is 0.125. The population of cell C 1 is 100 individuals, while the other two cells have 200 inhabitants. By default, all the population is susceptible to the disease. However, 10% of the people in cell C 3 is infected. Figure 10. Use case scenario for the asymmetric Cell-DEVS pandemic model.
C2 C1 C3 Code 6 shows the JSON configuration file for simulating this scenario. There are four JSON objects inside the cells JSON object. The default object (lines 3 to 8) determines the default configuration of all the cells in the scenario. We use the inertial delay type function (line 4). As we have only implemented one cell logic, the cell model type ID of all the cells is set to "SIR" (line 5). The coupled Cell-DEVS model will analyze this value when creating every cell in the scenario. As it is set to "SIR", the coupled Cell-DEVS model will generate a cell of the class SIRCell (see lines11 to 13 of Code 4). By default, the initial state of all the cells is set to the value shown in line 6. Cells contain 200 inhabitants susceptible to the disease. In the config JSON object (line 7), we set other model-related configuration parameters. Specifically, we set the recovery factor to 0.2, the susceptibility factor to 0.8, and the virulence factor to 0.4. Cells have access to these additional configuration parameters in their constructor function. Lines 13 to 15 in Code 3 parse this JSON object to obtain the values.
Code 6. Example of a JSON configuration file for an asymmetric Cell-DEVS scenario. The c1, c2, and c3 JSON objects determine that there are three cells. We modify the default configuration parameters depending on each cell. For example, in line 14, we determine that C2 has three neighboring cells: C1, C2, and C3, and their vicinity factor over C2 is 0.125, 1, and 0.125, respectively. Line 10 sets the population of cell C1 to 100 people. Finally, in line 17, we set the initial ratio of susceptible and infected people in cell C3 to 0.9 and 0.1, respectively. Now, we can run the scenario. Simulation results are stored in the log.csv file (see line 11 in Code 5). Figure 11 displays the simulation results for first 50 days of the presented use case. At the beginning of the simulation, the ratio of susceptible people in cells C1 and C2 is 1, while the 10% of the population in cell C3 is infected. The disease spreads faster in cell C1, as is has less population than the other cells and the vicinity factors of neighboring cells over it is greater than in the rest of cells. These aspects negatively affect the ratio of new infections, as shown in Equation (22). The ratio of infected people reaches its peak in days 12, 18, and 11 for cells C1, C2, and C3, respectively. By the end of the simulation, the ratio of susceptible people for cells C1, C2, and C3 drops to 0.05, 0.21, and 0.19, while the ratio of recovered people is 0.95, 0.79, and 0.81, correspondingly. To run a different scenario (e.g., a lower susceptibility factor due to the use of facial mask to stop the spread of the virus), we just must modify the JSON configuration file and run the simulation again. Figure 11. Simulation results of the asymmetric Cell-DEVS use case scenario.

Classic Cell-DEVS Scenarios with the Cadmium Cell-DEVS Library
Let us assume that we now want to explore the scenario shown in Figure 12. In this scenario, every cell has 100 individuals susceptible to the disease. However, 10% of the population of cell C1,1 (outlined in red) is infected at the beginning of the simulation. C-1,-1 C-1,0 C-1,1 C0,-1 C0,0 C0,1 C1,-1 C1,0 C1,1 rest of the code remains intact. The scenario JSON object (lines 2 to 4) specifies that we want a 2-dimensional scenario of 3 by 3 cells. The coordinates of the origin cells are (-1, -1). The default cell configuration (lines 6 to 15) is like the previous example. However, we define a default neighborhood. In line 12, we define a von Neuman neighborhood of range 1 (see Figure 3a). The vicinity factor of all the cells in this neighborhood is set to 0.25. This vicinity factor matches with the shared border relationship for all the cells in this neighborhood except the cell itself. In line 13, we overwrite the von Neumann vicinity factor of one cell over itself to keep using the same definition of the vicinity factor.
Code 7. Example of a JSON configuration file for a classic Cell-DEVS scenario. The infected JSON object (lines 16 to 20) defines an alternative cell configuration that sets the initial ratio of infected people to 0.1. The cell_map array indicates that this alternative configuration only affects cell (1, 1), while the rest of the scenario uses the default configuration.

Extending the SIR Model including Geographical Information Systems
In Cárdenas et al. (2021) we introduced an extended SIRDS compartmental model with irregular topologies and multiple infection phases with different recovery factors. In this model, individuals that die due to the disease transition to a new D compartment. Furthermore, recovered people may lose their immunity and become susceptible to the disease again. The population is also divided into age segments. We computed the vicinity factor as the length of the shared border divided by the perimeter of the region represented by the influenced cell.
We integrated GIS models with Cadmium for simulation based on real geographies. GIS software integrates physical location data with descriptive information (e.g., population or weather conditions). With GIS, we can analyze patterns and relationships in a geographical context. For example, we can monitor and forecast changes to understand trends motivated by geographic characteristics. Figure 13 shows the workflow used to conduct these experiments. Figure 13. GIS integration for asymmetric Cell-DEVS models First, a Cell-DEVS scenario generator reads geographical information from a GIS database. The generator adds a cell in the Cell-DEVS scenario for every physical location. Furthermore, it manipulates the descriptive characteristics of the physical location to define their initial state and the vicinity factor of neighboring cells. For the proposed SIRDS model, the generator uses population data to generate the initial state of the cells. Additionally, it computes relationships between physical locations to determine the cell neighborhoods and the vicinity factors to be applied. The resulting asymmetric Cell-DEVS scenario is stored in a JSON scenario configuration file. Cadmium executes the simulation of the scenario and outputs the simulation results. Then, simulation results are displayed on a map corresponding to the area under study using GIS tools and methodologies. Davidson & Wainer (2021) presented an extended compartmental model that followed the proposed workflow for integrating GIS models with asymmetric Cell-DEVS scenarios. They adapted a GeoJSON file with geographical information about the Ontario province to create an asymmetric Cell-DEVS scenario in which each cell corresponds to a region of Ontario. For every pair of regions, a vicinity factor was computed as the shared border length between regions divided by the total border length of each region. The neighborhood of the cell is comprised of all the cells which vicinity factor is greater than zero. Simulation results were then adapted to a format compatible with the DEVS Web Viewer tool (St-Aubin et al., 2021). This software represents simulation results of asymmetric Cell-DEVS scenarios on a map, making it easier to understand and analyze simulation results. Figure 14 shows the simulation results of a pandemic scenario over the city of Ottawa.
For each district, the ratio of infected people is displayed in red tones. As simulation advances, all the regions turn darker. Darker cells correspond to districts with more cases of contagion. Additionally, the authors validated the model and calibrated all the configuration parameters (e.g., virulence and recovery rates) to reproduce the effect of the COVID-19 disease in Ontario. Simulation results were compared to the reports of the Government of Ontario in these regions from January 1st, 2020, to February 2nd, 2021 for validation and calibration. The structure of Cadmium allowed us to reuse the model for exploring multiple scenarios by just modifying the JSON configuration file, improving the experimentation phase.  Figure 14. GIS visualization of simulation results for asymmetric Cell-DEVS models.

Conclusions
Cellular models provide a simple means of describing the behavior, dynamics, and structure of natural systems with spatial features. While the classic Cell-DEVS formalism presents advantages over other approaches (e.g., discrete-event nature, performance, or ease of integration with other simulation, visualization, and analysis tools), it is not able to effectively model scenarios with irregular topologies. This issue makes modeling scenarios based on real geographies a complex and inefficient task. Furthermore, if relations other than spatial are needed to be considered (i.e., closeness, friendship, political opinions, or other social aspects) classic Cell-DEVS modelers need to interpret the results of the cellular model accordingly, which is difficult to perceive.
We dealt with these issues by introducing the asymmetric Cell-DEVS formalism, which extends the classic approach by defining the relationships between cells using a graph-based approach. Asymmetric Cell-DEVS combines concepts of CA with metapopulation models to capture the behavior of more realistic natural systems using cellular models. Neighborhoods do not depend only on spatial associations but on an abstract concept called the vicinity factor. The vicinity factor of one cell over another can represent any relationship (e.g., spatial relationship, cultural kinship, or any other spatial relation) and thus allows modelers to define more complex and realistic cellular scenarios. Asymmetric Cell-DEVS is a generalization of classic Cell-DEVS. Therefore, we can still model grid-based cellular models. Its discrete-event nature avoids unnecessary computations by only triggering the state transition function of active cells. Additionally, as it relies on the DEVS formalism, we can easily combine asymmetric Cell-DEVS models with other DEVS models.
We also presented a new version of the Cadmium simulator, which supports the development of asymmetric Cell-DEVS models. It provides an API to develop classic and asymmetric Cell-DEVS scenarios, focusing on the definition cell behavior. This tool is being used for integrating asymmetric Cell-DEVS models with GIS tools, which allows to generate realistic Cell-DEVS scenarios based on actual geography data automatically, providing means for the analysis of simulation results using advanced visualizations.