r := 1.9;
                            r := 1.9
i := trunc(r);
                             i := 1

First of all, you don't tell us anything about the qualitative nature of the plot you are expecting, or what specifically you object to above the plot originally produced. (The thing you wrote about "two arguments" makes no literal sense.)

We can of course guess that you object to the sign flip between the discontinuities. But tell us precisely.

Next, while it may not be the cause of your issues, it looks like a really bad idea to apply evalf all over the place, and have those float exponents. Do you understand that when there are branch-cut issues -- around say rational multiples of Pi -- turning exact values into floating-point representations can be trouble. If the float rounds just above..., or just below..., the behavior can change.

So, I am guessing that the combine(zeta_c, symbolic) might resolve your issue. (But, really, you're the one who supplied the various exp calls in the first place, without explanation or source...)

Here's one version with floats, and one without. Is this the plot you expected? Or perhaps as likely, its negation?

Toya_complexPlot2_ac.mw

Toya_complexPlot2_ac_exact.mw

I no longer believe in coincidences.

Working on another question here -- right now -- I stumbled across the same phenomenon.

The problem is the gridlines option, which your .mapleinit sets to true in a call to plots:-setoptions.

If I include that gridlines setting, then the GUI goes bonkers in the way described when I try to use plottools:-transform to raise a 2D plot up to 3D. (I have to use the menubar's Edit->Remove Output From Worksheet, then Save As another filename, then File->Close, then re-open, etc, to recover.

But if I exclude that setting then it goes OK.

I found this out, on the side, because I now habitually use plots:-setoptions to set gridlines=false so that the ancient Mapleprimes backend MapleNet engine doesn't render my inlined worksheet's 2D plots with ugly gridlines.

And then when I tried to transform a 2D plot to 3D I saw the same GUI crash, in Maple 2018.1 on 64bit Linux.

One might guess that setting gridlines=false wouldn't do anything concrete, since the default in the Maple GUI is not to show gridlines when no option for it is supplied. But in recent versions of Maple it actually puts a _GRIDLINES substructure within the PLOT structure of a 2D plot.

Anyway, the problem seems to happen whether the 2D plot is constructed with gridlines=true or gridlines=false.

Anyway, either the plottools:-transform command doesn't handle the GRIDLINES substructure properly when converting from PLOT to PLOT3D, or the GUI is mis-handling what it gets. Probably the former, where plottools is now failing to strip it out, since 3D plots don't really support gridlines. I will submit a bug report.

If you wish to retain your use of the gridlines option within the setoptions call, you could work around the issue by stripping out the _GRIDLINES structure.

Download display3d_subs.mw

Try the command ListDirectory from the FileTools package.

Your main problem was that you were calling your procedure UP with GAMMA as the argument instead of the typeset GAMMA-with-an-overbar.

In order to use Grid:-Seq here you also need to tell the kernel to pass along the definitions of `index/xxx` and RrProc. For that you can use the Grid:-Set command. And also, pass Rr into UP.

I changed the unprotect(GAMMA) to local GAMMA as a top-level declaration. You don't anything like that for the typeset GAMMA-with-an-overbar.

Now the Grid:-Seq runs twice as fast as seq on the two UP calls, on my quad-core 64bit Linux machine under Maple 2017.2. I change M=5 to M=12, to make it take a little longer.

What matters is the real time, which is wall-clock time.

[edited] If I set M=100 to make it long enough to examine the timings better, it takes 33sec with Grid:-Seq and 66sec with serial seq. And the answers are the same. Under serial seq my Linux machine's load showed at 100% (one mserver process), while under Grid:-seq it showed at 200% (across two mserver processes). 

[edited] Your mileage here may vary with OS and Maple version, but this exercise leaves my OS running multiple defunct or orphaned mserver processes (taking no load, phew!), even when the GUI is completely quit. I have to kill them manually.

Download soal_ac.mw

The problem is that you are trying to use GAMMA as if it were a previously unused name. But it is already the name of a procedure in Maple itself.

Trying to unprotect the name, so as to try and use it like a regular, unassigned name, is something you should NOT do.

The error message is telling you what to do. Replace the call to unprotect(GAMMA) with,

local GAMMA;

Or use another name. That might be advisable, if it's supposed to be passed off via Grid. 

Why not solve for t, symbolically, up front? You can utilize that formula directly within the plot command. (There's no need to produce discrete data, although you can if you want.)

Download form_plotting.mw

You can automate parallel (concurrent) computations by using either the Grid or Threads packages. That would be considerably superior to using separate worksheets to cobble together your own parallel computation environment.

As a very rough but general rule: if you can parallelize the job at a fine level (usually for something which is purely numeric and thus more readily made thread-safe) then the Threads package is more suitable, while if your overall goal is more easily parallelized into larger and more computationally expensive (usually fewer, higher level) jobs then the Grid package is more suitable.

With the Threads package the concurrent computations take place under the same kernel session, hence the need for them to not interact with each other (an aspect of the needed thread-safety). Most of the Maple Library's commands are not thread-safe, hence the common occurrence that thread-safe code is mostly numeric or mostly uses kernel builins.

With the Grid package there is greater overhead for launching the concurrent sub-computations, but that is relatively negligible if the sub-computations are more expensive and there are less of them. With this package the sub-computations run in separate kernels, and so are protected from interfering with each other, and the issue of thread-safety is mitigated.

See the Help, or search this site, for examples.

It sounds to me as if the Grid package might be more suitable for your job.

Download loop_print.mw

Here it is with everything but the last plot's output:

triangle_analysis_ac1.mw

Another thing that worked for me was to File->Open the original, and then (even though it appears to have not loaded and sheet appears blank!) use the menubar's Edit->Remove Output->From Worksheet , and then save it to another filename. That produces a version with all output removed.  triangle_analysis_gone.mw

The term G*M/R^2 does not appear alone in your second expression. Before your second attempt, the value of work is actually G*M*m*h/R^2 . Mathematically G*M/R^2 divides that expression, but subs is a syntactic replacement mechanism. This is one of the reasons why the algsubs command exists.

Is this what you wanted to accomplish?

Download Gravity_ac.mw

The following all works ok for me using either Maple 2017.3, or Maple 2017.2, or Maple 2017.0 on 64bit Linux.

It also includes an example in which the color shading goes from green through purple to blue (by surface height), without using the colorscheme option at all.

All the examples which do not use the colorscheme option will work in Maple 17.02 (released 2013), including the one in which the color shading goes from green through purple to blue (by surface height).

Perhaps you could upload a .mw worksheet in which it does not work, so that we could try and diagnose the issue.

Download plot3d_color_20172.mw

You need to use := instead of just = when making an assignment.

The concatenation operator (with evaluation of the suffix) in modern Maple is done using the cat command. (It was dot in the very distant past, but not now. In modern Maple the dot is used for multiplication.)

The name index is protected. Use another name.

Is this what you were trying to do?

Download coeff_max1.mw

It's more effiecient to use an indexed name rather than a concatenated name, but in that case use another name since D is protected and has a particular meaning.

Download coeff_max2.mw

If you have no other reason to retain the coefficients then there's no need to assign them separately to any new names.

Download coeff_max3.mw

I find that manual rotation (or even selection) of an implicitplot3d t makes my Linux machine bog down, especially when the grid or numpoints setting is high.

But, here, the jaggedness of the boundary can be reduced quite a bit with a higher grid setting of an explicit plot3d or contourplot3d result. And manual rotation, etc, seems to behave better.

I include a few small contour values, to illustrate the restricted domain better.

I zip the worksheet because the saved file is large, due to large plot structure which present a problem for inlining here.

3d_cont.zip

restart:
with(plots):
Omega:=5*Pi:
gamma1:=8*Pi:
gamma2:=0.002*Pi:
x1:=100*Pi:
omega2:=200*Pi:
gamma0:=0.2*Pi:
G:=20*Pi:

lambda1:=(1/(2*Pi))^2*(G*Omega*gamma0/(2*(0.25*gamma0^2+Delta^2))):
lambda2:=(1/(2*Pi))^2*(-G*Omega*Delta/((0.25*gamma0^2+Delta^2))):
lambda3:=(1/(2*Pi))^2*gamma1+lambda1:
lambda4:=(1/(2*Pi))^2*(0.2*omega2-G^2*Delta/(0.25*gamma0^2+Delta^2)):
lambda5:=(1/(2*Pi))^2*(2*x1^2*omega2/((omega2^2+gamma2^2))):
f:=epsilon-(lambda1+sqrt(-lambda2^2+Y*(lambda3^2+(lambda4-lambda5*Y)^2)))^2:
contourplot(solve(f,epsilon), Delta =-25*Pi .. 25*Pi, Y=0..1,
            contours=[0.01,0.1,0.5,1,4,8,12,16,20], axes=boxed, color=black,
            tickmarks=[3, 3], linestyle=1, grid=[501,501],
            gridlines=false, view=[-25*Pi .. 25*Pi,0..1]);

plot3d(solve(f,epsilon), Y = 0 .. 1.0, Delta=-25*Pi..25*Pi,
       style=surfacecontour, color=khaki, labels=[Y,Delta,E1],
       tickmarks=[3,3,3], grid=[351,351], view=0..20,
       orientation=[180,0,-180], lightmodel=none);

plots:-contourplot3d(solve(f,epsilon), Y = 0 .. 1.0, Delta=-25*Pi..25*Pi,
                     contours=[0.01,0.1,0.5,1,4,8,12,16,20], color=khaki,
                     labels=[Y,Delta,E1],
                     tickmarks=[3,3,3], grid=[551,551], view=0..20,
                     color=black, thickness=2, orientation=[180,0,-180]);

If you are still using Maple 13 (released in the year 2009) then remove the option size=[...] which I added only to try and make the offset a little better. I figured that you didn't want the text to cross the y-axis.

Download gk_text.mw