SPADE vs MESA vs JADEX?

[mmea...@gmail.com]

I am starting work on an ABM for a complex supply chain/value network and I am trying to decide between several alternatives, none of which appear to be sufficient. 

Mesa

Pro: Nice integration with Javascript so I can do the nice D3 models for showing output

Pro: In Python, not Java.

Con: No support for Belief-Desire-Intention (BDI) reasoning by agents

Con: No agent to agent exchange mechanisms (doesn't have to be FIPA compliant but it would be nice)

SPADE: (https://github.com/javipalanca/spade)

Pro: Supports FIPA transports

Pro: Supports BDI

Pro: Python not Java

Con: Hasn't been updated since 2013

Con: Not ready for Python 3

Con: No UI or data visualization to speak of

JADEX (or any of the other Java based ABM systems):

Pro: Supports FIPA transports

Pro: Supports BDI (and does it well)

Pro: has support for large numbers of agents through massively parallel systems on the JVM

Con: Java

Con: Eclipse

Con: Overly complex. Like most Java applications it took a week to get it completely configured.

One part of me thinks I can pull the BDI and messaging transports out of SPADE and shove them into Mesa. Or I go the other way and build an API on top of SPADE so I can visualize the agent states in the browser. Another realizes most of this exists in JADEX so just suck it up and deal with Java's complexity.

So, Mesa, what should I do?

[Jacqueline Kazil]

You are talking to a generally bias crowd on this list. :-D

But I would tell you how I would approach this, I would ask myself the following questions... 

* What is your timeline?  

     * How much work would each of these require?

* What is your end goal? 

     * To make something and move on?

     * To make something and maintain it?

     * To make something and give back to the community so that others can use it?

* What is documentation like? / How hard is it to build a model? 

When I choose to use a library in whatever language, I usually choose it based on its potential and future trajectory, unless I know that the work that I am doing is for throw away purposes ---  For example, in another project I worked on part of what I had to do is to general pptx files. This library generates pptxs using python has 13 pull requests -- https://github.com/sc anny/python-pptx, But the java version is well developed and stable. Because I know that I won't be generating pptx for long, I used the java version in a python project because it was a means to end. However, it I wanted long term sustainability, I would have reached out to the pptx owners and offered to maintain OR built out my own version if that didn't go well. 

^^ The last sentence is basically what happened with Mesa. Interestingly I never contacted the Spade owners, because I didn't know about spade, but we contacted PyABM, Indra & a few others (don't bother looking at those, they are not what you are looking for.)

Mesa believes is community contributions and if there is something that you think could be added to improve core Mesa, you can submit a pull request. Contribution guidelines are here: https://github.com/projectmesa/mesa/blob/master/CONTRIBUTING.rst. If we don't think it belongs it core Mesa, but as add-on, we can discuss what that means and how to maintain --- for example a geo-mesa or mesa-gis would be a library that wouldn't go into core, because not everyone needs it and GIS stuff can be difficult to set up. 

Mesa generally believes in decoupling as well -- at one point we talked about decoupling the visualization into another library, but never got around to it, because there are only so many of us working in our spare time on the project. 

In conclusion... tl;dr

- If this is a longer term commitment, use to Mesa & help built on it, so the fruits of your labor is not lost. 

- If this is a short term commitment, then do whatever helps you get shit done the quickest, so you can get on with the actual research portion and other things life. (This might be Mesa, but only you know the answer to this one.) 

-Jackie

 

--
Project repos: github.com/projectmesa
---
You received this message because you are subscribed to the Google Groups "ProjectMesa" group.
To unsubscribe from this group and stop receiving emails from it, send an email to projectmesa+unsubscribe@googlegroups.com.
To post to this group, send email to proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectmesa/148ebfda-8606-49ce-a10f-121d69415c76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jacqueline Kazil | @jackiekazil 

[David Masad]

I'll just add one more thought there -- based on your priorities, how important to you is having a built-in BDI implementation? If the specific ways in which agents make decisions are (a) complicated enough that you'd rather not model them using simple rules, and (b) not interesting enough to what you're modeling for you not to *need* to model them yourself, then having a premade BDI system is a big advantage. On the other hand, if your agents are simple enough that you can model their decisionmaking directly, using a BDI system just adds an unnecessary layer of complication to your model.

To unsubscribe from this group and stop receiving emails from it, send an email to projectmesa...@googlegroups.com.

To post to this group, send email to proje...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/projectmesa/148ebfda-8606-49ce-a10f-121d69415c76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

Jacqueline Kazil | @jackiekazil 

--
Project repos: github.com/projectmesa
---
You received this message because you are subscribed to the Google Groups "ProjectMesa" group.

To unsubscribe from this group and stop receiving emails from it, send an email to projectmesa...@googlegroups.com.

To post to this group, send email to proje...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/projectmesa/CAKD0ODzV6qSuBQg5snGv0yeR7%2BXfagrmqgz7ftvwFeUi8J8vDA%40mail.gmail.com.