This is an Answer to your deleted Question.

Here is your worksheet, as you posted it, which contains your Question: doubt_2.mw

Your line

TP12(alpha):= TP__1

needs to be changed to

TP12:= unapply(TP__1, alpha)

The reason is that "TP__1" doesn't explicitly contain the parameter alpha. The parameters of a function must explicitly appear in the function definition or they won't be treated as parameters; alpha just continues to be a symbolic global variable.

Here's a crude way. Let e be the equation the you entered:

e:= W__1 + W__2 = -sin(-beta + alpha)*((H^2 - h^2)*gamma + h^2*psi)/(2*sin(beta)*sin(alpha));

Then,

subsop(2= H^2*subs(H= 1, h= h/H, rhs(e)), e);

Here's an easier way:

SLA:= Student:-LinearAlgebra:  # I use this instead of with(...).
A:= <3/4, 3, 2;  3/4, 0, 0;  0, 1/3, 0>; #easiest way to type in a matrix
SLA:-Eigenvectors(A);

In the output, the entries of the vector on the left are the eigenvalues, which you'll see are the same 3 eigenvalues that you got. The columns of the matrix on the right are corresponding eigenvectors. The middle column is an eigenvector corresponding to -1/4. It is a scalar multiple of the eigenvector that you got. (Any nonzero scalar multiple of an eigenvector is also an eigenvector corresponding to the same eigenvalue.)
 

Here's a procedure for it:

SeqSDP:= proc(N::posint, p1::prime:= 2)
local S:= Array([p1], datatype= integer), Used:= table([p1= ()]), s, k, p:= p1, j;
    for k from 2 to N do
        s:= `+`(convert(p, base, 10)[]);
        p:= s;
        for j by 2 do
            if p::prime and Used[p]<>() then break fi;
            p:= Scale10(s, length(j)) + j
        od;
        S(k):= p; Used[p]:= ()
    od;
    [seq(S)]
end proc
:
CodeTools:-Usage(SeqSDP(199));
memory used=3.81MiB, alloc change=0 bytes, cpu time=31.00ms, 
real time=31.00ms, gc time=0ns

[2, 23, 5, 53, 83, 11, 29, 113, 59, 149, 1423, 101, 211, 41, 521, 
  89, 17, 811, 103, 43, 7, 71, 821, 1117, 107, 823, 13, 47, 1123, 
  73, 109, 1013, 523, 1019, 1129, 131, 541, 1021, 419, 1427, 
  1429, 163, 1031, 547, 167, 1433, 1151, 827, 173, 1153, 1033, 
  79, 1613, 1163, 1171, 1039, 137, 1181, 1187, 179, 1721, 1193, 
  1439, 1723, 139, 1319, 1447, 1619, 1733, 1451, 11113, 719, 
  1741, 1321, 727, 1621, 1049, 1453, 1327, 1361, 11117, 11119, 
  1367, 1747, 19, 1051, 733, 1373, 1459, 191, 11131, 739, 193, 
  1381, 1399, 223, 743, 1471, 13103, 829, 197, 1753, 1627, 1637, 
  1759, 227, 11149, 1657, 199, 1913, 1481, 1483, 1663, 1667, 
  2011, 421, 751, 13109, 1487, 2017, 1061, 839, 2027, 11159, 
  1777, 229, 13121, 853, 1669, 2213, 857, 2029, 13127, 1489, 
  2221, 757, 1931, 1493, 1783, 1933, 1693, 1949, 233, 859, 2237, 
  1499, 239, 14107, 13147, 1697, 2311, 761, 14143, 13151, 11161, 
  1063, 1069, 1699, 251, 863, 1787, 2333, 11171, 11173, 13159, 
  1951, 16103, 11177, 1789, 257, 14149, 1973, 2039, 14153, 14159, 
  2053, 1087, 16111, 1091, 11197, 1979, 263, 11213, 877, 2239, 
  16127, 17107, 16139, 2063, 11239, 16141, 13163, 14173, 16183, 
  1987, 2521, 1093, 13171, 13177]

CodeTools:-Usage(SeqSDP(199, 3));
memory used=3.78MiB, alloc change=0 bytes, cpu time=47.00ms,
real time=37.00ms, gc time=0ns

