Agent-Based Modeling via graph rewriting

Kris Brown


(press s for speaker notes)

5/31/24

Outline

$$

$$

I. Motivation

II. AlgebraicRewriting overview

III. Agent-based programming

IV. Agent-based modeling

Goal: modeling framework which facilitates

comparing

combining

editing

visualizing

Hi, I’m going to talk about AlgebraicRewriting, agent-based programming (a term I will introduce), and agent-based modeling. (…)

The ultimate goal is to produce a modeling framework that can be handed off to domain experts in all sorts of domains, and they should agree that the tasks of comparing models, combining models, editing models, and visualizing models is made much easier than the status quo. Let me start by showing you what the status quo is:

I. Motivation - examples

• Game of Life

• COVID modeling

• Discrete Lotka Volterra

An important class of scientific models are agent-based models - there are types of agents and they interact in various ways, not much more you can say in general about them. Part of the goal of this talk is to introduce some formalized idea that I claim captures a lot of practice without throwing up one’s hands in defeat and saying “An Agent Based Model is any piece of software with things we call agents.” Here are three motivating examples:

Now the problem: how do we represent these models, if not just as source code? Unfortunately, the status quo is that, despite the modeler’s high-level conceptual understanding of the model, the only formal artifact is a piece of code. That makes comparing, combining, editing, and visualizing difficult.

I. Motivation - examples

Schema

Dynamics

Control flow

• Discrete Lotka Volterra (link)

breed [ sheep a-sheep ]   ; sheep subtype of turtle
breed [ wolves wolf ]     ; wolf subtype of turtle
turtles-own [ energy ]    ; add energy attr to W + S
patches-own [ countdown ] ; add countdown attr to grid

to eat-sheep  ; wolf procedure
  let prey one-of sheep-here                ; grab a random sheep
  if prey != nobody  [                      
    ask prey [ die ]                        ; eat it
    set energy energy + wolf-gain-from-food ; get energy
  ]
end

ask sheep [
  move
  set energy energy - 1  
  eat-grass 
  death ; sheep die if they run out of energy
  reproduce-sheep 
]

ask wolves [
  move
  set energy energy - 1  
  eat-sheep ; wolves eat a sheep on their patch
  death ; wolves die if they run out of energy
  reproduce-wolves ;
]

ask patches [ grow-grass ]
tick

Let’s focus on the wolf-sheep model. This is written in Netlogo, a language built for the purpose of agent-based modeling. I want to break down the file into three parts:

• schema: declares the data structures that make up the state of the simulation
• dynamics: declares the possible transformations that can happen
• control flow: declares how the set of events in dynamics are to be orchestrated.

AKA the things, the things that happen, and how the things happen.

I. Motivation - examples

• COVID modeling (link)

Schema

mutable struct PoorSoul <: AbstractAgent
    id::Int
    pos::NTuple{2,Float64}
    vel::NTuple{2,Float64}
    mass::Float64
    days_infected::Int  # number of days since is infected
    status::Symbol  # :S, :I or :R
    β::Float64
end

Dynamics

function elastic_collision!(a, b)
  v1, v2, x1, x2 = a.vel, b.vel, a.pos, b.pos
  length(v1) != 2 && error("This works only for 2D")
  r1 = x1 .- x2; r2 = x2 .- x1
  !(dot(r2, v1) > 0 && dot(r2, v1) > 0) && return false
  dx,dv = a.pos .- b.pos, a.vel .- b.vel
  n = norm(dx)^2
  n == 0 && return false # do nothing if at the same pos.
  a.vel = v1 .- ( dot(v1 .- v2, r1) / n ) .* (r1)
  b.vel = v2 .-  ( dot(v2 .- v1, r2) / n ) .* (r2)
  return true
end

Control flow

for (a1, a2) in interacting_pairs(model, model.radius)
    transmit!(a1, a2, model.reinfection_probability)
    elastic_collision!(a1, a2)
end

• Discrete Lotka Volterra (link)

Schema

breed [ sheep a-sheep ]   ; sheep subtype of turtle
breed [ wolves wolf ]     ; wolf subtype of turtle
turtles-own [ energy ]    ; add energy attr to W + S
patches-own [ countdown ] ; add countdown attr to grid

Dynamics

to eat-sheep  ; wolf procedure
  let prey one-of sheep-here                ; grab a random sheep
  if prey != nobody  [                      
    ask prey [ die ]                        ; eat it
    set energy energy + wolf-gain-from-food ; get energy
  ]
end

Control flow

ask sheep [
  move
  set energy energy - 1  
  eat-grass 
  death ; sheep die if they run out of energy
  reproduce-sheep 
]
ask wolves [
  move
  set energy energy - 1  
  eat-sheep ; wolves eat a sheep on their patch
  death ; wolves die if they run out of energy
  reproduce-wolves ;
]
ask patches [ grow-grass ]

Now on the left I’ve added the epidemiology model in Julia using a library called Agents.jl. This similar structure between the two examples is not explicit in the code itself - we’ll make that structure explicit in the formalization of ABMs at the end of the talk.

But the takeaway from this slide should be: “Wow! This syntax for models is not amenable to comparison, combination, editing, nor visualizing.” For example, writing a generic ‘combiner’ of models means that someone gives you a wolf-sheep model and a covid model and tells you “what if sheep could get COVID? make it happen.” and you need to apply your function which takes to arbitrary source code files and produces the composite model as a piece of source code. That would be nearly impossible to write.

I. Challenges with getting engineers into graph rewriting

The syntax of graph rewrite rules has the virtues we want, but:

• It is a syntax for atomic changes. Nondeterminism from match and rule choice.
• Engineers / modelers need more determinism / coordinated rewriting.

What is a good syntax for talking about the algorithmic application of rewrite rules?¹

I think these four virtues among others do in fact hold for models specified in graph-rewriting language. I don’t need to sell graph rewriting to this community, but I often need to do need to make a case for it for engineers who are used to thinking in imperative languages or even pure functional languages. So why is this a hard sell?(…)

Engineers need nondeterminism when choices really don’t matter or they are explicitly modeling something probabilistic. (…)

This picture from Reiko’s and David’s book. It breaks down various features of control flow. It seems like explicit control of matches is not in this feature list, though.

1. Fig. from Graph Transformation for Engineers

I. General strategies for control

1. Unordered rules, but control via constraints / maintain program state ‘in the graph’

2. Directed graph of rewrite rules
   • No control of matches
   • No complex control flow

3. General program with rewrite primatives
   • No explicit control of matches
   • Program language syntax

We want a graphical language for control flow + one which lets us say “use this match”.

For 3, note we also have GP 2 as an example, there will be a comparison with GP 2 later in the talk.

The third option which is very practical is to just use a general programming language that has access to a graph rewriting library and use rewrites to perform the heavy lifting. This has the aforementioned issues from making one’s syntax a general purpose programming language, although by factoring out a large portion of the model into rewrite rules the situation is still greatly improved from the status quo.

In this talk I will something ‘in between’ these last two options, something expressive yet still working in a category with nice structure which can then be given a computational semantics.

II. AlgebraicRewriting

AlgebraicRewriting.jl is a library for graph rewriting written in Julia.

• Part of the AlgebraicJulia ecosystem
  • Open source packages implementing computational CT / concrete applications.
  • General computer algebra features for working in a variety of categories
  • Emphasis and special support for the category of \(\mathsf{C}\)-Sets

AlgebraicRewriting supports:

• DPO, SPO, SqPO, Conegation, and PBPO+ rewriting
• Rewriting with attributes (e.g. Int, Tuple{String, Float64})
• Application conditions (e.g. PAC, NAC, arbitrary commutative diagram constraints)
• Automated morphism search and incremental homomorphism search
• Automated functorial migration of rewrite rules between different schemas
• Enumeration of partial overlaps between graphs / \(\mathsf{C}\)-Sets

Installation is easy: just download Julia

using Pkg; Pkg.add("AlgebraicRewriting")

Let me introduce AlgebraicRewriting now. (read the slide)

II. Catlab basics review

• Declaring \(\mathsf{C}\)-Sets
  • Manually, via @acset
  • Via custom functions, e.g. cycle_graph
  • Via (co)limits

• Declaring morphisms between \(\mathsf{C}\)-Sets
  • Manually, by specifying each component (e.g. V=[2,3], E=[1])
  • Via automated search + constraints, (e.g. monic=true)

• CSet schemas (ACSet schemas)
  • DDS, Graph, Petri Net (ChemicalRxn)

• Data migration:
  • Functor between schemas presents transformation process on instances
  • DDS to Graph, Graph to Petri Net

I moved some slides to the end that were basically an intro to Catlab tutorial. I don’t think it’s feasible in the same talk to cover both the big picture as well as what it looks like in code, even though the gap between those is remarkably small.

Just to briefly say we work with \(\mathsf{C}\)-Sets, which are presheaves which form an adhesive category. These are slightly generalized by Attributed \(\mathsf{C}\)-Sets (ACSets) which add in attribute information (such as strings, floats).

II. AlgebraicRewriting basics

AlgebraicRewriting introduces the Rule data structure:

zero = Graph(0)
edge = path_graph(Graph, 2)
del_edge = Rule{:SPO}(homomorphism(zero, edge),  # L <- I
                      id(zero);                  # I -> R
                      monic=true                 # constraints on the match morphisms
                      ac=[PAC(...), NAC(...)]    # feed in morphisms L -> P, L -> N
)

rewrite(del_edge, G)                       # result of applying an arbitrary match
L_to_G = homomorphism(edge, G)             # pick a specific match
rewrite_match(del_edge, L_to_G)            # rewrite with a specific match
res = rewrite_match_maps(del_edge, L_to_G) # return the entire derivation diagram

Attributed \(\mathsf{C}\)-Sets (ACSets) can have concrete attribute values or variables (AttrVars).

• We can manipute the concrete variables with custom code

L = @acset WeightedGraph{Float64} begin
  V=2; E=2; Weight=2; src=[1,1]; tgt=[2,2]; 
  weight=[AttrVar(1), AttrVar(2)] 
end
I = WeightedGraph{Float64}(2)
R = @acset WeightedGraph{Float64} begin 
  V=2; E=1; Weight=1; src=1; tgt=2; 
  weight=[AttrVar(1)] 
end
l = homomorphism(I,L; monic=true)
r = homomorphism(I,R; monic=true)
merge_multiply = Rule(l, r; monic=[:E],
  expr=Dict(:Weight=>[(w1, w2) -> w1*w2]))

Using custom code makes model comparison, combination, editing, and visualization difficult.

Note we can migrate these rewrite rules using functorial data migration, so we can turn that graph rule into a petri net rule, for example.

III. Rewrite programs: SMCs

Symmetric monoidal categories are a desirable structure for one’s syntax to have:

• Can be graphically depicted
• Can serve as the syntax for varying semantics

So now I want to switch to solving our main problem, which was how to do we represent control flow and control of matches? (…)

First I want to talk about symmetric monoidal categories. When you’re fortunate enough to have a SMC, you can use directed wiring diagrams to talk about morphisms.

III. Rewrite programs: SMC composition

Symmetric monoidal categories are a desirable structure for one’s syntax to have:

• Can be graphically depicted
• Can serve as the syntax for varying semantics
• Can be composed in parallel or in series
• With further traced structure, we can have loops.

III. Rewrite programs: SMC substitution

Symmetric monoidal categories are a desirable structure for one’s syntax to have:

• Can be graphically depicted
• Can serve as the syntax for varying semantics
• Can be composed in parallel or in series
• With further traced structure, we can have loops.
• Can be operadically substituted

.

Graphical language of function composition

\(\mathbf{Set_*}\) has the required traced monoidal structure (using coproducts for \(\otimes\)).

Thus we can use this language to talk about composition of functions.

Think of rewrite rule add_loop as a function¹ \(Grph \rightarrow Grph + Grph\):

Add a loop to a vertex. If none exists, then add a vertex, then give it a loop.

The category of sets and partial functions (equivalently, the category of sets with partial functions) has the traced monoidal structure we need to license our use of wiring diagrams as a means of representing compositions of morphisms. (…)

Let’s consider the add_loop rule which matches a vertex as its pattern and as its output adds a loop edge to that vertex. We can think of this as a function that takes in graphs and spits out graphs (I want to put to the side the question of which match we use for now; we’ll return to that later). Now, generally a rewrite rule can fail to match, so we could distinguish two outcomes: the rule as successfully applied, and the rule as unsuccessfully applied. We either exit the top wire with our changed graph or we exit the bottom wire with an unchanged graph. Let’s see an example of composition of rewrite rules using what we have so far: (…)

Note we have a bit of control flow but the only ’if’s we can test are whether or not rewrites can succeed.

1. Ignore the nondeterminism temporarily, an arbitrary match is deterministically picked

Graphical language of function composition

New primitive type of box for control flow:

• Can only redirect its input, not modify it
• \(A \xrightarrow{f} n \times A\) for \(n \in \mathbb{N}\) such that \(f\cdot \pi_i = id_A\)

Remove edges, until we have a DAG

Remove an edge, distinguish between cases of empty result or not

We don’t want boxes with arbitrary functions, because that would be hard to reason about. So we want a curated core of primitives which are expressive enough to do what we want to do while being easy to reason about. So we should be very judicious about when to introduce a new primitive. Here we are forced to do this because we want to branch on possibilities other than merely whether or not a rewrite rule succeeded or failed.

