Merge pull request #249 from SciML/fix-doc-deps

fix doc dependencies

docs/Project.toml

@@ -3,4 +3,6 @@ Catalyst = "479239e8-5488-4da2-87a7-35f2df7eef83"
 DiffEqJump = "c894b116-72e5-5b58-be3c-e6d8d4ac2b12"
 DifferentialEquations = "0c46a032-eb83-5123-abaf-570d42b7fbaa"
 Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
+OrdinaryDiffEq = "1dea7af3-3e70-54e6-95c3-0bf5283fa5ed"
 Plots = "91a5bcdd-55d7-5caf-9e0b-520d859cae80"
+StochasticDiffEq = "789caeaf-c7a9-5a7d-9973-96adeb23e2a0"

docs/src/api.md

@@ -7,6 +7,7 @@ CurrentModule = DiffEqJump
 ```@docs
 JumpProblem
 SSAStepper
+reset_aggregated_jumps!
 ```
 
 ## Types of Jumps

docs/src/faq.md

@@ -110,9 +110,9 @@ used (otherwise a different time stepper is needed). When using an ODE or SDE
 time stepper any callback should work.
 
 *Note, when modifying `u` or `p` within a callback, you must call
-`reset_aggregated_jumps!(integrator)` after making updates.* This ensures that
-the underlying jump simulation algorithms know to reinitialize their internal
-data structures. Leaving out this call will lead to incorrect behavior!
+[`reset_aggregated_jumps!`](@ref) after making updates.* This ensures that the
+underlying jump simulation algorithms know to reinitialize their internal data
+structures. Leaving out this call will lead to incorrect behavior!
 
 A simple example that uses a `MassActionJump` and changes the parameters at a
 specified time in the simulation using a `DiscreteCallback` is

docs/src/tutorials/discrete_stochastic_example.md

@@ -184,7 +184,7 @@ people, and solve the problem from `t=0.0` to `t=250.0`. We use the parameters
 
 ```@example tut2
 p     = (:β => 0.1/1000, :ν => 0.01)
-u₀    = [:S => 999, :I => 1, :R => 0]
+u₀    = [:S => 999, :I => 10, :R => 0]
 tspan = (0.0, 250.0)
 prob  = DiscreteProblem(sir_model, u₀, tspan, p)
 ```
@@ -301,7 +301,7 @@ jump2 = ConstantRateJump(rate2,affect2!)
 We will start with `999` susceptible people, `1` infected person, and `0`
 recovered people, and solve the problem from `t=0.0` to `t=250.0` so that
 ```@example tut2
-u₀    = [999, 1, 0]
+u₀    = [999, 10, 0]
 tspan = (0.0, 250.0)
 ```
 *Notice, the initial populations are integers since we want the exact number of
@@ -538,7 +538,7 @@ function f(du, u, p, t)
   du[4] = u[2]*u[3]/100000 - u[1]*u[4]/100000
   nothing
 end
-u₀   = [999.0, 1.0, 0.0, 100.0]
+u₀   = [999.0, 10.0, 0.0, 100.0]
 prob = ODEProblem(f, u₀, tspan, p)
 ```
 Notice we gave the 4th component a starting value of 100.0, and used floating
@@ -570,7 +570,7 @@ is not constant between jumps, *we must use a `VariableRateJump`*.
 
 Solving the equation is exactly the same:
 ```@example tut2
-u₀   = [999.0, 1.0, 0.0, 1.0]
+u₀   = [999.0, 10.0, 0.0, 1.0]
 prob = ODEProblem(f, u₀, tspan, p)
 jump_prob = JumpProblem(prob, Direct(), jump, jump2, jump3)
 sol = solve(jump_prob, Tsit5())

src/aggregators/aggregated_api.jl

@@ -1,15 +1,14 @@
 """
-    reset_aggregated_jumps!(integrator,uprev = nothing; update_jump_params=true)
+    reset_aggregated_jumps!(integrator, uprev = nothing; update_jump_params=true)
 
 Reset the state of jump processes and associated solvers following a change
 in parameters or such.
 
 Notes
-    - `update_jump_params=true` will recalculate the rates stored within any 
+    - `update_jump_params=true` will recalculate the rates stored within any
       MassActionJump that was built from the parameter vector. If the parameter
       vector is unchanged this can safely be set to false to improve performance.
 """
-
 function reset_aggregated_jumps!(integrator, uprev = nothing; update_jump_params = true,
                                  kwargs...)
     reset_aggregated_jumps!(integrator, uprev, integrator.opts.callback,