Mesa.jl?

[rht]

Do you think it is worth it to make a Mesa-like library in Julia, maintaining the familiar APIs?
Example of a library doing it: https://github.com/QuantEcon/QuantEcon.py (reference implementation), with https://github.com/QuantEcon/QuantEcon.jl.

[Corvince]

Someone started a port a few months or maybe even years ago. I think it was named black mesa, but I can't find it anymore right now.
There is also the excellent https://juliadynamics.github.io/Agents.jl/stable/, so I don't see the imminent need for another abm library on Julia.

That said I don't think there will be any resistance if you want to port it!

[rht]

Their benchmark claims that Agents.jl is significantly faster than Mesa, with fewer LOC. Sounds very promising. People could be migrating to Julia for ABM instead of Python.

I'm still investigating why they have fewer LOC, while at the same time porting a subset of Mesa just enough to be able to run the forest fire example.

[rht]

Ugh! The benchmark is not fair.

The Mesa code for forest fire includes data collection (see https://github.com/JuliaDynamics/Agents.jl/blob/4bf56d853cdaa47db8416ab92271d2dedfc499ff/benchmark/compare/Mesa/ForestFire/model.py#L63).
When I ran the benchmark as is, I got:

Mesa ForestFire (ms): 1050.3123858943582

When I commented out all the data collection lines, I got

Mesa ForestFire (ms): 760.3026318829507

The Agents.jl implementation of forest fire contains no data collection at all: https://github.com/JuliaDynamics/Agents.jl/blob/4bf56d853cdaa47db8416ab92271d2dedfc499ff/src/models/forestfire.jl.
This is what I got for running on my laptop:

Agents.jl ForestFire (ms): 32.785682

Which is definitely hard to beat.

Regarding with LOC, another reason why the Mesa version is longer is because of the boilerplate line like self.pos = pos, the code for data collection, and the wrapper for step() to include data collection. If all of these are addressed, I think the LOC is comparable to Agents.jl.

[rht]

Also, since the Mesa benchmark code is copied/derived from Mesa's exmples/ code, there should be an attribution somewhere in Agents.jl repo.

[rht]

JuliaDynamics/Agents.jl#388

[Corvince]

Great, it is already merged! The comparison is definitely motivating for optimizing mesa. Not necessarily the performance, which will be impossible, but also the LOCs (although, as you have shown, not the best metric).

[Corvince]

Further unnecessary code in ForestFire:

    # unused agent method
    def get_pos(self):
        return self.pos

        # unnecessary attribute settings
        self.height = height
        self.width = width
        self.density = density

Just on a first look!

[rht]

Not necessarily the performance, which will be impossible, ...

Python may not be able to outrun Julia, but Mesa is even slower and more verbose than NetLogo in the outdated benchmark.

[rht]

#981

[rht]

self.density = density

This line is necessary.

[Corvince]

self.density = density

This line is necessary.

Why/how? Maybe I just don't see it, but it would be very helpful if you could explain your comments a bit more

[rht]

Ah, never mind. Yeah, density is only used for the TreeCell placement. I will remove the 3 unused params initialization from the example.

[rht]

I removed them in #981

[rht]

From https://juliadynamics.github.io/Agents.jl/stable/#Comparison-with-existing-software

Agents.jl was originally inspired by the Mesa framework for Python, but has since then departed in design, leading to a dramatically simpler and cleaner API, ...

[rht]

Maybe @Libbum can explain a few of the design choices? There is stuff like the dict of agents lives in ABM struct in Agents.jl, while the dict lives in a scheduler in Mesa, but this is not crucial; I am still reading the code of Agents.jl. The slight naming differences of the functions are also not crucial.

Maybe the API simplifications can be incorporated into Mesa?

[Libbum]

Hi all!
So I've just taken over as lead dev on Agents.jl as of v4.0. Have been assisting since about v2.4.
My understanding is that v1 was mostly a Mesa clone and once it became a part of JuliaDynamics, started to diverge in some ways. Explicitly how though I'd really need to take some time on that to get you a decent answer, since I've never used Mesa personally. (I know how everything has changed, just unaware whether those changes are related to the Mesa design or not)

The benchmark files you're actively working on now and comparisons you see in our table in the documentation were completed by the original author who has now left the project.

That being said, I'm very happy to work with you on improving what we can together, for both packages and ABM frameworks in general.

One thing I know is a problem in terms of speed for Mesa is your continuous space. The way we (and MASON) manage this is we actually operate on a grid for neighbour searches etc, so we don't have to do a bunch of vector calculations to everyone in the space, just those in grid cells covered by some radius.

[jackiekazil]

I am catching up, but I wanted to say that I love everything about this thread and everything that came from it including the dialog that has started with @Libbum.

[tpike3]

Closing discussion linked to optimize continuous space module #993

[rht]

Why is the issue closed? Continuous space is not the only point in this design discussion.

[tpike3]

@rht Sorry, I closed after the dev meeting discussion. The larger goal was to transition from a comparison to julia to actionable issues to take as Mesa transitions to GitHub discussions.

Please, feel free to add more action items to the issues list from this discussion. (Can we just transition this to discussions??)

[rht]

Did you mean GitHub Discussions? It isn't enabled yet. #987

[rht]

@tpike3 can you leave this issue open until the Dicussions is enabled?