@adel-00 Is this what you are trying to accomplish?

Apart from other problems including misuse of assumed names, your sprintf calls tried to use Lambda as if its value were a float, but it is unassigned.

Download adel00.mw

@Rouben Rostamian  The OP gave a target rhs in which most of the original (diff-unrelated) terms were not expanded. Kitonum called collect (wrt R1) to undo that effect, but that is a slightly ad hoc or manual intervention.

I surmised that the OP wanted the remaining rhs terms left mostly as is, perhaps even more so than in the supplied target.

By using either collect or expand the diff terms can be initially separated. But by using collect for the initial separation of the derivatives there is less expansion to undo, for this example.

And if the leading sign is not crucial then my answer is shorter still.

There are other kinds of example where the effects of expand can be troublesome to undo. Sure an expanded call like sin(a+b) can be undone using combine. But there may be other trig products in the original which one doesn't want combined into a sum of trig calls on sums. Sometimes a frontend'ed call to expand can serve, but that's more effort to invoke.

And there are other related examples -- originally only partly expanded. Calling expand may expand too much, so that recovery of the very same extent of expansion is hard or practically impossible.

So it's my preference to not call expand, generally, if something else serves reasonably.

More specifically for this particular example: the OP wrote that he wanted the derivative terms to be collected, and he even provided a target that illustrated that. Now, the following accomplishes that but seems inferior because,
1) it calls both expand and collect, yet as I showed only collect is needed, and,
2) it expands all the remaining rhs terms, which would requires a rather ad hoc call to undo.

((L,R)->collect(L,diff)=-R)(selectremove(has,expand((rhs-lhs)(eqn)),diff));

@adel-00 This is still reasonably quick.

Download evalf_int_3d.mw

@vv It can survive garbage collection while there is still some reference to it.

In your example it is still referenced by % (and %% and %%%).

@pauldaas I am guessing that you are showing a reduced example of what you eventually hope to accomplish. But it's difficult to make it the easiest and most robust without knowing in what more general ways you intend on using the code.

But here are two versions that might give you some hints. I've removed the `global` of the procedures because those seem unnecessary (the code assigns the returned results to R, and C seemed to serve no further purpose). I've removed calls to linalg commands. The procedures aF00111 and aM0011 are merged into a single procedure where the key aspect is that the 4th argument passed to it may be, say, F or M. And in one version I've removed L altogether, since there seems no real need to assign to the global names RA,MA,tA,yA when calling aFshear since the entries of R can be utilized directly.

pauldaas_01.mw

pauldaas_02.mw

Hopefully these still operate in a way that blends with your more general (and as yet unstated) purposes.

@Christian Wolinski Those work, too, for the polynomial p I created.

@MDD It only takes a fraction of a second to check hundreds of thousands of entries (in the worst situation that all the polynomials depend on x or y). It may not make much difference to you which you use.

restart;
randomize():

N := 10^5:
S := {seq(randpoly([x,y],degree=3),i=1..N),
      seq(x+randpoly([a,b,c,x,y],degree=3),i=1..N),
      seq(x+randpoly([a,b,c],degree=3),i=1..N)}:

func := S -> not andmap(has,S,{x,y}):

CodeTools:-Usage(func(S));
memory used=13.73MiB, alloc change=0 bytes, cpu time=96.00ms, real time=96.00ms, gc time=0ns
                             false

func4 := S -> ormap(s -> degree(s,{x,y})=0,S):

CodeTools:-Usage(func4(S));
memory used=36.62MiB, alloc change=0 bytes, cpu time=289.00ms, real time=289.00ms, gc time=0ns
                             false

nops(select(s -> degree(s,{x,y})=0,S));
                               0

nops(S);
                             300000

@mmcdara Of course it is necessary to utilize either the set/list of variables or the set/list of parameters. Even though I've edited my Answer (mostly for efficiency), every method I've written has utilized either the variables {x,y} or the parameters {a,b,c}. So I don't follow your point.

