This alone causes a crash in my Maple 2020.1.

restart;
evalf(LaguerreL(5, HFloat(4.1001001001001e258)));

And that kind of call is done during the DirectSearch example.

I will submit a bug report.  (I'm pretty sure I've seen another example very similar, but I will submit regardless.)

The crash might be occuring during the next gc (garbage collection) following the computation. I am not sure. In the CommandLine Interface (CLI),

restart;
evalf(LaguerreL(5, 4.1001001001001e258));
                             1246
             -0.9793474754 10

gc();
GC Thread signalAbort 0x7f67e0a3c700 Execution stopped: Stack limit reached.
maple: fatal error, lost connection to kernel

Deeper down,

restart; printlevel:=999:
`evalf/hypergeom/kernel`([-5.], [1.], .4100100100e259): gc():
GC Thread signalAbort 0x7f71b1d70700 Execution stopped: Stack limit reached.
maple: fatal error, lost connection to kernel

And `evalf/hypergeom/kernel` is a kernel builtin.

In a related way, for a different input sometimes I can get this effect (without gc),

restart; hypergeom([-3],[1],1e350):
gmp: overflow in mpz type
maple: fatal error, lost connection to kernel

In your example A the arguments being passed to PDEtools:-Solve are 0=0, x~  (where x~ is the replacement name for x, with assumptions placed on it).

You can easily see this by using the trace command.

restart;
ode:=(x+1)*diff(y(x),x)+y(x)^(1/2) = 0;
ic:=y(0) = 1;
sol:=dsolve([ode,ic],y(x));
check:=odetest(sol,ode);
trace(PDEtools:-Solve):
PDEtools:-Solve(check=0,x) assuming x>-1,x<6;
untrace(PDEtools:-Solve):

That is similar to doing this:

PDEtools:-Solve(0=0,x) assuming x>-1,x<6;                                          
Error, (in assuming) when calling 'PDEtools:-Solve'.
Received: 'not a system with respect to the unknowns {x}'

When you call,
    PDEtools:-Solve(check=0,x) assuming x>-1,x<6;
the assumptions are used to replace all instances of name x present in the main expression, including those within check. Then check is evaluated up front (normal evaluation rules, innermost to outermost) when passed as argument to PDEtools:-Solve. After the assumed name x~ replaces x within check then check evaluates to just zero. Eg,

check assuming x>-1,x<6;

                 0

Using Maple 2020.1,

restart;

Expr:=arctan((1-tan(20*Pi/180))/(1-tan(25*Pi/180))):

simplify(convert(Expr,exp));

                   5    
                   -- Pi
                   18   

In Maple versions 16.02, 17.02, 18.02, 2015.2, 2016.2, 2017.2, 2018.2 and 2019.2, you could do the following, though the timing varies,

simplify(expand(convert(Expr,exp)));

Here are two polar density plots, from the given data (with my understanding so far), using this attached worksheet:

  polar_densityplot.mw

As you can see, one displays with rectangular coordinate axes, and the other polar.

The ranges on the rectangular case is restricted since I didn't set up the interpolation to nicely extrapolate outside r=0..1, but that might be adjusted reasonably if needed I think.

The choices of coloring gradients (colorscheme) can be adjusted quite easily.

There are a few ways to include a colorbar, but none is quite perfect. Please state whether that is a requirement, and whether you need to export the result to a single image file (it makes a difference to which approach works best.)

(If the ranges -200..200 and 0..0.6 from your posted image are supposed to relate then please explain.)

In the first case you are also calling odetest (and not just simplify) under the assumption.

And that produces zero (in my Maple 2020.1 at least) even before simplify is called.

Here it is, with both called separately and under the assumption.

restart;
mysol:= exp(sqrt( y(x)^2/x^2+1)) = _C1*x:

ode:=diff(y(x),x) = (y(x)^2+(x^2+y(x)^2)^(1/2)*x)/x/y(x):

  diff(y(x),x) = (y(x)^2+(y(x)^2+x^2)^(1/2)*x)/x/y(x)

simplify(odetest(mysol,ode)) assuming x>0;

                      0

res:=odetest(mysol,ode) assuming x>0;

                   res := 0

simplify(res) assuming x>0;

                      0

