My presentation at Cafe MTD on 13 February 2024

1. Oleksandr ZAITSEV
Café MTD — February 2024
oleksandr.zaitsev@cirad.fr
CIRAD, UMR SENS, Montpellier, France
Cormas: Modelling for Citizens with Citizens
Building accessible and reliable ABM software

2. 2
Plan
Participatory agent-based modelling (ABM)
and Cormas platform
1.
Software engineering and ABM
2.
Related applications for interaction and
accessibility
3.

3. Agent-Based Modelling
Part 1:

4. 4
Which Queue to Choose?
Real world Model

5. 5
Your Own Little Lab
Test theories, explore interactions …

6. 6
« Conventional » Modelling
Local stakeholder
(e.g., farmer)
Researcher Policy maker
(makes decisions)
data knowledge
Local stakeholders are only contacted for data collection

7. 7
Participatory Modelling
Researcher
…insights…
Local stakeholders are involved in every step of modelling: data collection,
model building, model exploration
Local stakeholder
(e.g., farmer)
Policy maker
(makes decisions)

8. 8
Participatory Modelling
Oleksandr Zaitsev © Cirad Oleksandr Zaitsev © Cirad
Iteratively co-designing a model together with local stakeholders

9. 9
Cormas Platform
✓ Multi-agent simulations
✓ Developed in 90s at UMR SENS (Green)
✓ Based on years of field experience
✓ Well-suited for participatory modelling
✓ Implemented in Pharo - live programming
language with immediate feedback

10. 10
Unique Features of Cormas
… that make it well-suited for participatory modelling
👀 Different « Points of View »
🎲 Live dynamic environment where everything is an object
⏰ Stepping back in time
Observe a simulation from different perspectives at the same time
Interact with anything at any time without stopping the simulation
Move back the time, change conditions, continue on alternative path

11. 11
Different « Points of View »
PoV 1: Grass PoV 2: Water

12. 12
Inspect and Control Agents

13. 13
Stepping Back in Time
Not yet supported in Pharo version

14. Part 2:
Software Engineering & ABM

15. 15
Common Mistake
People think of software as a static thing that can be built and then used
📝 Step 1: Specification
🔨 Step 2: Implementation
🧐 Step 3: Validation
💰 Step 4: Operation
« We know what we want. So we will
hire a developer to build it for us,
and then we will use it forever »

16. 16
Software Has to Evolve
Every software is a living system that is changing as long as it is alive (used)
Factors that force us to change:
(1) Client requirements
In most cases, as long as
somebody uses the software,
they will ask for new features
or bug fixes
(2) Changing environment
Every software is executed on some computer,
in some environment and OS, it has some
external dependencies — those things change

17. 17
Software Naturally Deteriorates
We can not stop it, but good practices help us slow down this process
time
failure
rate
change
ideal curve
actual curve
Every new feature increases the size
and complexity of software. It
becomes harder to manage and more
prone to errors.
Even if no new features are
added, dependencies break,
developers leave, etc.

18. 18
Software Testing
without tests
with tests
time
effort
(cost)
Testing takes discipline but it pays off in a long run
Writing tests takes a lot of time that
could be spent adding new features
Having tests early in software lifecycle
😤
Having tests later in software lifecycle
The cost of modifying software does
not grow exponentially
Tests help us maintain the quality of
software and be confident that new
features don’t break things
😍

19. 19
Testing ABM
Participatory modelling requires quick coding and prototyping
Published model must remain valid,
reusable, and reproducible
Modelling phase
Post-modelling phase
without tests
with tests
time
effort
(cost)
In participatory sessions, speed and
simplicity are the key factors
Q: What is the testing workflow for ABM that
would not interfere with participatory practices?

20. 20
Live Debugging Tools
Fix errors without stopping the execution
(1) Browse the
execution stack
(3) Edit the
source code
(2) Inspect
variables
(4) Resume the
execution

21. 21
Debugging ABM
Modellers may ask different debugging questions than other developers
Have to deal with many live objects
that have autonomous behaviour
and can cause strange phenomena
Models are usually small and
their code is easy to
understand
Software Development Modelling
Developers have to explore
large code bases with many
dependencies

22. 22
Object-Centric Debugging
Put breakpoints on
individual objects;
Observe specific variables
« Halt the execution and open
debugger when Cow (id: 42)
has energy level > 50 »
Apply breakpoints to one specific object instead of all instances of a class
Example:

23. 23
Time-Travelling Debugging
Travel back in the execution stack
Can be combined with the time travelling feature of Cormas to help us
explore unexpected phenomena in the simulation by stepping back
through the actions of individual agent

24. 24
Summary
Software evolution in the context of ABM
Q1:
Do the principles of software evolution apply to agent-based modelling?
Testing ABM
Q2:
What is the testing workflow that would allow us to ensure correctness,
reusability, and reproducibility of ABM while doing participatory modelling?
Debugging ABM
Q3:
How is debugging ABM different from debugging other software?
What specialized tools do we need to debug ABMs?

25. Part 3:
Related Applications

26. 26
Two Research Directions
Tangible Interaction
Topic 1:
Collaborative Modelling
Topic 2:
Can we help stakeholders to build and control models through physical interaction?
Can multiple people interact with the same model simultaneously with different PoV?
… to improve interaction and accessibility

27. 27
Topic 1: Tangible Interaction
Can we help stakeholders to build and control models through physical interaction?
Problem:
Caroline Dangleant © Cirad
During the participatory sessions in the
field, it is often difficult to put every
participant in front of a computer and
make them manipulate the model.
Access to electricity
Access to computers
Computer literacy
🖥
📚
⚡

28. 28
Topic 1: Tangible Interaction
Can we help stakeholders to build and control models through physical interaction?
Solution 1: Sensory game board
• Game board can detect the
position of pieces using sensors
• The id of the piece together with
its coordinates are then sent to
Cormas for processing
• Game board can also display
information using coloured LED

29. 29
Topic 1: Tangible Interaction
Can we help stakeholders to build and control models through physical interaction?
Christophe LePage © Cirad
Solution 2: Computer vision
• AI algorithm that detects game
pieces on a table
• Can be paired with simulation
projection that was done with
Cormas (ReHab?)

30. 30
Topic 2: Collaborative Modelling
Can multiple people interact with the same model simultaneously with different PoV?
Fisherman
Farmer Policy maker
Pastoralist
Thierry Brevault © Cirad Patrick Dugue © Cirad Eric Malezieux © Cirad I. Duriez © Cirad
Problem: Farmers think about crops, pastoralists think about cows.
How can we help them understand each other and collaborate?

31. 31
Topic 2: Collaborative Modelling
Can multiple people interact with the same model simultaneously with different PoV?
Solution: One model — many devices.
Different « point of view » and different set of controls
for each participant
Farmer controls the growth of crops.
Pastoralist manages the behaviour of kettle.
Fisherman observes the amount of fish in the river.
Policy maker calculates the expenses.
🐮
🐟
💰
🌾

32. CORMAS
• Tangible interaction through
IoT or computer vision
• Collaborative modelling
based on different « points
of view »
• Allow quick modelling
and prototyping
• Ensure correctness,
reusability, and
reproducibility
• Object-centric
debugging
• Time-travelling
debugging
Debugging ABM
Testing ABM Accessibility
… modelling for citizens by citizens
Modelling environment that is inclusive and takes into account the
nature of its target communities, adapts to their particular needs
and helps them overcome their limitations