Simulating MJPs many times with different parameters as inner loop

[Sam_Power]

Hi,

I’m currently coding up a particle filter (a.k.a. Sequential Monte Carlo, among other names) for approximate inference in Chemical Reaction Networks. My dynamics for the propagation of particles will be based on the SSA algorithm, as implemented within DifferentialEquations.jl.

The plan is to eventually use this filter within a Particle MCMC scheme (with some extra details), and so I need to be able to run the SSA algorithm many times, with many different initial conditions, and with different rate constants. For the moment, let’s just focus on varying the initial conditions.

My main concern is how I should construct the DiscreteProblem, JumpProblem objects which will be solved in the main loop of the filter. Below is a toy version of the problem in which I am interested:

using Catalyst, DifferentialEquations, Distributions

lotvol_model = @reaction_network begin
    c1, x1 --> 2x1
    c2, x1 + x2 --> 2x2
    c3, x2 --> 0
end c1 c2 c3

# Generate synthetic data
x0 = floor.(100 * rand(10))
y0 = [rand(Poisson(1)) for i in 1:10]

# Advance MJP from x by time Δt, with rates c

function MJPStep_LotVol(x, c, Δt)
    MJP = DiscreteProblem(lotvol_model, x, (0.0, Δt), c)
    jump_prob = JumpProblem(lotvol_model, MJP, Direct())
    sol = solve(jump_prob, SSAStepper())
    return sol(Δt)
end

# Importance Sampling with 
# prior (independently across time) x[1], ... , x[T], 
# evolution by MJP with rates c, and
# data y[1], ..., y[T]

function ImportanceSampling(x, y, c)
    T = length(y)
    Z = zeros(T)
    W = zeros(T)            

    for t = 1:T
        Z[t] = MJPStep_LotVol(x[t], c, 1)       # propagate particle using SSA
        W[t] = logpdf(Poisson(Z[t]), y[t])      # weight particle by observation likelihood
    end
end

The situations in which I am interested correspond (roughly) to T in the above being very large.

My main worry is that the way in which I define MJPStep_LotVol(x, c, Δt) is probably quite inefficient - I’m guessing that forming the DiscreteProblem, JumpProblem at each step in the inner loop could be quite costly, or might be in some way unnecessary?

On the other hand, the problems which the function is trying to solve at each step are very similar (in this example, they only differ in initial conditions) and so it seems reasonable that there’s a simpler solution which isn’t so costly.

[lmiq]

I cannot go deeply in your code to see if this makes sense, but maybe this thread is useful to give you insights:

Define data-dependent function, various ways

This is a topic that is frequently raised here (I have asked this before). The problem is that of defining a function that will be input as a parameter for a solver, but the function depends on data while the function call inside the solver does not have a field to accept the data. Usually, the first try of a new programmer is to set the data on global variables, which is very detrimental to performance. Soon one finds out that if one declares the data as a constant global the performance is goo…

[Sam_Power]

Thank you, this looks useful and relevant - I will have a read through it.

In the mean time, I’ve run (a debugged) version of the above code, and the cost of re-forming the sub-problems is not as bad as I had worried. There are probably still ways of speeding it up, though, so it should be worthwhile to read through the above.

[ChrisRackauckas]

@Sam_Power

My main worry is that the way in which I define MJPStep_LotVol(x, c, Δt) is probably quite inefficient - I’m guessing that forming the DiscreteProblem, JumpProblem at each step in the inner loop could be quite costly, or might be in some way unnecessary?

It is unnecessary. I assume you just want to tell the stepper to take new random numbers?

[Sam_Power]

New random numbers, possibly new initial conditions / new rate constants, but the same set of reactions throughout.

[ChrisRackauckas]

Then you just need to call DiffEqJump.reset_aggregated_jumps!. It’s not documented yet, but it should work just fine.

[Sam_Power]

Would it be possible to elaborate on how this should be implemented?

e.g. if I do something like

DiffEqJump.reset_aggregated_jumps!
sol = solve(jump_prob, SSAStepper())
return sol(Δt)

then I don’t ever pass the new rate constants c to the solver.

Do I modify jump_prob in-place somehow to hand it new initial conditions + rate constants?

I’m assuming that it is worth avoiding having to re-define

MJP = DiscreteProblem(lotvol_model, x, (0.0, Δt), c)
jump_prob = JumpProblem(lotvol_model, MJP, Direct())

for each new c.

[ChrisRackauckas]

Sorry, just found this question again. You just add DiffEqJump.reset_aggregated_jumps!(integrator) inside of your callback.

[Sam_Power]

No problem, and thank you. I apologise, but I’m still not totally following. I’ll try to simplify my example, and be a bit more specific.

I’ll say that I have a few different initial conditions from which I want to solve the MJP, and call them x[1], x[2], x[3].

using Catalyst, DifferentialEquations, Distributions

# specify parametrised MJP system
birthdeath_model = @reaction_network begin
    c1, x1 --> 2x1
    c2, x1 -> 0
end c1 c2

X_Initial = [10, 40, 70]
C_Global = [1, 2]

X_Final = zeros(3)

