In Matlab I know how to solve an ODE until an even occurs (for example, solve the ODE until the y-coordinate is zero):
http://www.mathworks.com/help/techdoc/ref/odeset.html#f92-1017470
Is there an analogy in Octave?
Here is the relevant code:
lsode_options('Events', #events);
t0 = linspace (0, 20, 1000);
[t,x,te,ye,ie] = lsode(#HH, ynot, t0);
Install the package odepkg from Octave-Force. You may well already have this installed. You then use the ode solver functions from this package, which have identical syntax to the Matlab ode solvers, such as ode45. Note that the names of the solvers may not be identical, and you will need to find the appropriate one for your problem. ode45 does appear to have an implementation in the latest version though.
Related
im using Matlab to trying to solve 2 equations with 2 variables.
I define the 2 functions, f2(n_1,n_2),f3(n_1,n_2) which both depend on f1(n_1,n_2), then I defined the vectorised function G(n_1,n_2) which contain both of them.
Later I defined a the desired stating point, and tried to solve. but when running the code it raise an error which I'm not fully understand.
the above mentioned is displayed in the code below:
the code:
clear, close all; clc
%Const
N0=25;
G1=1;G2=1;
a1=6;a2=3;
k1=1;k2=4;
%main
syms n_1 n_2
X_0=[-5;5];
f1=N0-a1.*n_1-a2.*n_2;
f2=f1.*G1.*n_1-k1.*n_1;
f3=f1.*G2.*n_2-k2.*n_2;
G=#(n_1,n_2) [f2;f3];
s = fsolve(G,X_0);
the error:
Error using fsolve (line 269)
FSOLVE requires all values returned by functions to be of data type double.
Error in Ex1_Q3_DavidS (line 37)
s = fsolve(G,X_0);
thanks
fsolve is a function that uses numerical methods to find the root of a numerical function.
A numerical function is, for example f=#(x)x^2=2;. In MATLAB, you can evaluate f() at any number and it will return a number, but there is no higher order mathematical abstraction to it. This is however the fastest way to do maths in a computer, as it is not a higher intelligence, just a glorified calculator.
Some people however, want to give higher intelligence to computers and coded very complex symbolic toolboxes that with sets of rules try to teach computers to think semi-like humans and solve symbolic equations, as you do in paper. To solve those equations a function called solve is introduced in MATLAB.
You are doing symbolic math, but using the numeric solver. It does not work, just use the symbolic solver for symbolic math.
I have a system that looks like
dn/dt=f(n,v)
dh/dt=g(h,v)
I want to solve this equation on the manifold F(v,n,h)=0, a nonlinear function in v. I tried to use something like v=fzero(#(x) F(x,n,h),0) to solve for the value of v on the manifold at each time step. But this is incredibly slow and ode15s (my system is a relaxation oscillator) fails to meet integration tolerance. How do I find solution to the ODE on the manifold defined by F(v,n,h)=0?
I find #LutzL's comment very helpful. It is possible to set up a DAE solver using ode15s.
Example: The "Solve Robertson Problem as Semi-Explicit Differential Algebraic Equations (DAEs)" section in https://www.mathworks.com/help/matlab/ref/ode15s.html
In my case, I would setup a matrix:
M=[zeros(1,3);0,1,0;0,0,1];
options = odeset('Mass',M,'RelTol',1e-5,'AbsTol',1e-6,'MaxStep',0.01);
y0=[v0,n0,h0];
[T,Y]=ode15s(#slow,[0 50],y0,options);
And slow is a function defined as:
function dy = slow(t,y)
v=y(1); n=y(2); h=y(3);
dy=zeros(3,1);
dy(1)=F(v,n,h);
dy(2)=f(n,v);
dy(3)=g(h,v);
end
One of the possible ways to solve this problem is to differentiate
the F(v,n,h)=0 equation:
Now we can obtain the ODE system
or
which can be solved in the usual way.
I'm trying to derive Lagrangian equations of motion in Matlab using the symbolic toolbox. This involves partial derivatives of a function and your coordinates, but matlab seems to not accept this.
So I would do this in Matlab:
syms t x(t) % t: time, x(t) position dependent on time
m = sym('m'); % mass, a constant parameter
T = m/2*diff(x,t)^2; % kinetic energy
dTdx = diff(T,x);
ddTdxDotdt = diff( diff(T,diff(x,t)), t);
But as soon as I try to differentiate anything in x (or diff(x,t)), Matlab complains:
Error using mupadmex
Error in MuPAD command: The variable is invalid. [stdlib::diff]
Error in sym/diff (line 44)
R = mupadmex('symobj::diff', S.s, x.s, int2str(n));
Does anyone know the proper way of handling this?
Matlab ought to be able to do this as you have it written, but I think that it doesn't like taking derivatives with respect to a symfun. Type whos in the command window and you'll see that x is listed as a symfun while t is just a sym. The help for diff kind of indicates this limitation. It won't event try to take the derivative of a constant with respect to x(t): diff(1,x) "complains" just the same. Unless newer versions of Matlab fix this (I'm on R2012b) I think you only option may be to come up with a scheme using two instances of x.
I have a problem in solving nonlinear parabolic pde of following form.
(consider u_x as differentiation of u w.r.t. x)
U(1)_t = a1(U(1),x)*U(2)_t + b1(U(1),x,U(3)) = ( D1(x,U(1))*U(1)_x )_x + c1( U(1), U(3))*U(1)_x ---(1)
and its coupled equation
U(3)_t = a2(U(1),U(3))*U(2)_t + b2(U(1),x,U(3)) = ( D3*U(3)_x )_x ---(2)
as you can see U(1), U(2), U(3) are there with only two PDE. That is because U(2) is not function of x and has its own pde as
U(2)_t = (1/r)( D2(U(2))*U(2)_r )_r ---(3)
Now (3) is standalone solvable. I solved it with pdepe in MATLAB. Now I need to put value of U(2)_t in (1)&(2) then solve them, which I couldn't do in pdepe.
So this is my question. Is there any way that after solving (3), value of U(2)_t could be imported in (1)&(2) and solve them simultaneously. Alternatively, is there any way that I can incoporate (3) directly in differential form in (1)&(2) and solve resulting coupled system in MATLAB. Thanks in Advance.
You'll have to linearize and do an iterative solution. Newton-Raphson is usually the preferred method, although some people like BFGS.
I don't know how you formulate your PDEs. Finite difference, finite element, boundary element, or something else? Just posting the PDEs doesn't tell me enough.
Here is the MATLAB/FreeMat code I got to solve an ODE numerically using the backward Euler method. However, the results are inconsistent with my textbook results, and sometimes even ridiculously inconsistent. What is wrong with the code?
function [x,y] = backEuler(f,xinit,yinit,xfinal,h)
%f - this is your y prime
%xinit - initial X
%yinit - initial Y
%xfinal - final X
%h - step size
n = (xfinal-xinit)/h; %Calculate steps
%Inititialize arrays...
%The first elements take xinit and yinit corespondigly, the rest fill with 0s.
x = [xinit zeros(1,n)];
y = [yinit zeros(1,n)];
%Numeric routine
for i = 1:n
x(i+1) = x(i)+h;
ynew = y(i)+h*(f(x(i),y(i)));
y(i+1) = y(i)+h*f(x(i+1),ynew);
end
end
Your method is a method of a new kind. It is neither backward nor forward Euler. :-)
Forward Euler: y1 = y0 + h*f(x0,y0)
Backward Euler solve in y1: y1 - h*f(x1,y1) = y0
Your method: y1 = y0 +h*f(x0,x0+h*f(x0,y0))
Your method is not backward Euler.
You don't solve in y1, you just estimate y1 with the forward Euler method. I don't want to pursue the analysis of your method, but I believe it will behave poorly indeed, even compared with forward Euler, since you evaluate the function f at the wrong point.
Here is the closest method to your method that I can think of, explicit as well, which should give much better results. It's Heun's Method:
y1 = y0 + h/2*(f(x0,y0) + f(x1,x0+h*f(x0,y0)))
The only issue I can spot is that the line:
n=(xfinal-xinit)/h
Should be:
n = abs((xfinal-xinit)/h)
To avoid a negative step count. If you are moving in the negative-x direction, make sure to give the function a negative step size.
Your answers probably deviate because of how coarsely you are approximating your answer. To get a semi-accurate result, deltaX has to be very very small and your step size has to be very very very small.
PS. This isn't the "backward Euler method," it is just regular old Euler's method.
If this is homework please tag it so.
Have a look at numerical recipes, specifically chapter 16, integration of ordinary differential equations. Euler's method is known to have problems:
There are several reasons that Euler’s method is not recommended for practical use, among them, (i) the method is not very accurate when compared to other, fancier, methods run at the equivalent stepsize, and (ii) neither is it very stable
So unless you know your textbook is using Euler's method, I wouldn't expect the results to match. Even if it is, you probably have to use an identical step size to get an identical result.
Unless you really want to solve an ODE via Euler's method that you've written by yourself you should have a look at built-in ODE solvers.
On a sidenote: you don't need to create x(i) inside the loop like this: x(i+1) = x(i)+h;. Instead, you can simply write x = xinit:h:xfinal;. Also, you may want to write n = round(xfinal-xinit)/h); to avoid warnings.
Here are the solvers implemented by MATLAB.
ode45 is based on an explicit
Runge-Kutta (4,5) formula, the
Dormand-Prince pair. It is a one-step
solver – in computing y(tn), it needs
only the solution at the immediately
preceding time point, y(tn-1). In
general, ode45 is the best function to
apply as a first try for most
problems.
ode23 is an implementation of an
explicit Runge-Kutta (2,3) pair of
Bogacki and Shampine. It may be more
efficient than ode45 at crude
tolerances and in the presence of
moderate stiffness. Like ode45, ode23
is a one-step solver.
ode113 is a variable order
Adams-Bashforth-Moulton PECE solver.
It may be more efficient than ode45 at
stringent tolerances and when the ODE
file function is particularly
expensive to evaluate. ode113 is a
multistep solver — it normally needs
the solutions at several preceding
time points to compute the current
solution.
The above algorithms are intended to
solve nonstiff systems. If they appear
to be unduly slow, try using one of
the stiff solvers below.
ode15s is a variable order solver
based on the numerical differentiation
formulas (NDFs). Optionally, it uses
the backward differentiation formulas
(BDFs, also known as Gear's method)
that are usually less efficient. Like
ode113, ode15s is a multistep solver.
Try ode15s when ode45 fails, or is
very inefficient, and you suspect that
the problem is stiff, or when solving
a differential-algebraic problem.
ode23s is based on a modified
Rosenbrock formula of order 2. Because
it is a one-step solver, it may be
more efficient than ode15s at crude
tolerances. It can solve some kinds of
stiff problems for which ode15s is not
effective.
ode23t is an implementation of the
trapezoidal rule using a "free"
interpolant. Use this solver if the
problem is only moderately stiff and
you need a solution without numerical
damping. ode23t can solve DAEs.
ode23tb is an implementation of
TR-BDF2, an implicit Runge-Kutta
formula with a first stage that is a
trapezoidal rule step and a second
stage that is a backward
differentiation formula of order two.
By construction, the same iteration
matrix is used in evaluating both
stages. Like ode23s, this solver may
be more efficient than ode15s at crude
tolerances.
I think this code could work. Try this.
for i =1:n
t(i +1)=t(i )+dt;
y(i+1)=solve('y(i+1)=y(i)+dt*f(t(i+1),y(i+1)');
end
The code is fine. Just you have to add another loop within the for loop. To check the level of consistency.
if abs((y(i+1) - ynew)/ynew) > 0.0000000001
ynew = y(i+1);
y(i+1) = y(i)+h*f(x(i+1),ynew);
end
I checked for a dummy function and the results were promising.