Cormas is an agent-based modeling and simulation platform that deals with interactions among stakeholders about the use and management of renewable resources.
The philosophy is to use the platform with people who are not specialist of modeling. The development of the platform seeks to support companion modeling approach - a form of participatory modeling. The aim of the models and simulations built with the platform is to promote a shared vision of the system by taking into account the different viewpoints and concerns.
With Cormas, in 10 years, we want to have more responsive human-computer interactions. We will be able to use interactive gameboards with tangible objects during a participatory simulation, as well as multiple devices in to order to smoothen the way participants interact with a simulation. This will encourage spontaneous behavior, expression of emotions and empathy for more lively and interactive simulations. Collective design using executable UML and software blocks will be important innovations for making model development accessible to non-modeler. Artificial intelligence and high performance computing will be used to enhance hybrid simulation and model exploration. The aim is to be able to change the model and to explore all the possible trajectories of a simulation during the course of a participatory workshop with the stakeholders.
In short, the development of Cormas in the 10 coming years will focus on the meaning of the model and on the interactions among participants.
Video by Pierre Bommel, Nicolas Becu, Bruno Bonte, Etienne Delay and Christophe Le Page
This is a fun video An interesting contrast to some of the other platforms (such a Repast @jozik) who focus on adding more details and resolution to make more realistic simulations, you focus on improving the experience of interactive use of models and games. You mention not to go to 3D simulations. WIth the advanced technologies in the future why not provide the stakeholders more detailed simulations? Could you expand on that?
The sharing of model components is also something CoMSES would like to facilitate more with the updated model (component) library (@abell@dtrobins@alee@cmbarton ). By sharing model components of one platform, this may make it also more convenient to adopt components into another platform (and share both versions of course). How do you envision the future of sub-model / model components, and how you like to share this between models? This is not just a technical issue.
Hi Marco,
Thank you for your comments.
Yes, our objective is not to go towards more realistic simulations. I didnât say that we will never use 3D representations, nor immersion glasses (who knows what the future will be like!). But we do not focus our work on this type of development. We are not necessarily looking for more realism. Why?
Because a model (or simulation) is only an artifact that allows a group of participants to project themselves into the future, but above all to debate the orientations of this given collective.
We must therefore not try to dazzle this collective with high-tech tools, but rather to produce a representation of the socio-ecological system that is transparent and understandable. Our concern is that presenting high-tech tools may overly impress the participants, which would prevent them from questioning the structure of the model and the behaviour of the agents.
The criticism and revision of a model are the very driving force behind a dynamic learning process. From the âKISSâ to the âKIDSâ approaches, we give priority to the KILT approach: Keep It a Learning Tool !
Very enjoyable presentation, thank you for sharing! I like the idea of co-creating a simulation using participant real-world actions - taking ideas from ubiquitous computing or augmented reality to explore the possibility spaces encoded in the model.
For example participants could be given fitbit-like devices to identify them and travel between different stations to perform actions using other RFID tagged objects that change the state of the simulation world in real-time. Or they could put on some google cardboard and interact with each other in the simulation⌠as long as they have a way to avoid bumping into each other in meatspace
That said, I also very much agree with the notions of keeping it simple for model developers so that others (including their future selves) can understand and reuse the model - this is partly an issue of documentation and good software engineering practices but being able to express model code as clearly & simply as possible is a great ideal to share across all model frameworks.
Indeed, ubiquitous computing is a great source of inspiration, and we also try to bring into Cormas some ideas from the simulation and gaming community. Our efforts are currently on tangible objects recognition, to serve as input in the simulation. Somehow, we still have difficulties to integrate a low-tech reliable object recognition system (we aim for low-tech because Cormas users often run participatory simulation workshops in remote areas). We havenât explore yet participants recognition but indeed, using fitbit-like devices could be a good solution. It would be great from a gaming perspective, because it would enable to integrate body language in the simulation.
Interesting. Strong emphasis on interactive modeling seems important for making models and model technology more accessible to a wide audience. Iâd like to hear more about plans for modularity in model components and sub-models.
The bright future of CORMAS! I have been working on building RPGs for several participatory workshops and experienced the potentials and limitations of using game. Some issues have been already mentioned in your video. Based on the lesson learnt, the most cumbersome is the data (playersâ decisions) input and the information (mostly completed in spreadsheet) output for group discussion during gaming session and debriefing after game. The process generally takes too long in particular if the game is quite complex. I have to either replace the game with simulation (most difficult for me to build and for participants to understand) or make the game simpler (not so easy either). Thus, only a wishlist that I have so far is to integrate game-like interface with computing capability in CORMAS (I think it is currently possible) and enable CORMAS to take advantage of high-tech device like a large touch screen computer to replace limited game board (in case of spatially-explicit case) so that players can take actions right on the screen and observe the data input and information output as the game designer planned with short pause. I guess if this is possible, games would be more transparent and playful as well as coding for game might be less complicated than coding for simulation. This way could increase the game flexibility (make some changes) as well.
Thank you and looking forwards to seeing â10 year CORMASâ sooner.
Some reactions regarding a discussion in another thread by @marcojanssen and @boltej between realism and simple model.
As @pierrebommel mentioned some post before, our development effort is highly driven by the KILT conception of modelization formalized in Le Page and Perrotton, 2018. With this approach we want to get out of a polarization between KISS and KIDS paradigms.
What the purpose of a model? As Banos (2010) said (sorry in French), the model/simulation is a crutch for the human mind.
Developing a model as a tool for social learning is distinct from when one uses people as a source of evidence in the form of their expert or personal opinion for a descriptive of explanatory model.
Developing models to support social learning related to environmental management aims at tackling the wickedness of problems such as those encountered in that domain, which are characterized by a high degree of scientific uncertainty and a profound lack of agreement on values (Balint et al., 2011).
Instead of trying to eliminate or reduce uncertainties by collecting more data used to make the model more sophisticated, the post-modern view of science (Funtowicz and Ravetz, 1993) suggests that it could also be useful to try to illuminate these uncertainties (one of the purposes of modeling mentioned by Epstein in his 2008 paper), for their better recognition and acceptance by stakeholders who become then enabled to make informed collective decisions.
So for the Cormas team, having a realistic model or a simple one depends of the model purpose as @boltej said. In most of our modeling situation, models are designed regarding the needs of our partners to empower themselves in order to allow them to take a decision or to be ready to react in certain situations.
Designing simple stylized empirical models to support social interaction , according to the âKILTâ (Keep It a Learning Tool) moto, corresponds to the strategy of maximising the relevance and accessibility of a model so that participants can engage with the model and be willing to help specify or improve it (Le Page and Perrotton, 2018). The âimprovementâ, in such a context, does not necessarily implies a sophistication.
So from my point of view, the debate is more about âwhat we need to formalize in an ABM in order to empower stakeholdersâ. So it recovers all stuff we can do to improve learning process.
Thank you @wnaivinit for your wish list! I would like to share some information about the CORMAS development roadmap. As we said in the video, we are shifting cormas from visualwork to a completely open source platform : pharo maintain by a very active community.
This radical movement is also supported by the implementation of continuous integration and continuous documentation tools support by GitHub (Since the 1st of October (Hacktoberfest 2018), everyone can participate to the cormas development using pull request ).
Jokes aside, with pharo, we can imagine to integers a great diversity of other stacks as, machine learning (in order to agentified some players behaviors in agents for example), or use some server client infrastructure in order to support participatory simulation.
Since virtual reality is a burgeoning technology, do you forsee the use of VR in the future for Cormas? It seems that VR could be especially useful in participative simulations.
Hi
I think we will go for VR if we can use it to stimulate social interactions among participants in a same place (most of the time we conduct participatiry simulation with participants physically present in a same place). My guess would be that immersive room are more suited for face-to-face social interactions than VR.
âŚnext month Iâll be trying an immersive room for the first time
Thank you for your comment. I remember now that I had indeed passionate discussions with Andrew Bell (@abell) about agent-based modelling primitives in Pheonix at CSSâ15. From what I remember from our discussions and reading again the Adrewâs paper in iEMS I think that using the Agent-based Modeling Primitives and Land-Use Modelling Primitive that they propose is a great idea, especially in our community in which we use different platforms that have many similarities. Proof is that we are still organizing each year a common training MISSABMS (Multi-plateforms summer school on ABMS) for the three platforms Gama, Cormas and NetLogo! So I agree that we should use generic descriptions for these primitives and I would be very glad to exchange about that with Andrew et al.
This being said, when we shoot the video, I was actually thinking at something slightly different. I was thinking of implementing in Cormas a discrete event scheduler implementing the paralell Discrete EVent System Specification (DEVS) proposed by Bernard P. Zeigler in order to be able to have modularity in terms of a coupled model composed by the coupling of sub-models. The idea is that at the moment, a Cormas model is though as a whole, and the consistency of scheduling must be designed for the whole system (even though there are of course some basic features available such as cellular automaton framework). By implementing a DEVS scheduler, we should be able to have real sub-models that we can connect together in a âplug and playâ manner.
Of course it is a huge undertaking since it can be heavy to code models in DEVS and thus this way of developing must co-exist with the actual Cormas scheduling system which is much more intuitive⌠And of course, a higher level of model description (such as the unit of numeric input or output variables, etc.) is necessary to describe clearly these sub-models so that end-modellers do not connect these sub-models in an inconsistent wayâŚ
I did not think about it in the first place but reading your post, I think that this could be helpful too in the perspective of sharing models across platforms since it reaquires to specify them with enough details to couple these sub-models to any other sub-model.
If we work well, maybe in 10 years we will have both AMPs and LUMPs coded as modular sub-models!
An interesting contrast to some of the other platforms (such a Repast 
).