dependency graphs for JumpSystems

[isaacsas]

Still needs:

• Equation to Equation DiGraphs
• Variable to Variable DiGraphs
• tests, tests, tests

[ChrisRackauckas]

I think this may be able to be done at the abstract system level, which would be nice because #281 could then be solved at the same time. I think there could be an equation_dependencies(sys) = extract_variables(equations(sys),states(sys)) and then extract_variables! could dispatch on the types of equations. For Equation it could find all of the variables in the rhs of the equation, and then on jumps it could do what you have as ratevars. ReactionSystem may have to be specialized here as well. But that would do it everywhere. Then dependency_graph(sys) would just use this and generate the graph. Then an option for creating the second graph, which is essentially the graph of the transpose, which is needed for some calculations but not for others.

Also, I wonder if we should go all of the way at this point to making that return a LightGraphs SimpleGraph, since IIRC that kind of graph is a vector of vector edge lists, so I don't think we'd lose any speed (the underlying data representation would be the same, but it would make this a much nicer user-facing feature because then plot(graph) would work and all sorts of nice functionality would come for free.

Then solving #281 is just equation_dependencies(sys) which gives the sparsity pattern row by row, and then we just loop over the sparsity pattern and only differentiate at the non-zeros.

[isaacsas]

Jumps will also need an eq to eq dependency graph, which you can build using the eq to state and state to eq graphs. Just to be clear, you are suggesting the default dep graph be a map from eqs to states each eq depends on, as opposed to states to eqs that depend on them.

Before I work on this more there are a few questions that would be good to settle (to avoid rewriting this too much):

1. Should the graph just map from the integer id for each eq? What about for states, ids or the actual Variable?
2. I had forgotten that DiffEqJump requires an ordering of jump types for such graphs; namely MassActionJumps need ids before ConstantRateJumps. Do the underlying equations in an AbstractSystem always need to be stored in a vector? I was thinking maybe JumpSystems should store a tuple containing arrays of MassActionJumps, ConstantRateJumps and VariableRateJumps. We would then assume an implicit ordering of majs, then crjs, and then vrjs. (BTW, for now I don't think having a dep grap with vrjs will work with the current SSAS, so we'll need a check for that.)
3. I haven't used lightgraphs; can we directly pass them to SSAs, which require vectors of vectors of ids?

I'll take a look at LightGraphs tonight before I work on this more as I haven't used it much.

[ChrisRackauckas]

Just to be clear, you are suggesting the default dep graph be a map from eqs to states each eq depends on, as opposed to states to eqs that depend on them.

eq -> states is the rows of the Jacobian and states -> eq is the column. states -> eq might be the most performant one for building sparsity patterns. eq -> eq is needed for SSAs, and states-> states is probably what people want to plot most of the time. So it would be nice to have a whole section of the docs on these different dependency graphs and maybe have four functions, or one function with switches on what to create and output?

Should the graph just map from the integer id for each eq? What about for states, ids or the actual Variable?

The simplest version of the graph should probably just go to id for the equations and variables, which is unique because we keep our variables/equations ordered. Though for graphing, it would be nice for these to be a MetaGraph which would then add the names of the variables automatically to the plot. But that could probably be done with a thin wrapper of sorts over a SimpleGraph, so if it would effect speed/memory then we can just leave it off and come back to that later.

I had forgotten that DiffEqJump requires an ordering of jump types for such graphs; namely MassActionJumps need ids before ConstantRateJumps. Do the underlying equations in an AbstractSystem always need to be stored in a vector? I was thinking maybe JumpSystems should store a tuple containing arrays of MassActionJumps, ConstantRateJumps and VariableRateJumps. We would then assume an implicit ordering of majs, then crjs, and then vrjs.

That makes a lot of sense for type reasons as well. Or make it an ArrayPartition and then it would be both the tuple of arrays but also act as a single array of equations. I think JumpSystem might be the one that needs the most special handling of equations though, just in general, so if it doesn't quite follow the rules to the t that might just be the nature of it.

BTW, for now I don't think having a dep grap with vrjs will work with the current SSAS, so we'll need a check for that.

Yeah, and I don't think it can specialize on that, so it might need to ignore vrjs in the SSA side. That might be a deep and hard issue to solve though...

I haven't used lightgraphs; can we directly pass them to SSAs, which require vectors of vectors of ids?

I believe so.

[isaacsas]

I had a vague memory you had a way to have a heterogeneous tuple of arrays look like one array, but couldn’t remember the type/package name. Thanks for the pointer to Arraypartitions.

[isaacsas]

I looked at the Lightgraphs docs yesterday some; my impression is it doesn't out of the box nicely support bipartite graphs in the sense that it seems to me, and correct me if this is wrong, we would need. That is, we'd have to merge the eqs and states into one set of (neqs+nstates) vertices by renumbering one of them. (We could use metagraph on top to specify the type of each vertex.) So this wouldn't be directly passable to SSAs. I guess the question is whether we want our own internal representation that mixes vertices labelled 1:neqs that are eqs and vertices labelled 1:nstates that are states, for which it would be easy to create a Lightgraph conversion, or whether the preference is to use Lightgraphs as the default and then convert to SSA format when making a JumpProblem. For the latter, if we number eqs and then states, I think we'd just have to copy the fadjlist within the corresponding SimpleGraph and then renumber the entries by substracting the number of eqs. On the other hand, eq to eq or state to state representations could be stored in Lightgraphs, with the former being passable to SSAs as the standard dependency graph I believe (some SSAs also need eq to state or state to eq graphs).

[ChrisRackauckas]

Do the bipartite graphs with the special representation that we need. We can always find the right way to convert to LightGraphs for plotting and such later.

[isaacsas]

How does this look for the API? It works for both states and parameters currently (for jumps). Next I can add eq-eq and state-state graphs, for which I'll use LightGraphs. (The BipartiteGraph I defined is basically their same structure as DiGraph, but splits the two graph component indices instead of merging them.)

[ChrisRackauckas]

Looks great. We should just keep consistency in our variable extraction utils.

[isaacsas]

Need to add state_dependencies too before can do state-state or eq-eq.

[isaacsas]

@ChrisRackauckas Assuming tests pass I think this is done.

[isaacsas]

Adding ODEs should be pretty easy I'd think and can be a separate PR.

[isaacsas]

SDEs will need a dispatch for equation_dependencies and variable_dependencies since they need to check the noise terms too I presume.

[isaacsas]

Actually, there seems to be an issue when testing with RSSA so something is not quite right yet.

[isaacsas]

@ChrisRackauckas Tests seem to be failing from a DiffEqJump error?

[ChrisRackauckas]

yeah I'm looking at it.

[ChrisRackauckas]

it's all good now