One way is to utilize the plots:-listplot command, with the useunits option.

testSheetHorseShoe_ac.mw

That attachment produce the following, amongst a few other plots.

The plot command works with Maple's usual scheme for procedure calls, and its arguments are evaluated up-front, ie. before the plot routine receieves them.

So when you call,

   plot(kk(3,m)[1], ...)

then the call kk(3,m) gets evaluated up-front, ie. before m gets any actual numeric values.

But when m is just a symbolic name then the sort actions inside your kk procedure don't act the same way (for generic name m) as they would for all the numeric values of m.

The key thing, then, is to delay the evalutation of the argument k(3,m)[1] passed to the plot command until such time as name m gets actual numeric values. That avoids the so-called premature evaluation.

This is a very common user-issue.

Below, I show you code for two ways to delay that evaluation, for your plot attempts. The underlying problem and its possible alternatives are the same here for plot3d as they are for plot, so I'll leave those for you to adjust according to whichever approach you choose.

Download gra423_Omega_ac.mw

nb. You could also delay the evaluation with single right-ticks (aka unevaluation quotes), by instead doing it as,
      plot( 'kk(3,m)'[1], ... )
but I didn't show that above because quotes seems to confused some people (and also because the uneval-quotes are ephemeral; if you pass around an expression with them then they vanish, upon intermediate evaluation...). Definitely not the best choice.

ps. There are several kinds of ways in which the issue of premature evaluation can be an issue. Another common case is where an error message occurs when the plotted procedure call gets accidentally evaluated. As you can see from that link, that error is common enough that it has its own special page. Your situation is more insidious because instead of a helpful error and stoppage your code merely procedes with wrong values (which for another example might possibly be overlooked).

Using implicitplot3d for generating a plot of a plane is a relatively very inefficient way to do it.

But first, to address your particular query: No, you don't need the plots:-display call, and that's not actually what made it work for you. What made it work for you is that your large plot structure by default needs a separate printing, without being in an assignment statement, in order for the GUI to render the plot. See the attachment below, for an example.

A more efficient way to construct the 3D plot of the plane would be to use the plot3d command with the minimal grid=[2,2] option. (Using a small plot structure will get better GUI performance if you have to rotate it much, or use it in an animation, or export it, or transform it, or right-click adjust it much, etc.)

Download 2025-05-18_Q_display_a_simple_plane_ac.mw

nb. For this example, the plt0 structure is about 1000 times larger than P.

Here are a few ways, producing either Matrices or DataFrames. Choose which you'd prefer.

The key bit seems to be removal of the datatype=truefalse from the inner Matrix, so that arbitrary substitutions can be made. That datatype restricts what kind of value can the stored entries can take.

I've split these into a few steps, both to show an idea of what's going on as well as to allow you to just take the generated Matrix rather than the new DataFrame (if you prefer).

Download TT_dt.mw

You can use Or(x<1,x>1), to forestall difficulties with assuming x<>1 (both at once, which can sometimes accidentally turn into `false`).

Download odetest_challange_may_15_2025_ac.mw

ps. I do not recommend using simplify(...,symbolic), if you really care about whether the result is correct.

It's pretty easy to just do the brute force check, with a double seq/loop, and quite quick for just going up to 100.

So, for a fun alternative,

Download sol_fac.mw

Since N=7 is small there are even more lightweight and very fast alternative approaches. (Even the cost of the F procedure calls is slightly wasteful here.) Perhaps the nice typesetting of the solutions is the more interesting bit here, and naturally you can use that no matter how you compute the solutions.

Another way, for the second problem,

Download test1_ac.mw

I agree that it is a bug, the behaviour is at odds with the Description on the ?convert,Vector Help page which states that the default orientation is column.

I notice that Description says that an Array or list would each be passed straight to the Vector constructor. But notice the following difference in behavior (which appears to be the explanation of the behavioral side of the coin here):

It's possible that the person who wrote the ?convert,Vector Help page overlooked the fact that no single orientation satisfies that act of passing some structures straight to the constructor; ie. it varies by nature of the argument. It's even reasonable that someone might deem the appropriate fix to be to amend that documentation and retain the current behavior.

Having said that, I usually prefer do that kind of thing like,

    Vector[column](A);

