Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Potential changes for a breaking release #465

Open
isaacsas opened this issue Nov 12, 2024 · 2 comments
Open

Potential changes for a breaking release #465

isaacsas opened this issue Nov 12, 2024 · 2 comments

Comments

@isaacsas
Copy link
Member

isaacsas commented Nov 12, 2024

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.

@ChrisRackauckas
Copy link
Member

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.

@isaacsas
Copy link
Member Author

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.

Modeling the changing volume of a cell is a case where ODEs aren't really needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants