search

SciML / JumpProcesses.jl

Build and simulate jump equations like Gillespie simulations and jump diffusions with constant and state-dependent rates and mix with differential equations and scientific machine learning (SciML)
https://docs.sciml.ai/JumpProcesses/stable/
Other
140 stars 35 forks source link

rate function interface #314

Open isaacsas opened 1 year ago

isaacsas commented 1 year ago

Is there a reason that rate functions for jumps don't take integrators? One disadvantage of this design is that one can't use the new symbolic indexing options in them.

ChrisRackauckas commented 1 year ago

They do take integrators, but the issue is that it needs to be interpolated to the right point.

isaacsas commented 1 year ago

Ahh yes, I always mix it up with the jump rate definition. I guess I was actually thinking of the latter (which is of the form rate(u,p,t), i.e. doesn't take the integrator).

isaacsas commented 1 year ago

@ChrisRackauckas what do you think about using SciMLBase.numargs to add support for single argument rate(integrator) functions? (Basically, we create a wrapper if passed a rate(u,p,t) function which forwards the appropriate integrator fields, letting us standardize on rate(integrator) as the real interface.)

My thought is this would ensure rate, condition, and affect functions across callbacks and jumps all have access to integrators. Users would then always have access to the symbolic indexing.

We could also then unify that rngs are stored in integrators across SciML, which fixes the issue that we store them in the JumpAggregations here, and means users would be able to use the internal rng we are using in their callback/jump functions. (It also avoids having to break/modify the definition of rate and affect functions to support an explicit rng argument.) Of course, it would then require adding this field across to most ODE/SDE integrators, which I guess could be a lot of work?

isaacsas commented 1 year ago

Ahh, I see that this won't work for variable rates since they have to support being called without integrators via the ODE derivative interface:

https://github.com/SciML/JumpProcesses.jl/blob/fd47a8212711c85687e93b8bc9e90e82fb134d36/src/problem.jl#L272

That's unfortunate as this seemed like a clean way to pass around rngs too.