History-sensitive hazard rates

[kris-brown]

Here is a trichotomy of ways the hazard rate of a rewrite rule could be triggered:¹

1. Stateless: we simply provide a probability measure $Meas$ which is sampled whenever a match is found.
2. Stateful: Let $\Xi:=Ob(ACSet)$.² We provide a function $\Xi \rightarrow Meas$, which is sampled whenever a match is found. However, because the event may happen in the future, our world state could change before the event is triggered. There are a few ways we could deal with this, but by default we would cancel the timer, and resample a new event with the new state.
3. Historical: We provide a function $\sum_{t \in [0,\infty)} \Xi^{[0,t]} \rightarrow Meas$, which takes any trajectory (of some length) and gives a probability measure. In this case, we are not forced to draw from our single $\Xi \rightarrow Meas$ function at the current time $\Xi$ has changed, but we can take into account what has happened.

As a motivating example: consider $\Xi = {sick,verySick}$. The moment we enter the sick state, we are triggered to die in four years. However, three years in, we transition to verySick, which has as its rule that one has two years to live. With the stateful-but-not-historical approach, becoming very sick adds a year to one's life!

Another motivating example: consider a rewrite rule with a probability measure that is a decaying exponential $e^{-\alpha(t-5)}$ which is delayed 5 seconds from when the match occurs. If $\alpha$ is a continuous variable that is updated at very short intervals via continuous dynamics, then we will certainly change its value before 5 seconds have passed, and thus by the stateful approach we would constantly be resetting the 5 second clock and the event would never fire.

Currently we do not implement historical dependency, but it is something consider if we find ourselves limited by the stateful approach (and compensating for it by sticking lots of historical details into the schema itself).

Footnotes

1. We'll ignore the parameterization via absolute clock time for simplicity ↩

2. This is for simplicity; in reality we have slightly more data, i.e. a choice of X in Ob(ACSet) and morphism L->X ↩

[sdwfrost]

How is initialization of the clocks ,e.g. in a Petri net model, handled at present? It's important for non-exponential passage times - as a simple test case, you could have a gamma distribution of passage times. Is it possible to specify the initialization state of the clocks?

[kris-brown]

Hi, I'm not sure I follow what you mean by initialization of clocks. When a match is discovered, we draw from a potentially non-exponential distribution of waiting times to determine when that rewrite will fire. Are you talking about how, at t=0, there is an artifact of a bunch of matches coming into existence at the same time?

[sdwfrost]

You've got it; at t=0, you need to have a history of the states of the system (this could be that they all start at the beginning of the waiting time distribution, but it should be more general), just as you would provide to a delay differential equation system.

[slwu89]

@sdwfrost the clocks are taken care of by CompetingClocks.jl (formerly named Fleck.jl, we had to rename the package due to issues getting "Fleck" accepted on the general repo). When a clock is enabled the enable! method here is called https://computingkitchen.com/CompetingClocks.jl/dev/interface/#CompetingClocks.enable! Note that the enablingtime may be allowed to be different from when (the current simulation time). I assume this would be for a case where at t=0 we know for example a person has already been infectious for n days, so that enablingtime=-n but when=0. Is this sufficient for your needs? I don't think we can provide a general "history function" currently as one does for DDE solvers, but if all the information from the history can be contained in the behavior of clocks that may have been enabled at times <0, we can definitely do that. I am not sure that an easy interface exists currently, but if you can confirm that my understanding is right, I'll check it out.

[sdwfrost]

Thanks @slwu89! I think you're on the right track; the ideal API would be to have some Distribution (or set of distributions) that would describe the history at t=0. Imagine you have a DDE with a fixed delay as the infectious period. If you start all the initial infecteds at the beginning of their infectious period at t=0, you'll end up with some transient behavior that may be undesirable. In this case, assuming some distribution (e.g. a Uniform) on the time elapsed in the infectious compartment would be better.