[3, 31, 41, 5, 53, 83, 11, 2, 23, 59, 149, 1423, 101, 29, 113, 
  521, 89, 17, 811, 103, 43, 7, 71, 821, 1117, 107, 823, 13, 47, 
  1123, 73, 109, 1013, 523, 1019, 1129, 131, 541, 1021, 419, 
  1427, 1429, 163, 1031, 547, 167, 1433, 1151, 827, 173, 1153, 
  1033, 79, 1613, 1163, 1171, 1039, 137, 1181, 1187, 179, 1721, 
  1193, 1439, 1723, 139, 1319, 1447, 1619, 1733, 1451, 11113, 
  719, 1741, 1321, 727, 1621, 1049, 1453, 1327, 1361, 11117, 
  11119, 1367, 1747, 19, 1051, 733, 1373, 1459, 191, 11131, 739, 
  193, 1381, 1399, 223, 743, 1471, 13103, 829, 197, 1753, 1627, 
  1637, 1759, 227, 11149, 1657, 199, 1913, 1481, 1483, 1663, 
  1667, 2011, 421, 751, 13109, 1487, 2017, 1061, 839, 2027, 
  11159, 1777, 229, 13121, 853, 1669, 2213, 857, 2029, 13127, 
  1489, 2221, 757, 1931, 1493, 1783, 1933, 1693, 1949, 233, 859, 
  2237, 1499, 239, 14107, 13147, 1697, 2311, 761, 14143, 13151, 
  11161, 1063, 1069, 1699, 251, 863, 1787, 2333, 11171, 11173, 
  13159, 1951, 16103, 11177, 1789, 257, 14149, 1973, 2039, 14153, 
  14159, 2053, 1087, 16111, 1091, 11197, 1979, 263, 11213, 877, 
  2239, 16127, 17107, 16139, 2063, 11239, 16141, 13163, 14173, 
  16183, 1987, 2521, 1093, 13171]

@Joe Riel The key for sort doesn't need to be numeric or string: It can be a list of numerics and strings/names. Thus the sort that Scot requested can be done with the one line:

F3[sort(RowLabels(F3), 'key'= (i-> [F3[i,"BType"], F3[i,"Minutes"]])), ..];

where F3 is the largest of the DataFrames of flashlights that exists after executing Christopher's worksheet.

This works even if the RowLabels aren't integers.

Change indexed to algebraic​​​​​. 

Read the entirety of these instructions carefully before proceeding with any of them.

This idea will definitely work with worksheets. I'm not sure how well it'll work with workbooks, but it's worth a try. Since this is experimental, make copies of any useful workbooks that you're going to open before trying this.

