Accuracy of "Events" in ode45 in Matlab - matlab

I'm consider a problem of integrating until an event occurs using ode45 in Matlab, as in here:
http://www.mathworks.com/help/techdoc/math/f1-662913.html#f1-670140
Is there a way to control how accurately Matlab computes the event location? More specifically, the events tell you to solve on ODE until one finds a zero of the value parameter, but how small is value? Is there a way to specify how small I want value to be when the integration terminates?

Is there a way to control how accurately Matlab computes the event
location?
The short answer appears to be "no, but it's at machine precision anyway". Matlab's ode45 (and the rest, like ode15s, ode23, etc.) calls a function called odezero, which does the work of computing the zero events of the ODE integrators. Here are the relevant lines in odezero where the tolerance is set:
tol = 128*max(eps(t),eps(tnew));
tol = min(tol, abs(tnew - t));
From this, you can see two things: (1) there is no dependence on any user options and (2) even if you had control, you couldn't set it any smaller because the tolerance is 128*eps.
Is there a way to specify how small I want value to be when the
integration terminates?
Matlab's ODE event detectors don't look for value going to zero or getting close to zero, it looks for it crossing zero. If you want to look for a particular value of the ODE crossing a certain value, then have the event function return the difference between the solution and the desired threshold.

Related

Explain Matlab ode45 output. Is ode45 an iterative algorithm?

