Sam Isaacson

Which I guess would break the whole purpose of the `ExtendedJumpArray`s, i.e. https://github.com/SciML/DiffEqJump.jl/blob/c66a4d9595813199f0e9e794d2d43880f25759eb/src/problem.jl#L189-L192 Otherwise, the solvers shouldn't really be making use of the `ExtendedJumpArray` anywhere outside of DiffEqJump right? i.e....

@ttolppanen at this point I have to turn it over to @ChrisRackauckas as this is getting too much into the weeds of the general way that integrators and solution objects...

What about dropping the ExtendedJumpArrays, and instead building a functor with internal state for the `jump_u`s that handles the ode rhs and callback functions?

I meant that the state in integrators and solution objects is just the user’s type. The functor is a wrapper that serves as the ODE’s internal rhs function, and the...

Ahh, got it. Right, the intensities won’t get automatically integrated by that approach.

Yeah, that flexibility would be good, and is something we should support more generally anyways. We have no explicit mark support currently, and since users doesn't have access to the...

I'm not sure though that allowing marks to `MassActionJump`s really makes sense. Allowing marks will presumably mean allowing a user-defined `affect!` function too, at which point one is basically back...

There is still a ways to go till we support the full graph generality we need.

That would be great! There have definitely been people that asked about this.

Sorry for missing this post! Yes, people definitely are interested in systems with interparticle forces. We've actually worked out a method recently to handle them in reaction-drift-diffusion situations and are...