for i = 1:3
   MJP = DiscreteProblem(birthdeath_model, X_Initial[i], (0.0, 1.0), C_global)
   jump_prob = JumpProblem(birthdeath_model, MJP, Direct())
   X_Final[i] = solve(jump_prob, SSAStepper())

Where in the for loop does the DiffEqJump.reset_aggregated_jumps! call go?

I can sort of see how if it were the same JumpProblem for each i, then I could do something like

for i = 1:3
   DiffEqJump.reset_aggregated_jumps!(SSAStepper())
   X_Final[i] = solve(jump_prob, SSAStepper())

- would this be correct?

For my problem, I need to change the parameters of the problem at each step as well, and I’m assuming that reset_aggregated_jumps doesn’t handle this issue (?). So if I’m going to get rid of the lines of code which start with MJP =, jump_prob = , then I will need to specify the new initial conditions somewhere in the loop - otherwise I will end up re-solving the original problem with the same initial conditions. Maybe I’m missing something simple.

Thanks again for your help and patience.

[ChrisRackauckas]

@Sam_Power

For my problem, I need to change the parameters of the problem at each step as well, and I’m assuming that reset_aggregated_jumps doesn’t handle this issue (?). So if I’m going to get rid of the lines of code which start with MJP = , jump_prob = , then I will need to specify the new initial conditions somewhere in the loop - otherwise I will end up re-solving the original problem with the same initial conditions. Maybe I’m missing something simple.

It does handle it. Whether nothing changes or everything changes, it’s correct because of the no-memory property of the exponential distribution. But if anything changes you have to have it of course.

[isaacsas]

@Sam_Power For your example, a MassActionJump should be getting created. Changing the parameter vector is unfortunately not currently propagated to the MassActionJump, which internally stores the rates for each jump, unless you create an entirely new JumpProblem. That said, it should be possible to get the MassActionJump within an existing JumpProblem and then change entries in the scaled_rates field directly. After that one would call reset_aggregated_jumps! as @ChrisRackauckas mentions.

I’ll try to put an example together of doing this for you in the next day or two, and verify it does indeed propagate the changed rates ok. (Sorry that I had missed your initial question. Feel free to ping me on Slack through the DiffEq-Bridged or SciML channels with future questions, or post to the DiffEqJump issues on Github – sometimes it is easy to miss stuff on Discourse.)

More generally we probably need some API functions that make this an easier process for users.

[isaacsas]

OK, so on a quick glance, if you only need to change parameters between solves this seems to work (but note the caveats I mention at the end):

using Catalyst, DiffEqBase, DiffEqJump
 rn = @reaction_network begin
           α, S + I --> 2I
           β, I --> R
         end α β
p = [.1/1000, .01]
tspan = (0.0,250.0)
u0 = [999,1,0] 
dprob = DiscreteProblem(rn,u0,tspan,p)
jprob = JumpProblem(rs, dprob, Direct())
sol = solve(jprob, SSAStepper())

# change the rate of the first reaction
jprob.massaction_jump.scaled_rates[1] = .001
sol = solve(jprob, SSAStepper())

I think this should work ok for changes between simulations, especially for Direct, but please test with some examples of your own before trusting! I don’t think reset_aggregated_jumps! is actually needed here since the jump data structures are reinitialized with each call to solve, but again please double check on your own examples and let us know if you have any issues.

Now the caveats: if any of your reactions are not mass action, i.e. the rate is time-dependent or something like

k1*S,  S+I -> R

where the rate expression involves a species, then you need to figure out the internal reaction order. In the generated JumpSystem, we internally order MassActionJumps in the order they appear within the reaction_network macro, so that will tell you the ordering of rate constants in the scaled_rates field. If you want to update the rate for a reaction involving a time-dependent component or as above, i.e. a reaction that is internally stored as a ConstantRateJump or VariableRateJump, you need to update the p vector and call reset_aggregated_jumps! as Chris mentioned.

The other thing to be aware of is that for a reaction like

k1, A+A -> B

the corresponding entry in scaled_rates will be k1/2, so if you update such an entry you should make sure to divide by two to preserve the correct scaling. (See Model Simulation · Catalyst.jl)

[Sam_Power]

Thanks for this - this is very close to what I’m looking for! I’ll try to get in touch via Slack going forward.

[isaacsas]

Posting here is fine too! If you drop a link in the Slack channels though that will help with noticing your post if it seems we missed it.

[Sam_Power]

Great, that sounds good. I’ve had a look through the API, and I think that I’m a bit closer to a solution now. I follow that

jprob.massaction_jump.scaled_rates[1] = .001

is being used to change the parameters, and so I’m guessing that something broadly similar should work to change the initial conditions.

At the moment, I’ve tried a couple of things lke

jprob.states = [499,1,0]
jprob.prob.states = [499,1,0]
jprob.prob.u0 = [499,1,0]

but these don’t seem to be working quite right. It seems like reinit is the way to handle this for ODEs, but doesn’t apply to jprob since it’s not an integrator per se (?). Is there an analog for jump problems?

[isaacsas]

What about jprob.prob.u0 .= [499,1,0]?

[Sam_Power]

There we go - it seems to be working, thank you!

[isaacsas]

Just to followup on this; remake should now properly change the initial condition and parameters for JumpProblems, and we’ve added examples for this to the docs.