In such situations I usually utilize algsubs or simplify-with-side-relations to accomplish the temporary substitution of the target subexpression by a token (since subs would fail due to the absence of the target structurally).

For a token I sometimes use a double-underscore name since that should ideally not be otherwise present. For more a more programmatic approach I sometimes utilize freeze & thaw, which also lets me skirt having to reverse the substituion-equation.

Download asi.mw

All of the above works in your older Maple 2015.2 version.

In current Maple 2023.0 you could alternatively utilize Physics:-Substitute (instead of algsubs or simplify-with-side-relations) for the first step of substiting for the target by a token. But that doesn't make it easier.

Useful might be something like (I'm making this up),
   PDETools:-Solve(eq,lhs(eq))
as a means to directly handle this whole task.

It seems that subs can handle your example in a straightforward manner,

In particular, you don't have to construct your eq_Dx equation by any manual copy&paste, ie. of a denominator in the rhs of the original. It can be formed programmatically.

Download Q20230606_ac2.mw

That latter one is like Edgardo's, except that it uses subs instead of Physics:-Substitute. (That is, there's not much especially tricky about this example.)

This is not very attractive, but agrees, for real x (almost everywhere, leaving out x=1 say).

Download ugly.mw

Here are some examples.

Adjust the various options, as wanted.  See also the Help page with topic plot,options (in Maple's own Help, or online).

Download ode_leg_lab_ex1.mw

Here is a somewhat crude approach to your problem, using Maple 18.02.

There are several ways to make it fancier, or more general (but I only had 10 minutes for it).

I made very little effort to make it efficient.

Download simp_newt.mw

[edit] Here is some rough code that shades by varied intensity, according to how many iteration it took to get below a threshold value.

(It's not very robust, as far as adjusting the max.iteration or tolerance values, but seems ok for these values. Sorry, I don't have time to improve it.)

Download simp_newt_alt.mw

ps. Apart from not having much spare time, I apologize but I'm not so inclined to make it more general for the requirement that the Maple version is 9 years and 9 major releases out-of-date.

Here are two ways:

Download subst_ex4.mw

ps. I removed this one from my worksheet, because it seemed unnecessarily complicated; the collect call is not needed.
   collect(simplify(eq),diff,
          u->simplify(u,{coeff(eq,diff(U(z,t),z))=t1}));

[edit] other possibilities include,
    simplify(subs(coeff(eq,diff(U(z,t),z))=t1,
                collect(eq,diff)));
  simplify(map[2](subs,coeff(eq,diff(U(z,t),z))=t1,
                  collect(eq,diff)));

The lhs of your equation (hidden input) is entered as,
   Int(E*r, r = 0 .. 2*sigma, varphi = 0 .. 2*Pi)
instead of as,
   Int(E*r, [r = 0 .. 2*sigma, varphi = 0 .. 2*Pi])

The GUI's Typesetting system is not pretty-printing the former in Maple 2023.0 and Maple 2022.2. Within Maple 2021.2 (and earlier, say 18.02) it does get pretty-printed as you're expecting.

Note that in M2023.0, even when not pretty-printed as you'd like, value still works on it. The former is not actually one of the documented calling sequences of int, say, afaics, even if accepted.

Fwiw, the command IntegrationTools:-CollapseNested seems to turn the former into the latter, programmatically.

There is a typical issue with nested numeric computations, where the outer process might not be able to attain some target tolerance because the inner process is not guaranteeing corrspondingly adequate accuracy.

For example, if the inner process guarantees only 6 digits of accuracy, and the outer process has a "convergence acceptance" criterion involving 8 places of accuracy. Random 7th and 8th digits from the inner results prevent the outer process from successfully converging.

This kind of thing can happen when you do fsolve of a dsolve process, or Optimization of a dsolve process, of fsolve of an evalf/Int process, evalf/Int of some other numer process, etc, etc.

Even a rough understanding of the issue can help in such situations (as opposed to flailing around). But it can get tricky. It can get even more complicated if there are both relative and absolute accuracy tolerances in play.

Sometimes the simplest thing is just to crank up the working precision of the inner process, eg. Allan's suggestion to set Digits:=18 in ss. That may bring about enough improvement in the inner results's accuracy that the outer process can also meet its own tolerances. But sometimes this can make the whole computation too slow.

Sometimes having unfortunate choices of tolerances (inner and outer) can produce results successfully, but slower than with more fortuitous choices.

Being able to relax the accuracy of the outer process while retaining, say, the compiled/evalhf hardware double precision speed of inner processes is often desirable.

For these reasons knowing the required accuracy of the outer process is a very good place to begin. Alternatively, if there is a cap on the working precision of the inner process (eg. it requires hardware double-precision speed, etc), then one might need to accept a less accurate outer result -- according to the given problem.

nb. There are also some situations where a final step of rounding to a specific number of digits in the inner process (thereby removing all innaccurate digits) can additionally help with this kind of thing. I didn't do that here.

Here is an adjustment that produces results for your three cases. Experiment and adjust as necessary. You indicated that you'd rather not raise the working precision of the inner process (involving dsolve/numeric), so instead I've relaxed the optimalitytolerance of NLPSolve.

Download test_VS1_ac.mw

The OP mentioned fdiff. If the internal methods NLPSolve uses to compute numerical derivatives is not accurate enough here (it could be a weak link in the nesting of numeric processes) then NLPSolve could be passed a user-defined procedure for objective gradient or constraint jacobian. That might leverage dsolve/numeric itself as a more robust mechanism for that part of the computation. For convenience sometimes the DE system can be augmented for more convenient&direct access to derivative results.

Here is one way, moving from red to the end-color (here, blue) through HSV color-space.

I'll do it for your rho, and then also for another, slightly different formula.

For the first example, I've rotated the orientation to try and illustrate that the shading gradient is orthogonal to the plane defined by that original rho formula.

Download cube_col_ac.mw

Here's another variant. This has the color go from red to blue through the RGB color-space, the proportion determined by where rho's value is between its min and max values (for the given ranges).

Download cube_col_02.mw

That can also get the previous result I showed, by commenting out the line that sets the color-space names.

I didn't make that efficient.

You could also make that work with other color-spaces like Lab or Luv, but there's be additional conversion steps (to and from, since some plotting aspects only accept the RGB or HSV).

You could also make an arbitrary coloring action, according to some scheme you want, given this ability to compute the position between min&max value. So, if you describe some other particular scheme in detail then I can show you how to use that with the above approach. (That could likely also be done using another colorscheme approach, possibly re-using colors generated from that option on a simple 2D curve for convenience.)

In your previous Question the Answer by vv contained a link to an older thread.

   https://mapleprimes.com/posts/214347-Multibyte-Characters

In that older posting there is code for another routine by vv, named SS, which leverages vv's LEN procedure to get substring functionality.

So, your current attached worksheet could be easily revised as, say,

Download substrings_ac.mw

It offers additional functionality, eg.

It's not much of a stretch to imagine that "SS" stands for SubString.

Are you just trying to compute this?

   convert( p(x)/q(x), parfrac, x )

If that's the case then could it really be that you didn't try entering the term partialfraction into Maple's Help search box?

1) It may work. Solving equations using the numerators could also produce some solutions which don't satisfy equations obtained from the original expressions, since it's possible that some solutions (of the new system) could make both numerator and denominator (in the original system) be zero. You don't want solutions which make any of the denominators zero. That might be unlikely. It's a general statement.

