@Michael 

1) I terminated my commands with a full colon in a few places, deliberately. I was trying to focus on the way the entries and procedure were displayed, without any distracting visual effects. This included:

   a) After definition of my variant on a procedure to read and then print a list of what changed in anames. That input line of code provides as much insight as would any displayed output of that same proc. I terminated that defining statement with a full colon to avoid such repetitious clutter.

   b) After my interface call. I set interface(verboseproc=2) higher than its default value of 1, so that procedures get displayed more usefully here. Note that here we want procedure bodies to be displayed in full even if they are read in from a dotm file or Library archive. When the interface command is used to set an option then its return-value is the old setting. I terminated that statement with a full colon so that you would not be distracted by that aspect.

   c) After my map[2] call. That call invokes printf on each entry in a list assigned to res. The printf effect is what I wanted you to see, ie. a plaintext display of your procedure, with line-breaking. But that printf display is a visual side-effect; the programmatic return-value from printf is NULL, and the return-value from that map[2] call is thus [] an emtpy list. I terminated my statement with a full colon so that you would not be distracted or thrown off by the output [] an empty list being printed at the very end.

2) Line-feeds are not part of a procedure structure, as stored by Maple. When a procedure is pretty-printed it gets displayed with some line-breaks, but not as many as you would like, it seems. There are a variety of ways to display the code of a procedure, and they display it in different ways. Not everyone else wants what you happen to want here, all the time.

ps. Here are some varieties of ways to display a procedure body. Since I'm doing it here on a proc that I define in the session (and not reading from Library archive or .m file) I don't need verboseproc=2.

Note that the first two examples below render differently in Maple 2024.1 than they do when the worksheet is inlined in this forum, ie. the outer procedure body may not get displayed with line-breaks. But your issue -- that the inner proc body is displayed in a single line -- is the same there.

Using lprint[2] is an alternative way to render display of the nested procedure with statement line-breaks and indentation.

Download disp_ex.mw

pps. Up until Maple 2018.2 the first example above would actually render with both inner and outer proc displayed with line-breaks (statement by statement), if one had the setting interface(prettyprint=1). But that no longer has that effect.

The %P modifier for printf was introduced in Maple 2019. The ability to add display a proc with line-breaks using lprint[2] was introduced in Maple 2019.

Starting in Maple 2022 the first example above even the outer proc would get less line-breaks during normal print rendering.

Also, since you're interpolating the data for the "density" plots then you might also want to use that same interpolating process for the contour lines (which then become smoother in places). It's just an idea.

For example,  Help_4_acc.mw

@salim-barzani I asked earlier what you meant by "export", but you still haven't explained either that or what you mean by "template".

Does template just mean a re-usable example that you could understand? Or does it mean a reusable procedure to help automate the process? Or something else? I don't understand why you keep mentioning it without explaining it in detail.

Are you hoping to export the numeric data, eg. a 2D Matrix after a plot3d call? mat_ex_3d.mw

Please don't post wholly separate duplicate/followup Question threads for this problem.

Instead, you can add your followup attempts and queries here, or use the Branch button from here.

Duplicate threads get flagged as such, and may be deleted.

@salim-barzani Your attempt,

   [abs]([s1, s2])

is not the right syntax here.

You can use the elementwise syntax,

   abs~([s1, s2])

to apply abs to both entries of the list [s1,s2].

Or you can use the map command to get the same result.

   map(abs, [s1, s2])

plot_of_2_function_of_one_type_ac.mw

@salim-barzani Here is an example. The two ways can produce the same combine result. It's your choice.

graph_in_simple_shape_acK.mw

Are you also wanting to annotate the various surfaces, in the combined plot, like with a legend for 2D plots? If that is so then you might look here.

@salim-barzani Four days ago I already showed you that you can construct a 3D combined plot of real and imaginary parts of an expression like so,

plot3d([Re, Im](s1), t = 0 .. 0.5, x = 0 .. 5, color = [red, blue])

But you've since deleted that entire Question thread, so I cannot make a working link to my Replies that contained it.

Of course, you can add other options to that call, eg.
   view = -15 .. 15, grid = [500, 500], style = surface, etc.

Note that for options such as color, style, etc, you can either use a single value which then gets applied for all the surfaces, or you can use a list of as many choices as there are surfaces. Eg, you can do either of these:

