DifferentialEquations v1.9.1 is a feature update which, well, brings a lot of new features. But before we get started, there is one thing to highlight:
I first want to highlight upcoming API changes so that users can be aware. These are changes that have been discussed for quite awhile. I would like to make these changes before the JuliaCon workshop "sets in stone" the API. Most of the changes are rather minor.
NOTE: Please feel free to comment in the issues! APIs are for the users, and so if there's anything you think would make things easier to use, now is the time to say something!
https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/132 https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/133 https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/139
These changes detail changes in how one can specify timepoints to save. The summary is:
If you give saveat a scalar, it will save at the timepoints tspan[1]:saveat_num:tspan[end].
Using saveat will default save_timeseries to false, meaning that if you set saveat, it will only save at the points you requested. This will also turn off dense output. These can then manually be turned on via save_timeseries=true,dense=true. Note that these will still default to true when no saveat is given. The reasoning is that, if you choose saveat points, you likely only want those timepoints!
save_timeseries will be renamed save_everystep. There have been lots of questions about what this argument means, and the name change should clarify it.
saveat_idxs: Allows you to choose which components to save. This way you can save memory and simply save the components you want. Not every solver will be able to support this, but the *DiffEq methods will for sure.
There is a lot of bikeshedding for the future of the @ode_def DSL. For information, please see:
https://github.com/JuliaDiffEq/ParameterizedFunctions.jl/issues/17
Essentially, the breaking change will be x_t instead of dx for writing the derivative part (meaning derivative in time). This makes it easier to carry over into things like PDEs and DAEs. While this is breaking, this should be a very simple fix.
There is a question as to whether we should keep the sol[:,i] as the way to get the timeseries for the ith component, or change that to sol[i,:]. The reason this was originally chosen was because it's stored as a vector of arrays, so it naturally indexes like sol[:][i]. However, since indexing "within the same timepoint" is faster, this convention breaks column-major ordering which is prevalent in Julia. Thus with sol[i,:], it would be more apparent that the faster indexing is the inner indexing. The full proposal is here:
https://github.com/JuliaDiffEq/DifferentialEquations.jl/issues/152
While this is likely not going to be a huge internal change, it is a breaking change which can get opinioned. Whatever the indexing choice is, this setup will be made more generic for a wrapper of VectorOfArrays, making it "more standard" throughout the diffeq ecosystem.
Now, onto the new features!
This change is by a new contributor, Ayush Pandey. The Two-stage method is a statistical method for estimating the parameters of ODE systems. While restricted to ODEs, it's a very robust method which can be used to get the general ballpark for parameters even when the model is slightly wrong. Since it does not actually require solving the ODEs, it is a very fast method as well. One very good use of this method is to get an approximate answer, which can then be refined with the nonlinear regression approaches.
This method will be added to the documentation in the near future. Many more updates to parameter estimation are planned, such as likelihood and Bayesian techniques.
This is more of a development change, but I wanted to mention that the parameter interface has been refined to work entirely off of dispatches. This means that the development tools can query for the parameters of problems which even have parameters on multiple different functions. A good example is an SDEProblem which has parameters on both f and g.
A side effect is that now the parameter estimation tools are compatible with more than just ODEProblem types: it's compatible with any DEProblem. This brings me to my next point.
The changes to the Monte Carlo interface is large. To see how to use the newest version of this interface, see the documentation page here:
https://docs.juliadiffeq.org/latest/features/ensemble
The biggest part of this change is that now you can specify how the simulations are reduced, instead of saving the solution object each time. Thus you can specify an output_func and just save the last value of the 1st component, allowing you to run millions of simulations without running out of memory.
In addition, the setup is now along the lines of creating a MonteCarloProblem and calling solve on this problem. Because of this, a few things happen. First of all, solving Monte Carlo problems is now naturally compatible with addons of the common solve interface. But secondly, the dispatches on the parameter interface can apply, meaning different parts of the MonteCarloProblem can be parameterized. This means that parameter estimation routines can be run to estimate parameters using Monte Carlo simulations! Optimize the mean-squared error over many replicates of a stochastic problem, and estimate population parameters.
PyDSTool.jl is a new wrapper for the Python library PyDSTool. While it can do things like solve ODEs, those features are not of much use. However, with this wrapper comes PyCont, a library for continuation (bifurcation plots). You can see an example for making bifurcation plots here:
https://docs.juliadiffeq.org/latest/analysis/bifurcation
This is in its very early stages, but now that it is working all that's left are API improvements! But note that it's currently disabled due to a Windows bug with PyCall's latest release. This will be fixed very soon, and DifferentialEquations will be patched in a way that makes PyDSTool.jl a standard tool in the ecosystem.
Retcodes are hard to make sexy, but they are useful.
https://docs.juliadiffeq.org/latest/basics/solution
Now the solvers have a set way to tell you if the solver was successful, or why it exited pre-maturely. This setup will grow overtime, but is already fully functional.
Callbacks are now allowed to have an initialize function which will be run before a simulation begins. Thus if you need to initiate some random event at the start of a simulation, or set some values in the callback using values from the problem, callbacks can do this.
The Gillespie-type jumping models have improved behavior. Before, the starting random numbers would only be generated on construction of the jump type. This lead to some weird behavior. But initiating a new first jump using the callback initialization phase, every simulation will have a different first jump just by calling solve another time.
Now you can choose a function to be called on the plotted points. This allows you to easily do things like plot the norm of the solution over time. For more information, please see the improved plotting docs:
https://docs.juliadiffeq.org/latest/basics/plot
The SplitODEProblem is the generic diffeq answer to IMEX problems. It was implemented by a new contributor Om Prakash. These allow you give define an ODE by a tuple of functions instead of a single function. Solvers can then use these components separately. This is sufficient for specifying any PDE method, and so we will be using this to implement PDE methods. Docs will be added when the solvers which make use of this are created.
This was implemented by a new contributor Hendrik Ranocha. These methods are higher-order methods which are capable of solving the semi-discretizations arising form hyperbolic partial differential equations which have some discontinuities. You can find these algorithm choices in the docs:
https://docs.juliadiffeq.org/latest/solvers/ode_solve
This was implemented by a new contributor Ethan Levien. Split coupling of jumps allows the variance of Monte Carlo estimates to be reduced, allowing you to estimate moments estimators with less runs. He is developing a more general approach which will extend the Monte Carlo setup and do things like Multi-Level Monte Carlo.
Docs for this coming soon.
Many Google Summer of Code (GSoC) applications went in for JuliaDiffEq. This means there is a lot of potential GSoC activity over the summer with new contributors (students) expanding the ecosystem. A post will detail what these project will be about when more information is known. This will likely guide a good portion of JuliaDiffEq summer activity.