In your second example you only used the assumption in the call to simplify, but not the initial call to odetest. Thus you made your two examples different.

What made the difference was not that you were "putting an intermediate result in a variable". What made the difference was that you were no longer calling odetest under the assumption.

Before anything else, you should fix your syntax, by including explicit multiplication symbols as needed.

Your example contained both GoHo (with not even any space) as well as Go Ho (with a space). It looks as if you may have intended Go*Ho, in which case that is the best way to write it, and in which case GoHo is a typo mistake.

I am supposing that your goal is an approach that will let you substitute some variables (eg. Uo,Go,Ho) with dimensionless variables (eg. Fr and likely others), into one or more expressions -- according to one or more given equivalency rules.

Your given example is, unfortunately, overly simple. That's a bit of a problem since there are very many ways to produce the result. Many of those will be quite ad hoc, and won't generalize well (if at all) to similar but more involved examples. This also makes it more difficult to generalize the approach, since we don't know what dificulties will be presented by more involved examples.

Here is one idea. (Pay attention to the syntax, if typos and syntax is a common issue.) One point is that it doesn't require you to discriminate between Uo, Go, and Ho, if those are indeed the variables you wish to eliminate. This is not the only possible general approach, but it can be systematically extended to examples involving more equations and "dimensionaless" variables.

restart;

eq1 := Uo/sqrt(Go*Ho)=Fr:
new1 := targ1 = Go*Ho/Uo^2:

eval(targ1,
     [solve({new1,eq1}, {targ1,Go,Ho,Uo})][1]);

That produces the following in my Maple 2020.1,

                    1
                   ---
                     2
                   Fr

One natural way to extend this to cases of several equations and additional dimensionless variables would be to augment the sets in a single call to solve made as above.

Note that additional equations would further constrain the variables (if all are to hold at once). That might mean that eliminate could be necessary instead of solve, since the non-eliminated variables might not be wholly free in which case solve would return NULL. Another possibility here is a pair of eliminate calls (dealing with the nondimenionless variables and the introduced names for the target expressions separately).

And so another possibility is to eliminate the nondimensionless variables from the supplied equations, and then substitute those results into the target expressions (and possibly simplify, as it might get messy).

Again, be careful about syntax errors. Be careful about accidentally suppressing output by using full colons instead of semicolons as statement terminators. (But you can terminate will full colons, even for intermediate terms, as that may help you learn what Maple is doing.)

If you have additional, more involved examples, then you should provide them as soon as possible. (Better would be to have provided them up front, in your Question.) Note that it's possible that results may not be uniquely determined.

If your Maple version is older than Maple 2020 then you should indicate that in your query. You can mark your Question's Product in its header.

[edit] Here is an example, using a larger system of equations, and a pair of target expressions, and one of my alternate suggested approaches. Notice how the inclusion of eq5 changes the representation of the first target expression (but still in terms of the new, dimensionless variables). You should decide how you'd want to handle such ambiguity.

restart;

eq1 :=  Uo/(sqrt(Go*Ho)) = Fr:
eq2 := (rho*Go*Ho^2)/sigma = W:
eq3 := St = (To*Uo)/Ho:
eq4 := Ca = (mu*Uo)/sigma:
eq5 := mu/sqrt(rho*sigma*Ho) = Oh:

dvars := {Go,Ho,To,Uo}:

new1 := targ1 = Go*Ho/Uo^2:
new2 := targ2 = mu/To*Ho:

SS1 := eliminate({eq1,eq2,eq3,eq4}, dvars)[1]:

eval(targ1, new1) = eval(eval(targ1, new1), SS1);

                          Go Ho    1 
                          ----- = ---
                             2      2
                           Uo     Fr 

eval(targ2, new2) = eval(eval(targ2, new2), SS1);

                        mu Ho   Ca sigma
                        ----- = --------
                         To        St   

SS2 := eliminate({eq1,eq2,eq3,eq4,eq5}, dvars)[1]:

eval(targ1, new1) = eval(eval(targ1, new1), SS2);

                                     2
                         Go Ho   W Oh 
                         ----- = -----
                            2       2 
                          Uo      Ca  

