Inconsistencies in extracting graph object from model

[prochlorothrix]

Not sure whether this is an issue or a feature request, but I'm trying to extract the graph from the model to plot it with GraphPlot and it seems to be difficult or impossible to re-link the edge structure with the node (that is agent) properties. Ideally, I'd extract the space, defined for instance as GraphSpace(SimpleGraph(x, y)), and then attribute the correct agent properties to each node using the agent IDs as key.

The problem is that, extracting the graph structure with getfield(model, :space).graph returns a graph object with node IDs that are not consistent with the agent ones I get from allagents(model). This means that I'm no longer able to attribute the correct properties to each node.

There may be some workaround I did not find yet, but enforcing coherence between the different elements of the model would be really useful, especially for people working with ABMs on dynamic networks.

[Datseris]

A GraphSpace is not built for "social networks", or in general the scenario that each node of the graph is an agent. Is this your scenario? In a GraphSpace multiple agents may occupy a node.

[prochlorothrix]

Yes I want to have an agent per node. If not GraphSpace, which is the best space to use?

BTW I agree that you should write better that GraphSpace is not for social or similar networks but please also highlight what it the best alternative. Reading the manual it's not really clear (at least to me).

[Datseris]

https://juliadynamics.github.io/Agents.jl/stable/examples/schoolyard/

[prochlorothrix]

Using ContinuousSpace() and then setting the graph as model property, as in the schoolyard example, works but looks somewhat abstruse to me. This may be more of a feature request, but a nice development could be to have a specific social network / graph space where each node is an agent. Linked to that could be the possibility to visualize the network with abmplot(), without the need to extract it from the model and plot it externally, for instance with GraphPlot.

[Datseris]

This may be more of a feature request, but a nice development could be to have a specific social network / graph space where each node is an agent

I don't see much justification or benefit to complicate things and add an additional space. What the example I linked shows is how incredibly simple it is for you to create an interaction network directly. Why conflate the agent spatial position with their interaction network? Or, perhaps the better question is: What is there missing from the example I've linked? Having a dedicated space won't make things simpler, you will still have the same amount of lines of code to write. Its just that when you are trying to get an edge or a vertex instead of enquiring model.graph you would be enquiring abmspace(model). The rest all would stay pretty much the same...

[Tortar]

What about the better integration with abmplot (or all the rest plotting stuff like abmexploration) @prochlorothrix is thinking about though? I'm not sure but maybe having a GraphSpaceSingle could be advantageous in such a case.

[Tortar]

To generalize this a bit, we could even have a capacity keyword for our discrete spaces cells, as they do in Mesa (https://github.com/projectmesa/mesa/blob/08ff1edaba02bd6af95c545f4312dd039fb80bb9/mesa/discrete_space/grid.py#L88), e.g. you can have a GridSpace where the maximum number of agents for each grid position is fixed beforehand

[Datseris]

To generalize this a bit, we could even have a capacity keyword for our discrete spaces cells, as they do in Mesa (https://github.com/projectmesa/mesa/blob/08ff1edaba02bd6af95c545f4312dd039fb80bb9/mesa/discrete_space/grid.py#L88), e.g. you can have a GridSpace where the maximum number of agents for each grid position is fixed beforehand

I don't see a reason to do this either. It is so simple to enforce such things on the user side by just checkiing how many agents are in a position. Agents.jl provides a simple function ids_in_position that you can just call length on in an if clause. Perhaps Mesa doesn't provide such simple API functions for the user?

The reason we differentiate between single and non-single space is because there is a fundamental difference in the internal implementation, and hence resulting performance. This "capacity" option on the other hand has no fundamental impact on either.

[Tortar]

It clearly has, we can use fixed size containers for some sizes e.g. for capacity=1 we can use already our implementation, for capacity at least <=5 we can use an MVector and we are better off in every way. The question is for me instead: what are cases where fixing a capacity at the start of the simulation is possible?

[Tortar]

actually I'm not sure because we need also to track the real length in any case.