I tried to use ode45 to solve an equation, and get output like the following. I get the idea it is trying to estimate using nearby points (as explained here https://www.mathworks.com/videos/solving-odes-in-matlab-6-ode45-117537.html). By my understanding, it should solve the equation in one round of computation? but the output looks like ode45 is an iterative algorithm (so that it generates output that repeat the '... steps ... failed attempt ... function evaluations' over and over again)? If it is iterative, could you help give some detail or references? Thanks!
ode45 is an iterative adaptive ODE solver. That is, it uses a 5th order (FSAL) method to propose the an update using some stepsize h. Then it does the same again, but now with a 4th order method, then it compared those two updates to one another, if the difference is less than some local tolerance, it accepts the proposed update. If the difference is larger than some local tolerance, the update is rejected and the stepsize is lowered (in some smart way).
To reduce the cost of using both a 4th and 5th order method, those two methods uses (roughly) the same function evaluations.
As for your output, it is, as also noted by #LutzL, not the standard output, which might point to an error in your code.

Solving ODEs in NetLogo, Eulers vs R-K vs R solver

In my model each agent solves a system of ODEs at each tick. I have employed Eulers method (similar to the systems dynamics modeler in NetLogo) to solve these first order ODEs. However, for a stable solution, I am forced to use a very small time step (dt), which means the simulation proceeds very slowly with this method. I´m curious if anyone has advice on a method to solve the ODEs more quickly? I am considering implementing Runge-Kutta (with a larger time step?) as was done here (http://academic.evergreen.edu/m/mcavityd/netlogo/Bouncing_Ball.html). I would also consider using the R extension and using an ODE solver in R. But again, the ODEs are solved by each agent, so I don´t know if this is an efficient method.
I´m hoping someone has a feel for the performance of these methods and could offer some advice. If not, I will try to share what I find out.
In general your idea is correct. For a method of order p to reach a global error level tol over an integration interval of length T you will need a step size in the magnitude range
h=pow(tol/T,1.0/p).
However, not only the discretization error accumulates over the N=T/h steps, but also the floating point error. This gives a lower bound for useful step sizes of magnitude h=pow(T*mu,1.0/(p+1)).
Example: For T=1, mu=1e-15 and tol=1e-6
the Euler method of order 1 would need a step size of about h=1e-6 and thus N=1e+6 steps and function evaluations. The range of step sizes where reasonable results can be expected is bounded below by h=3e-8.
the improved Euler or Heun method has order 2, which implies a step size 1e-3, N=1000 steps and 2N=2000 function evaluations, the lower bound for useful step sizes is 1e-3.
the classical Runge-Kutta method has order 4, which gives a required step size of about h=3e-2 with about N=30 steps and 4N=120 function evaluations. The lower bound is 1e-3.
So there is a significant gain to be had by using higher order methods. At the same time the range where step size reduction results in a lower global error also gets significantly narrower for increasing order. But at the same time the achievable accuracy increases. So one has to knowingly care when the point is reached to leave well enough alone.
The implementation of RK4 in the ball example, as in general for the numerical integration of ODE, is for an ODE system x'=f(t,x), where x is the, possibly very large, state vector
A second order ODE (system) is transformed to a first order system by making the velocities members of the state vector. x''=a(x,x') gets transformed to [x',v']=[v, a(x,v)]. The big vector of the agent system is then composed of the collection of the pairs [x,v] or, if desired, as the concatenation of the collection of all x components and the collection of all v components.
In an agent based system it is reasonable to store the components of the state vector belonging to the agent as internal variables of the agent. Then the vector operations are performed by iterating over the agent collection and computing the operation tailored to the internal variables.
Taking into consideration that in the LOGO language there are no explicit parameters for function calls, the evaluation of dotx = f(t,x) needs to first fix the correct values of t and x before calling the function evaluation of f
save t0=t, x0=x
evaluate k1 = f_of_t_x
set t=t0+h/2, x=x0+h/2*k1
evaluate k2=f_of_t_x
set x=x0+h/2*k2
evaluate k3=f_of_t_x
set t=t+h, x=x0+h*k3
evaluate k4=f_of_t_x
set x=x0+h/6*(k1+2*(k2+k3)+k4)

using "Refine" option in Matlab's ode45

I am trying to use ode45 in MAtlab and want to fix the number of points that MAtlab uses (number of time steps). Using the 'refine' option in ode45 seems not to help. For instance, if I set 'refine' to be 10, Matlab returns an array of 101.
Changing 'RelTol' and 'AbsTol' also does not help either. I know that it is possible to write tspan as [0,t1,t2,t3,...,tn] and that solves this issue, but I'd like to fix number of points via the 'refine' option.
Perhaps you misunderstand what the 'Refine' option actually does. From the documentation for odeset:
Refine — If Refine is 1, the solver returns solutions only at the end of each time step. If Refine is n >1, the solver subdivides each time step into n smaller intervals and returns solutions at each time point. Refine does not apply when length(tspan)>2 or the ODE solver returns the solution as a structure.
In other words, setting 'Refine' to 10 does not guarantee that you'll get 10 output points but rather that you'll get 10 output points per integration time step. In the case of an adaptive step size method like ode45, the solver chooses how big the steps are based on many criteria. If you want a given number of output points you must specify fixed time steps as you've already done via tspan. The linspace function might be helpful to you.
Another possibility is that you're not actually applying your options. Simply calling odeset is not sufficient. You must also remember to pass the output into ode45.

Accuracy of numerical integration in Matlab

I am trying to integrate an analytic function (a composite of sqrt and trig function) on a rectangle area. It has no singularity point in the area and seems to be a perfect candidate to use dblquad. My question is how to evaluate the accuracy of the numerical value that Matlab provided to me. Without knowing the exact value of the integration, how can we justify the significant-digits? When you are required to give a value with certain digits of precision, you should be able to justify. Is it possible to achieve this given the value is calculated by using Matlab?
Unless you set it otherwise, dblquad uses a default tolerance threshold (10-6 in the latest releases) for the absolute quadrature error. The approximation of the integral will be within an error no larger than the specified tolerance.
You could have a peek at the source code for dblquad, somewhere it will be using a certain number of 'steps'. I guess you could make a new m-file with the important bits that get the integral working and play around with the number of steps until it takes the computer a long time and doesn't change the result. Personally I use a custom simpsons rule for numerical integration and just change N (number of steps) to some large number.

By setting a tspan=[to:very_small_step:tf], can it affect ode45 solver's step size?

I have know that the ode45 solver has adaptive step size controlled by Matlab program itself. The description below is given by Matlab website:
Specifying tspan with more than two elements does not affect the internal time steps that >the solver uses to traverse the interval from tspan(1) to tspan(end). All solvers in the ODE >suite obtain output values by means of continuous extensions of the basic formulas. Although >a solver does not necessarily step precisely to a time point specified in tspan, the >solutions produced at the specified time points are of the same order of accuracy as the >solutions computed at the internal time points.
However, if I specify very_small_step in tspan=[to:very_small_step:tf], will this affect program controlled step size. Will this force step size less than the value of very_small_step? OR matlab will make interpolation calculation to get the corresponding result at specified time point?
From your quote
Specifying tspan with more than two elements does not affect the internal time steps
Also there exists the MaxStep property to configure the maximum step size.
For steps in between the solvers use continuous extension formulas as described here.
Why are you asking anyway? What problem do you encounter?