eval(targ2, new2) = eval(eval(targ2, new2), SS2);

                        mu Ho   Ca sigma
                        ----- = --------
                         To        St   

elimination_dim_vars2.mw

For now (until I get time to write more, or someone else does), you could compare the 2D Output of the following.

I think that it does not look best when subscripts appear in the same font size as the main characters. I think that the rendering gets even more awkward as the subscripting is nested.

restart;
kernelopts(version);

R1 := `#msub(mi("x"),msub(mi("i"),mi("j")));`:
S1 := `#msub(mi("X"),msub(mi("G"),mi("H")));`:
use Typesetting in
  R2 := msub(mi("x",size="12"), msub(mi("i",size="10"), mi("j",size="8")));
  S2 := msub(mi("X",size="12"), msub(mi("G",size="10"), mi("H",size="8")));
end use:

R1, x[i[j]], x__i__j, R2;
S1, X[G[H]], X__G__H, S2;

nested_subscripts_sized.mw

You may already know this, but the lprint command can be useful in having a look at the structures (whether XML-style names, or Typesetting export function calls, or TypeMK or whatever you'd like to call them).

To answer your question, I suspect that it is "known" since I recall earlier reporting a similar example.

But I will submit this example anyway. (In 2020.1 the call solve(sol, allsolutions) produces it.)

How about something like the following, using evalc to deal with csgn beforehand.

new := simplify(evalc(sol))=0 assuming real:

    -(a-x)^2*(-abs(-1+(a-x)*_C1)-1+(a-x)*_C1)/(k+1)/abs(-1+(a-x)*_C1)^3 = 0

S := [solve(new, allsolutions, real)]:
map(lprint, S):
{_C1 = _C1, a = x, k = k, x = x}
{x = x, -1 < k, _C1 < 0, a < (_C1*x+1)/_C1}
{x = x, -1 < k, 0 < _C1, (_C1*x+1)/_C1 < a}
{x = x, _C1 < 0, a < (_C1*x+1)/_C1, k < -1}
{x = x, 0 < _C1, k < -1, (_C1*x+1)/_C1 < a}

map(proc(s) local eqs, ineqs;
      eqs,ineqs := selectremove(type,s,`=`);
      simplify(eval(sol,eqs)) assuming ineqs[];
    end proc,
    S);

             [0, 0, 0, 0, 0]

simplify_real_solve_examp.mw

Then adjust as appropriate (including for other examples, of course).

That is because the length command does not return the number of elements of a Vector or a Array. You have used the wrong command.

Instead, you could use the numelems command here, eg.
   numelems(R1);

Since R1 in your example is a row Vector, you could also use these commands,
   LinearAlgebra:-Dimension(R1);
   op(1,R1);
 

Does it work if you first execute the command,

     interface(prettyprint=3):

If so then you might need to set that as
  Tools->Options->Display->Output Display->2D Math Notation
rom the main menubar. Then save preferences using the Apply Globally button.

You might possibly also need to shut and relaunch the GUI altogether.

You have compared an equation in Maple  (ie. =) with an equality test in Mathematica (ie. ==). That comparison of those two quite different intended functionalities is not justified.

A mathematical comparison can be done using the is command (as Kitonum mentioned).

f:=(9*(x^(-2/3*a))^2*exp(6/a*(x^(-2/3*a))^(1/2))^2*_C0^2-6*(x^(-2/3*a))^(3/2)*exp(
6/a*(x^(-2/3*a))^(1/2))^2*_C0^2*a+x^(-2/3*a)*exp(6/a*(x^(-2/3*a))^(1/2))^2*_C0^
2*a^2+18*(x^(-2/3*a))^2*exp(6/a*(x^(-2/3*a))^(1/2))*_C0-2*x^(-2/3*a)*exp(6/a*(x
^(-2/3*a))^(1/2))*_C0*a^2+6*(x^(-2/3*a))^(3/2)*a+x^(-2/3*a)*a^2+9*(x^(-2/3*a))^
2)/(3*_C0*exp(6/a*(x^(-2/3*a))^(1/2))*(x^(-2/3*a))^(1/2)-exp(6/a*(x^(-2/3*a))^(
1/2))*_C0*a+3*(x^(-2/3*a))^(1/2)+a)^2:

g:=x^(-2/3*a):

is(f=g);
                    true

The comparion using evalb is merely structural in this case. It is weaker to place the additional burden of both expressions "simplifying" to the same canonical form (if it exists) than to test whether their difference is mathematically zero. This is important. You should not make your primary approach be such a test of separate simplification to the same expression.

Having said that, both parts of the given example can be simplified to the same expression (though not directly in just one call to the simplify command).

And the given example can be done with a straightforward nesting of 2 or 3 simplifying commands. That is achievable in several different ways. It doesn't require ad hoc substitution or any restrictive assumption (both of which Kitonum used in his answer).

For example, using Maple 2020.1,

simplify(expand(rationalize(f)));

                   (- 2/3 a)
                  x          

There are other, even shorter ways to get that, some involving calls that generally involve less computational effort. For example,

normal(radnormal(f));
                            (- 2/3 a)
                           x         

expand(radnormal(f));
                            (- 2/3 a)
                           x         

normal(expand(rationalize(f)));
                            (- 2/3 a)
                           x         

And these more generally more computationally intensive forms follow from those,

simplify(radnormal(f),size);
                            (- 2/3 a)
                           x         

simplify(radnormal(f));
                            (- 2/3 a)
                           x         

Another terse approach here is:

evala(Normal(f));
                            (- 2/3 a)
                           x         

I shall submit a bug report against simplify, for this example.

[edit] Some additional notes:
 - There are some cases where is(A-B=0) does better than is(A=B), but I don't recall ever seeing the opposite case.
 - There are some rare cases where is(simplify(A-B)=0) does better than is(A-B=0) , but those have become even more rare in past years.
 - Generally is is stronger than just simplify, by which I mean that generally is(A-B=0) does better than evalb(simplify(A-B)=0) .
 - There have always been some relatively uncommon examples where some mix of simplify, rationalize, expand, combine, evala, and radnormal do better at zero recognition than does simplify alone.

You can use the plots:-display command to combine several plots, for example the curve, more than one point plot, and more than one textplot.

If this is not a homework question whose goal is get you to learn how to do all those things together, then you might also look at the FunctionChart command.

(You didn't provide the actual example, which isn't very helpful.)

Your procedure f may not be written to allow for the case that its passed argument x does not (yet) have a numeric value.

Note that Maple's usual evaluation rules for procedure calls is that the arguments are evaluated up front. That means that the call f(x) in your fsolve call gets evaluluated before x takes any numeric value.

But this call, for symbolic name x, returns your error. That is what fsolve sees. This is the primary problem. The call to f(x) is evaluated prematurely.
   f(x);
Error, (in ValveLaminarMassFlow_proc) cannot determine if this expression is true or false: 10000.0 <= 8848.331994*x

There are some other complications, but to keep it brief: Here is one way, using the operator-form calling sequence of fsolve, rather than the expression-form.   fsolve_if_then_not_evaluating_in_proc_ac.mw

That gives the result 13.95e-3 which seems to agree with the plot from,
   plot(x -> [f(x)][1] - x, 0 .. 0.02)

In Maple 2020, with default interface(typesetting=extended) the name Change appears by itself, in the output printed in the Java GUI for that unevaluated function call. But if I set,
    interface(typesetting=standard):
then the fully qualified name IntegrationTools:-Change is shown on that unevaluated function call.

If I use Maple 2016 (say), in which the default was typesetting=standard, then even there I can suppress the package name in that unevaluated fucntion call in output, by first forcing typesetting=extended via kernelopts.

You didn't mention which version you are using. I don't know whether using typesetting=extended is acceptable for you, or whether it would have some other effect that you don't like.

The bytesused number (shown by CodeTools:-Usage) refers to how much memory has been processed by Maple's garbage collector, during the computation. This doesn't relate directly (or meaningfully, IMO) to the amount of resident memory in use, let alone the peak of that.

The bytesalloc number (shown by CodeTools:-Usage) refers to the difference in how much of the OS memory is allocated by the Maple kernel -- comparing the end against the start of the computation. (This number can sometimes be reported as negative, if garbage collection has freed up memory back to the OS during the computation -- not common, but possible.) This quantity relates to memory allocation, but is not an indicator of peak allocation over a computation.