Mesa is an agent-based modeling framework in Python 3. It was created in 2014 to make building agent-based models in Python easier, but also to seed an ecosystem of reproducibility. The framework provides building blocks both on the front-end and back-end for you to build a model easily. The architecture focuses on being decoupled and extensible, and the creators encourage you to share model components to push the domain of agent-based modeling forward.
Thanks Jackie. This is an interesting presentation. I am not a Python programmer but I understand that Python i more suitable compared to other languages used by ABMers, to run the model in the browser and to containerize models. As such Mesa might be the platform for the future of ABM ;-).
I am poking some comses members who have used python for ABM to see what they think about Mesa (@jma@acardona@furtadobb@azvoleff).
This has convinced me that I need to get Python 3 and try this out in the near future. As one of the GRASS GIS dev team members, this looks like it has a lot of potential for integration with the powerful geospatial tools of GRASS–and much of GRASS uses Python. I encourage you to take a look at this and let me know if you have questions about GRASS. Michael Barton
@cmbarton, awesome to hear that! I have seen GRASS before, but I have never played around with it. The only GIS integration that has been done with Mesa is mesa-geo (https://github.com/Corvince/mesa-geo). There is no geo-pandas integration, but a few folks have been talking about getting geo-pandas integrated into that as well. Let me know if you do anything with GRASS and Mesa.
Dear Jackie,
Thank you for your clear talk. I like the idea of reusability.
Just one question: for the 3rd scheduling feature, you explain that the user can choose “simultaneous activation (simulating them all being activated simultaneously)”. I imagine that you associate 1 thread per agent. But in that case, how Mesa manages the interactions between agents ? Or competition for a shared resource?
Thank you
While core GRASS libraries and modules are written C for fast execution, GRASS has a sophisticated GRASS Python library and interface to both low-level (via ctypes) and high-level functions. Many GRASS modules are Python scripts that call the C libraries or modules. All GRASS functions/modules can be executed from the SHELL, making it it highly scriptable. You can find more information at: https://grasswiki.osgeo.org/wiki/GRASS_and_Python
The main GRASS website is at http://grass.osgeo.org, a member of the OpenSource Geospatial Foundation.
I’d love to see a Python package like Mesa have an option to connect with GRASS for geospatial ABM.
Definitely an interesting work. I study on ABMs, but not a Python programmer. I wonder is it easy to use? and its advantages when comparing with other popular ABM platforms, like Repast and NetLogo? Nevertheless, thank you for your sharing.
As a possibly experienced Python programmer I’ve started looking at building models in Mesa and so far I’ve found it to be quite idiomatic and well-designed (albeit in an OOP / imperative style). As you become more familiar with Python I think you’d find its abstractions sensible and straightforward but of course that’s highly subjective. I’m also a fan of the browser GUI.
Another significant side benefit of a Python ABM framework is the rest of the scientific Python ecosystem directly available to your ABM code. Not to diminish the quality of scientific libraries in other languages but the community & support for the scientific and numerical libraries in scipy, or machine learning libraries whether low-level like TensorFlow, or higher level like scikit-learn or Keras, is quite stellar.
Access to a variety of useful computational techniques in your ABM code is a great thing - you can leverage and reuse the work of others if for example you need to do GIS, data cleaning / transformation (pandas), or experiment with machine learning techniques in your models.
All that said, there are a variety of great ABM tools and communities as evidenced by these talks and finding the appropriate tool for your particular research questions and needs will depend on your own local context .
The code for simultaneous activation does not touch threading, but ‘freezes’ the state of the model and then had all agents execute on that frozen state. Here is the specific class that does that. It is a super light read.
Let me know if you have more questions.
It would be an interesting thought experiment to introduce threading and to research the impacts of it… maybe publish something.
N.B. The danger with threading is that it often leaves scheduling decisions up to the operating system, which leads to results that are arbitrary, but not necessarily random in any useful way – and likely biased by specific optimizations that an OS may have chosen. I doubt that using separate threads for agent scheduling is a good idea for reproducible scientific modeling. Also, because of Python’s GIL (Global Interpreter Lock), you may not get as much of a performance boost from multi-threading in Python has you’d hope… although I guess that situation got better with Python 3… anyway, I digress. The frozen state approach MESA is using sounds very useful (e.g. for cellular automata models, among others), provided that performance is decent.
Speaking of performance, have you done any benchmarking to compare Mesa model execution speed with other platforms like NetLogo or Repast? (I tend to think of interpreted Python as being perhaps 20x slower than pure Java code, but I know that there are libraries and tools for partially-compiling and optimizing Python…) I was part of the NetLogo team when we were trying to compile certain language features down to JVM bytecode to squeeze better performance out of the system, to better compete with plain Java code.
Overall, I like Python, and I think that Python’s huge ecosystem of data analysis and visualization tools could make it an appealing language to write ABMs in, for easier integration with data import/export and graphical exploration.
.