Tracking issue: Stabilizing the Cell Space

[EwoutH]

A tracking issue for stabilizing the experimental Cell Space.

Mesa 3.0

A lot of active development, including:

• Generalize CellAgent #2292
• Make cell connections public and named #2296
• Have a dedicated neighborhood property and a get_neighborhood method on Cell #2309
• experimental: Integrate PropertyLayers into cell space #2319
• Encapsulate cell movement in properties #2333
• Add support for drawing discrete grids #2386

Current spaces

• space: Add note that Grids are maintenance only #2420

Mesa 3.1

Integration and documentation.

• Add full support for property layers to cell spaces #2512
• Add full and complete docstring
  • Module-level Add module-level docstring to experimental features #2532
  • Classes
  • Methods

Mesa 3.2

Stabilizing release

• Integrate ContinuousSpace Reimplementation of Continuous Space #2584
• Refine visualisation Improve visual styling of grid drawing #2438
• Update tutorial
• Switch over basic example models
• Write migration guide

Current spaces

• Update to DeprecationWarning

Mesa 4.0

• Make new (optionally breaking) changes to Cell Space
• Remove current spaces
• Rename to "space"?

Everyone let me know what you think, especially @quaquel and @Corvince.

[Souvik9205]

Hi, I would like to work on this issue

[EwoutH]

Great! You can see what’s still TODO, feel free to pick one and start working on it.

[quaquel]

@EwoutH, do we want to move over the basic examples as part of 3.2, or as part of 3.3?

Personally, I think it would make more sense to do it for 3.2.

[EwoutH]

I’m also good with 3.2, like the tracking issue currently states.

The big ticket item is integrating the Continuous Space, so we can keep a unified concept of space.

[quaquel]

The big ticket item is integrating the Continuous Space, so we can keep a unified concept of space.

sounds like a fun thing for me to work on over the christmas break. In the mean time, I'll continue updating various examples to use all the new stuff that came in 3.1.

[EwoutH]

Actually, I might be interested to do some exploratory work on this over the weekend, as an integrated effort on integrating (parts of) Mesa-Geo.

We can do the MPIEvaluator combo, were I do some pathfinding and deliver a shit PoC and you make it a proper implementation ;)

[EwoutH]

Now that we want to stabilize the the cell space, we have to think about the namespace or module name we're going to put it in.

Since it also contains a continuous component, I don't think cell_space is the perfect description anymore. We could simply put it in a space namespace (folder) and let the space module exists as is. That could introduce naming conflicts, so we could also name it new_space before 4.0, and than with 4.0 make it simply space again.

[quaquel]

Since it also contains a continuous component,

Cell-spaces/discrete spaces and continuous spaces are really different things, so I would counsel against collapsing them. Conceptually, the underlying maths, for example, is quite distinct. Implementation-wise and API-wise, they are also quite different. I want to explore the possibility of having a generic space protocol to improve API alignment, but I don't see a feasible or desirable path beyond that.

So, I prefer mesa.discrete_space and mesa.continuous_space as folders while we leave the existing mesa.space file with a deprecation warning. I prefer folders over a single file because of the ease of finding stuff. From a user side, it does not matter as long as the relevant stuff is just importable from the right namespace.

[EwoutH]

Sounds logical. Maybe we can even do mesa.space.discrete and .continuous.

[quaquel]

not sure: flat is better than nested.