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.

@Suy The Jacobian of f (as a list of lists) is map2(diff~, f, x). If you want a matrix, then you might as well use what mmcdara showed.

@pik1432 The function that you call I_armature2 simplifies to abs(Q__t). You can see this by

simplify(i_armature2);

@datokala 

Consider the solutions produced by solve that Tom's code has stored in sol: It is a list of sets of inequalities, each set containing a pair of inequalities that constrains m either to a bounded real interval or the complement of a bounded real interval. For the plots, we need bounded intervals expressed as m= a..b where a and b are real constants. (I find it unfortunate that Maple has several ways of expressing real intervals (at least 5 (!) that I can immediately think of), and it's not always easy to convert them from one form to another.) In the case that you just asked about, a = lhs(sol[1][1]) and b = rhs(sol[1][2]). Let's parse those:

• sol[1] selects the first set from the list. Every nonempty list has a well-defined "first" entry.
• sol[1][1] selects the first inequality from the set sol[1], and sol[1][2] selects the second. When dealing with sets, there is some risk involved in ascribing ordinal positions (i.e., first, second, etc.) to the members. I would only do it in one-time code where the set involved is displayed on the screen. Thus, this operation is not suitable for automatic use.
• lhs(sol[1][1]) selects the left-hand side of that first inequality, and rhs(sol[1][2]) selects the right-hand side of the second. The commands lhs and rhs are used to deconstruct those Maple operator expressions that necessarily have exactly two operands: a=b, a<b, a..b, a <= b, a::b. Maple always converts a > b to b < a and a >= b to b <= a, so there's no need to consider those cases separately.

@mmcdara I think that many people aren't aware that bug has a precise technical definition. Perhaps when you've had disagreements about whether something is a bug,, one of the disagreeing sides is not using that definition. A bug is a situation where a program behaves contrary to its documentation. 

@vv The crucial difference, which the OP has repeatedly made mistakes with, is how irem and mod react to the combination of symbolic input for their 1st argument and integer input for their 2nd argument: mod evaluates and irem does not.

I point this out for the benefit of the OP, not for you: These are the intended behaviors of these two commands by design; they are not bugs or even shortcomings.

If the OP would like to change the behavior of mod so that it acts like irem, it's trivial to do that. I think that Maple makes that much easier to do than most languages.