@Joe Riel If the Iterators can be meaningfully compiled with dummy input as you showed, then why not do that and store the compiled versions in the library during the overall installation of Maple?

@subzero The command op(k, f) will extract the k^th argument of function f. Note that f must be a function (i.e., it must have arguments) for this to work; it can't simply be a function's name as is the U in the example that you just posted. The command op(0, f) will extract the function's "name", which isn't always a name in the strict sense. For example, op(0, D(y)(0)) returns D(y). Another way to think about it is that op(0, f) is what remains after f​​​​'s argument sequence is removed.

If you have an expression e from which you want to extract all functions whose first argument is x, use

indets(e, patfunc(identical(x), anything))

@Joe Riel Joe, If you're looking at that SCR that I submitted last night regarding the kernel crash, I have very significant additional information about it, which I'll email to you if you want. My evidence proves that the bug is specific to the combination of add and Iterator, that eval has nothing to do with it, and that the compilation is only tangentially related to it (the compilation leads to the kernel crash, but the underlying bug occurs regardless of compilation). However, my evidence suggests that the culprit is Maple 2021 changes to add, which may not be something that you work on.

@Ronan I don't think that using startup code would help because compilation happens for each use by default. [Edit: Joe has just said below that due to a recent change, the startup code actually will help.] But, for the small sizes of the cartesian products that we're dealing with here, the effort of compilation isn't worth it, and it can be turned off. Compare:

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
CodeTools:-Usage(
    seq[reduce= `+`](
        eval(B, M=~ [seq](c)), 
        c= Iterator:-CartesianProduct([$0..N]$(P-1))
    )
):
memory used=13.48MiB, alloc change=35.01MiB, 
cpu time=203.00ms, real time=205.00ms, gc time=0ns

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
CodeTools:-Usage(
    seq[reduce= `+`](
        eval(B, M=~ [seq](c)), 
        c= Iterator:-CartesianProduct([$0..N]$(P-1), compile= false)
    )
):
memory used=2.48MiB, alloc change=0 bytes, 
cpu time=31.00ms, real time=23.00ms, gc time=0ns

One may wonder why I chose a new-fangled embedded for-loop for the above Answer when an old-fashioned add command with an index variable would've been shorter and more to the point. The reason is that in Maple 2021 (only), the following gives a kernel crash:

restart:
B:= (2*m2 + 3*m3 + 4*m4)!*c0^(1 + m2 + 2*m3 + 3*m4)*c2^m2*c3^m3*c4^m4
    /((1 + m2 + 2*m3 + 3*m4)!*m2!*m3!*m4!*c1^(2*m2 + 3*m3 + 4*m4 + 1))
:
P:= 4: M:= [m||(2..P)]: N:= 4:
add(eval(B, M=~ [seq](c)), c= Iterator:-CartesianProduct([$0..N]$(P-1))); 

I have formally reported this bug. However, this bug is not manifested by the OP's slightly simpler expression A.

Delete As Spam seems to be working now.

@acer Yes, I understand, and if it were my code, I'd use add. Like you, I don't understand why inert Sum is being translated as it is, and I'd prefer it to be translated as inert; that just seems to be the way that it currently is (which is usually the basis for my Answers).

@subzero I think that you may find these examples useful:

e:= u(x,y) + u(0,y) + sin(x);
indets(e, function);
indets(e, function(name));
indets(e, And(function, Not(typefunc(mathfunc))));
indets(e, And(function(name), Not(typefunc(mathfunc))));

If you have an older version of Maple, the last two of those may given you an error. In that case, replace typefunc(mathfunc) with typefunc(anything, mathfunc).

@Thomas Richard @acer Thank you both; you've answered my Question.

@Axel Vogt Yes, ordinary deletion works as a stop-gap measure; however, we've learned the hard way here that it's ineffective as a long-term solution to the spam problem. I'm surprised that the Delete As Spam option has been quite effective.

@subzero

indets(e, function) 

@Maplestudent 

