@Rouben Rostamian  There are a few things I find alarming about the way fsolve "works" with units. As Axel showed, the following works (Maple 2021.2, for me) with Units:-Simple loaded and in play.

   f:= r -> eqn2(6*Unit('degree'), r*Unit('m'/'sec'))/Unit(N);
   fsolve(f, 7 .. 8);

However, that takes about 11sec on my Intel Core i5-7400 @3.00GHz. That's not good.

One problem is that each call to int(...,numeric) involves a complicated integrand with a mess of subexpressions with unsimplified units all round. Those all get combined and simplified at each call. And dimensional checks are also done repeatedly.

There's also some memoization of the units analysis, so that exact same fsolve attempt returns quickly when done a second time. (That's also scary to me -- what if increases in working precision were ignored by that!)

So here's a revision in which I've avoided loading Units (and thus also Units:-Simple) altogether. A judiciously placed and terse invocation of a few things like evalf(Int(...)) instead of int(...,numeric), change of variables to clear the units out of the range of integration, combine(...units) , etc, can still get the job done.

On my machine it's about 250 times faster to compute it this way.

But I didn't edit any of the definitions prior to that of eqn2, and even in a revision of eqn2 I only switched int to Int. The "unit handling" was only added under the procedures passed to fsolve.

Download rotor_equation_acc.mw

If you upload and attach here your corrupted worksheet then we could try and repair it. You can use the green up-arrow in the Mapleprimes editor for that.

It doesn't help to duplicate your message in several other old Question threads.

@Rouben Rostamian  Alternatively,

f := u -> int(cos(1+arctan(u,r)), r=1..2, numeric) - u^2:

fsolve(f, 0..1);

       0.4910845909

fsolve('f'(u), u=0..1);

       0.4910845909

This can be managed by avoiding evaluation of a symbolic function call such as f(u), thus f treated like a black box.

I haven't investigated yet as to the precise nature of the difficulty.

@MANUTTM I find it difficult to tell exactly what you mean, in this new and related query.

Are you trying to say that you want to compute the globally best D as a function of inputs g and Sr? If so, then is y also an input of that, or is the optimization allowed to vary y over its stated range?

Also, did you see the result of simplification of the Hessian Matrix in my revision of your worksheet above? Do you know how that impacts on your convexity query?

I have deleted three duplicate postings of this. Please stop submitting duplicates of it.

Also, if you have followup details on this query then please add them here, instead of spawning a separate Question thread.

The data of this Question has been changed, so I've deleted my Answer and my followup alternative since they pertained to that particular form of data.

The original Question referrred to only the following data:

and asked about how to produce an image like this:

@Carl Love You example works in Maple 2022.1, but not in all older versions. Below I mention some edits that allow it to work more as intended in older versions (that supported Typesetting).

That text denoting the color, eg. green in your code, should be within escaped string-quotes, ie, \"green\" .

The hex variants should be prefixed by #, rather than x. (In Maple 2022.1 there must be some preceding character(s), and it needn't specifically be x or #)

Also, use in some plotting situations, that name constructed by nprintf should be terminated by the semicolon character.

Maple 2022.1 respects the leading/trailing blanks, but it's trickier in some older versions. This is one reason I preferred (here) the Typesetting exports rather than the MathML style name-markup. However the OP has not yet told us precisely how he intends on using these colored things, nor his Maple version, and so I cannot know which is best here.

@Ronan If you are using 2D Input mode then the anonymous procedure can be delimited by brackets.

Eg, you can paste in this:

   (add@map)((proc(E) ``(lcoeff(E))*normal(E/lcoeff(E)); end proc)@add, [Q(expand(pn))])

That "end" goes with the "proc".

I have deleted a duplicate of this topic.

Put your followup queries and details on this here, not in separate Question threads.

@mehdibgh Yes, fsolve is having problems finding/accepting the multivariate roots if the ranges's boundary is very close.

Download SoalNewton2_ac.mw

You haven't stated why an optimization approach is not acceptable.

@dharr For some reason I had convinced myself that the solution of the linear problem lay outside the OP's provided ranges -- hence my least-squares approach. I might not have looked properly at the range end-points X that the OP provided.

@gravatarq I deleted a duplicate posting of this.

@mehdibgh Your description is that of an inverted range, since with your t value as 1 the values in X will be negative and you have the lower range value q as 0.

Also, you have the same kind of indexing mistake with X, which you have as a 4x1 Matrix, and not a Vector.

You could try the ranges as,

     { seq(V[1, r] = X[r, 1] .. q, r = 1 .. 4) }

but you might not find a solution.

[edit] Perhaps you might actually be satisfied with a solution to an optimization problem of minimizing some related objective (eg. least-squares). Here I raise the working precision to try and get a more accurate result:

Download SoalNewton_acc.mw

@fkohlhepp I have deleted a duplicate of this Question thread.

If you have any additional details or related followup queries then feel free to add them here. Please don't spawn a separate Question thread for this.

And here is an animation, based upon the OP's revised code...

I let it be animated w.r.t. the parameter t passed to CircleParm for point P1.

The procedure F produces each plotted frame.

(It could also be done with Explore, optionally with additional parameters passed for F's other arguments -- being the values passed to CircleParm for P2,P3,P4.)

Download jamet_anim1.mw