@mmcdara You're a little close (IMO) to suggesting that it is the imaginary unit I in particular that is the cause of your difficulty, and that would not be accurate.

In fact similar difficulties exist for compound products involving several extra multiplicands in the coefficient, even without I being present.

As sursumCorda has explained, it is due to the fact that your target term is not structurally present in the rhs.

Consider the example below. The term c*Int(f(x),x), ie. the lhs(eq), is not structurally present in rhs(eq). That is the case, even though the printing gives that appearance.

The "sub-product" c*Int(f(x),x) is not an actual structural component of the product 2*b*c*Int(f(x),x).

@tomleslie I asked whether he wanted just some kind of reflection (for which I too would have reflected/other, and spoofed the tickmarks, etc).

But the OP wrote, "However, I will like the horizontal axis to remain 0 to 15 but on the vertical axis, instead of having it going from 1 down to zero, I want it to be from 1 going up to 2."

What do you imagine that is supposed to mean?

I can concoct several different kinds of mapping that do that to an arbitrary curve, but it's unclear whether any of them are what's wanted. The goal is -- as yet -- not adequately specified.

@jmakinde The vertical position of the curve, at any horizontal value 't', is a consequence of the mathematical nature of the function. It's a math aspect, not a Maple aspect.

Suppose I plot A=t^2 between t=0 and t=3. It ascends from A=0 to A=9. How should I respond to the request that instead it descends from A=18 down to A=9?

@jmakinde I don't understand what you're saying, sorry.

Do you want to change the values of the curve?

Can you not provide some other curve/function, and show an analogous (but unambiguous) result with a similar kind of mapping?

@jmakinde I don't really understand what you mean, sorry.

I'll note that you have not provided your actual ODE. Is there a reason for that?

Are you trying to say that you want the values reversed on the x-axis, ie. going from say 15 to zero and one moves from left to right?

@jmakinde For asterisk or cross you would use style=point (instead of linestyle=dot and the default style=line).

For example,

plots:-display(
  plots:-textplot([4.4,120,N(t)]),
  plots:-odeplot( sol7, [t, N(t), color = red,
                  style=point, symbol=asterisk, symbolsize=12],
                  0 .. 5, numpoints=30),
  labels = [t,N(t)], size=[475,400] );

The file has not been attached.

Do you want to shade or color the basin of attraction of a univariate equation when using Newton's method? Would that be as a function of the complex-valued starting point?

If so, do you want it shaded/colored according to which root it converges to (eg. here), or according to how many iterations it takes to converge (eg. here).

What is an example of your kind of equation? Does your equation contain special-function calls, or calls to non-evalhf'able procedures? Or, perhaps, it just involves rational polynomials, or...?

@ijuptilk The ways that were suggested apply the substituion process to all of the expression or to all of the coefficients of derivatives (possibly simplified). And, in a way, the offered solutions are concocted to "get lucky", in the sense that the subexpression for replacement doesn't occur anywhere else, but only as the coefficient of your chosen derivative.

For example, I'm guessing that you would not want this accidental result:

In general such an coincidental, unwanted substitution could also occur when using plain subs, if the target coeffcient also appeared elsewhere in the expression.

It seems that the spirit of your question may be to only substitute for the coefficient of your chosen derivative. So, straightforward and possibly more robust (in general) in the sense just mentioned,

@Carl Love Sorry, you're quite right. I had already tried simplify-with-side-relations, getting the same result as you. Hence I was expecting to see it in Tom's answer, and somehow misread his call.

@Carl Love Does that produce a result for you which is different from what Tom showed with his second approach, ie. simplify with side relations, without a third argument?

Please put your followup queries for this problem here, instead of spawning completely separate new Question threads on it.

@tomleslie Yes, internally NLPSolve finds a point at which the objective value is better (or improved). Yes, the error message states (cryptically) that, "no improved point could be found."  NLPSolve also requires a better objective value to meet some acceptance criteria in order for it to be returned as a solution.

NLPSolve throws an error here, rather than a warning alongside the better result which fails to meet the acceptance criteria.

This kind of programming conumdrum arises in Maple because mere warnings are not catchable programatically.

The developers of NLPSolve likely decided that it would be wrong to return a value (even if strictly better) that did not meet the acceptance criteria -- because that aspect could not be programatically detected in an adequately straightforward manner. (Who knows, perhaps if reimplemented today then the better value could get returned as part of a "solution module" which exported the value as well as incidentals and programatically accessible convergence/acceptance data and information.)

[edited] I'll try to offer some more concrete evidence. When the problematic example (nvar=2) is run in the OP's worksheet the problem is attempted using an external call to a wrapper which calls the e04uca NAG library function. The first attempt using evalhf-callback mode fails because procedure ss is not evalh'able. The second attempt using evalf-callback mode returns with that function's error-level code of value 6. The current Maple Library procedure Optimization:-External:-E04UCA then throws an error with the following error message:
     "no improved point could be found; consider increasing
      optimality tolerance and checking correctness of objective
      and nonlinear constraint functions"
That error is caught by a higher Optimization internal procedure and rethrown with the terser error message, "no improved point could be found".

See,
   showstat(Optimization:-External:-E04UCA,44..45);
   showstat(Optimization:-NLP:-SolveGeneral,40);

I do not know why someone thought it best to conflate several error cases like that, in NLP:-SolveGeneral.

That Nag error code is also described (in more detail, ie. for case ifail=6) here: e04ucf.html#errors   
Because the example involves the nested numeric computation of another process (with possibly loose accuracy or cruft trailing digits) I hazarded the supposition it was the (Nag-documented case) that raising optimalitytolerance might work.

The facts that either (only) raising optimalitytolerance or decreasing dsolve's "error" via relerr/abserr/Digits both succeeded is evidence that the cause is related as suggested. (Switching to a stiff ode solver might also fortuitously improve the dsolve result's accuracy enough to allow NLPSolve's default conditions to be met.)

IMO the above also indicates that merely finding some point which produces a better objective value is not sufficient to meet all the local optimality conditions. NLPSolve is intended to compute a locally optimal value, not just any old better value.

note: Sometimes I wrap local- or global-optimization problem's objective function in a procedure that retains the running best value/point in a global variable.

@tomleslie That error message doesn't mean that it didn't compute any better objective value altogether; it means that it did not compute a better objective value which also passes its acceptance criteria.

(I'd agree that that error message's wording could be improved. It can give the wrong impression, as evinced by your response.)

Please add your followup queries for this in a Reply here (or your other recent threads on this, here, or here), instead of spawning even more completely separate Question threads on this topic.