Another possibility for your Maple 13 is to transform a result from odeplot using your known procedure FAK.

You could do that in one line (or in two steps, if you want to save the intermediate plot).

In older versions such as yours the odeplot curve renders thinly in places, which you may be able to make up for using the refine=1 option (which Preben also utilized).

(Although, for your given FAK, Preben's solution to utilize piecewise seems much more sensible.)
 

Download odeplot_actest.mw

Here are various versions, with the rest in black (rather than just default blue for output), or background effects as in the original question, etc.

Mix and match as wanted.

note: In the actual Maple GUI the 2nd and 3rd versions below render properly with the 5's having white foreground as well as the red background. Mapleprimes' backend doesn't render them properly.

Download mathcoloring.mw

You can scale the frames to a common x-y range, so that the conventional  animation (from plots:-animate, or collection displayed with the insequence option) renders them more like the Explore frames.

FractalesAnim_ac.mw

For example, using procedure PP to scale all the frames to [0..1]x[0..1],

PP := proc(P)
  local data,xmin,xmax,ymin,ymax;
  data := indets(P, Array)[1];
  xmin,xmax := [min,max](data[..,1])[];
  ymin,ymax := [min,max](data[..,2])[];
  plottools:-transform((x,y)->[(x-xmin)/(xmax-xmin),
                               (y-ymin)/(ymax-ymin)])(P);
end proc:

plots:-display(
  seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
           Fractals:-LSystem:-LSystemExamples:-KochCurve,a))$5,
      a=1..5),insequence);

plots:-display(
  seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
           Fractals:-LSystem:-LSystemExamples:-Carpet,a))$5,
      a=1..4),insequence);

plots:-display(
  seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
           Fractals:-LSystem:-LSystemExamples:-Rings,a))$5,
      a=1..4),insequence);

plots:-display(
  seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
           Fractals:-LSystem:-LSystemExamples:-Seaweed,a))$5,
      a=1..4),insequence);

plots:-display(
  seq(PP(Fractals:-LSystem:-LSystemExamples:-PlotExample(
           Fractals:-LSystem:-LSystemExamples:-GosperCurve,a))$4,
      a=1..5),insequence);

The most likely scenario is that procedure X called searchtext with invalid arguments by mistake -- in other words, a buggy situation overlooked by whoever wrote procedure X.

There are some other variations on the theme (eg. rethrowing errors of a similar sort, but made at a deeper level).

But it's difficult to say for sure, because you have, unhelpfully, omitted the example in which this arose.

It is not clear from you description what you are trying to do. Is it something like either of these?

Download fitting_ac.mw

The problem is a lack of simplification, such that a verification fails.

As one of some preliminary steps, the free Vector v2 in cartesian coordinates is used to generate a new rooted Vector, and then a coordinate transformation is done. Unfortunately the coordinates of the ensuing extracted root-point of that new rooted Vector is not in simplified form. A later call to verify produces a spurious false result when comparing against the root-point of the rooted Vector v1, and a somewhat unhelpful error message is emitted.

The following commands are some of these internal steps, done under VectorCalculus:-DotProduct for the example at hand. The following rooted Vector vv2 is generated by MapToBasis, executed under PrepareBinaryVectorOp. The verify call is done under ValidateVectorSpaces.

Download VC_dot_simp.mw

I could probably construct a hot-fix patch. I'm trying to figure out whether it would be best to strengthen the call to verify, or simplify the stored root-point when constructed by MapToBasis.

In the other example, the simplified coordinates happen to be produced directly, and the straight verification succeeds.

Download VC_dot_simp2.mw

It should be clear to you from the error message that the problem is that T is not assigned and doesn't provide a numeric value. It looks like you inadvertantly omitted it.

There are other efficiency problems, but you need to fix the T issue first. You should know the formula to do one iteration by Newton's method. See below.

I am leaving most of the rest as it was, and not addressing the inefficiency of augmenting a set with each new plot, or cleaning up the role of A, and so on.

I also made a change to allow the initial point to be passed (xinit).

Download exc_set_3_task_6_ac.mw

If you are using 2D Input mode then the open context-panel (right panel) may be trying to call ifactor on your 123!+1 (after evaluating it). There is a timeout of a few seconds, but for some inputs it might still seem sluggish.

Try closing (collapsing) the right-panel, using the double chevron that looks like << at the right side of the menubar.

note. I will submit a bug report -- at the very least there ought to be a more sensible check on whether to try ifactor, or a way to disable it while keeping the context-panel open.

[edit] The following command will disable the subexpression menu parts that appear at the top of the context-panel, but it will allow the lower context-menu portion to work as usual.
    _EnvSubexpressionMenu := false:

