-
Notifications
You must be signed in to change notification settings - Fork 879
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add cell-centric discrete spaces (experimental) #1994
Conversation
There’s a lot in here that I like! let me know when you want any input / a review. |
If you add mesa/.github/workflows/benchmarks.yml Line 31 in 7b0d3f1
|
Thanks, I now tried to bypass the jupyter stuff, but I am not sure if this is working. If I change the benchmark.yml won't the action stop working? Because of the pull_request_target thingy? |
Feedback ist welcomed at all times! |
/rerun benchmarks |
Yeah it might, honestly I don't know. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just some random thoughts from reading the code. On a high level, I think I really like it but I feel like I don't have enough comprehension of all the nuances and implications to say for sure.
Guess I would need to start make models with it to see what happens!
Had 3 comments at 2e78940#comments. |
/rerun-benchmarks |
Performance benchmarks:
|
@EwoutH it looks like the benchmark wasn't run for this PR after the comment trigger. You can see that from the action. Maybe you can look into that? |
You forgot the dash between rerun and benchmarks. It has to be the exact string (see rht's one). |
mesa/experimental/cell_space.py
Outdated
if radius == 0: | ||
return {self: self.agents} | ||
if radius == 1: | ||
return CellCollection( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this currently breaks neighborhoods with radius>1 Made some errors while refactoring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested in on Schelling, radius 2 and seems fine?
Ha, I see how my comment was completely miswritten. I already realized after @rht made the correct comment. But in the action that was actually triggered this PR isn't checked out, hence no difference in performance. Performance should actually be about 20% faster. Here is the exact line of the Action. It should check out this PR, but instead creates a new branch "main" |
Looks like it checks it out differently when initiated from a PR opened then from a comment. Will check it out! (current workaround it so mark PR as ready to review (and back to draft)) |
Thanks for this! I will take a deeper dive at this, hopefully, tonight or otherwise over the weekend. I quickly checked the code this morning and have a few additional comments and suggestions in addition to the various points already raised I will also move my versions of Schelling and WolfSheep into this (do I have write access)? So we can properly see the change in performance. |
I tried some stuff in #1998. Let's see if it works. |
Merged, here we go: /rerun-benchmarks |
for more information, see https://pre-commit.ci
I did some more testing. I can't reproduce my initial performance differences so I guess I made a mistake when I thought there was a massive difference. I also tested a dedicated SingleAgentCell next to the normal cell and updated CellCollection.agents to take advantage of this. Again, this did not produce a massive speedup. So, I suggest we leave the code as is for now and just merge it. I have updated the PR text to better reflect the actual performance figures. |
Agreed, we can always optimize more later if needed. On thing I'm not sure about is already porting our main benchmarks over. Maybe we could add those models to mesa-examples, and leave the benchmarks here as is. |
Performance benchmarks:
|
In both my datacollection and devs branch, I have added a simple examples folder within the folder with the new experimental code. I am fine with using either mesa-examples or doing what I have been doing in devs and datacollection. Let me know what you prefer and why. |
I would suggest this PR shouldn't change the models in Out of curiosity, where any models with an NetworkGrid tested? |
I think an example folder inside the experiments sounds good and like the place to be. But maybe it would still be nice to have one of the benchmarks use this feature, since I think we all agree that cell space is going to be the recommended space implementation eventually |
I like @Corvince suggestions. It also allows us to track how the performance of the new grid stuff is affected going forward. |
We could have two sets of benchmarks, regular ones and experimental ones |
I am also fine with adding additional benchmarks, but how would that work out if we add additional experimental stuff? For example, if I add devs, which benchmarks would I edit to showcase their impact? |
Thought about it a bit, let's keep it simple. Benchmarks are an internal development tool, not user examples. So let's keep them on the cutting edge. I'm good with merging (please clean ip or squash). I would like a second aproval before doing so. Thanks for the thremendous effort! |
@quaquel can you handle the merging, since I opened the PR? I'm swamped with work until next work and won't be able to do so until then |
I can also do it |
Performance benchmarks:
|
## Summary This PR introduces an alteranative implementation for discrete spaces. This implementation centers on the explicit inclusion of a Cell class. Agents can occupy cells. Cells have connections, specifying their neighbors. The resulting classes offer a cell centric API where agents interact with a cell, and query the cell for its neighbors. To capture a collection of cells, and their content (_i.e._, Agents), this PR adds a new CellCollection class. This is an immutable collection of cells with convenient attribute accessors to the cells, or their agents. This PR also includes a CellAgent class which extends the default Agent class by adding a `move_to` method that works in conjunction with the new discrete spaces. From a performance point of view, the current code is a bit slower in building the grid and cell data structure, but in most use cases this increase in time for model initialization will be more than offset by the faster retrieval of neighboring cells and the agents that occupy them. ## Motive The PR emerged out of various experiments aimed at improving the performance of the current discrete space code. Moreover, it turned out that a cell centric API resolved various open issues (_e.g._, projectmesa#1900, projectmesa#1903, projectmesa#1953). ## Implementation The key idea is to have Cells with connections, and using this to generate neighborhoods for a given radius. So all discrete space classes are in essence a [linked data structure](https://en.wikipedia.org/wiki/Linked_data_structure). The cell centric API idea is used to implement 4 key discrete space classes: OrthogonalMooreGrid, OrthogonalVonNeumannGrid (alternative for SingleGrid and MultiGrid, and moore and von Neumann neighborhood) , HexGrid (alternative for SingleHexGrid and MultiHexGrid), and Network (alternative for NetworkGrid). Cells have a capacity, so there is no longer a need for seperating Single and Multi grids. Moore and von Neumann reflect different neighborhood connections and so are now implemented as seperate classes. --------- Co-authored-by: Jan Kwakkel <j.h.kwakkel@tudelft.nl>
Summary
This PR introduces an alteranative implementation for discrete spaces. This implementation centers on the explicit inclusion of a Cell class. Agents can occupy cells. Cells have connections, specifying their neighbors. The resulting classes offer a cell centric API where agents interact with a cell, and query the cell for its neighbors.
To capture a collection of cells, and their content (i.e., Agents), this PR adds a new CellCollection class. This is an immutable collection of cells with convenient attribute accessors to the cells, or their agents.
This PR also includes a CellAgent class which extends the default Agent class by adding a
move_to
method that works in conjunction with the new discrete spaces.From a performance point of view, the current code is a bit slower in building the grid and cell data structure, but in most use cases this increase in time for model initialization will be more than offset by the faster retrieval of neighboring cells and the agents that occupy them.
Motive
The PR emerged out of various experiments aimed at improving the performance of the current discrete space code. Moreover, it turned out that a cell centric API resolved various open issues (e.g., #1900, #1903, #1953).
Implementation
The key idea is to have Cells with connections, and using this to generate neighborhoods for a given radius. So all discrete space classes are in essence a linked data structure.
The cell centric API idea is used to implement 4 key discrete space classes: OrthogonalMooreGrid, OrthogonalVonNeumannGrid (alternative for SingleGrid and MultiGrid, and moore and von Neumann neighborhood) , HexGrid (alternative for SingleHexGrid and MultiHexGrid), and Network (alternative for NetworkGrid). Cells have a capacity, so there is no longer a need for seperating Single and Multi grids. Moore and von Neumann reflect different neighborhood connections and so are now implemented as seperate classes.
Usage examples
Below are a few examples demonstrating the functionality of the cell spaces.
Creating a Grid and Adding Agents
Agent Movement
Querying the Neighborhood
Agent Reproduction
Removing an Agent
Checking Cell Properties