Feature: Graph/Network-based Communication

[ptheywood]

Implement network based communication for road network simulation style models.

This should account for multiple styles of network communication:

• Communication as graph
  • Agents output messages to graph elements
  • Graph is independent of agents
  • I.e. FLAMEGPU1 road network comm
• Agents as graph
  • Graph is the agents
  • I.e. infectious disease moddelling

---

Edit

This issues will be closed by #1089, as this will add the initial network support, and enable messages-on-network, networks with a fixed structure.

#1120 has been opened to cover messages-on-mutable-networks

#1121 has been opened to cover agent networks (i.e. social networks)

Ideally #1089 is going to be implemented in such a way that #1120 and #1121 will have a relatively common API, to simplify switching between them and prevent API breaks when implemented.

[ptheywood]

Bucket messaging provides most of the support for this, just need an on-device graph data structure to achieve this. Will postpone for after the first release.

[Robadob]

Communication as graph

• Messages are attached to edges
• Edges are linked to two vertex IDs
• Write Messages Via
  • Specifying edge ID
  • Specifying two vertex IDs
• Read Messages Via
  • All messages at edge ID
  • All messages at edge, specified by two vertex IDs
  • All messages on edges attached to vertex ID

This would require a bit of extra metadata to map between two vertexIDs/edge ID, and would make the graph implicit,

[ptheywood]

That will exclude multigraphs (graphs with multiple edges between a pair of vertices), but we might want to ignore multigraphs for now anyway (and then if any use-cases come up implement them separately).

E.g. for road networks, multigraphs can be used to allow per-lane properties for a section of road (e.g. travel time for bus lanes vs regular lanes for routing). In practice you can just add some nodes and use a non-mulit-graph though.

Otherwise providing both sounds good for usability.

There will likely also be a distinction between the user-visible edge ID and the edge index used within the in-memory representation of the graph.

[Robadob]

That will exclude multigraphs (graphs with multiple edges between a pair of vertices), but we might want to ignore multigraphs for now anyway (and then if any use-cases come up implement them separately).

Could add an extra argument "edge index" which defaults to 0. But definitely getting more complicated.

There will likely also be a distinction between the user-visible edge ID and the edge index used within the in-memory representation of the graph.

Fair point, definitely needs some thought/planning/discussion. Will probably try to mockup some psuedo code and consider how it would operate on the back-end.

[Robadob]

There also seems to be the chicken/egg situation. We can provide a utility for users to convert between vertex pair IDs and edge ID. But where do the initial vertex or edge IDs (which the user knows) come from?

[ptheywood]

Closed by #1089, as this will add the initial network support, and enable messages-on-network, networks with a fixed structure.

#1120 has been opened to cover messages-on-mutable-networks

#1121 has been opened to cover agent networks (i.e. social networks)