Error "Subscript indices must either be real positive integers or logicals."

1 view (last 30 days)
helle everyone, im trying to run this code in matlab 2013b and im getting this code and i cant figure out why,
here is my code
function dy=thermal_bubble6(t,y)
dy=zeros(4,1);
d=998;
dg=23;
c=1500;
k=0.016;
u=0.000001;
ps=10^5;
cv=1.5*10^3;
a=2.338*10^-5;
Tinf=300;
g=1.31;
global pa f pv s r0 p0
pv=2.33*10^3;
s=0.0725;
p0=ps+2*(s/r0)+pv;
dy(1)=y(2);
dy(2)=((1/(d*r0))*(1+r0*y(2)/c)*(p0*y(3) ...
-4*u*y((2)/y(1))-(2*s/(r0*y(1)))+pv-ps+pa*sin(t))+ ...
(y(1)/d*c)*(p0*(((3*y(1)^2)/(t0*Tinf*dg*cv))* ...
((k*Tinf*(1-y(4))/min(sqrt(a*y(1)/abs(y(2)))))-p0*r0*y(2)*y(3)))+ ...
4*u*((y(2)/y(1))^2)+2*s*y(2)/(r0*y(1)^2)+2*pi*f*pa*cos(t))- ...
1.5*r0*(y(2)^2)*(1-r0*y(2)/(3*c)))* ...
((r0*y(1)*(1-r0*y(2)/c))^(-1))*(1+(4*u/(d*c))*(r0*y(1)* ...
(1-r0*y(2)/c))^(-1))^(-1);
dy(3)=g*y(3)*(-3*y(2)/y(1))+(g-1)*(3*k*Tinf/(r0*p0*y(1)))*(y(4)-1)*sqrt(3*(g-1)*y(2)/(a*y(1)));
dy(4)=((3*y(1)^2)/(t0*Tinf*dg*cv))*((k*Tinf*(1-y(4))/min(sqrt(a*y(1)/abs(y(2)))))-p0*r0*y(2)*y(3));
and then i run this solver to solve it
clear;
global pa f r0 p0
r0=10*10^-6;
pa=50*1000;
f=250000;
[t,y]=ode45(@thermal_bubble6,(0:0.01/f:20/f),[r0 0 p0 300]);
plotmatrix(t,y);
and this error appears,
Subscript indices must either be real positive integers or logicals.
Error in thermal_bubble6 (line 21)
dy(2)=((1/(d*r0))*(1+r0*y(2)/c)*(p0*y(3)-4*u*y((2)/y(1))-(2*s/(r0*y(1)))+pv-ps+pa*sin(t))+(y(1)/d*c)*(p0*(((3*y(1)^2)/(t0*Tinf*dg*cv))*((k*Tinf*(1-y(4))/min(sqrt(a*y(1)/abs(y(2)))))-p0*r0*y(2)*y(3)))
Error in odearguments (line 88)
f0 = feval(ode,t0,y0,args{:}); % ODE15I sets args{1} to yp0.
Error in ode45 (line 114)
[neq, tspan, ntspan, next, t0, tfinal, tdir, y0, f0, odeArgs, odeFcn,
...
Error in Untitled4 (line 6)
[t,y]=ode45(@thermal_bubble6,(0:0.01/f:20/f),[r0 0 p0 300]);
thanks for your consideration, cheers,

Answers (2)

dpb
dpb on 31 Aug 2014
I don't know precisely what you're after, of course, but after breaking the line up I just created some dummy values and started evaluating sections...at the following --
>> -4*u*y((2)/y(1))-(2*s/(r0*y(1)))+pv-ps+pa*sin(t)
Subscript indices must either be real positive integers or logicals.
Now with the yelp you can see the problem--there's an extra opening parenthesis in the first y(2)/y(1) expression; it's written as y((2)/y(1)) which is interpreted as y(2/y(1)) which would be highly unlikely to work out to be an integer.
Fix that and then figure out where the then missing parenthesis belongs or perhaps this term is just intended to be
-4*u*y(2)/y(1)-(2*s/(r0*y(1)))+...
?
Anyway, simplify, simplify, simplify...

John D'Errico
John D'Errico on 31 Aug 2014
Edited: John D'Errico on 31 Aug 2014
I've not looked at the entire line, BUT DO SO YOURSELF. Look more carefully at your use of parentheses, as this error arose from an index operation. When you see an error message, think about what it means.
For example, a quick glance shows this fragment:
y((2)/y(1))
What do you think MATLAB will do when it sees that subexpression? It divides 2 by y(1), then uses that result as an index. If y(1) is not either 1 or 2, there will be an obvious error.
My guess is you intended something different, but this is your code, not mine, so I cannot know your intent. Perhaps you intended to write
(y(2)/y(1))
so it may have been a simple misplacement of a single paren. Only you know that to be true or not. And there may be other errors.
  6 Comments
John D'Errico
John D'Errico on 31 Aug 2014
I once worked with a fellow who believed that anything created by symbolic math must be correct and must be the right way to solve a problem. After all computers can't be wrong. And the bigger and messier an expression is, it must mean you are doing something impressive, right?
So when the time came to optimizing a nasty function with many parameters, he threw it at MACSYMA to generate an analytical gradient vector, then wrote it out formatted for Fortran evaluation in the optimizer. Of course, each expression had hundreds of continuation statements, so many that we had to track down how to reset the compiler flag to allow more continuation lines.
What he did not understand (and I only learned later in life) was that often these massive messes of code are truly useless. You end up with massive subtractive cancellation far too often. The computed "analytical" gradient ends up being no better and often worse than what you would get from simple finite differences.
In that context, this line above is actually tiny. :)
dpb
dpb on 31 Aug 2014
I scanned for the same things, John, but w/ my lack of acuity missed it until broke it up into pieces and let Matlab do the dirty work...20 (or even 10) years ago probably would have seen it but it just isn't so simple any longer, unfortunately.
On the symoblic story--I've had colleagues or run into the same ideas in consulting gigs off and on over the years as well. It can be hard to convince sometimes until one simply just does the numerical experiment and hists the results or something similar...

Sign in to comment.

Categories

Find more on Creating and Concatenating Matrices in Help Center and File Exchange

Tags

Community Treasure Hunt

Find the treasures in MATLAB Central and discover how the community can help you!

Start Hunting!