By the way, I don't have the foggiest idea what your intention was with the line
if i=1 then k:= k+1 end if
but nothing like that is needed. Possibly it'd be educationally worthwhile for you to try to explain that to me.

@pik1432 I agree with Tom that all of the parametric 2D plots that you show are correct, that they are as you originally specified, and that they all show a single curve rather than 2 curves as you claim. Note that all of your expressions named i_armature... become extremely simple after they are simplified. I suspect that this may be the root cause of your inability to see that these plots are correct.

@Rookieplayer 

Procedures vs. Expressions:
If W is defined as

W:= beta-> ... some expression that is piecewise wrt (wrt= "with respect to") beta...

then W is called a procedure. But if you define it as

W:= ... some expression that is piecewise wrt beta... 

then W is called an algebraic expression (you may need to set aside any preconceived ideas that you have about the definition of algebraic and just accept that that's what Maple calls it). There are pros and cons to either formulation, and it's often difficult to decide which to use. The two differences that are very significant in this case are How to take the derivative of W (or a function of W, such as W^2) wrt beta, and How to "set" the value of beta after that is done. I made W a procedure in my Answer, but the syntax in what you just wrote will only work when W is an expression. And so I suggest that you make W into an expression by simply removing the beta-> part from its definition.

If W is a procedure (which I'm recommending against at this point), then the derivative of W^2 wrt its 1st argument and then evaluated at beta is D(W^2)(beta) or diff(W(beta)^2, beta). Either will work just as well. Unfortunately, your diff(W^2, beta) returns 0 rather than an error message for any procedure W. The reason that it returns 0 rather than an error is an idiosyncracy of Maple (called last name evaluation) that's probably not worth discussing further right now.
 

Assumptions on variables:
In order to perform useful symbolic manipulations on expressions, it's often necessary to simplify those expressions (and I'm not referring specifically to the simplify command here but rather to the common verb simplify of mathematical English). This is especially true when integrating piecewise expressions. In order to perform useful simplifications, it's often necessary to place assumptions on variables, such as that they are within certain real intervals. Maple's default assumption is that variables represent complex numbers. In some contexts (such as inequalities), that becomes real numbers.

In your case, it will be useful to assume that theta__M is in the closed interval 0..Pi/4. Is that true?

There are two ways to make assumptions in Maple. These ways are closely intertwined, and there are several ways (often quite subtle) to affect the manner in which they're intertwined that I won't discuss further right now. The two ways are

1. use the assume command to make assumptions that will remain in effect either permanently on until they are explicitly removed;
2. use an assuming clause to make an assumption temporarily, for the scope of a single command or perhaps even a subexpression within a command.

At the moment, I'm going to recommend that you use assume. I may change my mind about that as I see how your work progresses. So, I recommend that you use the following command, preferably somewhere before the first place that you use theta__M:

assume(0 <= theta__M, theta__M <= Pi/4);

Simplification and merging of piecewise expressions:
Take a look at the output of the derivative that we've been discussing:

diff(W^2, beta);

You'll see that it's expressed as a product of two piecewise expressions. This is the result of the straightforward application of standard derivative rules (chain rule, power rule). I don't know what your ElementInt is, but it likely will work better if those piecewises are merged into one. That can be done by

diffW2:= combine(convert(diff(W^2, beta), piecewise, beta));

Then use diffW2 in place of diff(W^2, beta) as you proceed. This will only work if you've made an appropriate assumption on theta__M.

There are several further snags that can come with piecewise expressions, especially when they're inside integrals. I'd like to see how your work progresses before I make further recommendations.
 

@subzero If e is the expression, then do

indets(e, specfunc(U))

There's virtually no limit to the complexity and specificity of these type expressions.

@Rouben Rostamian  While it's true as you say that using and in piecewise is syntactically correct, it can cause unexpected results, and there's a recommendation against it. There are some examples at ?piecewise. It's almost never needed to combine inequalities (because of the left-to-right processing), although sometimes And (capital A) is needed for conditions that aren't inequalities.