Update paper.md #2566
Update paper.md #2566
Conversation
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
|
Thanks, a PR like this is fine for me. I like to be able to view a diff. For JOSS we have to prioritize a bit, since they target a 1000-word length. With these changes we will be around 1500 words. |
Ok, I can easily trim it down again |
paper/paper.md
Outdated
| ### Spaces | ||
| Mesa offers a variaty of spaces within which agents can be located. A basic distinction is between discrete or cell-based spaces, and continous space. In discrete spaces, the space consists of a collection of cells and agents occupy a cell. Examples of this include orthogonal grids, hexgrids, voroinoi meshes, or networks. In a continous space, in constrast, an agent has a location. | ||
|
|
||
| Mesa comes with a wide variety of discrete spaces, including OrthogonalMooreGrid, OrthogonalVonNeumanGrid, Hexgrid, Network, and VoroinoiMesh. These are all implemented using a doubly linked data structure where each cell has connections to its neighboring cells. The different discrete spaces differ with respect to how they are "wired-up", but the API is uniform across all of them. | ||
|
|
||
| Mesa also offers 3 subclasses of the Agent class that are designed to be used in conjunction with these discrete spaces: FixedAgent, CellAgent, and Grid2DMovingAgent. FixedAgent is assigned to a given cell and can access this cell via `self.cell`. However, once assigned to a given cell, it can not be moved. A CellAgent, like a FixedAgent, has access to the cell it currently occupies. However, it can update this attribute making it possible to move around. A Grid2DMovingAgent extends CellAgent by offering a move method with short hand for the direction of movement. | ||
|
|
There was a problem hiding this comment.
Personally, since all this is experimental, I would save it for a Mesa 4 paper when it's stable.
There was a problem hiding this comment.
Or make it significantly shorter, as a "we're working on"
There was a problem hiding this comment.
I disagree. From 3.2 onwards, cell spaces are stable, and old-style spaces raise a pending deprecation warning. It is plausible that by the time this paper is accepted 3.2 is out.
paper/paper.md
Outdated
| A more advanced alternative to discrete time advancement is discrete event simulation. Here, the simulation consists of a series of time stamped events. The simulation executes the events for a given timestep, Next, the simulation clock is advancent to the time stamp of the next event. Mesa offers basic support for discrete event simulation using a Discrete event simulator. The design is inspired by Ziegler (add ref), and the java-based DSOL library (add ref). | ||
|
|
||
|
|
||
| 1. Event-based scheduling for non-uniform time steps: | ||
| ```python | ||
| devs_simulator = DiscreteEventSimulator() | ||
| model = Model(seed=42, simulator=devs_simulator) | ||
|
|
||
| devs_simulator.schedule_event_relative(some_function_to_execute, 3.1415) | ||
| devs_simulator.run_until(end_time) | ||
| ``` | ||
|
|
||
| It is also possible to create hybrid models that combine discrete time advancement as typically seen in agent based models, with event scheduling. For this, MESA comes with an ABMSimulator. This simulator has integer based time steps. It automatically schedules the step method of the model for each time tick. However, it is also possible to schedule events on these ticks. This allows for hybrid models combining the ease of discrete time advancement seen in typical ABMs, with the power, flexibility, and potential for substantial runtime reductions of event scheduling. | ||
|
|
||
| 1. Hybrid discrete time advancement with event scheduling | ||
| ```python | ||
| abm_simulator = ABMSimulator() | ||
| model = Model(seed=42, simulator=abm_simulator) | ||
|
|
||
| abm_simulator.schedule_event_next_tick(some_function_to_execute) | ||
| abm_simulator.run_until(end_time) | ||
| ``` | ||
|
|
||
|
|
There was a problem hiding this comment.
Since this is also experimental I would suggest also keeping this concise.
Co-authored-by: Ewout ter Hoeven <[email protected]>
|
I'm fine with you putting in what you want, we can trim down later. |
|
I have adopted or at least addressed most of @EwoutH feedback. I am merging this now, so @jackiekazil can move it over to overleaf. |
|
Awesome! I created a Google Doc: https://docs.google.com/document/d/1HdoNDecjRvvmYhMyr9lZqPj3mmTOa3lrFv1a8_NCk38/edit?usp=sharing |
This is WIP, but I put it here so others can see the changes I am making to the manuscript.
At present, I have partially done
I find it virtually impossible to turn all these changes into separate atomic commits. Code and paper writing are just different activities in my brain.