Start a fresh Maple session (because you definitely don't want this weird setting to apply in general). Before opening any workbooks, go to menu Tools => Options => General. The first question is "How should Maple handle the creation of new Math Engines?" Select first the answer, "Share one engine among all documents." Click Apply to session, which'll dismiss the dialog. (Don't click Apply globally!) Now open your workbooks, and first execute the worksheets that should "dominate" (determine the desired values of variables). Then execute the others. Because of the shared kernel, a given variable name's value should be the same across all worksheets. When you're done, exit that Maple session so that the "math engines" setting will go back to its normal value.

Note that "kernel" and "math engine" mean exactly the same thing in this context. The more common term is "kernel".

OrProp is a procedure. At the time of the error, that procedure has a very large remember table. (I can't tell yet whether it's large due to having a large number of entries or the entries being large, but I suspect the latter.) When you use print with a procedure name, it expands the procedure, including the table. (Whether the table is actually shown on screen depends on your setting of interface(verboseproc).) But if you just issue lastexception as a command, then the procedure is shown simply as its name, OrProp, due to the "last-name-evaluation" rule that applies to the names of procedures, modules, and tables.

I recommend that you use lprint instead of print, because lprint won't expand the procedure.

Other tips:

1. Assumptions don't usually work with solve, and an assumption of real definitely doesn't work.
2. Your equation can be solved in under 20 seconds by
   sol:= timelimit(20, solve(evala(Norm((lhs-rhs)(eq))), y, parametric, real))
   The evala(Norm((lhs-rhs)(...))) is needed to convert eq to a polynomial form so that it's accepted by the parametric option.

You asked:

• 1. What is the difference between the “process” and “task” conception and meaning in Threads and Grid packages?

A process is an independently running instance of a program. In this case, that program is the Maple "kernel". If you were to open two or more Maple worksheets in the same session, each would have its own kernel process (unless you changed your configuration from the Tools => Options menu so that the same kernel is re-used). Setting a variable's value in one worksheet wouldn't change its value in any of the others. That's what I mean by "independently running". Likewise, each node used by Grid is an independent kernel process. They don't share any memory unless you explicitly tell them to share specific pieces of it (through commands such as Set and Send). That last sentence is really the only thing that you need to know about processes in order to use the Grid package.

The meaning of "task" is more vague and more general. It would be a mistake to think that tasks are what Threads uses instead of processes. Perhaps we could say that a task is the smallest unit into which the work is divided in either package, but understanding the definition is not that important. What you need to know is that all of the simultaneously running code in a Threads application is running as part of a single process, a single kernel; they share all memory that is global or up-level to themselves unless you explicitly tell them to not share specific pieces of it or to share it in a controlled way. So, you see that Grid and Threads treat memory in exactly opposite ways. It is the uncontrolled sharing of write access to global or up-level memory that makes code not threadsafe.

• 2. What is the discrepancy between Grid:-Map and Threads:-Map commands in the practice and execution?

Both are parallelized versions of the regular map command. The only practical differences are as I described in the answer to #1 and that Grid naturally uses far more memory.

• 3. Between the “process” and “task”, which one of them does have the smaller run-time?

The question is irrelevant if asked exactly like that, because "processes" and "tasks" are not necessarily distinct entities. But if you change it to "Between Grid:-Map (or Seq) and Threads:-Map (or Seq), which has the smaller run-time?" then the answer is easy: If the code is threadsafe, then you should definitely use Threads; it is faster and uses less memory. (The vast majority of high-level Maple commands are not threadsafe.)

• 4. What is the default value of “tasksize” option in Grid:-Map and Threads:-Map commands?

For Grid:-Map and Grid:-Seq, the default tasksize is

`if`(n < 1000, max(1, floor(n/NN)), ceil(n/(20*NN)))

where n is the total number of items being mapped over and NN is the number of nodes (usually the same as kernelopts(numcpus)). So, the default for n > 1000 is such that there are 20 tasks per processor. The code for Threads is compiled and built-in, and thus I can't read it.

• 5. Does or the larger value of the “tasksize” option results in smaller run-time either the smaller value of that?

If there were an easy answer to that question, then there'd be no need for a tasksize option. Using too large a tasksize risks that some processors will finish long before the others and remain idle. Using too small a tasksize means that there'll be more overhead for the task initializations.

See this paragraph at ?has:

• If the item that you want has to search for is itself a list or set, you must enclose it in a list or set. Otherwise, has will search for items in the list or set as described above.

Thus, the answer is has(x, {{}}).

The green output is due to some kind of tracing or debugging being turned on. If you didn't turn it on, then it's unusual, but it's certainly possible. I suspect that some code author at Maplesoft accidentally left some debugging code in.

The green output is supplementary. It is not part of the return value of your command, which is the blue part. Nothing bad would happen if you simply ignored the green output.

For some strange reason, GetProperty returns the string "true" rather than the constant true. 

Although this code is ugly to me, you can workaround by 

if GetProperty(...) = "true" then ...

You can intersperse plots and text by putting it all in a column vector. This avoids the need to rely on side effects produced by print:

right:= ()-> <plot(x, x= -1..1), `This is a line of text.`, plot(x^2, x= -1..1)>:
right();

If you prefer normal-sized display, use

print~(right()):

Note that that last command ends with a colon.

My advice is to just use a Matrix from the start, and forget about the Vector of lists. The Matrix can be created in a single line by any of the following four commands (and there are several other variations possible):

restart:
vars:= 4:  n:= 1..2^vars:
sgn:= 2*<seq(<Bits:-Split(i-1, bits= vars)>^+, i= n)> -~ 1;
sgn:= Matrix([seq]([seq]([-1$2^j, 1$2^j][], i= 1..2^(vars-j-1)), j= 0..vars-1))^+;
sgn:= Matrix(combinat:-permute([-1$vars, 1$vars], vars))[.., [seq](vars..1, -1)];
sgn:= Matrix((2^vars, vars), (i,j)-> 2*irem(iquo(i-1, 2^(j-1)), 2)-1);

The commands vector, matrix, and evalm (all lowercase) should never be used. Replacements are Vector, Matrix, and the angle bracket constructors shown in the first construction above.

A Maple session runs as two or more separate processes (independently running programs): one user interface (either plaintext as you show above or GUI) and one or more "kernels" or "mathematical engines". The message "lost connection to kernel" almost always means that there was an untrapped error due to a bug in the kernel, and the process has died. (Occasionally, it does mean a severance of the connection between the kernel and the user interface. That seems extremely unlikely in this case.)

Yes, running out of memory can precipitate this error. The messages that you show indicate that this Maple kernel (alone) was using about 32 Gigabytes of memory at the time of the crash and that that amount was rapidly increasing. (Look at the "alloc"; ignore the "memory used".) How much memory does your machine have?

The fact that you got this message says nothing whatsoever about the mathematical solvability of your system or whether you've input it correctly. Groebner calculations often take an extreme amount of memory and time.

It may be possible to achieve better results by changing the order of the variables in plex. However, I have no advice on how to select one of the 13! possible orders. A Groebner expert may be able to advise on this.