Here is a Maple sheet that illustrates a pitfall, and a couple of alternatives.

Let us know if aspects are still unclear.
 

Download solve_asn_rec.mw

ps. At the risk of partly repeating myself...
    M[8] := eval(M[8], raw);        # OK
    M[8] := rhs(raw[1]));             # poor

[edit]
Maple guards against a recursive assignment, as shown above. If you trick/force it, and then evaluate, you can see a similar error message to what you had from Maple Flow. I mention this just to illustrate the similarity. Eg,

Is this the kind of thing you're after, for the,
   MinMachineNumber
   MaxMachineNumber

Download evalhf_const.mw

See the ?evalhf,constant Help page.

And for the "software" float case, you could look at the ?Maple_floats Help page. (But MAX_FLOAT divided by MIN_FLOAT would produce Float(infinity) in that context... as would DBL_MAX/DBL_MIN under evalhf.)

The union command merges sets.

In this example, you don't need union at all. You can just use {C4, C44} .

If C3 and C4 were themselves sets, then you could use {C4} union {C44} (and which would also work here).

Download Q_Constraint_error_ac.mw

Here are two ways of doing it, each showing both the difference and the ratio, in side-by-side plots.

>  restart; with(plots): setoptions(size=[500,200],style=pointline,labels=[x,""]); First way, calling dsolve just once, and using a procedure to set the parameter value. Calling the dsolve-return at each x-value in the target Vector.   >  de := diff(f(x),x,x) = -sin(a*x): >  dsol:=dsolve({de,f(0)=1,D(f)(0)=1},numeric,parameters=[a],output=listprocedure): Y := eval(f(x),dsol): >  F := proc(aa::numeric) dsol(parameters=[aa]); Y~(A); end proc: >  A := Array([seq(0..3,0.1)],datatype=float[8]): >  display(Array([   plot(A, F(7.1)-F(7.0), title=y[7.1](x)-y[7.0](x)),   plot(A, F(7.1)/~F(7.0), title=y[7.1](x)/y[7.0](x), color="Navy") ]));   >  restart; with(plots): setoptions(size=[500,200],style=pointline,labels=[x,""]); Second way, calling dsolve for each parameter value, and specifying the output option to the target Array of x-points.   >  de := diff(f(x),x,x) = -sin(a*x): >  G := aa -> dsolve(eval({de,f(0)=1,D(f)(0)=1},':-a'=aa),numeric,output=A)[2,1][..,2]: >  A := Array([seq(0..3,0.1)],datatype=float[8]): >  display(Array([   plot(A, G(7.1)-G(7.0), title=y[7.1](x)-y[7.0](x)),   plot(A, G(7.1)/~G(7.0), title=y[7.1](x)/y[7.0](x), color="Navy") ]));

Download de_V.mw

There are even more ways of accomplishing this. I don't know whether you'd rather focus on simplicity, or flexibility, or performance.

If you omit the stated conditions that TM1,TM2,TM3 are all positive then the shaded regions extend to the boundaries of the Pn=0..1,w=0..1 square.

Download Plot_3D_to_2D_ac.mw

One of the important differences is that, while both a[1] and a__1 get printed/rendered with a subscript in 2D Output, the double-underscore a__1 name is wholly distinct and independent from a the base-name of a[1] the indexed name.

Yet there is a programmatic dependence of the name a[1] on the base name a.  In consequence, it is problematic to use both a[1] and bare a in a set of equations used with commands like solve, dsolve, etc.

It doesn't make much sense to form an equation or system of equations in which both a[1] and a are both present. Worse still, doing so can confuse the solvers and lead to wrong results.

But people often like having both the base name and some subscripted form appear in some 2D Math examples. For example, it's popular to use y(x) , diff(y(x),x), etc, as well as y__0 (with a subscripted rendering) as placeholder for the initial condition y(0). That's not sensible to do with y[0] instead of y__0.

nb. In Maple terminology, the name a__1 gets printed with a subscripted 2D Output form, but it is not an indexed name. The name a[1] is an indexed name. Both names get printed with a subscripted form.

Try executing the Document using !!! and, when the popup appears, add some expression (say, just x) and press OK so that the plot gets inserted.

And make "Markers" visible. By that I mean the left, thin, side-bar.

That execution may remedy the Markers which were previously muddled together.

Then you may see that the Marker for the problematic block has two parts, ie. the red line doesn't extend to its very top. On the upper, smaller part (without the red line, ie. just above the red line) you can try toggling the box from the right-click action,
   Document Block -> Show Command

Those steps revealed the inserted command, for me.

I think that using a procedure for handling M and Br values is more flexible than preforming a Matrix with a fixed spead of values for those variables.

The following is just one example of what you could do. Note that dsolve computation is only ever done once for any M,Br pair of values. Mere plot-data-transformations are all that's then needed once that computation is done.

