I keep getting an error stating that fsolve has stopped because it has exceeded the function evaluation limit.

Here is my code

 %%Fsolve portion
fun = @root2d;
x0 = [10000,1];
x = fsolve(fun,x0);
%%Actual functions
function F = root2d(x)
F(1) = (24/(x(1)))+(3/(sqrt(x(1)))) - x(2) + 0.34; %%first function
F(2) = x(1) - ((371e-4)/.0014)*sqrt((4*9.81*(6800)*1000*(371e-4))/(3*x(2))); %%2nd function
end

Every time I run this code, I run into that error that the function evaluation limit has been reached. What can I do to solve this?

[KALYAN ACHARJYA]

Here is the Answer from @Walter Roberson sir

https://in.mathworks.com/matlabcentral/answers/353235-i-am-getting-this-error-while-solving-fsolve-stopped-because-it-exceeded-the-function-evaluation-li#answer_278485

[Walter Roberson]

KALYAN ACHARJYA is correct to refer to that solution.

You will need about 2000 iterations and about 6000 function evaluations.

Answer 1

[John D'Errico]

These equations are rather numerically nasty. So fsolve may well have problems.

x = sym('x',[1 2]);

F(1) = (24/(x(1)))+(3/(sqrt(x(1)))) - x(2) + 0.34; %%first function
F(2) = x(1) - ((371e-4)/.0014)*sqrt((4*9.81*(6800)*1000*(371e-4))/(3*x(2))); %%2nd function

xsym = solve(F)
xsym = 
  struct with fields:

      x1: [4×1 sym]
      x2: [4×1 sym]

There are 4 solutions that solve found, only two of which are real. And one of those real solutions was apparently not a solution at all.

vpa(xsym.x1)
ans =
                                       81273.682385843104986453160925862
                                        83807.81449859714950662847111925
 - 82572.409341874106485295141282072 - 1268.168832976111876747928305322i
 - 82572.409341874106485295141282072 + 1268.168832976111876747928305322i

vpa(xsym.x2)
ans =
                                        0.35081846126435722534542088738111
                                        0.32992352460468702550608076574237
 0.33962925563058826267375383409956 - 0.010434692599468016237426647495723i
 0.33962925563058826267375383409956 + 0.010434692599468016237426647495723i

Taking those possible solutions, we see that the first is indeed a root, while the second real solution is indeed spurious, thus not a root.

X = vpa([xsym.x1(1),xsym.x2(1)])
X =
[ 81273.682385843104986453160925862, 0.35081846126435722534542088738111]

subs(F,x,X)
ans =
[ 0, 2.4074124304840448163199724282312e-35]

X = vpa([xsym.x1(2),xsym.x2(2)])
X =
[ 83807.81449859714950662847111925, 0.32992352460468702550608076574237]

subs(F,x,X)
ans =
[ 0.020725689744471398174727540556394, 0]

[Walter Roberson]

(Maple correctly returns one solution, somehow figuring out that the other 3 are not valid. It is even possible to generate a closed form solution involving one of the roots of a quartic (degree 4)... but it's a pretty long solution!

[Peter Phung]

I appreciate the detailed answer from John. Thank you so much, John, you've helped me out tremendously.

Walter; Unfortunately, my teacher only wants use to use MATLAB to solve the problem. In the real world, I will definitely use Maple.

[Walter Roberson]

In real life, the answers from Maple need to be cross-checked too!

[DHABALESWAR MOHAPATRA]

what if i have a large system? How to find the solution then?

[Walter Roberson]

@DHABALESWAR MOHAPATRA

Are you trying to proceed purely numerically using fsolve() ? Or are you trying to find closed-form or indefinite precision solutions using Symbolic Toolbox solve? Or are you trying to find higher-precision numeric solutions using Symbolic Toolbox vpasolve ?

If you are doing numeric solutions using fsolve() then you would provide it with an options structure that increased the maximum iterations and the maximum number of function evaluations. For particularly "bumpy" systems it can take sometimes millions of evaluations to find a solution, and that can add up to a fair bit of time.

vpasolve() is typically slower than fsolve() -- but not always. There are some functions that vpasolve() is able to reason about to pick more likely solution spaces. There are also cases where double precision calculations are not stable enough, leading to long searches using fsolve() but the extended precision of vpasolve() might happen to give a system stable enough for relatively direct solution.

solve() is typically the slowest of the possibilities... but again not always