Support for graphs of SSAs

[isaacsas]

Since this is being talked about in MT here, we should figure out how to make this work efficiently for jumps, preferably with a general API that allows us to compose different SSAs.

I think the primary challenge is that we need to support the ability for jumps at one location to also change species at neighboring locations on the graph, with data structures, rate functions and dependencies at that and other neighboring sites getting updated as appropriate. For spatial bio problems spatial jumps are usually representable as mass action reactions, i.e. A_i -> A_j or A_i + B_j -> C_k. In many cases though, for example Cartesian grids, it can be more efficient to do one jump for a diffusive hop away from a site, and then sample the particular placement site within the affect. These will often be the most executed jumps, sometimes as much as 99% of the events, so I would think performance will strongly depend on optimizations like we did for MassActionJumps.

Note, if the spatially-distributed jumps were all just thrown into one SSA there is nothing to do, but the idea is there are hierarchical SSAs where the top level stores next event times (or total propensities) for each site, and then each site has an associated SSA for determining what happens there. So we should aim to be able to support this type of composition.

[ChrisRackauckas]

In many cases though, for example Cartesian grids, it can be more efficient to do one jump for a diffusive hop away from a site, and then sample the particular placement site within the affect.

Sounds like we should allow for a mark distribution in the MassActionJumps?

[isaacsas]

Yeah, that flexibility would be good, and is something we should support more generally anyways. We have no explicit mark support currently, and since users doesn't have access to the current rates I guess they can't really do it themselves. I'm not sure it will be faster though than putting in separate normal mass action jumps to go to each neighbor if it doesn't get inlined.

[ChrisRackauckas]

I'm not sure it will be faster though than putting in separate normal mass action jumps to go to each neighbor if it doesn't get inlined.

I'm not sure either. It's worth constructing on its own first to see if it really matters. I just know about mark distributions from the tau-leaping stuff, and in there indeed it would be good to add.

[isaacsas]

I'm not sure though that allowing marks to MassActionJumps really makes sense. Allowing marks will presumably mean allowing a user-defined affect! function too, at which point one is basically back to a ConstantRateJump (i.e. one only gets the benefit of rate calculation component of the MassActionJump).

[ChrisRackauckas]

A mark can just be a distribution, so we can have a it be a distribution rand that is then used... somehow? I guess that somehow is the hard part.

[Vilin97]

@isaacsas, should this be closed now, given #183 and #189?

[isaacsas]

There is still a ways to go till we support the full graph generality we need.