Agents.jl: Continuous space brainstorming

[Datseris]

So, let's get this party started!!! The end goal of this discussion is a new space type, ContinuousSpace and robust support for this in Agents.jl.

First, let's make a wishlist of all the things that are at least in imagination possible, and then as the ideas mature we will see which ones are possible:

1. A ContinuousSpace struct.
2. from 1 to 3 dimensions.
3. Support for periodic or not boundary conditions.
4. Concrete way for the agents to have velocity (does it also have to be a specfic field of the agent?)
5. Interaction radius: in principle could take any real number as value.
6. Interaction radius could be on a CityBlock metric, or Euclidean metric (square shape versus circle shape)
7. Interaction a' la billiards: agents have a "size", and interaction is literally collision between the balls of the agents. We can use HardSphereDynamics.jl for this.
8. Can all agents move in parallel, or is it only possible to move sequentially...? (For HardSphereDynamics, all spheres move in parallel)
9. Avoiding double interactions: the framework should be able to understand that two agents have _just interacted_, and thius, even if they are in the interaction radius of each other, they shouldn't interact again.
10. Allow generic equations of motion, i.e. besides linear motion, acceleration, deceleration, repulsion

I will be updating this list as we talk about this more

When comparing _different_ space implementations, these are the things that should be compared performance-wise:

• Initializing spatial structure
• moving 1 agent in spatial structure
• adding 1 agent in spatial structure
• finding neighbors of 1 agent in spatial structure, for several different radii

[Datseris]

@kavir1698, please describe here your idea of using a database like you used in the social distancing model.

---

Another idea comes from a colleague of mine @lhupe , and goes like this:

• There is an underlying graph, and it is the same as the graph of GridSpace (i.e. there is a grid).
• One keeps track of the Agent's continuous position (it is their field pos), and also their position on the grid.
• The interaction units are multiples of the grid spacing.
• Finding all agents our agent interacts with is the same as finding the neighboring nodes.
• An internal "move" function is used at each agent, and then interaction is checked.

We should check whether this approach is more performant than the SQL. I think it is safe to say that this approach is more natural given the way we have set up Agents.jl so far, but I am very happy to use SQL or anything else if it is much better. In the end, the SQL stuf will be hidden from the end user I hope.

[kavir1698]

My idea for implementation of continuous space can be seen in #138. The main requirement of a continuous space model is, I suggest, quickly finding agents in a given area. A SQL database helps with that.
I have written two functions: move! and collide! which can be part of Agents.jl API and a user just calls them, thus having no direct interactions with the database object.

The MWE already incorporates 1, 2, 3 (by changing newx/y in move!), 4 (right now it is a universal model field, but could be an agent-specific field too), 5, and 6 (it is a square right now in collide! because it was easier, but can be extended).

Point 7 would be same as 6 when interaction sphere is a circle.

Point 8: does it matter in a discrete time model?

Point 9: I think this can be relaxed. Two agents might as well keep interacting if they remain in their interaction sphere.

I guess that network implementation of continuous space would be slower because add/remove agent functions that we currently have are more expensive and database mutations, but we can test the.

[Datseris]

I've updated the list because we didn't discuss something sofar: generic equations of motion so agents can accelerate and decelerate towards each other.

[Datseris]

Here is my sketch on how to allow arbitrary equations of motion:

The ContinuousSpace has a field move!, which is a function move!(agent, model) that updates the agent's position. We provide two default move functions:

• standard linear one
• standard euler solver that takes in a function f that gives the derivatives, and then just does pos += δt * derivatives.

The ContinuousSpace goes through the agents and move! them, and then the interaction part takes place.

What do you think?

[kavir1698]

Looks clean to me.

[lhupe]

It could be useful to include stochastic equations of motion in some way; I can imagine a lot of people in the biophysics/active matter community will need Brownian dynamics in agent-based models. This could be a different implementation of move! that implements an Euler-Maruyama scheme (scaling the noise variance with δt)

[Datseris]

Sure. Just in case it wasn't clear in my suggestion: move! is provided by the user. So with the framework I sketch above, this stochastic is very much possible, but the user has to write how move! behaves. Although I guess what you describe shouldn't be too hard to provide as one of the possible defaults.

[kavir1698]

The ContinuousSpace has a field move!, which is a function move!(agent, model) that updates the agent's position.

Or move can be overloaded on the current move_agent! function where model.space is of ContinuousSpace type.

[Datseris]

In #138 we just merged in a WIP version of continuous space. We are happy with the design, but there are alot of "TODOs" left. Anyone that wants to help us: just search "TODO" in the source code :D

[Datseris]

The discussion in https://github.com/JuliaDynamics/Agents.jl/issues/155 is directly relevant here. What becomes apparent is that before we release 3.0 it is critical to compare the two ways of representing continuous space: via a Database or via an Array with element type Vector{Int} (the agent IDs in each bin, almost identical with GridSpace).

[Datseris]

I've further updated the original post to reflect what should be compared performane-wise across different spatial implementations.

[Datseris]

it is certain that I can't find enough time to implement the matrix+vector approach, so I'll close this and we will stick with the database. Good thing is, the API is defined by the documentation strings and nothing stops adding CompartmentSpace after 3.0.