Alternate UI for Mesa -- maybe we should reach out?

[jackiekazil]

RE: This paper --

N. Smirnov and S. Tomforde, "Navigation Support for an Autonomous Ferry Using Deep Reinforcement Learning in Simulated Maritime Environments," 2022 IEEE Conference on Cognitive and Computational Aspects of Situation Management (CogSIMA), 2022, pp. 142-149, doi: 10.1109/CogSIMA54611.2022.9830689.

The built their own UI

I wonder two things --

1. Did they know about mesa-geo?
2. Is there something that they needed that mesa-geo didn't have OR was it too difficult to figure out?

I am wondering if it would be worth reaching out and exploring more.

[wang-boyu]

This is an interesting application, and looks like a lot of work to rewrite a desktop gui app!

Let me email and ask them the questions we have.

[jackiekazil]

Can you add me to the email?

[wang-boyu]

Sure, will do.

[gehirndienst]

Hi there!

I'm the main author of this paper and I've already answered these questions to Boyu by email. But I'll post my answer here as well in case someone is interested in it.

First question short: yes
Second question long:

1. Coordinates transformation. I had a following scenario: all my computations were in a plane world and then the results were translated with the UTM to the spherical coordinates to calculate lat/long. So for the end-user everything happened in lat/long, whereas actually in Cartesian projection. That helped to make simulated computations consistent as they use Runge-Kutta method underneath and at least a bit more realistic in the context of a ship motion model. Since mesa-geo uses pyproj and all the complex stuff with geopandas I found much easier back then to use that simple module to do my coordinates transformation and have therefore a generic class of Point, which could be switched to Cartesian/spherical coordinates very easy and fast. Actually now I think it was mostly my personal problem with crs parameter perception, not really the mesa-geo problem.

2. Absence of physics. Since I needed to test collision detection and avoidance using a real ship motion model and more or less a realistic shape, the absence of 2D physics was a critical factor for me. I use that module to implement simple 2D physics and found easier back then not to extend mesa-geo but write my own classes. Actually I believe that won't be much of a problem to bring some 2D physics to mesa-geo, but I was very limited with a time back then.

3. Visualization. I found it simply bad, sorry, so I have implemented my own GUI in Tkinter, a very lame one of course as you may see from the OP post :-) but I needed a feature to draw the trajectories of my agents in real time, while also having widgets like this one to print the current agent parameters in a nice way. Actually I think Tkinter's instruments are not well enough to draw complex things in real time, if you have a swarm of agents, I guess my red line was between 50 and 70 agents, crashes and freezes are a common observation. So I implemented my own GUI and therefore I needed to enrich my base classes like Agent or Model with some useful fields to use them back in GUI. Once again I found it easier to implement my own classes rather than extending the mesa-geo ones.

Nevertheless I have chosen mesa after a review of existing solutions for modelling an agent-based environment in different languages, so I believe mesa is the best existing solution for a fast simulation prototyping, especially if your agents are not complicated themselves and do not use BDI model or something like that. And mesa-geo extension should be included in mesa by default, because the presence of GIS support was one of the key factors of choosing mesa. Yeah, I made finally my own implementation, however mesa-geo served as a perfect source for inspiration.

[rht]

Whoa! I wonder if for point 1, we can have a huge speedup if the computations are implemented in Cython.

Nevertheless I have chosen mesa after a review of existing solutions for modelling an agent-based environment in different languages

I assume you have looked at Agents.jl. What do you think of it for your specific use case?

[gehirndienst]

I needed to integrate my ABS with an OpenAI Gym Environment to apply Deep Reinforcement Learning algos, which aim to control my agent(s) in a simulation. So the main criterion for an ABS framework was the following: either it should be in python or it could be not in python but at least it should be in a well-known language and it should have extraordinary features to make it worth to implement inter-process communication with python. Since Agents.jl is implemented in a quite exotic language (for me), it was rejected.

[rht]

I see.

Regarding with visualization and GUI, we were wondering if reimplementing everything in React will make things more easily extensible in general (see this PR). With your use case, you want real time updates of huge number of agents. What is lacking in the current Mesa-Geo GUI?

[jackiekazil]

Thank you! This is quite informative. I was thinking of integrating with OpenAI Gym env as well -- i wonder if we could do something standard around that.

[gehirndienst]

@rht

What is lacking in the current Mesa-Geo GUI

for we it was important to draw real time trajectories to understand how good the "intelligence" of my agents in terms of formed trajectories is and at the same time it was important to have a handy real time observation of tons of parameters of my target agent.

@jackiekazil

I was thinking of integrating with OpenAI Gym env as well

I guess this is a very desired feature taking into account the exponential growth of interest in (D)RL and mesa can profit from it being implemented in the same language.

I did this integration for this article and this was actually one more point to have a python-implemented visualization to elaborate render method of Gym class. My idea was very simple, I just injected the Model instance into my custom Gym environment and trigger its step method inside the step method of Gym environment. Then I wrote a wrapper, which builds the environment from Model object and optionally instantiates a GUI object and also take several DRL parameters and then controls the execution. Instantiating my GUI allowed me to have an option to add a "pause" button and therefore pause and resume my simulation from GUI. I can also pause at any iteration and extract my current target agent's parameters as .csv file from GUI.

[wang-boyu]

Posting my email reply to Nikita here as well:

1. Coordinates transformation: Yes, I do agree that CRS settings could be very confusing. From a package developer's perspective, I often realized that it is a challenge to balance usability and correctness.
2. Absence of physics: Someone has posted a similar feature request earlier this year: Agent collisions #53. However, although it can be very useful, I think it would be better to have the physics extension separately. First, it is orthogonal to GIS apps, which means it can also be useful for non-GIS usages; second is to avoid unnecessary dependencies, since not everyone needs it.
3. Visualization: Sorry to hear that you did not have a good experience experimenting with it. We will improve this part in our future work. Agent trajectories sound like an interesting topic, and I'll ask around to get the others' opinion.

[wang-boyu]

Have created projectmesa/mesa#1405 for #​3.