Project Topics
Get Complete Project Material File(s) Now! »
Integration in the GAMA platform
A proposal about models coupling needs to rely, somehow, on at least one im-plementation in an existing programming or modeling environment, effectively used by modelers, otherwise it is bound to remain a pure conceptual exercise. In his survey [75], Kravari compares 24 modeling platforms using different criteria: usability, operating ability, pragmatics, security management and ap-plication domains. According to the latter, which is an important criterion for modelers and an indication that it can be usable for building interdisciplinary projects, GAMA is today the platform used in the widest variety of domains (in-ternal numbers, obtained from the developers, estimate its user base at around 2000 to 3000 users). It extensively supports data-driven models, creating agents from almost any data sources, including spatial databases, and supports the sim-ulation of large models (up to millions of agents with complex behaviors).
GAMA is built around a dedicated high-level agent-oriented language (GAML), which sports a clean and simple syntax that makes it accessible for modelers who may have difficulties in programming in conventional languages like Java or C++. GAMA is also built as an extensible open-source platform that allows modelers to develop new features and functions, in Java, to satisfy their needs if they are not yet available. All these characteristics made it the ideal candidate for implementing and testing a model coupling architecture.
Implementation
My approach mainly consisted in enriching the GAML language in two direc-tions: (1) by allowing a model to reference other models as micro-models (and not as regular imported models); (2) by allowing these references to be instanti-ated as agents. Although the result seems like a small addition to the language, it has required a lot of under-the-hood efforts, which are detailed below. I firstly had to alter the existing meta-model of GAMA (depicted in Fig-ure 3.3 [76], [77]), which was a “traditional” agent-based meta-model supplied with a less traditional multi-level extension allowing to declare agents as com-positions of other agents. The first addition, conducted together with my PhD supervisor (one of the main designers of the platform), consisted in clarifying the status of models and simulations in GAMA, by making the meta-class of models inherit that of regular agents. In that way, models acquired a status equivalent to that of species in GAML (and similar to classes in object-oriented approaches), and their instances, called simulations, became regular agents. The second modification consisted in clarifying the role of experiments in the meta-model: initially, experiments were designed to behave like “main classes” in Java, a set of specifications for building instances of models, with different pa-rameters, outputs, etc. I reinforced this role by making experiments the manda-tory access points to imported models (so as to preserve their encapsulation) and, since experiments are also agents, the only possible representative of a micro-model in a co-model. Declaring and instantiating a micro-model then consists in creating an instance of one of its available experiments (which in turn can give access to the instance of model it is encapsulating).
Toy model description
The example I use in this chapter is a classical toy model (called “Prey-Predator co-model” in the following). This model attempts to describe the dynamics of two populations part of a simplified food chain: a population of “preys” composed of simple individuals wandering around and looking for “resources” in their environment, and a population of “predators” that feed on the preys. The reproductive success of each population is dependent, as it is classical in this family of models, on the ability of its individuals to find enough food to survive. This model relates to a wide literature, in computer science, economy ([78]), ecology ([79]), or sociology ([80]), etc. but the goal of this particular implementation is neither to be realistic nor to bring new findings, just to serve as a demonstration of the co-modeling approach.
Toy model implementation
I take the hypothesis, in this example, that we are in a fairly classical situation: on one hand, there exists a model that describes the dynamics of a population of animals, situated in an environment where they can feed on some resources; plenty of similar models exist in the literature, but we chose to implement a deliberately simplified one for the sake of the demonstration; on the other hand, we have another model, completely independent from the first one (it could have been designed by other modelers), that describes two populations of animals: preys, which are supposed to be “available » and their predators. Both models can be experimented, studied, calibrated with respect of real data, and used for their own purposes (i.e. depicting the dynamics of their respective populations). The goal of the exercise is, then, to build a third model with a slightly differ-ent purpose: understanding the combined dynamics of two populations, one of preys and one of predators, each of them feeding either on environmental resources (preys) or preys (predators), like a short and simplified food-chain.
The animal-resource model
The first model, which I will call “animal_resources », is then composed of a population of preys that move around in a shared environment and hunt for its resources. Preys are supposed to follow some random walk, avoid other agents (whichever they are) and consume resources when they find some. Each move costs them some energy (we suppose they have some), each consumption of resource adds to it. When the energy is below a certain threshold, they die; above a certain threshold, they give birth to a new prey with which they share equally their energy.
Such a model is very easy to implement in GAMA. Since any model defines, by default, a “world », we give this world two behaviors: at initialization, to create animals and, at every step of simulation (in a so-called reflex), to cre-ate some resources. By default, all these created agents are placed randomly in the world. Animals belong to a specific species (the equivalent of a class in GAML) called animal, which is decorated with a skill called moving. This provides its instances with default displacement behaviors (like wander, goto, follow, etc) that can be parametrized if needed (with a speed, a target, etc.). We also provide animals with three perception functions: resource_perceived (if a resource can be seen in the world), resource_available (if one can be eaten), and animal_around (if any agent, including other preys, is present). Each of these functions is tested at every step of the simulation and leads to a possible behavior: moving towards a resource, eating a resource (which takes the form of “killing it and adding some energy”) and fleeing randomly to avoid others. Resources are also represented by agents, but they don’t do or know anything (hence their “empty” definition). Note, at the end of the definition, the “exper-iment Simple;” statement. Experiments are, in GAML, the way to instantiate and run the simulations of a model. They are used to setup their parameters and define their outputs. Multiple experiments can be defined for a given model.
The prey-predator model
The second model represents similar dynamics, but this time between two “mo-bile » populations, respectively called predator and prey. Both move randomly and predators are opportunistic: whenever they are close to a prey, they eat it (they could of course have more sophisticated behaviors). In order for predators to know which agents they can still “eat », this model maintains a list of avail-able preys (every time one is eaten, it is removed from this list by its predator). And it creates, from time to time, some preys (since these ones do not repro-duce). Nothing too extraordinary, then, in this model, except that it is of course possible to define displays (like the one on Figure 4.1) in order to follow what is happening.
Step by step co-modeling the prey-predator co-model
Step 1: The co-model is declared as any other model, with the exception that it imports now the two previous ones as micro-models and provides them with a unique identifier:
1 model coupled.
3 import « animal_resource.gaml » as Preys.
4 import « predator_prey.gaml » as Predators.
Step 2: Like we instantiated animals or predators in the previous models, we can in-stantiate models. The only difference is that a model can only be instantiated through one of its experiments (in our case, both micro-models have only one, called “simple »). This step will create one instance of each model, which will now be components of the co-model’s simulation and, most importantly, inhabit its “world » (with its own spatial and temporal scales, which will then become the spatial and temporal scales of the two micro-models).
Step 3: Micro-models can behave in their new world like any agent. To ask them to execute one step of simulation, we just need, literally. . . to ask them. Their attributes, actions become accessible to the co-model. ask [Preys.simple, Predators.simple] { do _step_;}.
Step 4: However, asking the two micro-models to execute their steps will have them run in parallel, like two different models, which is not exactly what we intended to do. So the last step required for building a co-model consists in defining the “glue » between the micro-models, i.e. the coupling mechanisms: what in-teractions and exchanges of data are necessary to couple the models? In our current example, the coupling mechanism is simple: we need to substitute the preys of the second micro-model by the animals of the first one to create a food-chain linking predators-preys/animals-resources. This sentence translates into the GAML code below, within the reflex. Each step of a simulation of a co-model consists in: (1) emptying the predator-prey of its prey agents (in case some are still alive); (2) tell this micro-model that its available_preys is now the population of animals of the animal_resource micro-model; (3) ask the two micro-models to execute one step of simulation.
Transformation of the Switch model into a co-model
The Switch model uses a tilting mechanism based on the number of susceptible and infected individuals. When the density of the population is high, it switches to the EBM and switches back to the ABM when the density is low. This mech-anism is fundamentally a mechanism of “coupling”, with the drawback that the micro-models considered are directly implemented in the Switch model and cannot easily be replaced (for instance other SIR-based representations, involv-ing different hypotheses, different datasets, or other behaviors for individuals). A transformation of this model into a co-model has then been handled in or-der to (1) increase its flexibility; (2) clearly separate the concerns between the representation of the disease (SIR models) and the coupling mechanism; (3) of-fer the possibility to reuse this coupling mechanism for other models sporting different representations.
Dynamics of co-model
In the co-model resulting from the transformation, all the concepts, work flows and algorithms presented above are kept intact. Just a small change needs to be done regarding the declaration of the micro-models. A micro-model is not anymore a species that inherits from a SIR_model, but rather a whole model (for example a legacy model belonging to a set of library models) which is accessible through an interface named xxx_wrapper. The interface is only com-mitted to provide accessors, such as get_num_s, get_num_i, get_num_r, and set_num_s_i_r. As long as it can be imported and manipulated by the wrap-per, the legacy model can be a black-box model using whatever formalism or paradigm the modeler needs. The co-model just needs to ask, through this in-terface, the legacy model for the current values of S, I and R and, once it has computed the size of the population using an appropriate model, to return this number to the imported model.
Table of contents :
0.1 Acknowledgement
0.2 Abstract
1 Introduction
1.1 Context
1.2 Motivations and Research questions
2 STATE OF THE ART
2.1 Why coupling models ?
2.1.1 Model
2.1.2 Models Coupling
2.1.3 Advantages of coupling
2.2 Different kinds of coupling
2.2.1 Weak coupling
2.2.2 Strong coupling
2.3 Challenges of model coupling
2.3.1 Reusability
2.3.2 Scalability
2.3.3 Expressivity
2.3.4 Flexibility
2.4 Existing solutions in modeling/simulation
2.5 Conclusions
3 CO-MODEL: AN INFRASTRUCTURE FOR SUPPORTING THE DYNAMICAL COUPLING OF HETEROGENEOUS MODELS
3.1 Introduction
3.2 Basic concepts
3.2.1 Co-model
3.2.2 Micro-model
3.3 Integration in the GAMA platform
3.3.1 Why GAMA?
3.3.2 Implementation
3.3.3 Portability
3.4 Example of use (syntaxes)
3.4.1 Importation
3.4.2 Instantiation
3.4.3 Execution
3.5 End of chapter
4 Demonstration and usage
4.1 Objective
4.2 Toy model description
4.3 Toy model implementation
4.3.1 The animal-resource model
4.3.2 The prey-predator model
4.4 Co-modeling
4.4.1 Step by step co-modeling the prey-predator co-model
4.5 Discussion
4.5.1 Reusability
4.5.2 Expressivity
4.5.3 Scalability
4.5.4 Flexibility
5 Dynamic choice of the best representation of a phenomenon
5.1 Objective
5.2 Modeling context
5.3 Definition of micro-models
5.4 Transformation of the Switch model into a co-model
5.4.1 Dynamics of co-model
5.5 Conclusion
6 Incremental design of a complex integrated model
6.1 Objective
6.2 Modeling context
6.3 Definition of micro-models
6.3.1 Farmers behaviors model (M_F)
6.3.2 Salinity intrusion model (M_S)
6.3.3 Parcels model (M_P)
6.3.4 Economical model (M_E)
6.3.5 Farmers relationships model (M_N)
6.3.6 Summary on the micro-models
6.4 Impact of environmental factors on farmers’ decisions
6.4.1 Implementation
6.5 Coupling of Farmer and Socio-Economy factors
6.5.1 Implementation
6.6 Coupling environmental, social and economic models
6.6.1 Implementation
6.6.2 Experimentation
6.7 Conclusion
7 Conclusion