2) Where did you get this command which you are trying to use but don't understand? (If from another of your several threads on a common problem, why not ask there and keep the content sensibly close?)

It's mostly a composition. I don't know why its author included the evala@Norm since that does not have major effect on this example. You could more quickly just use numer(Eqs) , which produces a similar result as before if compared via normal. In that case you would not need the elementwise ~ here. The numer command gets mapped across the set of expressions automatically.

3) Your three expressions are sums of products. The numer command is performing expansion, when reforming over a common denominator. As illustration, notice for the following that the result from numer has greater length than the original,

Download num_ex.mw

It's not clear why you want these numer results in more compact form, since the next step is to pass them on to some system solver which will need to manipulate/reform as it needs.

Is this adequate for your goal?

Download ph_diff_ex.mw

Here is a shorter example of the underlying error occurring during evaluation at some kind of point of some kind of piecewise.

restart;
piecewise(abs((HFloat(infinity)+HFloat(infinity)*I)*2^(1/2)
              + HFloat(infinity)+HFloat(infinity)*I) < 1,
          1, undefined);
Error, (in sprintf) too many levels of recursion

That error relates to this:

restart;
radnormal(abs((HFloat(infinity)+HFloat(infinity)*I)*2^(1/2)
              +HFloat(infinity)+HFloat(infinity)*I)-1);
Error, (in sprintf) too many levels of recursion

And that in turn tries the following:

`radnormal/ToRadical`(abs((infinity+infinity*I)*2^(1/2)+infinity+infinity*I)-1);
Error, (in sprintf) too many levels of recursion

And here is how that error can occur for your expression assigned to ff, (the plotting internal process will construct a procedure from the expression)

FF := unapply(ff, x):
FF(HFloat(1.9954019196875001));
Error, (in sprintf) too many levels of recursion

subs(x=HFloat(1.9954019196875001),ff):
eval(%);
Error, (in sprintf) too many levels of recursion

bug_plot_may_29_2023_pw_ac.mw

note. So far I'm seeing this problem in Maple 2019.2.1 and after, but not in 2018.2 and earlier.

I will submit a bug report.

A smooth plot can be obtained reasonably quickly in Maple 2023.0 with,
   plot(evala(ff),x=-3..3);
That skirts around issues near 2 for, say,
   plot(X->eval(ff,x=X),-3..3);

I can see that rationalize computation go away for a long time, even in earlier versions.

If you need to get around this, how about one of,

   radnormal(expr,':-rationalized')

   simplify(radnormal(expr,':-rationalized'),size)

   simplify(radnormal(expr,':-rationalized'))

For example, in under 2sec on my Maple 2023.0,

Download nm_rdnm.mw