I also convert-to-Matrix in a similar manner. Those constructor calls preserve datatype which is often quite important to me, and also storage=sparse (which, while much rarer for me, is something I'd often prefer my code respect by default unless I was deliberately coding to clobber it).

For example, if I had a list L I'd convert it to a Vector with,
    Vector(L)
rather than,
    convert(L,Vector)
which is both longer as well as (for my purposes, often) inferior. Similarly I'd handle a listlist LL with,
    Matrix(LL)
rather than,
    convert(LL,Matrix)

nb. In other words, I'd prefer to call the constructor directly, rather than write out a convert call which is more verbose while getting to the same act. I see less merit in calling convert in many such situations.

This was reported by someone else a little while ago, also for Maple 2025.

You might need to wait for the 2025.1 point-release, to get a GUI-update that fixes this.

(I do not believe that this can be fixed by a pure Library-side change, eg. in SupportTools).

That's the way it is, for 3D plots.

For 3D plots, the GUI places the largest "square" inside the inline plot window (the thing that has resizable borders, when you place the mouse focus on the plot). The `size` option only specifies the dimensions of the inlined plot window, and has no effect on the aspect ratios between the three extents of the displayed axes. I believe that the design intention is to allow the full plot to remain fully visible upon any manual rotation angles.

It is possible to use the DocumentTools package to embed an inline plot with the zoom factor programmatically specified. This can give the effect of stretching (only) horizontally, without the wasted white space above and below. If you look at the InlinePlot call in the very last example here ( Help Topic ?DocumentTools,Components,Plot ) then you can see such a programmatic zooming effect in which a long, short 3D thing is plotted without wasted vertical white space. (The effect is better see if you run the example in your Maple; the online Help page's rendering muddies the effect.)

The idea here is that the size option forces a long&short inlined plotting window, and then the rendered 3D plot seen through that window is forcibly zoomed in. That's the only way I know, to get such an effect programmatically at present. Another example, here.

Let us know, with an actual example, if you have trouble getting that effect to work for you. nb. I also don't know whether the effect maintains properly, on Close & Reopen of the sheet.

I've wanted 3D axes aspect ratios, as programmatic options, for some time now. But, in their absence, you're left with the choice of either unconstrained scaling (ie. all-equal aspect ratios) or a poor man's (still not fully satisfactory) effect if you manually rescale all your plot data/functions to mimic the desired aspect ratio.

The OP has encountered a common usage difficulty for users new to Maple.

In summary,
i) Using unevaluation quotes to delay the evaluation of the first argument works here, but is not the best general solution. Yes, it works for this example. But I've seen this usage devolve into even murkier difficulties far too often.
ii) Using irem vs modp happens to work for this example (and can have better efficiency) but is not by itself the best general solution because many similar difficulties arise for problems having nothing to do with modp/irem.
iii) The add command is more appropriate that sum here. It's specifically designed to better and more more generally handle this kind of issue. Yes, it's unfortunate that the 2D Input Sigma symbol is hooked into sum rather than add. But the allure of the typeset Sigma notation doesn't generally make up for the shortfalls of using sum in such situations.
iv) Similar distinctions can arise with product vs mul.

Altogether,
    add(irem(5, mul(2, t = 0 .. irem(q - 1, 3))), q = 1 .. 2)

And now, for some details,

Download sum_add_eval.mw

This is a common issue for new Maple users. There are lots of examples of this kind of problem on this forum.

There are also several Help Pages devoted specifically to the issue: eg,
1) special evaluation rules
2) sum vs add

Does this work for you? (Check that it makes good sense. It's late in the day...)

Download how_to_verify_parametric_solution_to_ode_ac.mw

You have defined the substitution equation T1 as,

   T1 := u(x, t) = U(-t*v + x)*exp(k(t*w + x)*I)

where you are missing a multiplication symbol between the k and the opening bracket. That gives you a function call k(t*w + x) , ie. a call to unknown function k. When you then substitute into the derivative wrt t the chain rule applies, and you get D(k)(...) terms.

You may have intended, instead,

   T1 := u(x, t) = U(-t*v + x)*exp(k*(t*w + x)*I)

Download tr_ac.mw

Is this something like you what you're after, without the fractions? (Below are two ways, for this example)

Download B-R_ac.mw

> restart;
> kernelopts(version);
   Maple 2025.0, X86 64 LINUX, Mar 24 2025, Build ID 1909157

> A := -x*(x - 4*exp(x/2) + 2):
> B := x*sqrt((-8*x - 16)*exp(x/2) + x^2 + 4*x + 16*exp(x) + 4):

> simplify(simplify(A-B, {exp(x)=exp(x/2)^2})) assuming x::real;

                    0