There are several other ways to do it, including even faster approaches, or ones with the colors being  "blocked" instead of in a density-style of spread. I don't know what balance of simple vs flexible vs fast you'll want later.

Download 3D_shadow_at_the_base_Help_ac.mw

I think that it it helpful to have more direct visual cues as to which vertical axis pertains to each curve.

I like to do that with color, so, below, the curves are in various shades of the two vertical axes' base colors. (Another way is to use various symbols, with point style, and colors that match the axes.)

The result is that, mentally, one only has to associate rendered curve's color with the nearby axis colors. But in your original scheme one has to mentally go from the curve color to the legend, then know/recall that the legend name's subscript relates to one of the two vertical axis labels, and then find which is that label by reading. Relatively, IMO, that was considerably more effort.

Also, this lets us make a visual association between matching superscripts (ie, W,S, or D), since each pair of curves that share a superscript can also be made to share a common brightness (or point symbol). The two brightest curves are the "W" expressions, and the darkest are the "S" expressions.

I've used Maple 2019, as the OP does.

Download All_plots_Combined_ac.mw

Student:-Calculus1:-InversePlot is an appliable module.

That means that when you call it with arguments (as a function call) Maple actually invokes the following procedure,

   Student:-Calculus1:-InversePlot:-ModuleApply

You can get the nicely printed rendering of that entry-point with,

restart;
kernelopts(opaquemodules=false):
eval(Student:-Calculus1:-InversePlot:-ModuleApply);

Or you can get the line-numbered display with,

showstat(Student:-Calculus1:-InversePlot);

Note that in 2D Input mode (only) the input that looks like,

     mX(m, isumSD_TOT) := isumSD_REG;

may get parsed as code to construct an operator (procedure) of two parameters.

But you obviously want to do Matrix indexing, instead. And you have chosen to use the round brackets for Matrix indexing.

I can't tell which version of Maple you're using (because you didn't mark this Question with a specific version, and you haven't provided your actual worksheet). But you appear to have encountered a 2D Input syntax clash, and are not getting the interpretation that you want.

I was able to reproduce it a few times in Maple 2022.2. Not every time, but enough to confirm it can happen there.

So you could either use 1D plaintext Maple notation for the problematic input line, or you could use the square bracket notation for Matrix indexing, ie.,

   mX[m, isumSD_TOT] := isumSD_REG;

The documentation of the Help page with topic overload explains that the mechanism attempts the procedures in order, and that it proceeds to the next only if an error exception prefixed by "invalid input" were raised by the attempt.

Note also that such an exception is raised for a procedure only if the "missing" argument corresponds to a parameter that is actually referenced in the procedure. Note the following distinction:

Download proc_ref.mw

The above distinction is clearly documented (by explanation in first bullet point, and also by the examples) in the "Required Positional Parameters" section of the Help page with topic parameter_classes.

And now we can see that, if such a error exception were raised in your first example pair, then the overload mechanism would proceed to the next proc.

Download nm_overload_ex_ref.mw

Was the file already there? If it wasn't, then you've likely got the wrong location. It's the existing user GUI-preferences file that you're editing, and it should contain a lot of other GUI options stuff.

Also, is it named, say,
    "//Users/$USER/Library/Preferences/Maple/2025/Maple preferences"
with a number like 2025?

(It wouldn't hurt to also put your userid in, rather than $USER, though it ought to resolve in a shell. You might also do it with, ~/Library/Preferences/ ...)

Of course, if you already found right the existing file (with its contents) then the location aspect is not the issue. The edited line ought to start like the other lines, eg. no tab at left.

Also, did you fully quit all Maple GUI instances before both editing that file as well as relaunching?

It is correct.

That squared term comes from the expanding of,
    cos(2*k*x)
to,
    2*cos(k*x)^2 - 1

Note that Maple's expand command by default will expand as much as it can here. That includes not only expanding the form cos(A+B) but also resulting terms like cos(2*C) and sin(2*C).

Let's go through the whole thing, in a few separate steps.

Download trig_exp_ex.mw

It occurs to me that you might not have considered that replacement of cos(2*k*x) as a kind of expansion. (And apologies if you were already fully aware of this aspect.) You can take 2*k*x as being equivalent to k*x + k*x, and so consider it like expanding cos(k*x + k*x).

Yes, see number 2 example compared to number 1; A reportable weakness.

Download simplify_real_ex0.mw

ps. I don't like the approach of placing assumptions on all indets of type `+`; it's rather ad hoc, presuming that those are all real without stating them explicitly, etc. It's not stronger than this (weak, IMO) approach:

Download simplify_real_ex1.mw

Note the following, which does not need x>=0 to be a given assumption. Looking at the expression, it seems reasonable to me: