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.

Perhaps you want to do something more like this?

I am guessing here. I have moved the end if, and use sum1[n-1] on the right-hand side of that problematic assignment, and initialize sum1[-11] to zero.

new_ac.mw

Here is one way, using algsubs instead of subs:

restart;
eq_5 := x = -(K_i*Zs - Z_AB - Zs)/(K_i*Z_AB);

                              K_i Zs - Z_AB - Zs
                eq_5 := x = - ------------------
                                   K_i Z_AB     

eq_5_m5 := x = expand(rhs(eq_5));

                               Zs     1       Zs   
             eq_5_m5 := x = - ---- + --- + --------
                              Z_AB   K_i   K_i Z_AB

expand(algsubs(Zs/Z_AB = K_S, rhs(eq_5_m5 )));

                                1    K_S
                        -K_S + --- + ---
                               K_i   K_i

Q20210103_ac.mw

[edit] It's worth noting that the expression Zs/Z_AB is not structurally present as a subexpression of Zs/(K_i*Z_AB) as stored in memory by the Maple engine. Yes, the former divides nicely into the latter, but the former is not structurally present in the latter. That's why your attempt using subs failed. The subs command does syntactic rather than "algebraic" substitution. (It's a frequent mistake, to try and use subs for all manner of mathematical substitutions.) See the Help page for algsubs, for some more examples.

Btw, your example could also be handled by simplify-with-side-relations, eg.

expand(simplify( rhs(eq_5_m5 ), {Zs/Z_AB = K_S}));

What you are encountering is an artefact of the printing of a Vector (or Matrix).

If you programatically access the entries of u then you will get results containing the current running value of the m parameter. Hence, if that is what you mean by "automating calculuations" then you may be good to go. This works because the entries are fully evaluated upon access.

If you have a program which needs to do a very large number of such accesses of a Vector/Matrix which contains such a parameter (subsequently assigned a new value) then you can do the full evaluations altogether, up front, which can be more efficient. The rtable_eval command provides this functionality.

This also happens to allow printing to display as you wanted, since the ensuing Vector (newly created by the rtable_eval command) doesn't contain the unevaluated name of the parameter.

Pay attention also to the fact that once you instantiate the Vector at a given value of the parameter then such new Vectors don't reflect those new values. But the original u Vector does.

restart;

u := <-2+m,3+m>;


                       [-2 + m]
                  u := [      ]
                       [3 + m ]

m := 5;

                       m := 5

u;

                      [-2 + m]
                      [      ]
                      [3 + m ]


u[1], u[2];

                        3, 8

T := rtable_eval(u);


                          [3]
                     T := [ ]
                          [8]

T;

                        [3]
                        [ ]
                        [8]

# Notice the name of the parameter
lprint(u);
Vector[column](2,{1 = -2+m, 2 = 3+m},datatype = anything,storage = rectangular,
order = Fortran_order,shape = [])

# Notice the absence of the name of the parameter
lprint(T);
Vector[column](2,{1 = 3, 2 = 8},datatype = anything,storage = rectangular,order
= Fortran_order,shape = [])

m := 17;

                      m := 17

u[1], u[2];

                      15, 20

T[1], T[2];

                       3, 8

Vector_rtable_eval.mw

Another way to produce a new Vector instantiated at the current value of the parameter is to map the eval command across it. Eg, map(eval, u) .

The behaviour you encountered in the printing of a Vector (or Matrix, or Array) is due to efficiency reasons: that structure is not fully evaluated entry-by-entry (and no full copy is made) each time it gets passed in a procedure call -- including passage to the printing procedures.

You could increase working precision. One root is so close to 1.0 that default Digits=10 is inadequate.

Digits:=16:

ans := fsolve(r2,ksi);

                   ans := 0.9999999999994157

eval((rhs-lhs)(r2), ksi=ans);

                                       -8
                       1.37357117458 10  

You could also make Digits greater still, and obtain higher accuracy.

II.01_ac.mw

You can construct a procedure which returns unevaluated when called with nonnumeric arguments returns unevaluated. You can then pass that around like an expression (if you want).

In the attached worksheet, I construct a procedure F_yX with parameters y and X. It computes the numeric integral for x=0..X and after substituting the given value of y.

You can construct other, similar, procedures, according to whether you want to compute a double integral (y=0..Y, x=0..X, or whatever), or a single integral y=0..Y for a fixed x value. There are other variants of this approach, depending on what you want as integration bounds, etc.

You haven't properly explained how you intend on using the result, which makes it difficult to cover all possibilities in an answer.

If this is not sufficient then you should explain properly what you mean when you write, "...i need an expression for v to use another place, i do need required its numeric value".

Integration_Help_ac.mw

By the way, it might be the case that exact symbolic integration is possible (or numeric integration is more stable) if you could manipulate or "simplify" the integral before all those coefficients appear as floats. This may be to complicated for you (...we've been here before...).