# to have all the surfaces get the same style
plot3d( [e1, e2, e3, e4], ...,
        style=surface );

# or, to get different styles for some of the surfaces,
plot3d( [e1, e2, e3, e4], ...,
        style=[surface,contour,surface,point] );

nb. In the special case of three expressions there is some ambiguity between whether those represent three different surfaces or three (x, y, and z) components of a single parametric surface. The default is to interpret a list of three expressions as denoting the parametric form. So, if you actually want three different surfaces then you also need the extra option,
  plotlist = true
For example,

plot3d( [Re, Im, abs](s1), t = 0 .. 0.5, x = 0 .. 5, 
        color = [red, blue, green],
        style = [surface, surface, point],
        plotlist = true )

Note that,
   [Re, Im, abs](s1)
is a shorter way to enter,
   [Re(s1), Im(s1), abs(s1)]

ps. You're sentences about a "template" are still opaque. You're not being clear about exactly what it is that you want.

Hi, sorry for adding this here; my link to contact a Member via message is not working.

Another Question by you (about Oct 2nd) was just deleted. I had an Answer in it relating to Explore. (I found your Explore usage followup goal -- about programmatic access to current parameter values -- so interesting that I wonder whether it might even make for a new Explore option, or at least a Help-page Example.)

Anyway, that whole Question thread has disappeared. Did you delete it, deliberately? If not, I might ask admin to reinstate it.

@Carl Love There are some chunks of right-click popup (or right-panel) menus which are purely GUI-generated.

Much of the remaining right-click popup menu items are pure GUI items, with all the items generated by the ContextMenu package appearing in the right-panel in modern versions.

The ContextMenu package is used to generate most of the menus of actions that appear in the right-panel in modern versions.

But even in the right-panel there are some items (appearing above the CM items, but below SubexpressionMenu items) which are GUI generated/related.

@salim-barzani 

graph_in_simple_shape_acccG.mw

@salim-barzani Please don't spawn yet another Question thread on variation of the Explore use I just showed above.

Instead, you could just put your followup in a Reply here.

@Paras31 Regarding your followup query 1) immediately above, I would first observe that even for,
   plots:-odeplot(sols, [t, U[67](t)], t = 0 .. 10, color = "green")
I get a more convincing and plausible plot if I called dsolve with stepsize=0.5e-5 rather than 0.5e-4.

So I am suspicious that the results even out as far as t=100 might be inaccurate. (I find it difficult to investigate, because it's time consuming. I worry about numeric error effects, limitations of the forced method, and who knows possibly even stroboscopic mirages.)

The smaller forced stepsize has another effect; it pushes out further the time at which that "cannot compute further..." error message might be a problem. But it also makes the computation slower.

On my Maple 2024.1 on Linux I can recover some timing performance here by also passing the compile=true option to dsolve.

So, for fun, you might adjust along these lines: v1_1_1_ac1b.mw

An animation from that, which looks plausible: (This is 200 frames. at 400 frames it's even more convincing. So this seems to be reasonably accurate out at least to t=10.)

ps. There's an old joke about computing. "Speed, robustness, flexibility. Pick two." Here I worry that your situation might be, "Speed, accuracy, ability to compute. Pick one-and-a-half."

Having said that, you haven't actually stated outright 1) whether you think your results were already all accurate (I doubt it), 2) whether you're actually striving for accuracy out for large t, or not, and 3) whether you're forcing rkf45 so that it might be more sensibly compared to solvers in other software, and so on. You haven't provided much in the way of explicit requirements. (For all I know, you might be studying the "apparently chaotic" effects of accrued error here.)

@Paras31 For your query 2) it looks like your two calls to plot U[67] are not the same. The second attempt is not a repeat of the first. It uses a different range.

The first has a range that in 2D Input looks like,
   0...58
which as 2D Input parses to 0 .. 0.58
But your second has,
   0..58
which is the range from 0 to 58.

Please don't spawn yet another wholly separate Question thread on the code shown here.

If you have a followup query (such as on the performance of code given here), then you can ask about that here in a Reply.

Duplicate Question threads get flagged as such and may be deleted.

AFAIK there is no limit (outside of memory and cpu resources).

I have spawned many concurrent commandline-interface (CLI) instances, without problem, on each of Windows, Linux, and OSX.

But, might there not be an optimal number, depending say on the number of cores/(hyper)threads?