Feedback before putting in the mass action update about jumpprocesses.jl HOT 4 CLOSED

I agree that Direct and DirectMA should be merged. However, I have to own up to not fully understanding the distinction between constant and mass action jumps. The only reason for keeping things separate would be performance. Is this correct? If so, I think this boils down to whether there is a performance penalty for adding a new field to DirectJumpAggregation. The only place I see this cropping up is in building the JumpAggregation but that should be negligible.

It should be possible to get the function wrappers working by adding the aggregate method in your gist to DirectJumpAggregation that specializes on a new aggregator algorithm. The Direct aggregator algorithm ought to be renamed, and the new aggregate method will specialize on the DirectFunWrappers type. All that is left is replacing the helper function for the next reaction with your implementation.

This brings up the issue of how to name these aggregator algorithms, so that a user can appreciate the difference solve(jump_prob, DirectTuples()) and solve(jump_prob, DirectFunWrappers()).

In this way, slight variations on the basic Gillespie algorithm (e.g. FunctionWrappers, sparse/dense stoichiometric matrix representations...) can be implemented by providing (1) a new type that implements AbstractAggregatorAlgorithm in aggregators.jl and (2) a new aggregate method that feeds in the correct types into a type constructor.

from jumpprocesses.jl.

The only reason for keeping things separate would be performance. Is this correct?

Yes that is correct. But it is a huge difference. For example, consider a system with 16 different A->B reactions (each having a different rate and ungrouped). Running the reaction 8000 times gives:

Direct method with tuples:
10.359 s (45989311 allocations: 1.03 GiB)
Direct method with function wrappers
2.928 s (29098591 allocations: 451.39 MiB)
Direct method with mass action rate function
146.208 ms (174991 allocations: 10.06 MiB)

As the number of reactions increases the function wrapper version gets much faster than tuples, but is still always much slower than the mass action jump version.

It should be possible to get the function wrappers working by adding the aggregate method in your gist to DirectJumpAggregation that specializes on a new aggregator algorithm.

That's what I did in the PR. Thanks for the suggestion!

This brings up the issue of how to name these aggregator algorithms

I used DirectManyJumps. If you have a better suggestion I'm happy to change it... I admit it's not great.

from jumpprocesses.jl.

If so, I think this boils down to whether there is a performance penalty for adding a new field to DirectJumpAggregation. The only place I see this cropping up is in building the JumpAggregation but that should be negligible.

Yeah, it would be negligible.

from jumpprocesses.jl.

Closed by 22

from jumpprocesses.jl.