simulations generally involve the interaction of different scientific
fields. Human economies, ecosystems or dynamic computer networks are
good examples. Since models and simulators already exist in those
fields, designing the simulation as a
society of interacting models and interacting simulators
appears attractive. Indeed, following that way, we can reuse existing
and well validated models from different scientific fields. Beyond the
conceptual and technical issues to make
the different models and simulators cooperate, a challenge is also to facilitate the design and implementation
of these societies of interacting models and simulators.
Facilitate the design of complex
Coherence between models
A conceptual issue that arise when we
couple several models, is that scales or dimensions in which a piece
of data is represented could be
different from a model to another. Moreover the representation can be
discrete or continuous. As a consequence, in order for two models to
interact (i.e. to exchange data), we may need to take several
operations [Bonneaud] on the data flow.
Compatibility between simulators
A technical issue that arise when we couple several simulators, is that each simulator could implement a
single piece of data in its own way
(integer, float...) or some simulators may not implement all aspects of
a given model.
When executing the models, we must be
sure that local causality constraint is respected [Fujimoto]. Moreover,
as we want to reduce the overhead of modifying both models and
simulators, we propose to avoid the use of a global
scheduler. That is, we want to make coordination in a decentralized way.
A model is a black box with input and output ports [Zeigler00].
We take the assumption that a simulator implements those functions.
||Initialize the model (e.g. set initial parameters, set random seed...).
||Execute the model (one simulation event, one simulation
step, for a given simulation time interval...).
||Return output data from the model output ports.
||Set input data to the model input ports.
||Return the current simulation time.
|Return the next simulation time. Don't need that function anymore (since revision 0.2) see the research report
||Manage the end of the simulation process (e.g. print results, close results files...) [optional].
Agent and Artefacts concepts
We propose to use the Agent and
Artefact paradigm to solve the previous
issues. Please refer to [Ricci08] if you are not familiar with the Agents and Artefacts concepts.
Their role is to manage the
simulation process for a given model
+ to manage the input/output data flows.
Deal with the coherence and
compatibility issues. Posses one input port
(in which a model-agent can post the data to exchange) and at least one
output port (in which a model-agent can read the exchanged data).
Interfaces in order for the agents to
interact on the model (init,
exec, set input, get output).
How coordination occurs ?
We propose to use objective
coordination. That is, coordination does
not rely on a single entity but is provided by the surrounding
environment. This method is well known in the field of situated
multi-agent systems (stigmergy) or in parallel systems (shared memory).
This provides a way to loosely couple and to coordinate the interacting
processes. In our case, the simulators interact through the set of data
they exchange. The simulation algorithm is explained in the research report
My own papers on the subject
Related papers [Ricci08][Zeigler00][Fujimoto][Bonneaud]