SciML / JumpProcesses.jl

Build and simulate jump equations like Gillespie simulations and jump diffusions with constant and state-dependent rates and mix with differential equations and scientific machine learning (SciML)
https://docs.sciml.ai/JumpProcesses/stable/
Other
135 stars 35 forks source link

mutating parameter vector needs to call reset_aggregated_jumps! #386

Open isaacsas opened 6 months ago

isaacsas commented 6 months ago

Right now we only call reset_aggregated_jumps! when parameters are modified via remake or jprob[:psymb]. I don't think mutating jprob.prob.p directly will correctly lead to MassActionJumps getting updated.

isaacsas commented 6 months ago

We should probably document this more clearly though (i.e. we tell people in the FAQs to use remake but don't explain not to directly mutate).

TorkelE commented 6 months ago

The policy is to never mutate these directly though, and always provide functions for this. Not that there is anything that can be done to stop people, but in principle, the fields are considered internal?

isaacsas commented 6 months ago

Well, see the Slack you were just posting on.

ChrisRackauckas commented 6 months ago

The policy is to never mutate these directly though, and always provide functions for this. Not that there is anything that can be done to stop people, but in principle, the fields are considered internal?

Not necessarily. They are documented to an extent for the other problem types. prob.u0, probp. For JumpProblem I don't think it is documented that it would be prob.prob.p though, so it's at least arguably not public, but in reality most people who use the rest of SciML will assume it'll act the same.

TorkelE commented 6 months ago

Well, see the Slack you were just posting on.

I mean, I obviously saw it, that is how I got here. But it still feels like an obscure case. If we have documented that these fields exist and can be used (even for other systems) then I agree. But I figured that it was an advanced user that where poking around in internals rather than a normal case.

ChrisRackauckas commented 6 months ago
help?> ODEProblem
search: ODEProblem RODEProblem SplitODEProblem DynamicalODEProblem ODEAdjointProblem IncrementingODEProblem RODEAdjointProblem

  Defines an ordinary differential equation (ODE) problem. Documentation Page:
  https://docs.sciml.ai/DiffEqDocs/stable/types/ode_types/

  Mathematical Specification of an ODE Problem
  ============================================

  To define an ODE Problem, you simply need to give the function f and the initial condition u_0 which define an ODE:

  M \frac{du}{dt} = f(u,p,t)

  There are two different ways of specifying f:

    •  f(du,u,p,t): in-place. Memory-efficient when avoiding allocations. Best option for most cases unless mutation is
       not allowed.

    •  f(u,p,t): returning du. Less memory-efficient way, particularly suitable when mutation is not allowed (e.g. with
       certain automatic differentiation packages such as Zygote).

  u₀ should be an AbstractArray (or number) whose geometry matches the desired geometry of u. Note that we are not limited
  to numbers or vectors for u₀; one is allowed to provide u₀ as arbitrary matrices / higher dimension tensors as well.

  For the mass matrix M, see the documentation of ODEFunction.

  Problem Type
  ============

  Constructors
  ––––––––––––

  ODEProblem can be constructed by first building an ODEFunction or by simply passing the ODE right-hand side to the
  constructor. The constructors are:

    •  ODEProblem(f::ODEFunction,u0,tspan,p=NullParameters();kwargs...)

    •  ODEProblem{isinplace,specialize}(f,u0,tspan,p=NullParameters();kwargs...) : Defines the ODE with the specified
       functions. isinplace optionally sets whether the function is inplace or not. This is determined automatically,
       but not inferred. specialize optionally controls the specialization level. See the specialization levels section
       of the SciMLBase documentation
       (https://docs.sciml.ai/SciMLBase/stable/interfaces/Problems/#Specialization-Levels) for more details. The
       default is AutoSpecialize.

  For more details on the in-place and specialization controls, see the ODEFunction documentation.

  Parameters are optional, and if not given, then a NullParameters() singleton will be used which will throw nice errors if
  you try to index non-existent parameters. Any extra keyword arguments are passed on to the solvers. For example, if you
  set a callback in the problem, then that callback will be added in every solve call.

  For specifying Jacobians and mass matrices, see the ODEFunction documentation.

  Fields
  ––––––

    •  f: The function in the ODE.

    •  u0: The initial condition.

    •  tspan: The timespan for the problem.

    •  p: The parameters.

    •  kwargs: The keyword arguments passed onto the solves.

  Example Problem
  ===============

  using SciMLBase
  function lorenz!(du,u,p,t)
   du[1] = 10.0(u[2]-u[1])
   du[2] = u[1]*(28.0-u[3]) - u[2]
   du[3] = u[1]*u[2] - (8/3)*u[3]
  end
  u0 = [1.0;0.0;0.0]
  tspan = (0.0,100.0)
  prob = ODEProblem(lorenz!,u0,tspan)

  # Test that it worked
  using OrdinaryDiffEq
  sol = solve(prob,Tsit5())
  using Plots; plot(sol,vars=(1,2,3))

  More Example Problems
  =====================

  Example problems can be found in DiffEqProblemLibrary.jl (https://github.com/SciML/DiffEqProblemLibrary.jl).

  To use a sample problem, such as prob_ode_linear, you can do something like:

  #] add ODEProblemLibrary
  using ODEProblemLibrary
  prob = ODEProblemLibrary.prob_ode_linear
  sol = solve(prob)

  ──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

  ODEProblem(f::ODEFunction,u0,tspan,p=NullParameters(),callback=CallbackSet())

  Define an ODE problem from an ODEFunction.
TorkelE commented 6 months ago

Sorry, I should have shut up.