rate function interface

[isaacsas]

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]

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

[isaacsas]

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]

@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]

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:

JumpProcesses.jl/src/problem.jl

Line 272 in fd47a82

update_jumps!(du, u, p, t, length(u.u), jumps...)

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