You cannot do it directly as some option to Tabulate.

But you can programmatically get a zoom by using some of the internal commands which Tabulate uses, and making use of an additional option of the InlinePlot constructor.

restart;
with(plots,display): with(plottools,cylinder):

c1 := display(cylinder([1, 1, 1], 1, 3), orientation = [45, 70],
              scaling = constrained, color = red, size = [300, 300]):
c2 := display(cylinder([1, 1, 1], 1, 3), orientation = [45, 70],
              scaling = constrained, color = blue, size = [300, 300]):

with(DocumentTools): with(DocumentTools:-Layout):

InsertContent(Worksheet(
  Table(exterior = none, interior = none,
        Row(Cell(InlinePlot(c1, scale = 1.7)),
            Cell(InlinePlot(c2, scale = 0.4)))))):

However, I'm not sure that the size=[300,300] will be preserved properly upon worksheet Close/Reopen. It's possible the DocumentTools:-Components could also be used, with the Layout:-InlinePlot call further wrapped in a Components:-Plot call that forced the 300x300 dimensions as width and height. Then suppress the component boundaries, etc. (Sorry, I was once more familiar with these subtleties, but it's been a while...)

I would not be surprised if Edgardo puts a fix into a Physics update.

But, here is a hot patch (for Maple 2024.0) that lets ODESteps handle that example.

Download odesteps_fail_nm_May_10_2024_ac.mw

One thing that it shows is that the two results of using alone either simplify or combine coincide, since the set of two identical results has collapsed to a set with only one member.

The sentence pertaining to this example in the Maple 2024 Advanced Math What's New page is [emphasis mine],

   "In Maple 2024, simplify and combine are both now better at
    recognizing when two piecewise branch values can be merged into one:"

I think that the main gist of that sentence is that simplify and combine are each separately ("alone") better at dealing with this example.

This is not a bug. Rather, it's a frequently asked question.

The sum command relies on Maple's standard evaluation rules for procedure calls, in which all the arguments are evaluated up front. But before p takes on actual integer values the first argument being passed to sum is actually zero.

In contrast, the add command has special evaluation rules, in which case evaluation of its first argument is delayed until the summing-index name p takes on its actual values.

Download bug_sum_ac.mw

When you use the key option the comparison `<` is done using evalb.

But evalb cannot resolve an inequality involving two items (the norms) which are not both of Maple type numeric.

The abs of the entries of your Vectors are all of Maple type numeric, so the infinity-norm works. But your other norm involves sqrt, and the ensuing radicals are not of type numeric. So comparison via evalb is inadequate.

But those radicals are of type realcons, hence applying evalf (in the key) produces corresponding floats, which are of type numeric.

So it's the very same reason as why you used is as your own check to compare 4th and 5th Vectors.

nb. When the key comparison fails an error is not thrown. But you can see the failure if using the equivalent two-element comparator instead of the key. option -- an error gets thrown,

Download SortingVectors_ac.mw

You can do that as follows, using assumptions.

Doing it in two separate steps avoids difficulties in the interplay of assuming and the names within the objects.

Download SMC_simplify_ex.mw

You do not need to use the symbolic option of simplify (which is dodgy in general).

You could also simplify the call directly, if using assume instead of assuming.

Download SMC_simplify_ex2.mw

You could construct them separately, with the disk having no edge.

Download how_do_i_change_the_color_of_the_line_around_a_disk_while_using_plottools_ac.mw

You can also compare the effect of having the inner color extend exactly as far as that of the edge (circle).

Download disk_edge_2.mw

If one simply shows the plots generated by your code then it doesn't appear that the numeric solutions for u(y) correspond to the purported "Analytic solution".  So, what is that "Analytic solution" formula supposed to represent? How did you obtain it? Be specific and clear.

Here's an adjustment to get results from your printf attempts. I adjusted the code to keep the dsolve,numeric solutions generated in its loop, so that these could be re-used when constructing the tabular data.

You haven't told us what you mean by "error". Do you mean relative absolute error, or absolute error, or something else? Be specific and clear.

HelpAhsan_ac.mw

Yes, there is.

Confusingly, that custom initialization file of preliminary Maple commands is named maple.ini on Windows.

See here for Help with that file, for all of Mac/Windows/Linux.

It's confusing on Windows because -- as you mentioned -- the user's GUI preferences file is named Maple.ini , ie. see here.

These two similarly named files have quite different default locations.

There are several stages to this explanation (which is part of what you asked).

The first is to recall/notice that a generic unspecified RootOf (for a polynomial) doesn't necessarily follow a single continuous curve. Even the indexed RootOf's don't do that. The indexed RootOf's are sorted, and the generic RootOf is taken from the end of those values (so doesn't follow any single one of them throughout). I try to illustrate this in the first attachment below.

The second thing is that when D happens to return unevaluated then evalf of that is a hook into fdiff. But D can actually work symbolically on the f that simply returns the RootOf. And for Gamma=0 the call to D[1] can produce a formula that generates an undefined result. Moreover, there's an important distinction between 'D[1](f)'(1/2,1/2) and D[1](f)(1/2,1/2). The former is an unevaluated call, and applying evalf to it will induce an fdiff attempt. The latter uses the formula that D[1](f)'s symbolic differentiation constructs. (Go back and see that you used the quoted 'D[1]'(f) in your original individual test calls, but in your plot3d attempts you used the unquoted D[1](f) variant. That's why your red and blue surfaces differ in their values along the relevant boundary.)

Also the numeric differentiation across the Gamma=0 and rho=1 boundaries will produce garbage results since the generic RootOf formula switches curve at the boundary on account of the appearance of multiple roots (which affects the principal root via sorting). See the second attachment.
ps. This "switching" affects not just parametrized indexed RootOf's. It also occurs with roots in explicit parametrized radical form. It's not just a Maple thing, but rather it's a Math thing.

The third thing is the issue of how to wade through all these difficulties. You might be able to get around the numeric differentiation issues by using slighty narrow regions. But how much narrower? How to know that features won't get missed? It's not very robust. So my third attachment uses the fact that the greatest root in the multiple root cases (of Gamma<0, Gamma near 0, or rho>1, rho near 1) happens to "match" the surface induced by the single root within Gamma>0,-1<rho<1. So one can compute all four roots (via indexed RootOf's), select the real ones, take the max of those, and get a smooth function across the boundaries Gamma=0, rho=1. So then numeric differentian behaves there. At rho=-1 I just went with a slightly narrower range. This is more time consuming, but the end result seems ok.  See third attachment.

And here they are:

Download PP_D_0_ac2b.mw

Download signs_derivatves_bivariate_acc2.mw

Download signs_derivatves_bivariate_acc2b.mw

To address your first query: the subs command does literal replacement. It's not for patterned replacement, e.g. catching any calls to s or any calls to s according to some pattern of its arguments. So, no substitution is done for s(n+1,t) is done if you merely instruct subs to use a formula for s(n,t).

Is this the kind of replacement you wanted for the first query?  shift_ac.mw

Apart from subsindets or evalindets, there is also the applyrule command for replacement of subexpressions by some pattern or rule.

You gave a link to an old Question. There is a statement that my Answer there:

    sourcefolder:=cat(kernelopts('homedir'),"/wkptest");

but you've instead got,

    sourcefolder:=cat(kernelopts('C:\Users\ahmed\Downloads\adty_v1_0'),"/wkptest");

which does not make sense. What you've got there is not a valid kernelopts call. But it also uses the wrong quotes, ie. neither name nor string quotes.

If you want the source to be located somewhere else (under your Windows home directory, say) then you could try it as one of these:

   sourcefolder:="C:\\\\Users\\ahmed\\Downloads\\adty_v1_0\\wkptest";

   sourcefolder:="C://Users/ahmed/Downloads/adty_v1_0/wkptest";

   sourcefolder:=cat(kernelopts(homedir),"/Downloads/adty_v1_0/wkptest"); 

and so on, presuming that you have actually unpacked it in such a location.

For query 2), if you pass Explore a parameter range with integer end-points, like,
   rho = -1 .. 1
then the Slider will only snap to integers -1,0,1.

You could alternatively pass a parameter range with float-point end-points, eg,
   rho = -1.0 .. 1.0
to have the Slider take on "more of a continuum" of float values.

@C_R You can make a first call to simplify with your expression, and trace `simplify/size` to see with what arguments that gets called.

Then you can restart (or forget as needed), and call `simplify/size` directly with the same argument that you ascertain from the first step. You can set printlevel before that.

I don't see how this would be effectively significantly different from what you are suggesting about some new functionality for a "local" printlevel option.

That second step would bypass printing of all the preliminary/final code executed by simplify, `simplify/do`, etc. And the second call could be terminated with a full color to avoid any typesetting details.

First step, from which all we want is to observe the arguments passed to `simplify/size`. (You could also pass the expanded expression, as a related example.)

restart;
trace(`simplify/size`):
simplify((a + b)*(c + d)+ (e + f)*(g + h)):
{--> enter \`simplify/size\`, args = (a+b)*(c+d)+(e+f)*(g+h)
{--> enter \`simplify/size\`, args = (_z1+_z2)*(_z3+_z4)
<-- exit \`simplify/size\` (now in \`simplify/size\`) = (_z1+_z2)*(_z3+_z4)}
{--> enter \`simplify/size\`, args = (_z5+_z6)*(_z7+_z8)
<-- exit \`simplify/size\` (now in \`simplify/size\`) = (_z5+_z6)*(_z7+_z8)}
<-- exit \`simplify/size\` (now in \`simplify/do\`) = (a+b)*(c+d)+(e+f)*(g+h)}

So now we know that we can just pass the expression itself to `simplify/size`, since we've now seen that's what happens when we call simplify itself upon the expression. (For other examples we might see that other arguments are passed at the inner stage of interest.)

Second step,

restart;
printlevel:=100:
`simplify/size`((a + b)*(c + d)+ (e + f)*(g + h)):
printlevel:=1:

Having said all that, I'll mention that -- personally -- I don't feel that printlevel is the most effective tool. I would always rather use the combination showstat/trace/stopat  with each of those being a crucial part of the mix. Others may feel differently, of course.

Here are two ways to get the value of S(t) from the solution returned by dsolve,numeric , where argument t has some numeric value.

You can actually use odeplot itself to get that other plot. Or you can use either way of using S(t) from the dsolve solution.

Download Paras31_2_ac.mw