These control flow boxes allow us to explicitly separate primitives which modify the input vs primitives which merely control the flow. We have some kind of equivalent to if, else and while, but not for loops. These boxes have no internal state, so there is no way to encode a history dependence. So our first generalization to this language will be to allow this.

Graphical language of dynamic function composition

Mealy machines (or dynamic functions) seem to form a symmetric monoidal category.¹

\[Hom_{\mathbf{Meal}}(A:Set,B:Set) := \left\{\left(S : \mathsf{Set},\ s_0 : S,\ \phi\colon A\times S\to S\times B\right)\right\}\]

• We allow Control boxes to have nontrivial state.

A control flow box which decrements its internal state each time it is entered:

A box which behaves like Add Loop the first three times it is used, then like Delete Vertex:

Our first upgrade is from functions to Mealy Machines, which are functions that have a parameter, a set \(S\), and applying the function is thought of as changing that parameter. So we also call these “dynamic” functions because they are like a function which you can run, but the input can alter the ‘internal state’ of the function and change its behavior.

Strictly speaking, Mealy machines do not work as a SMC, higher-powered category theory is required to explain why we can morally think of Mealy Machines as forming a SMC (in reality, they are presentations of the things which actually do form an SMC: behavior trees). But this is not where I want to focus my time today.

(Note: Rewrite rules and control flow without any internal state can be regarded as Mealy machines with S=1.)

We now have a very robust language for control flow, but I haven’t yet said how we are going to address control of matches.

1. Morally right, but requires high-powered category theory to show

Control of matches via a notion of ‘agent’

Our wires are labeled with “agent shapes”. These are \(\mathsf{C}\)-Sets.

• Set of possible values associated with a wire is the set of morphisms \(A \rightarrow G\) for some \(\mathsf{C}\)-Set \(G\).

• Crucial difference between adding a loop to some vertex vs adding a loop to this vertex.
• Gradient between two extremes:
  • determinism (\(A = L\))
  • nondeterminism (\(A = \varnothing\))

Rather than having our wires labeled “Graph” to say that elements of the set of all graphs can flow along the wires, we will now annotate the wires with specific graphs. I think of this as a ‘focus’ or ‘agent’ shape. The value which flows along the wire is a map from the shape into some graph which represents the state of the world. A rewrite rule then operates on not just a graph but a graph with a particular focus, and furthermore it outputs a graph with a particular focus. For example, consider a rule which adds a loop: (…)

Suppose \(A = B = \bullet\). The rule then expects not merely a graph as input but a graph with a distinguished vertex. It also needs to output a graph with a distinguished vertex.

This means we need, in general more information to specify a rule. We have to declare what sort of agent it is expecting, and we have to pick out what the output agent is. (…)

[read two bullets]

Example of rewriting with control of matches

Let’s look at this in action. Here we have two rules being executed in series. (…)

Rem Tgt&Edge expects a particular source and target vertex and then tries to delete the target vertex as well as the edge. It’s output agent shape is just a single vertex, which distinguishes the source vertex. (…)

Merge Vertices merges two specific vertices that come distinguished in the input. Its output interface also is two vertices, though they will always happen to mapped to the same vertex whenever we successfully apply the rule. (…)

When we run this on this input, which has these vertices distingiushed, they get merged, but then Rem Tgt&Edge has no edge from the merged vertex to itself, so the rule fails. (In fact, even if there were an edge, it would fail the identification condition since the vertex would be simultaneously preserved and deleted). So we finish the program coming out of the bottom wire.

Example: Binary DAGs

Suppose we want to classify binary DAGs¹

Next I have an example of writing a program which could classify whether a graph is a binary DAG (at most two outgoing edges). (…)

This is a GP2 example, and here is the GP2 program looks like. Now this featured in an earlier GReTA talk where it took a good 10 minutes to explain in full detail, so I would rather not actually get into the mechanics of how this works. The high level points I want to establish are:

• GP 2 has special “rooted graphs” constructions in order to make computations like this easy to specify and efficient. Whereas from our point of view, this is a very special case of a vertex-shaped agent.
• In addition to a notion of “roots”, they have to have a special “flag” marker on nodes to trigger control flow (this is putting program state into the graph itself).
• I’ll show how we depict this program at the top on the next slide.

1. From “Improving the GP 2 Compiler” (Campbell, Romo, Plump)

Example: Binary DAGs

Rewrite program in a category with schema \(\boxed{V \leftleftarrows E \leftarrow Seen}\)

