Coupling two JumpProblems about jumpprocesses.jl HOT 3 OPEN

Yes, that sounds like it would work. The rates are all stored in the discrete_jump_aggregation, so you can definitely double the size of the problem and create a DiscreteCallback which implements the algorithm from the paper. I don't think it would be possible to handle the variable rate callbacks with this algorithm though (the way to extend it would require doing everything via the SDE multi-level Monte Carlo method).

Also, note that there isn't a tau-leaping implementation yet, but it should be fairly simple to make a new aggregator following the template of Direct(), and have it instead just do the tau-leaping algorithm (and other variants of it). It seems then like there should be a way to make a construct_coupling implementation from that paper which is independent of the choice of the constant rate jump aggregator.

(Note the "new" terminology: I denote these as "aggregators" since what things like Gillespie's method does is aggregate all of the constant rate jumps into one callback, leaving the word "algorithm" for the ODE/SDE algorithm since the main goal is to couple all of them... if you know of a better term I'm open for suggestions).

from jumpprocesses.jl.

For the split coupling it seems construct coupling can be implemented without creating a new DiscreteCallback directly, and this is entirely independent of the aggregator. This is nice, since many researchers may be more interested in playing around with different coupled representations than the specific algorithm.

Would you like construct_coupling to be implemented within this package? I can put in a PR once I clean up my implementation and make some tests.

from jumpprocesses.jl.

This is nice, since many researchers may be more interested in playing around with different coupled representations than the specific algorithm.

Yeah, my main goal with all of this is to have a massive base for testing new algorithms. That already exists for differential equations through DiffEqDevTools + interop to all the C/FORTRAN solvers. I think for this to be really interesting, DiffEqDevTools/DiffEqProblemLibrary should get some tools for analyzing the timing and error of different jump problems / discrete aggregators. I'm not sure of a good way to do this though, because I'm not sure of any good discrete stochastic problems to test on with analytically known mean/variances. And this would only test in a "weak" sense: is there a way to strong test errors of jump equations? If you know of one, please share. Otherwise the only way to test errors is to do a massive simulation and get the values very exact, which can be a costly way to test.

Would you like construct_coupling to be implemented within this package?

For sure, this is a good place for it to go.

from jumpprocesses.jl.