There are a great many ways to do this.

One simple way is to use a list of the expressions (y(x) instantiated at the R values). The list can be constructed using the seq command. The list gets passed to a single call to the plot command.

That will color each curve differently, using the default color palette. But you could also specify the colors.

Download Ques1_ac.mw

You didn't state that it had to have maximal area, so I interpret your question to mean that you want a parametrized solution.

Here is one way to do that, using Explore,

Explore(plots:-display(
    plots:-implicitplot(x^2/a^2+y^2/b^2-2*m*x*y/a/b+m^2=1,
                        x=-a..a,y=-b..b,gridrefine=3,rational),
    plottools:-polygon([[-a,-b],[-a,b],[a,b],[a,-b]],color=white),
    scaling=constrained, size=[500,500]),
  parameters=[[m=-0.99999..0.99999, placement=bottom],
              [ a=1.0..5.0, placement=right, orientation=vertical],
              [ b=1.0..5.0, placement=right, orientation=vertical] ],
  initialvalues=[m=0.0, a=2.0, b=1.0]);

You could also do some algebra and utilize plottools:-ellipse.

ellipse_rectangle.mw

Or, using plots:-animate ,

F := proc(m,a,b)
       plots:-display(
    plots:-implicitplot(x^2/a^2+y^2/b^2-2*m*x*y/a/b+m^2=1,
                        x=-a..a,y=-b..b,gridrefine=3,rational),
    plottools:-polygon([[-a,-b],[-a,b],[a,b],[a,-b]],color=white),
    scaling=constrained);
end proc:

plots:-animate(F, [m,2.0,1.0], m=-0.99999..0.99999,
               frames=50, paraminfo=false);

You might also want to plot the tangent points (using +/- m*a and m*b).

Of course there are other ways to obtain a similar effect (using an angle as parameter, etc).  And in Explore you might use only one of the rectangle sides' lengths as a parameter, or neither.

They are in fact present in your plot, but they are too thin and short to be distinguished, or too dark and close to the x-axis.

You can shorten the x-range (which reduces the overall y-range and thus makes the 0 and 2*x^2 distinguishable from each other). And you can add thickness to make the 0 plot distinguishable from the x-axis. For example,

plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
     x = -1 .. 1, thickness=4,
     color = ["LightGreen", "CornflowerBlue", "Burgundy"]);

You could also change use the view option to force the visible y-range. For example, using a slightly wider x-range and a forced view,

plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
     x = -2 .. 2, thickness=4, view=-10..10,
     color = ["LightGreen", "CornflowerBlue", "Burgundy"]);

And here that is with the original x-range and another choice of y-range,

plot({0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5},
     x = -10 .. 10, thickness=3, view=-1e3..1e3,
     color = ["LightGreen", "CornflowerBlue", "Burgundy"]);

You can even specify the thicknesses to be different for each curve. For example,

plot([0, 2*x^2, 2*x^2 - 2*x^3 + 8/3*x^4 - 4*x^5], x = -2 .. 2,
     thickness=[4,1,1],
     color = ["LightGreen", "CornflowerBlue", "Burgundy"]);

And you can mix some of those effects.

But it is not reasonable to expect all three of those to stand out visually on a range of x=-10..10, with a full y-range on a non-logarithmic y-axis, and the colors almost as dark as the x-axis. Something could be conceded.

You didn't tell us the original form of u1hat, so I've guessed.

But the key thing, I expect, is that you needed to figure out how to utilize the dsolve result while plotting the expression u1hat that contained calls like A__2(t) or B__2(t).

Download ds_subs.mw

It could be adjusted if your u1hat expression contained calls to derivatives of A__2 or B__2. Please just ask in that case. But provide full details.

@pik1432 Here I address your followup query.

Your two expressions are not equal for all complex values of the unknowns. Here is an example set of values for which they are the negation of each other.

Is_eq := II[mu]/sqrt((omega__r^2 + omega__rK^2)*sigma^2
         /(sigma^2*omega__rK^2 + omega__r^2)):

Is_eq2 := II[mu] * sqrt((1+(omega__r/(sigma * omega__rK))^2)
         /(1+(omega__r/(omega__rK))^2)):

evalc(eval([Is_eq, Is_eq2],
      [II[mu] = 1, omega__r = 1,
       omega__rK = 1, sigma = I*sqrt(2)/2]));

            [-1/2*I*2^(1/2), 1/2*I*2^(1/2)]

It is not generally true that sqrt(1/x) is equal to 1/sqrt(x) . It is true for all nonnegative real x, but not for all complex x. 

