DEV SESSION [TUESDAY] 13 FEB -- 2130 UTC+8/1430 CET/1330 GMT/ 0830 EST

[jackiekazil]

Where: via Matrix

Because of some availability issues this month and discussions about trying an alternate / time -- we are going to have the dev session on 13.02 this month. I used the availability that @EwoutH collected for time guidance.

Action items...

1. If there is a strong objection to the time/date? (Not sure we can move it, but also - I want to know who this impacted for future discussions)
2. Please review the times above and make sure I didn't make a gross error. It should be 1.5 hrs later than our normal time.
3. Please share items below that you would like to add to the agenda.

/cc @projectmesa/maintainers

[quaquel]

The time and weekday are fine for me. However, my agenda is fully booked already (I am triple booked at that time slot).

Agenda-wise, I have a few requests:

1. What is the envisioned timeline for supporting cython through GitHub actions? I know @rht started work on this already. Would it be possible to sketch a timeline for this so I can align what I want to work on wrt MESA with this.
2. There are ongoing discussions in multiple places on data collection. @rht has given a good summary in The future of data collection #1944. It would be useful for me if we can concentrate discussions in a single place. How do other maintainers look at this?
3. Envisioned timeline for this year. What are key milestones we want to aim for? Mesa 3 is mentioned from time to time. However, personally, I would suggest flashing out various ideas first through experimental before making them part of the main release in 3.0. Key developments I see are (1) jupyter viz; (2) new data collection; (3) new discrete spaces; and optionally (4) pub/sub; (5) discrete event formalism at the core of mesa.
4. How to better handle backward compatibility and reduce the chance of needing several patch releases. I know I am partly to blame here because I moved the schedulers to AgentSet too quickly.

[rht]

Mesa doesn't do very much at all and any non-trivial model will spend most of its time on user related functions. So I don't see the point if making mesa considerably faster. I haven't seen a model where mesa itself has been the bottleneck.

This was from past discussions, and I still disagreed. This is situation with the current Mesa performance, which I am not satisfied with. Frameworks do shape the way user can implement their models, which can be done in several ways for a speedup:

1. Allow user to specify discrete events scheduling in general (hybrid simulation)
2. Constraint users to use vectorized operations
3. Allow user to write both slow code, and a more constrained code with a structure that can be sped up with @decorator
4. the way hEngine does it, which probably involves compilingtranspiling the agentstep() functions into Rust

[Corvince]

I know we've revisited this topic numerous times, and it's clear we hold different views. However, I'm still waiting for an example where the execution time of Mesa's library code significantly outweighs that of user code. Imagining Mesa functions operating instantaneously raises a question: would this dramatically alter performance? For such an impact, Mesa code would need to dominate 90% of the execution time.

Although I recognize the potential for theoretical applications to shape practical use, I don't see this principle at play here. If it were, we'd observe notable effects with agents.jl, which boasts performance up to two orders of magnitude greater. It prompts the question: are there models feasible with agents.jl that Mesa's performance gap renders impossible?

Regarding the point on writing highly optimized constraint models:

1. Mesa's appeal, in my view, lies in its flexibility to model without constraints, a significant benefit. This flexibility is mirrored in tools like NetLogo, which, despite its constraints, offers a vast array of modeling possibilities as seen in its extensive gallery of examples. While these may not always represent the most efficient approach, efficiency isn't always the primary goal.
2. I'm skeptical about achieving similar optimization in Mesa. The challenge doesn't stem from a handful of resource-intensive functions but from the multitude of minor function calls, making optimization more complex.
3. Nevertheless, I'm open to exploring the potential for optimization within Mesa. If it's possible to enhance performance for certain ABM subsets without limiting the scope of other models, that would be a welcome development.

[rht]

However, I'm still waiting for an example where the execution time of Mesa's library code significantly outweighs that of user code. Imagining Mesa functions operating instantaneously raises a question: would this dramatically alter performance? For such an impact, Mesa code would need to dominate 90% of the execution time.

I am aware of this argument. It's separating the concerns between Mesa-specific functions and user functions. For this framing, fine, the bottleneck is going to be Python functions being slow in general. What I am saying is to have a constrained framework. This should be clear.

