Cacheable mesa
2 main files (cacheable_model.py and cacheable_wrapper_example.ipynb), the rest are just my attempts
- cacheable_model.py is a wrapper to cache the results. Currently, it only caches the results without the agent.pos
- cacheable_wrapper_example.ipynb shows how the caching module is used. agent.pos
- tried caching the agent.pos in cacheable_wrapper_example.ipynb but I have not added it to the caching module
Performance benchmarks:
| Model | Size | Init time [95% CI] | Run time [95% CI] |
|---|---|---|---|
| Schelling | small | 🔵 -0.7% [-1.1%, -0.4%] | 🔵 +1.0% [+0.7%, +1.2%] |
| Schelling | large | 🔵 -0.7% [-1.2%, -0.2%] | 🔵 +0.9% [+0.5%, +1.4%] |
| WolfSheep | small | 🔵 -0.9% [-2.0%, +0.2%] | 🔵 -0.8% [-1.1%, -0.5%] |
| WolfSheep | large | 🔵 -0.5% [-0.8%, -0.2%] | 🔵 -0.2% [-0.3%, +0.0%] |
| BoidFlockers | small | 🔵 -1.0% [-1.9%, -0.2%] | 🔵 +0.3% [-0.3%, +1.0%] |
| BoidFlockers | large | 🔵 -0.7% [-1.7%, +0.4%] | 🔵 -0.1% [-0.6%, +0.3%] |
- It's quite hard to read the notebook with the long output. You should use fewer steps for the showcase purpose.
- What's the difference between
model.cache()andmodel.datacollector.cache_remaining_data(model)?
@Chan-Dong-Jun
This is some good work, well done!
A couple thoughts for your consideration:
- As this is to communicate progress you want to mark this as a draft.
- As open source and Mesa are globally dispersed over communication is paramount. Particularly, as GSoC is unusual and generally such large PRs are not accepted.
- In your PR you want to provide context and overview of what you are submitting, a description of each of the key pieces,
- Specifically point out questions or concerns you have,
- Key areas were you want the maintainers to look and provide feedback
- If you have time, next areas you are going to work such as tests or comments or.....
- As this is a major feature being added to Mesa and apologies I should have made this explicit beforehand you should be using branch
3.0a1as your Mesa library notmain. This will ensure it is compatible with the breaking changes that will occur when we release Mesa 3.0.
Again well done! Please change this to a draft and provide a comprehensive overview when you get the chance. Thank you!
Finally, as no one can see what everyone can see, for the other maintainers, please feel free to correct or refine my advice or add your comments or thoughts.
- It's quite hard to read the notebook with the long output. You should use fewer steps for the showcase purpose.
- What's the difference between
model.cache()andmodel.datacollector.cache_remaining_data(model)?
@rht I just realized if you click view file in the upper right you can see the .ipynb in notebook form, maybe is much easier to see what is happening.
@Chan-Dong-Jun this looks like an amazing and major effort! I agree with all of Tom's points, especially about communication.
As this is a major feature being added to Mesa and apologies I should have made this explicit beforehand you should be using branch 3.0a1 as your Mesa library not main.
Currently Mesa 3.0 is developed right here on the main branch, so you're actually merging into the right branch! Only after Mesa 3.1 development starts we will have a seperate maintenance branch for 3.0.
I want to give some examples of how a great PR message looks in our repo (in no particular order):
- https://github.com/projectmesa/mesa/pull/1898
- https://github.com/projectmesa/mesa/pull/1916
- https://github.com/projectmesa/mesa/pull/1994
@rht I just realized if you click view file in the upper right you can see the .ipynb in notebook form, maybe is much easier to see what is happening.
I have already viewed on the browser. It still takes a while to scroll in order to see the important bits.
It's quite hard to read the notebook with the long output. You should use fewer steps for the showcase purpose.
- What's the difference between
model.cache()andmodel.datacollector.cache_remaining_data(model)?
- I will edit and resubmit the pr to make it more legible. Sorry for the trouble.
- .cache_remaining_data(model) is to cache the remaining steps. For example, if I cache at intervals of 100s and the model runs for 150 steps, the last 50 steps is cached by cache_remaining_data. Not sure if that's the best way to do it. I'm open to suggestions.