Is there some reason why you haven't posted a worksheet which (for you at least) reproduces the problem?

@EB1000 I am not aware of any practical way (or GUI option) to force the Library-generated context items to appear in the right-click popup in Maple 2019.

I also don't see any option to control the destination in the GUI's resource file.

If you could demonstrate that some other installation of Maple 2019 really did offer all the Library-generated items in the right-click popup menu then it'd be quite interesting in how it was configured.

I'm not even sure how I could force/fake it, except by writing a complicated Maplet which utilized the results from the ContextMenu command (and launched that Maplet from an edited version of that command), and which also knew about the ancilliary popup sub-Maplets.

You wrote it as "ConxtextMenu" instead of "ContextMenu".

Or are you saying that right-click on output gives you no popup at all?

@waseem 

You should figure out whether your formulas actually represent what you want.

Help1_ac_k.mw

@waseem I don't understand why you are undoing key aspects of my edits. You're latest attachment had more changes than just the introduction of additional terms.

I deliberately made several changes to your earlier worksheet, including:
1) Adjusting the definition of A so that it matched the formula from your earlier post's question about translation from Mathematica. This produces plots with zero imaginary component, suggesting that it's moving towards the right approach. I don't understand why you have reverted this.
2) Removed applications of evalf to Int calls which had extra options (since doing so removes them).
3) Increased Digits to 15.

In the following worksheet purely real results are obtained using either your latest S1 or the adjusted S1 formula to match your earlier post's definition in Mathematica. So I cannot say for sure which one is correct. Both produce purely real results for plotting, but different results. Likely only you can figure out which is correct.

I cannot know whether your formulas for the additional terms in c2 and e2 are correct. You might have made the same kind of "mistake" as earlier, with the grouping of terms in the denominator. Likely only you can figure out what is correct there.

You should think hard and carefully about those formulas. Just because you obtain purely real results from the integrations does not by itself mean that you have the formulas correct.

I have tried to make the inclusion of extra options (for the numeric integration) come immediately before the plotting, so that even if you once again splatter evalf calls in the formula definitions the plots might still compute. But only you can check that your formulas are correct.

It's possible that you could screw up my edits again, despite my latest efforts to guard against that. If you do I won't be looking at it any more.

I ran this in Maple 16, since I won't have access to Maple 13 until later in the say. But I suspect it will produce plots in your Maple 13 (as I tried the same kind of thing yesterday).

note: You legend values don't match the actual values which you're using for gamma2. I'll let you correct that.

Download Help1_acc.mw

@fatemeh1090 Does this work better in your LaTeX environment?

Naturally, you may wish to break the line (using \\ in the LaTex, or pasting it in by parts, or however you utilize $, $$ \begin{} or what have you).

end_ac2.mw

printf(StringTools:-SubstituteAll(
         StringTools:-SubstituteAll(latex(eval(new,1),output=string),
                     "\\mbox ",""),"\\tt ",""));

\sum _{m=1}^{M} \left( \sum _{k=1}^{N}C_{{{1}}_{{{i,m}}}}\,C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,m}}}} \right) -A_{0}\,H_{1}\,\sum _{m=1}^{M} \left( \sum _{k=1}^{N}C_{{{1}}_{{{i,m}}}}\,C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,m}}}} \right) -A_{1}\,F\sum _{k=1}^{N}C_{{{2}}_{{{i,k}}}}\,\psi_{\theta_{{{k,j}}}}+{\frac {A_{1}\,K_{4}\,\sum _{k=1}^{N}C_{{{1}}_{{{j,k}}}}\,\psi_{\theta_{{{k,i}}}}}{r_{i}}}+1/2\,{\frac {A_{0}\,K_{4}\,\sum _{k=1}^{N}C_{{{1}}_{{{j,k}}}}\,v_{{{0}}_{{{k,i}}}}}{r_{i}}}