Add `RandomActivationByBreed` from Sugarscape example to available schedulers in time.py

[majdal]

What's the problem this feature will solve?
Sometimes you need to step() each breed of agent separately. The Sugarscape example already has a scheduler that takes care of that use case: RandomActivationByBreed. It makes sense for it to be merged into the schedulers available by default in time.py.

Describe the solution you'd like
Copy RandomActivationByBreed into time.py. The class might require some adjustment to work with the DataCollector class, since the agent_reporters loop over all agents in the schedule, regardless of breed, which will inevitably raise a bunch of AttributeError exceptions.

Alternatively we could subclass the DataCollector class to make it collect by breed.

Additional context
It might be interesting to also have a StagedActivationByBreed scheduler.

[rht]

Agents.jl has a very concise implementation of something equivalent to RandomActivationByBreed: https://github.com/JuliaDynamics/Agents.jl/blob/48f71a3b438e8cdcbb562067f5877e52cf0a6e5d/src/core/schedule.jl#L85. I wonder if we can replicate the design in Python.

[rht]

From the discussion in JuliaDynamics/ABMFrameworksComparison#2, it turns out that Agents.jl's by_type generates a list of list agent ids, where the first index of this list of list signifies agent types. This is inefficient, and looks like Agents.jl developers are looking to revamp their multiple-type schedulers as discussed in JuliaDynamics/Agents.jl#445.

I think the solution is going to look similar to the Sugarscape example's RandomActivationByBreed.

Note that not including RandomActivationByBreed in Mesa by default has costed Mesa a lot of LOC increase in the benchmark vs Agents.jl, NetLogo, and MASON.

[tpike3]

I agree I think a bybreed option should be default in Mesa.

[rht]

RandomActivationByType seems to be a more general name.

[rht]

This is the benchmark: https://juliadynamics.github.io/Agents.jl/stable/comparison/.

[EwoutH]

@tpike3 @jackiekazil @rht I think having proper multi-type agent support would increase the value of Mesa quite a bit. Implementing a RandomActivationByType scheduler as proposed above should be an easy first step.

NetLogo also supports different types of agents (called breeds), so it can be essential to porting some models.

[tpike3]

@EwoutH I absolutely agree if you are interested in working on it, that would be a great contribution :)

[EwoutH]

I might do some work on it next week. One thing I already noticed it that it will require some work on the DataCollector code, since that assumes "The schedule has an agent list called agents".

[tpike3]

@EwoutH My dissertation worked with sugarscape (sugar and spice trading model) and I don't remember adjusting the datacollector being that laborious. May not be helpful, but here is the code repo schedule and the whole repo with a data analysis notebook. I adjusted from the activiationbybreed example (although it should be by RandomActivationByType as you noted)

[rht]

My dissertation worked with sugarscape (sugar and spice trading model) ...

TIL! @tpike3 what do you think of adding various models of Sugarscape to the examples? E.g. {G,M,T}, not just constang growback.

[EwoutH]

@tpike3 Thanks for the links! I see you implemented recorder functions for each model. Looks doable, but also non-trivial.

[EwoutH]

I think I wrote a working DataCollector implementation with multiple agent-types.

The next problem I just encountered is that the ChartModule in ChartVisualization.py can't handle agent-level variables yet. This is listed as an TODO, but not yet implemented.

[EwoutH]

I misdirected some energy to a proof of concept: #1142

Please feel free to comment on both the architecture and specific implementation. I will try to spin up some production ready code over the next week.

[tpike3]

TIL! @tpike3 what do you think of adding various models of Sugarscape to the examples? E.g. {G,M,T}, not just constang growback.

@rht absolutely, once we get activation by type I think I can spin up some of the other variations pretty quick.

This only tangentially related (more a point of interest) when I did the sugar and spice variation, I could replicate all the results but the signature of trading volume. My best guess is still the way the underlying code is handled between python and basic. But never had a chance to really unpack it.