If all the unknowns within the radicals of your expressions are real then (since the arguments inside the radicals would then happen to be nonnegative) the expressions will be equivalent. That is a sufficient condition.

[edit] I adjusted the wording of the previous two paragraphs, to more closely match the situation in the OP's expressions and to clarify.

Now, the is command is usually as strong as simplify (and friends). But very rarely it will need a little prod. This seems to be one of those cases, at least for the version Maple 2020.0 in which I executed this.

So we can do the comparison under the assumption that the unknowns are real (and we can help the is command a bit).

simplify(Is_eq - Is_eq2) assuming real;
                               0

is(simplify(Is_eq = Is_eq2)) assuming real;
                              true

is(radnormal(Is_eq = Is_eq2)) assuming real;
                              true

is(evala(Is_eq = Is_eq2)) assuming real;
                              true

# Is it rare that such an extra simplification
# step is required.

is(Is_eq = Is_eq2) assuming real;
                              FAIL

is(Is_eq - Is_eq2 = 0) assuming real;
                              FAIL

Note. I changed I[m] to II[mu] since the name I is special and denotes the imaginary unit by default and you didn't declare it as local.

[edit] I shall log a bug report on the case where the is command needed an simplification extra step. (By which I mean the extra simplification step, not the assumption.)

A somewhat close conversion is as follows,

r,theta := (abs,argument)(1+I):
plots:-animate(
  a->plot(((r^(1/a))*~([cos,sin]))~([seq]((2*Pi*k+theta)/a,k=0..a)),
          style=pointline, symbol=solidcircle, symbolsize=25,
          gridlines, thickness=3, scaling=constrained, color=blue,
          labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]),
  [a], a=1..20, frames=20, paraminfo=false);

But it is not exactly the same, since your Explore example runs with the default of 50 frames.

Note that integer values for the parameter get passed by plots:-animate when the number of frames matches a supplied integer range, but otherwise a float gets passed by the animate command. In contrast, Explore passes the integer values (possibly multiple times) in that case.

For your example there is an effect of passing a float instead (ie. the computed points are different that those obtained from the rounded integers. And so a closer conversion would be as follows, keeping Explore's default of 50 frames.

r,theta := (abs,argument)(1+I):
plots:-animate(
  a->plot(((r^(1/round(a)))*~([cos,sin]))~([seq]((2*Pi*k+theta)/round(a),k=0..round(a))),
          style=pointline, symbol=solidcircle, symbolsize=25,
          gridlines, thickness=3, scaling=constrained, color=blue,
          labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]),
  [a], a=1..20, frames=50, paraminfo=false);

The same effect could be obtained more gracefully with a local variable.

r,theta := (abs,argument)(1+I):
plots:-animate(
  proc(aa) local a:=round(aa);
    plot(((r^(1/a))*~([cos,sin]))~([seq]((2*Pi*k+theta)/a,k=0..a)),
          style=pointline, symbol=solidcircle, symbolsize=25,
          gridlines, thickness=3, scaling=constrained, color=blue,
          labels=[Re,Im], labelfont=[Helvetica,bolditalic,20]);
  end proc,
  [a], a=1..20, frames=50, paraminfo=false);

Of course you are free to adjust the number of frames as you please. I just wanted to mention the difference in behavior.

Also, there's nothing inherently wrong with using non-integer values for the parameter, if you wanted to show the effect of it. There are some nice variants on your animation possible like that. But I was focused on a conversion of what your particular example did in Explore.

There is another difference that comes up for your example. The effective view of the result from plots:-animate is shared across all rendered frames. (Sometimes view is referred to as a "global" plot option.) But in Explore the example you gave shows with the non-forced view being different for each frame. You might actually prefer the common view, however, and of course that could also be forced in the Explore example by adding a view option to the call.

How about a piecewise logarithmic fit?

I am not bothering to make use of the fact that the data is symmetric (because I don't know whether this will be true of some larger data set you might actually have.)

[edit] The only reason I use evalf[6] below is to make the result look a little tidier on the page. You can remove the wrapping evalf[6] calls, if you prefer. (Doing so might improve the fit a little, though it's likely not optimal regardless.)

Download pwlog.mw

Or you could do a rational polynomial fit. (With so few points it's unclear what is the "best" form.) I'll use the symmetry here, for fun.

Fn := evalf[6]( Statistics:-Fit((a+b*x+c*x^2)/(d+e*x+f*x^2),
                                 Xn, Yn, x) );
F := piecewise(x<=0, Fn, -eval(Fn,x=-x)):

                     2                          
            4655.04 x  + 0.575145 x + 0.00875488
      Fn := ------------------------------------
                      2                         
            -6833.43 x  - 2.22097 x - 0.00889769