There are plenty researchers who want to upgrade their sketch of a model (in Python) into a much faster version, without having to rewrite into Agents.jl/hEngine. In my case, my own best practice was to rewrite the pain points in Cython (which is still not ~O(Agents.jl)).

I'm skeptical about achieving similar optimization in Mesa. The challenge doesn't stem from a handful of resource-intensive functions but from the multitude of minor function calls, making optimization more complex.

By constraint, the degree of it from highest to lowest: vectorization (Mesa Frames), how-hEngine-does-it (Cython/Rust), C extension (Cython/Rust). User-defined functions in hEngine seems general, it's just that one can't do walrus operation or custom decorator. All the 3 efforts can be developed in parallel. Is your skepticism on the C extension one?

Regarding with hEngine, it should be possible to write Mesa Python API on top of it, so that no Rust coding is needed.

[quaquel]

I guess I occupy a bit of middle position. With @Corvince, I see MESA's appeal in its flexibility. It also works well for teaching ABMs. However, with @rht, I agree that we should allways try to enhance the performance of MESA's core functionality. With one key caveat: speedups should not come at the expense of the flexibility and teachability of MESA.

The near complete work on DiscreteSpace is in my view the best of both worlds: it seems to result in about 20%-25% speedup in the benchmark models, while enhancing the flexibilty and expressiveness of MESA. It also shows that substantial speeds up are possible within the MESA framework by carefully reviewing the data structure we are using. This does however imply, as @Corvince rightly points out: optimization becomes complex.

My experiments with SystemState and my plea for pub/sub come are similar to the work on DiscreteSpace. It my testing, data collection became 20%-30% faster while allowing for a cleaner seperation of concern and thus cleaner code. @Corvince raised some valid points about adding pub/sub to the core API, however, that warrant a good solution before pushing forward with this.

I see discussions on Mesa-frames, Cython, Rust, and discrete event scheduling in a similar light. If it creates speedups, that is great. However, like with DiscreteSpace, it should offer benefits beyond raw speedup and not negatively affect MESA's core strenghts.

[rht]

However, like with DiscreteSpace, it should offer benefits beyond raw speedup and not negatively affect MESA's core strenghts.

There shouldn't be API collisions. I want Mesa to have both flexible API and constrained API, where the latter is for users who want to rewrite their flexible code for performance. This is how Polars does it: they support pandas expressions and their own native accelerated expressions.

[jackiekazil]

Notes from today's session

Cell space - almost done

• Fully experimental and contained.
• Needs final review

Data collection

• We have had a few issues over the last couple of years.
• There are two groups with respect to data collector.
  • Select subgroup of agents based on criteria
  • From this, you should be able to aggregate some set of
• The future of data collection #1944
• Maybe MEP 3?

Visualization

• Introduce Altair Grid #1902
• feat: Implement Altair version of grid visualization #1991
  • Clear port from tornado to Solara
  • It seems that we are trying to solve different problems... first we need clarity on what we are wanting to do.
• TODO: Finalize w/ meeting -- Required: @ankitk50, @tpike3, @rht, @Corvince (if available) ... (/cc @EwoutH, @jackiekazil)
• Does 1902 have significant advantages
• Get Corvince’s input
• What does our visualization look like in the end?

Discrete event simulation - This is recently discussed / proposed

• Allowing non-integer time steps
• As a project - do we want to stay strict ABM or do we want to be a discrete event sim
• Hybrid ABM DEVS with MESA #2032
• In default -- regrowth takes X ticks to grow. They are activated every time.
• In event based, they grow then the event occurs and they are NOT activated every time. This saves computational overhead.
• Example: poisson arrival process mixed with agent-based modeling
• why wouldn’t we do this -- Complexity? - But not that much more
• We want to keep the dominant model step.
• Related: Enable DiscreteEventScheduler to handle system-level events and task interruptions #1893
  • How do we introduce task creation, task interruption, etc
  • This is a list of ideas that we could do.

Meetings regularly -

• Weekends are impossible.
• Weekdays are generally fine.
• Evenings are fine until 10pm.
• https://www.when2meet.com/?23231948-rKO2t
• Next meeting -- Saturday, March 2
• We will continue this discussion to identify a regular pattern... tentatively we are considering about every two weeks rotating between weekday and weekend and shortening meetings to 30 min