The first one being "What software does your partner use?"

@Jean-Michel 

For your information there was also a recent question on Mapleprimes asking if  a "black mode" (black background and white text) would be avaliable soon.

Go to Preferences ; in French installation (Maple 2015)

:

In the pop-up window



increase the calue of the field "Default Zoom"
Next select "Apply Globally".

For your Maple version Preferences might be placed somewhere else, but the operations to do should
be more or less the same.
 
Hope it helps

@acer 

I really thought I'd done something stupid

@Aixleft math  @Yuri Zamorano

Thanks @Aixleft math

Just for fun, here is a proof that T^(-1)(solution(LM)) <> solution(PM) where T is the one-to-one transformation which maps the power regression model PM into the liearized regression  model LM.

The main result is that even if PM is linear, for instance Y = A*X^B with B=1,  T^(-1)(solution(LM)) is equal to  solution(PM) if and only if the data do not contain any observation error (that is the data exapctly verify the relation  Y_n = A*X_n).
As soon it i no longer the case, for  instance  Y_n = A*X_n + E_n. where E_n denotes an observation error
using a log-log transformation to assess log(A) and going backward to A introduces a bias.

It is worth noting that ExponentialFit suffers the same flaws, see below

PowerFit_Linearize_or_not.mw

First conclusion: "avoid using PowerFit or ExponentialFit and remain very careful as using the Statistics package".
I indeed found myself several errors, that I signaled, but not rnough persons seem to use this package for the core development team yakes time to correct them

Secondly, Maple put aside,  "always remain carefull when using linearization techniques".
Here are two short lectures about pitfalls in linearization of non linear regression models math.duke.edu or mathworks.

Not even saying that some statistics do not make any sense (R_squared, Cook's distance or Atkinson's T, to cite a few, that PowerFit nevertheless computes).

@salim-barzani 

In order to have a smart representation of the factored expression I had to use the neutral operator `` (see help page).

Here is a toy example where I explain how to factor an expression with respect to some other one
 

Download explanation_toy_example.mw

Once this trick understood, look to my find-parameter_2_mmcdara_explains.mw worksheet.

PS: I don't understand the final comment in your last file "NULL" ???

ATTACHED FILE UPDATED APRIL 12 AT 18.11 GMT

For years I use to use the Statistics package and I never pointed this error.

(At my discharge I always found stupid to develop the PowerFit  function [and the PolynomialFit function too] as the regression models they both use are linear under obvious transformations.
So I always use LinearFit (or Fit) after having possibly applied some linearization.
That is why I never payed any attention to PowerFit nor PolynomialFit.)

The core team made a big mistake here for two reasons:

• First error: PowerFit asseses the parameters after having linearized the model with a log-log transformation and next deduce the power fit model from the linearized fit model by appying the reciprocal of the log-log transformation.
  It is shown in the attached file (and proved in a separate comment) that the power fit we get this way is wrong.
   
• Second error: PowerFit and  LinearFit/Fit both provide the same values for all the statistics they assess, which is clearly impossible because some should be the logarithm (or the  exponential) of the others. In fact a lot of those statistices (correctly computed by LinearFit/Fit) are only defined on linear or multilinear models and have no sense on nonlinear, for instance power, models. 
   

About R-squared and Adjusted R-squared:
Googling a few seconds will reveal you that R-squared in intrinsic to LINEAR REGRESSION and cannot (should never) be used to assess the quality of a NON LINEAR REGRESSION model... even if a few authors in some unreliable forums advocate the opposite.
It"s better to kook to what serious statistical tools do say about this:

• MINITAB
• SPSS
• R also proposes a lot of packages to assess a so called "pseudo R-squared"

I advice you to read the seminal paper by Kvalseth where it discusses the weakness of R-squared as a goodness-of-fit criterion in the case of a power model.

Download PowerFit_vs_LinearFit.mw

@acer 

