You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It might make sense to layout some potential updates here that would make the workflow nicer and more consistent with other SciML libraries, but be breaking. JumpProcesses has a lot of historical cruft at this point which could potentially be cleaned up with a redesign. Some examples:
Specifying VRJ aggregators.
We essentially have a FRM currently, what I proposed the other day is a DM. There is also Anderson’s MFRM method and others. Plus the mix of integrating via the ODE integrator vs. quadrature. But selecting solvers here would require an interface.
To eventually support hybrid models it might make more sense to just have some type of structure that stores / encapsulates multiple solver selections (for constant jumps, variable jumps, ODEs, SDEs, etc), and knows how to put them together into a single solver.
For pure jump systems that have VRJs it seems like we might benefit from a version of SSAStepper or such and avoid ODE integrators (i.e. just have a time-stepper with root finding).
Not passing or building aggregators at problem construction (removing mutable state in JumpProblems). i.e. defering aggregator selection until calls to solve.
Storing rngs in integrators instead of in aggregators/JumpProblems (and providing users an API to access them that we internally use too).
Not having solve reseed when no seed is passed, but leaving such behavior to higher level callers.
reinit support to avoid overhead of reconstructing solvers if making changes as mentioned above.
Have aggregators store their kwargs, i.e. instead of passing dependency graphs as arguments to JumpProblem pass them as arguments to constructors of aggregators, i.e. NRM(; dep_graph), RSSA(; variables_to_jump_graph), etc.
Nailing down the bounded VRJ interface (should we have one function that returns all bounds and a time window, a function that just does upper bounds and time window, leave alone as separate functions as we do now)?
edit: This is just a draft, but I'll try to iterate on over time.
The text was updated successfully, but these errors were encountered:
All of these look like reasonable changes. I presume we might want a few changes to regular jumps / tau leaping as well, but I don't have any concrete suggestions right now.
For pure jump systems that have VRJs it seems like we might benefit from a version of SSAStepper or such and avoid ODE integrators (i.e. just have a time-stepper with root finding).
So a case where they are all time-dependent but not defined by an ODE? That would be fine but I haven't seen an example of that yet.
It might make sense to layout some potential updates here that would make the workflow nicer and more consistent with other SciML libraries, but be breaking. JumpProcesses has a lot of historical cruft at this point which could potentially be cleaned up with a redesign. Some examples:
solve
.reinit
support to avoid overhead of reconstructing solvers if making changes as mentioned above.NRM(; dep_graph)
,RSSA(; variables_to_jump_graph)
, etc.edit: This is just a draft, but I'll try to iterate on over time.
The text was updated successfully, but these errors were encountered: