@WD0HHU The direct result of your substitution is an expression that is unsimplified (and unexpanded).

You could apply one of the commands expand, normal, or simplify to that result, to get the explicit zero.

@nm In this case solve returns several solutions (as lists).

And here [solve(...)] is returning a list of lists.

So, here, you'd need to map your stated approach (which itself maps an operator).

And for a list of such lists of lists of equations, you'd need to map yet again at another layer...

I used subsindets because that single call handles all the equations in the whole expression list-of-lists, etc, directly, regardless of nesting depth. Not a map of a map of an action, or what have you.

It's not just that I don't want to have to type out any extra mapping layers. I'm also ok not having to need to think about it (as a single subsindets call suffices here).

@WD0HHU If you run the command,

   [solve(sys,explicit,allsolutions)]

on that system then the various solutions will contain many "trivial" items, such as a=a, or C[1]=C[1], or sigma=sigma, etc.

I find that those are somewhat distracting. So I apply the following to that list of solutions,

   subsindets( that_solution_list,
                       `=`,
                       eq->ifelse(eq,NULL,eq)
                      );

So, what does that do? If replaces with NULL any equation in that raw solve result whose rhs equals its lhs. A trivial equation like  lambda=lambda  has that property, and is one of those removed, ie. replaced by NULL. It's an equation, ie. of type `=`.  And under the evalb test which ifelse applies it returns true.

evalb( lambda=lambda ); # returns true, causing the next line:

ifelse( lambda=lambda, NULL, other ); # returns NULL

For example,

L := [a=b, c=c, d=e, f=f];

       L := [a = b, c = c, d = e, f = f]

subsindets( L, `=`, eq->ifelse(eq,NULL,eq) );

               [a = b, d = e]

So, the trivial identity equations are removed (replaced by NULL), and others are left untouched.

Hope that makes sense.

nb. The various solutions in that list [solve(...)] can be substituted into the original polynomial equations, to show that they really are solutions. But that can also be done with the shortened solutions (with the trivial items removed).

You could submit a Software Change Request (aka bug report) with those details, by filling out the form here.

@Ali Guzel  You didn't supply the details I described as being more important.

I changed your Post into a Question.

But your posting is missing important details. What version are you trying now? More importantly, what did the intermediate results look like in Maple 9.5 or whenever it last worked as desired?

@Hullzie16 For this plotting task it is much faster to use implicitplot rather than a procedure which calls fsolve.

The idea is to first compute the implicit plot where equation R holds (S vs C), and then to transform that plot result, using the T expression as a formula for the new vertical component.

Also, there appear to be two roots, for significant portions of your parameter space.

In this attachment I show Explore working on the implicitplot. I also include the two "curves" generated by taking either the first or second root that fsolve can find, just to show that together they correspond to the implicitplot result.

In the code below the procedures CC (and CC2 and CCboth) are now only used to first show that the new technique is ok. For the faster implicitplot approach (and its Explore) all the calls CC(S,mu,Z,Pr) in expression T are never executed or called(!). Instead, they are replaced by the vertical component y-values from the implicitplot of R, when transforming it. That's what's going on in the second line of procedure Timpl below.

The plot recomputation in the Explore assembly is so much faster with this approach that I can get rid of the continuous option on the Sliders, and get a nice smooth action.

Download Explore_Plot_Problem_ac4.mw

Without the above comparison of approaches, this implicitplot approach alone is quite short, and utilizes just your original expression forms for T and R.

Download Explore_Plot_Problem_ac4B.mw

@Hullzie16 I prefer assignments over Equation Labels, and I wanted a quick way to shoehorn the R expression into the procedure CC.

There are other ways, eg. using eval(R, [:-S=S,:-mu=mu, etc]) as the argument to fsolve, so that the arguments of CC got put into the R expression when CC were called.  Explore_Plot_Problem_ac2.mw

And here's another variant, using procedures instead of expressions&eval.
Explore_Plot_Problem_ac3.mw

@GFY I wasn't so confused by your use of Eval (vs eval) as I was that you were multiplying D[1] by something. The name D is special, and denotes the differential operator (for use on procs). If your using D[1] as a mere name then I suggest using another name.

On the subject of D, note this comparison of derivates in diff/Diff expression form and in D operator form. Note also that you can utilize Diff instead of diff, versus Eval instead of eval. I'm not saying that D would serve you better, as I don't know your full set of use-cases. But you might find it useful to learn about such, and conversions.

D_diff_ex.mw

(And the D operator can also handle multivariate procs. That's all related to why I found the product involving D[1] confusing. See also the Help-page.)

ps. Like sand15, I simply used lprint of what was actually being sent to algsubs (ie. the result of expand(eqn1)), to see what was going on. And now that's in your tool-set.

I have seen a report of it working in M2025 and M2026 on Windows 11.

@GFY I see now. Somehow I'd got the impression that there might be some other, more involved example.

Yes, this is a key purpose of IntegrationTools:-Expand, which is why I mentioned it in my Answer.

Your example-at-hand shows that I may have been too worried about unwanted extra expansion of subterms in the integrand. I was considering an unfortunate example such as,

    goo := Int( (1-cos(t)^2)*(1-sin(2*x)^2), x=a..b );
    IntegrationTools:-Expand(goo);

But if that kind of thing isn't causing you problems, then all the better.

ps. In your last Reply you seem to be using the word "summation" to refer to an explicit, finite sum of terms, ie. the result of explicitly adding a concrete, finite number of terms. That is not a good use of that word, especially since in your original Question you used around Sigma notation  and a name n as upper end-point, for your query 1).

You wrote, "...using Expand does indeed make it possible to transform the inert integral of a summation into a summation of inert integrals."  But that's not true at all. Transforming an integral of a summation into a summation of integrals is the topic of your other query 1). The Expand command makes it possible to transform an integral of an explicit sum of terms into an explicit sum of integrals.

@GFY You haven't supplied your more complicated, explicit examples, so it's difficult to be sure about what difficulties you might have had with part 2.

It's not clear to me whether you are starting with the integrand in a state that is factored into f(t) and g(x) multiplicands, and whether the stock command attempts were just muddying up the integrand too much for easy recovery.

It's quite possible that a dedicated routine would be much better, once in f(t)*g(x) form. I mean, that could be a reusable, short proc -- something nice in an init file. Would that be useful?

@GFY He has used a Code Edit Region.

This is a link to its Help page in a more recent version than your Maple 2022.

In your version your can access its Help page by query for Topic CodeEditRegion,

@emendes 

I realize that there were already comments that described that proc as being less efficient. But I don't understand the point of showing something flawed in ways that can be remedied. (That's a bit like a straw man...)

Also, another variant given by janhardo in the same Reply contains,

   [seq(seq(subsop(i = model[i] + t, model), t = convert(missing[i], list)), i = 1..n)];

but that lacks a check on whether missing[i] is of type `+`. If it's not, and if it's a single product term, then conversion to a list will produce the wrong result. That's a bug in the code.

Also, not all of these variants seem to give the same results for your example problem.

Parts of the revision shown by janhardo is inefficient. It illustrates a classic programming problem.

I have seen AI generated code (reposted by janhardo), make this mistake before, in other postings.

result := [op(result),
           subsop(i = model[i] + t, model)];

One of the problems with repeatedly augmenting a list in this manner is that it's unnecessarily of a higher computational complexity (in memory). It can scale up unnecessarily poorly in consequence.

A technique of instead adding new items into a table, and then producing a list from that as a final step, is often better. (Note that was done in the OP's earlier version.)

Using another data-structure might be faster, and doing less additional work (than the original) might be faster. But that revision by janhardo likely doesn't scale up as well as it might do, because it's falling afoul of O(n^2) instead of O(n) memory use for assembling some results (and ensuing memory management cost) unneceassarily.