Strange, isn't it? 
Do you have any idea of what might be going on? 
Is this a situation worth investigating by submitting an SCR or something like that?  Or should it be considered a marginal defect (using @C_R 's idea seems indeed to avoid the issue)?

@Jean-Michel 

@C_R I'm going to see what I can do about this driver thing and verify I don't have problems with `2`^n (good idea by the way).

@Andiguys 

For instance, the expression:

1/((w+Ce)2⋅(−δ+w+Ce)2⋅λ−16⋅U[0]2)

is common in g1,g2, g3,  pi1,pi2 and it also appears in g_1, g_2, g_3,pi_1,pi_2. though in the latter it includes an additional term 't'

Which means that

is common in g1,g2, g3,  pi1,pi2 but NOT to g_1, g_2, g_3,pi_1,pi_2. as it contains "t".
Indeed these latters both  both contain instead 


Then one can consider as common to the 10 quantities unless t=0.

The only common sub-expressions amid g1, g2 and g3 are (a+Cm), (a-Cm) and .
The only common sub-expressions amid g1, g2, g3 and pi1 are (a+Cm) and (a-Cm).

I didn't investigate g_1, g_2, g_3 but it is visualy clear that the only subexpressions they will shar withe g1, g2, g3, pi1 are again  (a+Cm) and (a-Cm).

Look common_term_mmcdara_2.mw

Maybe simplifying the expressions otherwise could reveal more common sub-expresisons, but it is like looking for a needle in a haystack.
Mybe you could find some idea in observing the outputs of things like this:

CodeGeneration:-Python(g1, optimize)
Warning, the following variable name replacements were made: lambda -> cg
t1 = w + Ce
t2 = t1 ** 2
t4 = (-delta + w + Ce) ** 2
t7 = U[-1] ** 2
t11 = Ce ** 2
t14 = a * delta
t15 = 2 * t14
t20 = w ** 2
t27 = delta ** 2
t28 = a * t27
t30 = 2 * U * delta
t32 = U[-1] * (a - Cm)
t33 = 2 * t32
t54 = 1 / (t2 * t4 * cg - 16 * t7) * (-t1 * (-a * t11 * Ce + (-3 * a * w + U + t15) * t11 + (-3 * a * t20 + (4 * t14 + 2 * U) * w - t28 - t30 - t33) * Ce - a * t20 * w + (t15 + U) * t20 + (-t28 - t30 - t33) * w + U * t27 + 2 * t32 * delta - 4 * U[-1] * k) * cg - 8 * t7 * (a + Cm))

Sub-expressions are t1, ...t33.
Next compare this output to the one of CodeGeneration:-Python(g2, optimize) for instance

CodeGeneration:-Python(g2, optimize)
Warning, the following variable name replacements were made: lambda -> cg
t2 = (w + Ce) ** 2
t3 = -delta + w + Ce
t11 = -a + Cm
t12 = Ce ** 2
t15 = -t11 * delta / 2
t18 = w ** 2
t30 = t3 ** 2
t33 = U[-1] ** 2
t37 = (t2 * t3 * (a * Ce - a * delta + a * w + k) * cg - 4 * (t11 * t12 / 2 + (t11 * w + U + t15) * Ce + t18 * t11 / 2 + (t15 + U) * w - U * delta + 2 * U[-1] * (a + Cm)) * U[-1]) / (t2 * t30 * cg - 16 * t33)

(You can redirect the ouputs to different files using writeto and use any file comparator after)

REMARK:
As I replied here to slim Barzani, "It's never a good strategy to complexify unnecessarily an expression before trying to solve it.".
Transpose to your problem I would say "It's never a good strategy to complexify unnecessarily several expressions and try to extract some common features after that.".

Let me be clear: your 10 equations do not come out from your mind but are more likely the results of some prelminary computations (what you name "scenarios").
I suspect that in those scenarios you have several assignments of form

a := F(x, y)
b := G(u, v, w):
...
c := H(a, b, p);
d := J(p, a, c);
...
e := K(c, d, k, m)
f := L(c, d, t, z)
...

final_expressions := {A(e, f), B(e, f, a, d), C(e, f, p, b)}

That is a succession of declarations that depend on the preceding declarations. I can't imagine another coding which can leads to the complex expressions final_expressions contains.

Now what you want is to identify common sub-expressions in final_expressions.
But they are clearly e and f, and at a deeper level c and d, and at an even deeper level a.
What I'm saying is that the way you get   final_expressions gives you directly the answer you are looking for.

Read carefully the question/answer/comments to this Question.

And, ann advice, share the worksheet where your scenarios are coded dor us to see if there is not a simple way to answer your question instad of working blindly on your 10 final_expressions.

Here is a very simple code based on two build-in Maple functions.
It enables getting the result you present and, potentially, the same kind of results for any value of n....

decompose := proc(n)
  remove(has, combinat:-partition(n, n), {1, n})
end proc:
decompose(8)
  [[2, 2, 2, 2], [2, 3, 3], [2, 2, 4], [4, 4], [3, 5], [2, 6]]

.... But your requirement "The program should be able to calculate these partitions for n=1..10000 in reasonable time" seems to me completely unrealistic for the reasons exposed in the attached file.
Indeed the number of partitions for n=1000 (including those containing "1") is about 10^31.

A_solution.mw

"Pr" is the conventional name for the Prandtl number: this is thus a numeric parameter that the OP most likely forgot to assign it a value (the same way C[p] denotes the Heat capacity for an isobaric process).

My bet is that the OP works on a some fluid dynamics problem with heat exange (aerodynamics?) problem (phi would then be a number called "potential velocity"... or a scalar function...), and I agree some explanations are necessary to state definitely if  a "*" is missing after phi[2] in these equations

   phi[2](1-phi[1]+phi[1]*rho[s1]/rho[fl])
   phi[2](1-phi[1]+phi[1]*rho[s1]*beta[s1]/(rho[fl]*beta[fl]))
   phi[1](k[fl]-k[s1]), phi[2](k[fl]-k[s2]),
   phi[2](1-phi[1]+phi[1]*rho[s1]*C[p][s1]/(rho[fl]*C[p][fl]))

@acer 

I agree, I was focused on the arguments of U and didn't payed attention to that point.
I woud have use  unapply if I had written the code myself.

Thanks for your correction

@salim-barzani 

In almost all the case a plotting error comes from the fact you want to plot something which is not plotable.
For instance, if plot(F, x=..) returns an error, it is almost always the case that F contains other names than x.

You can use indets(F, name) to check that, but its not enough, because F can also contains functions, for instance
F = s*g(a), or simply F = s*g(1),  and that will be revealed using indets(F, function).

In your case:

F := eval(U(x, y, a, b, alpha, beta, lambda__1, lambda__2, w__1, w__2), t = -50):

indets(F, name);
indets(F, function);
                             {x, y}
                          {Bij(1, 2)}

The plot can't be done as F contains this undeterminate function Bij(1, 2).

If you don'y want to use indets whar whatever reason, simply display F, examine carefully the output ans see by yourself what does wrong.
As a rule, as soon as you get a plotting error, display what you want to plot.

Personnaly I always display the function I want to plot before trying to plot it, self-overconfidence is never a good councelor and I know for sure that I do mistakes.