Splitting off kinetic and structural properties of reaction networks

[vyudu]

Many important dynamic properties of reaction networks depend on the choice of rate constants (complex/detailed balance, ACR, number/stability of equilibria, etc). I imagine there are situations where it would be useful to cache these as properties of the reaction network (though I'm not certain of this -- some of these checks are sort of costly so it might be useful to cache them, but not sure whether there are other good reasons), but it probably doesn't make sense to store them as properties of ReactionSystem itself if it depends on the parameters.

A couple of ideas I had (which maybe obviously don't work/would break something, but maybe there's something):

1. Have a KineticSystem type or similar, where the user constructs it by calling KineticSystem(rn, params) for some reaction network rn. Store the kinetic properties as properties of this type, and pass this type to functions like iscomplexbalanced. Could have these convert to ODESystems as well. I like this as well because you can inherit certain kinetic properties based on structural properties (e.g. if the parent ReactionSystem has deficiency 0, any KineticSystem built from it will be iscomplexbalanced)
2. Store this sort of kinetic information in the ReactionSystem as tuples, where the first entry is the parameters tested, and the second entry is the result for that choice of parameters. So, we could have something like iscomplexbalanced property be a vector of (Dict, Bool). The downside is that I think this would make it a bit less clear when certain kinetic properties always hold

[TorkelE]

To what extent do these depend on initial conditions as well? It might make sense to tie them to e.g. ODEProblems?

[vyudu]

Off the top of my head, the mixed volume (which bounds the number of steady states) depends on the initial conditions, probably there are other useful properties like that. Do you mean making a type that extend ODEProblem and storing information like that in there?

[TorkelE]

I don't have a full idea, but and ODEProblem is a representation of a simulation (which contains the ReactionSystem. So it miggt make sense to carry out network analysis stuff which is tied to simulation on that level.

Exactly how to set it up, I'm not sure of though.

[isaacsas]

I think we really want to avoid defining new versions of existing types like systems and problems. They have enormous amounts of functionality and dispatches defined on them. Having (separate) kinetic and structural property types we can attach to systems, get from systems in a standard way, and then modify/query seems much more manageable.

[isaacsas]

We can try to have an accessor to indicate / tag that a property is dependent on parameters in initial conditions.

[vyudu]

What do you mean by kinetic/structural property types?

[TorkelE]

Do we actually need to cache them? För the current ones it makes sense, since they depend on each others, and we do not want the user to have to save and pass them at each step.

But if these are all end products (?), that might not be needed (and the user can save any output that they think they might need later on, it whatever format suits them)?

[isaacsas]

@vyudu I mean having a separate StructuralProperties type (i.e. mutable struct) for parameter-independent property storage, and a separate KineticProperties type for parameter dependent properties. These can be stored within the ReactionSystem but as they are mutable can also be filled in when various analysis functions get run.

[isaacsas]

We could either have the ReactionSystem store a Dict mapping parameters to their KineticProperties, or encode this within the KineticProperties type.

[vyudu]

@TorkelE My thought was for the network summary function it would be useful to just fetch already-tested properties in case the user had called them already. And in general it seems like it could be nice to have everything collected in one place. I think complex/detailed balance and mixed volume also imply things about the number of equilibria, so they do serve some intermediate purpose.

@isaacsas that makes sense. I think having the parameters be a field of KineticProperties would be the most intuitive. Will try to circle back on this sometime next week.