So the point isn’t to step through the execution of this program, but just to flag it and show the expressiveness of the tools we’ve seen so far. This is a program which will take in a graph (with nothing in particular distinguished), and output a value from the top wire if it’s a binary DAG, otherwise the bottom output wire. (…)

Init distinguishes a vertex, and thereby selects a connected component that we begin to process in the upcoming loop. Every iteration of this loop makes us take a step backwards along the

Weaken: switching to less specific agents

Weaken is specified by a morphism \(Hom_{C\mathsf{Set}}(A,B)\).

• It converts \(B\)-agents to \(A\)-agents without changing the state of the world.
• It acts upon an agent via precomposition.
• Equivalent to a rewrite rule with \(A_{in} = L = I = R\)

Weaken: switching to less specific agents

Weaken is specified by a morphism \(Hom_{C\mathsf{Set}}(A,B)\).

• It converts \(B\)-agents to \(A\)-agents without changing the state of the world.
• It acts upon an agent via precomposition.
• Equivalent to a rewrite rule with \(A_{in} = L = I = R\)

We can always weaken with the initial object:

• Rewriting with initial agent is forgoing any explicit control of matches.

The Query primitive: more specific agents

Required data:

Example:

Fully connect all the outneighbor vertices of some distinguished loop

Although RuleApp and ControlFlow are the workhorse generators, we need others to facilitate the changing of control from agent to agent. Consider the Query morphism \(A + B' \rightarrow A + B + 0\), whose basic behavior is determined by the types \(A\) and \(B\) on its ports:

Query boxes play the role of “for all agents (i.e. subobjects of shape \(B\)), do this subroutine”. Afterwards we return to our original agent.

(If our original agent no longer exists (e.g. the map \(A \rightarrow X\) points to something that got deleted in the process of running the subroutine for every \(B\)), then we can still exit with the trivial/empty agent, which is the third outport.)

We need a way of fluidly switching switching from agent to agent.

Summary of rewriting programs

• Mealy machine primitives composed via directed wiring diagrams
• Wires represent sets of morphisms \(A \rightarrow X\) for a fixed \(A\)
• Changes are only performed by Rule
• Shifting ‘agent’ focus performed by Query and Weaken

Out of all primitives, Rules are the only one that can change the world. The control exists for control flow, and the latter ones are simply to change the agent we are focusing on so that the rules have as much determinism in matching as we care for.

Implementing ABMs via agent-based programs

One punchline is that, using the tools I’ve shown you so far, we can take that Netlogo code I showed in the beginning and make a program which implements the same simulation, modulo some small details.

I used to call these wiring diagrams agent-based models but over the course of the past year have learned to think of them as merely programs, not models.

Caveat: this is an old figure that has a more complicated Query interface, where the return type need not be \(0\) and there is a third outport for what to do when the original agent \(A\) that was entered with got deleted over the course of executing the subroutines for each \(B\). (This was omitted from the present presentation for simplicity)

Why are these rewriting ‘programs’ rather than ‘models’?

These feel less like programs compared to (equivalent) syntax like:

def simulate(X: Graph, steps: int) -> Graph:
  for step in steps:
    for match in homomorphisms(sheep, X):
      if length(homomorphisms(match, X)) > 3:
        res = rewrite(rule5, match)
        if success(res):
          ...
        else:
          ...

• Can be graphically depicted
• Can be composed in parallel or in series
• Can be operadically substituted
• Can easily vary semantics

Nevertheless, this is not suited for agent-based modeling

• Control flow fundamentally imperative rather than declarative.
  • To understand a diagram, you must run a simulation in your head.
• No built-in notion of time
  • Always a linear sequence of events
  • No capability for concurrency
  • No capability for continuous time events

Before criticizing what I just told you about, I’ll stress that it does meet our goal of being a graphical language for control flow and explicit control of matches. One can achieve that via writing ordinary programs that call upon rewriting primitives, but then one loses various forms of transparency and composibility. (…)

[read]

We’ll aim to address these issues in the next section.

IV: Agent-based modeling¹

These models are continuous time with discrete events and continuous dynamics.

To first order, an ABM is:

• A schema: possible world states are ACSet instances

Ok I will now transition to a new formalism.

1. This is work-in-progress with John Baez, Nathaniel Osgood, Xiaoyan Li, Evan Patterson, and Sean Wu.

IV: Agent-based modeling¹

These models are continuous time with discrete events and continuous dynamics.

To first order, an ABM is:

• A schema: possible world states are ACSet instances
• A collection of rewrite rules, \(\rho_i :: (L_i \leftarrowtail I_i \rightarrow R_i)\rightarrow \mathbf{ACSet}\)
  • An associated collection of ‘timers’ \(T_i :: \mathsf{P}([0,\infty])\).

So far there is no ‘programming’, just declarations of events that can happen, a probabilistic description of how long it takes for them to happen, along with continuous processes.

1. This is work-in-progress with John Baez, Nathaniel Osgood, Xiaoyan Li, Evan Patterson, and Sean Wu.

IV: Semi-Markovian ‘timers’

The probability measure captures a ‘residence time’:

• how long it takes to happen, conditional on nothing else happening first to remove it from that state.

• “staying in a state” = “match persists” over time

E.g.

Generalization: these are parameterized by the state of the world:

• the probability of (\(S_i\), \(I_j\)) depends on the viral load of \(I_j\)
• the probability of \(I_j\) recovering depends on the total # of doctors

We are intentionally supporting non-Markovian processes. This is because coarse-grained dynamics aren’t memoryless as physical equations are. (Likewise, coarse-grained chemical kinetics isn’t simply mass-action kinetics.)

The recovery transition temporal landscape is intelligible independently of the infection transition. If a recovery transition gets triggered first, then this invalidates the match associated with the later event firing, so we can ignore it when that time comes.

IV: Agent-based modeling¹

These models are continuous time with discrete events and continuous dynamics.

To first order, an ABM is:

• A schema: possible world states are ACSet instances
• A collection of rewrite rules, \(\rho_i :: (L_i \leftarrowtail I_i \rightarrow R_i)\rightarrow \mathbf{ACSet}\)
  • An associated collection of ‘timers’ \(T_i :: \mathsf{P}([0,\infty])\).
• A collection of continuous dynamics, given by ODEs \(O_j\)
  • An associated collection of patterns, \(P_j :: \operatorname{Ob}(\mathbf{ACSet})\).
  • Partial functions from \(P_j\) variables to \(O_j\) variables.

.

1. This is work-in-progress with John Baez, Nathaniel Osgood, Xiaoyan Li, Evan Patterson, and Sean Wu.

Example: Game of Life

@present SchLifeGraph <: SchSymmetricGraph begin 
  Life::Ob; live::Hom(Life,V)
end
@acset_type LifeState(SchLifeGraph); # defines LifeState

# Helper functions / building blocks 
#-----------------------------------
Cell = LifeState(1) # one vertex, nothing else
LiveCell = @acset LifeState begin V=1; Life=1; live=1 end 
to_life = homomorphism(Cell, LiveCell);

living_neighbors(n::Int; alive=true)::ACSetTransformation = ...

# Rules 
#------
underpop = TickRule(:Underpop, to_life, id(Cell); 
                    ac=[NAC(living_neighbors(2))]);

overpop = TickRule(:Overpop, to_life, id(Cell); 
                   ac=[PAC(living_neighbors(4))]);

birth = TickRule(:Birth, id(Cell), to_life; 
                 ac=[PAC(living_neighbors(3; alive=false)),
                     NAC(living_neighbors(4; alive=false)),
                     NAC(to_life)]); # doesn't apply if alive

GoL = ABM([underpop, overpop, birth]) # model is just the rules

.

Example: Petri net token semantics

sir_pn = @acset LabelledPetriNet begin 
  S=3; sname=[:S,:I,:R]
  T=2; tname=[:inf,:rec]
  I=3; is=[1,2,2]; it=[1,1,2];
  O=3; os=[2,2,3]; ot=[1,1,2]
end

# Create ABM by associating stochastic timers with each T
abm = ABM(sir_pn, (inf=ContinuousHazard(1000),
                   rec=ContinuousHazard(Weibull(30, 5)...)));
# Initial state
init = PetriNetCSet(sir_pn; S=95, I=5)
# Run the model
res = run!(abm, init; maxtime=2000);

.

Performance: representable patterns

In certain circumstances, we don’t have to keep track of all the matches explicitly.

• We have a simple exponential (memoryless) probability distribution
• The pattern is a coproduct of representables (e.g. \(L = \bullet \oplus \bullet \rightarrow \bullet\))

In this case, rather than draw a timer for every \((S, I)\) pair with probability \(e^{-kt}\), we draw just one timer with probability \(e^{-k*(|S|*|I|)t}\), then randomly pick a match at firing time.

Transitions derived from Petri nets are a perfect example where we should never need to do homomorphism search nor represent matches expcitily.

NOTE: this doesn’t work if we have constraints (monic, PAC/NAC) on the matches.

Performance: Incremental homomorphism search

For each overlap with \(R \setminus I\):

This is essential for the hope of good performance.

Hom Search becomes dependent not on the size of the world but the size of the change of the world, i.e. the difference between \(R\) and \(I\) in the rule which got applied.

I’m definitely curious about what techniques this community is aware of for this, as I have not been able to come up with much myself.

Synthesis of agent-based programs and models

One does not have to choose between ABP and ABM. In fact, we can use both:

• Generalize the earlier definition of ABM: pairs of ABP+timer
• Our previous formalism is a special case where all programs consist in just a single rule.

This lets us express things such as: after 5.0 s, something definitely happens, but which rule is applied depends on coin toss (or first one rule is tried, and a different is tried if that fails).

.

V: Conclusion

• AlgebraicRewriting is expressive, powerful, easy to install, easy to use.
  • AlgebraicJulia is moving in a direction of factoring out our language-specific features, so that the same core can be instantiated in Python, Java, Rust, etc.
• Graphical rewrite programs built from ControlFlow, Rewrite, Query, and Weaken
  • This syntax can be given a solid mathematical semantics.
  • Control flow + language for control over matches
• Agent-based models can be constructed declaratively
  • A clear separation of schema, actions, and timing.
  • We could associate timers with entire programs, rather than individual rules.
  • This can be used for cellular automata, epidemiology, operations research

• Libraries: Catlab.jl, AlgebraicRewriting.jl, AlgebraicABMs.jl
• Blog posts: Agent-based programming, Coupling ODEs to ACSets
• Papers: AlgebraicRewriting.jl, Rewriting programs

• Models: Wolf-Sheep Program, GoL Program, GoL ABM, Petri Net ABM, Pertussis ABM

Thanks for your attention

.

About the Topos Institute

Mission: to shape technology for public benefit by advancing sciences of connection and integration.

Three pillars of our work, from theory to practice to social impact:

1. Collaborative modeling in science and engineering
2. Collective intelligence, including theories of systems and interaction
3. Research ethics

• Physics simulations (PDEs) with Decapodes.jl
• Reaction networks with AlgebraicPetri.jl
• Epidemiological modeling with StockFlow.jl
• Agent-based modeling with AlgebraicRewriting.jl
• Interactive GUIs with Semagrams

• Vision: topos.institute
• Research: topos.site
• Blog: topos.site/blog

I also want to introduce the Topos Institute for those not familiar with it. We’re a nonprofit research institute aimed at creating socially-benefitial technologies through applied category theory, which we believe is the key to having formal artifacts that are intelligible to diverse stakeholders and tools which allow us to collectively build these models. (…)

We have a lot of examples of this, and I’ll just be focusing on the AlgebraicRewriting one there.

I’ll add that we often collaborate with the University of Florida, where I was previously a postdoc with James Fairbanks, who himself gave a GRETA talk a couple years ago.

II. Catlab basics preview

• Declaring \(\mathsf{C}\)-Sets
  • Manually, via @acset
  • Via custom functions, e.g. cycle_graph
  • Via (co)limits

• Declaring morphisms between \(\mathsf{C}\)-Sets
  • Manually, by specifying each component (e.g. V=[2,3], E=[1])
  • Via automated search + constraints, (e.g. monic=true)

• CSet schemas (ACSet schemas)
  • DDS, Graph, Petri Net (ChemicalRxn)

• Data migration:
  • Functor between schemas presents transformation process on instances
  • DDS to Graph, Graph to Petri Net

II. Catlab basics: category of directed multigraphs

Manually creating a graph

G = @acset Graph begin 
  V=3; E=3; src=[1,1,2]; tgt=[1,2,2]
end

Specifying via built-in constructors and coproducts

G = path_graph(Graph, 3) ⊕ cycle_graph(Graph, 3)

H = subobject_classifier(Graph) ⊕ ob(terminal(Graph))

Manually specifying a graph homomorphism

h = ACSetTransformation(
  path_graph(Graph, 2), cycle_graph(Graph, 5);
  V=[2,3], E=[2]
)

@test is_natural(h) # check naturality

Finding all homomorphisms \(X \rightarrow Y\) via automated search

hs = homomorphisms(X, Y; monic=[:E],              # the edge component is injective,
                         epic=[:V],               # the vertex component is surjective, and
                         initial=(V=Dict(2=>3),)) # X's V2 is mapped to Y's V3

Here are some examples of things you can do in Catlab, which is a package that AlgebraicRewriting is built on top of. You can do this interactively in the terminal or in a script or as library code for a package you are building that uses AlgebraicRewriting. (go through examples)

II. Catlab basics: attributes

We are not limited to working with the category of directed multigraphs. Attributed C-Sets (ACSets) can have concrete attribute values in the ambient programming language.

@present SchChemicalRxn(FreeSchema) begin
  (Atom, Bond, Molecule)::Ob
  # Functional relationships
  bond_atom::Hom(Bond, Atom)
  bond_pair::Hom(Bond, Bond)
  molecule::Hom(Atom, Molecule)
  # Equations
  bond_pair ⋅ bond_pair == id(Bond)
  # Data types and attributes
  (N, ℝ)::AttrType
  atomic_number::Attr(Atom, N)
  stoichiometry::Attr(Molecule, ℝ)
end

@acset_type ChemicalRxn(SchChemicalRxn){Int, Float64} 

O2 = @acset ChemicalRxn begin
  Atom=2; Bond=4; Molecule=1
  bond_atom=[1,2,1,2]; bond_pair=[2,1,4,3]
  atomic_number=[8, 8]; molecule=[1,1]
  stoichiometry=[1.0]
end

Here is an applied example, showing how we can talk about things other than graphs. This is also a showcase of attributed \(\mathsf{C}\)-Sets, which has the hungarian pronunciation of ACSets.

II. Catlab basics: attributes

We are not limited to working with the category of directed multigraphs. Attributed C-Sets (ACSets) can have concrete attribute values in the ambient programming language.

@present SchChemicalRxn(FreeSchema) begin
  (Atom, Bond, Molecule)::Ob
  # Functional relationships
  bond_atom::Hom(Bond, Atom)
  bond_pair::Hom(Bond, Bond)
  molecule::Hom(Atom, Molecule)
  # Equations
  bond_pair ⋅ bond_pair == id(Bond)
  # Data types and attributes
  (N, ℝ)::AttrType
  atomic_number::Attr(Atom, N)
  stoichiometry::Attr(Molecule, ℝ)
end

@acset_type ChemicalRxn(SchChemicalRxn){Int, Float64} 

O2 = @acset ChemicalRxn begin
  Atom=2; Bond=4; Molecule=1
  bond_atom=[1,2,1,2]; bond_pair=[2,1,4,3]
  atomic_number=[8, 8]; molecule=[1,1]
  stoichiometry=[1.0]
end

# Get a symmetry of the molecule: swap the atoms
sigma = homomorphism(O2, O2; initial=(Atom=[2,1],))

We can do the same things that we could do with graphs. Homomorphism search, subobject classifiers, limits, colimits, etc. Here is specifying the symmetry which swaps the oxygen atoms (once you specify here the atoms go, the rest of the morphism is forced by naturality).

II. Catlab basics: more schemas

A discrete dynamical system as a set of states and a \(next\) function.

@present SchDiscreteDynamicalSys(FreeSchema) begin
  State::Ob; 
  next::Hom(State, State)
end
@acset_type DDS(SchDiscreteDynamicalSys)

A petri net has a set of states, transitions, and input/output multirelations.

@present SchPetriNet(FreeSchema) begin
  (S,T,I,O)::Ob; is::Hom(I, S);
  it::Hom(I,T); os::Hom(O, S); ot::Hom(O,T)
end
@acset_type PetriNet(SchPetriNet)

An example discrete dynamical system and example Petri net:

dds = @acset DDS begin 
  State=3; next=[1,3,2]
end 

pn = @acset PetriNet begin 
  S=3; T=2; I=3; O=3;
  is=[1,2,2]; it=[1,1,2];
  os=[2,2,3]; ot=[1,1,2]
end

II. Catlab basics: data migration

DDS as a special kind of directed graph:

• each vertex has a “next” edge.

Graphs as a special kind of Petri net

• each edge is a 1-input, 1-output transition.

State, = generators(SchDiscreteDynamicalSys, :Ob)

# A DDS-to-Graph converter
F₂ = FinFunctor(Dict(:E=>:State,:V=>:State),         
                Dict(:src=>id(State), :tgt=>:next), 
                SchGraph, SchDiscreteDynamicalSys)

V, E = generators(SchGraph, :Ob)

# A Graph-to-Petri-Net converter
F₁ = FinFunctor(Dict(:I=>:E,:O=>:E, :T=>:E,:S=>:V),             
                Dict(:is=>:src,:os=>:tgt,:it=>id(E), :ot=>id(E)),
                SchPetriNet, SchGraph)                           

Catlab makes these intuitions computable

dds = @acset DDS begin State=2; next=[2,1] end 
P = migrate(PetriNet, dds, DeltaMigration(F₁ ⋅ F₂))

Entire codebases can be migrated forwards and backwards along these functors.