@Carl Love 

OK. So the issue is making further experiments along the line of the last example at ?Grid,Map. As Darin has said earlier:

However when programming for the distributed Grid, functions like Launch, Send and Receive become much more important.

I am currently short of time for that, but if you ever look at this issue, please report what you see if you can.

@Carl Love 

To confirm it, what you have done is (described earlier by Darin as the second case) with the calling kernel as a part of the grid?

No, the routine that you describe: educational institutions adopting multiple choice questions as a permanent tool for assessments, and moreover using scaning machines for that, may be particular of your country, but I have not seen it here or elsewhere. Only in one term I have made the experiment of using multiple choice questions for the exams (certainly no machines for that!). But it caused too much more trouble with the students than the traditional assesment method, so that I have never repeated the experience.

@dohashi 

I find that you are not addressing this question. Once again: can distributed grid mode computations be done within a single machine by means of the Grid package alone, without the Grid Computing Toolbox?

Documenting unsupported features looks as marketing. And mixing documentation with marketing seems a wrong approach in my opinion. As a user, I have to sieve out the pieces of information that are relevant from those that are not, in addition to the fact that they are written in a rather cryptic style. This whole situation do generate confusion, the same as the current discussion shows.

@dohashi 

No, the point is whether these distributed grid mode computations can be done within a single machine by means of the Grid package alone, without the Grid Computing Toolbox.

Nevetheless, your comment brings focus to one of the problems of the documentation of the Grid Package in "standard" Maple, namely making references to features of the non-included Grid Computing Toolbox. Documentation of an application like Maple should describe the features of this application, while additional or different features available only in addons should be the exclusive subject of their specific documentation. Mixing documentation of available features with non-available features is a source of confusion. Moreover as the Grid Computing Toolbox is not a subject for the large majority of users, like me. How many threads on this site have you seen dealing with this toolbox?

@dohashi 

So, in local mode there is a cpu running two kernels, a controler one outside the grid and a grid one, while the rest of the cpus run a single grid kernel, isn't it?  Well, I have been reading the documentation for the Grid package since its launch in Maple 15 and, even for such an elementary issue, I have never seen any description like that. Imagine the situation for non so elementary issues... May be that the tiny minority of those "sophisticated users" do not need much detail, and I feel that the current documentation is addressed to them. But I bet that the vast majority of the users like me is largely unfamiliar with grid computation details. So, yes, the documentation of the Grid package needs a significant improvement if you want it to be relevant for the user community in large some day.

You have said earlier: "The second case is intended to be used with the Grid Toolbox (although it does work without it)", and then "The Grid package is the api for both local and distributed Grid", meaning that the distributed Grid mode may be used without the Grid Toolbox. But now you say : "The distributed grid is only available with the Grid Computing Toolbox." For me this is a contradiction.

@dohashi 

If I follow you correctly, there is also a Distributed Grid mode, which can be used on a single machine by using the Grid package or on a network of machines by means of the Grid Computing Toolbox. Now, ?Grid,Setup describes three available modes: "local", "hpc" and "mpi", but not "Distributed Grid". Which is the relation, if any?

Really, the issue that the complete state is not copied by default to the nodes of the grid when executing "ordinary" commands like Map is, for me, a revelation from this thread. It is a key issue which is very obscure in the current documentation but deserves a full explanation and several detailed examples. In particular, how to copy the complete state and when it may make sense.

Overall, this thread confirms my opinion that grid paralelism is a rather niche facility, useful only under special circumstances, or for "sophisticated users".

@dohashi 

So you say that in Local Grid mode there is a controler kernel and a grid. The controler kernel is outside the grid and can create the grid by launching kernels in the local machine. So, if the machine has N kernels, the grid created by the controler kernel can have at most N-1 kernels, after your definition. Let us take now a concrete example. This is a Core i7-3820 CPU with 4 cores and 8 threads. Maple 18 reports:

> kernelopts(cputype);
                                     "i386"
> kernelopts(numcpus);
                                       8
> kernelopts(multithreaded);
                                      true

Assuming that N=8, that is that each of the threads count as a kernel for the grid, then the grid here can have at most 7 kernels. Now, ?Grid:-Status states:

The Status command queries the grid status and returns the total number of nodes in the grid as well as the number of nodes available for a computation. The return value is a sequence of these two integers.

Presumably, what is called "node" here, is what you call "kernel". However Grid:-Status reports 8 as total number of nodes in the grid :

> Grid:-Status();
                                      8, 8

There is here something that does not fit for me. 

By the way, I wonder whether this command does create a grid for the sole purpose of quering its status. Or it reports about something else, a potential grid say. Certainly, at the moment of executing this command, no grid had been launched.

I note also that the single example in this page does not show any output. Less it explains or discusses such result.

@dohashi 

Where is documented this "full Grid api"? A help search for "api" or "grid api" does not produce any result, except for a feature comment in ?about,GridComputingToolbox .

@dohashi 

This first case that you present: "one where the kernel calling Map is outside of the Grid", is still confusing for me. You say: "This is also the case shown in the first few examples". Let us take the first example:

Grid:-Map(x->x^2,[1,2,3]);
                           [1, 4, 9]

If the kernel is outside of the grid, it means that the grid exists independently and before executing the above statement. How could it be if I execute this statement in a fresh session? Or, what do you mean by "grid" in this context?

@Carl Love 

In this simplified example there is a problem with the discontinuity detection stage, actually with discont:

> discont(GAMMA(2/5,-t^(5/2)),t);
Error, (in discont) cannot determine discontinuities

> trace(discont):
> int(t^(5/2)*exp(t^(5/2)), t= 0..1);
{--> enter discont, args = t^(5/2)*exp(t^(5/2)), t
                            _EnvAllSolutions := true
                                  disr := {0}
                                   disc := {}
                                  disc := {0}
                                      {0}
<-- exit discont (now in GetPoles) = {0}}
{--> enter discont, args = 2/5*(-1)^(3/5)*(2/5*t*(-1)^(2/5)*Pi*csc(2/5*Pi)/
GAMMA(3/5)/(-t^(5/2))^(2/5)-t*(-1)^(2/5)*exp(t^(5/2))-2/5*t*(-1)^(2/5)/(-t^(5/2
))^(2/5)*GAMMA(2/5,-t^(5/2))), t
                            _EnvAllSolutions := true
                disr := "does not know about function %1", GAMMA
<-- ERROR in discont (now in FindDisconts) = "cannot determine discontinuities"
}
{--> enter discont, args = 2/5*(-1)^(3/5)*(2/5*t*(-1)^(2/5)*Pi*csc(2/5*Pi)/
GAMMA(3/5)/(-t^(5/2))^(2/5)-t*(-1)^(2/5)*exp(t^(5/2))-2/5*t*(-1)^(2/5)/(-t^(5/2
))^(2/5)*GAMMA(2/5,-t^(5/2))), t
                            _EnvAllSolutions := true
                disr := "does not know about function %1", GAMMA
<-- ERROR in discont (now in FindDisconts) = "cannot determine discontinuities"
}
                              1
                             /
                            |    (5/2)      (5/2)
                            |   t      exp(t     ) dt
                            |
                           /
                             0

So, the workaround is bypassing discontinuity checking:

> int(t^(5/2)*exp(t^(5/2)), t= 0..1,continuous=true);evalf(%);
          3/5 /          2 Pi      2 Pi
-2/25 (-1)    |-4 Pi csc(----) sin(----)
              \           5         5
                        2 Pi
     + 5 GAMMA(3/5) sin(----) exp(1 + 2/5 I Pi)
                         5
                                       2 Pi        \   / /               2 Pi \
     + 2 GAMMA(2/5, -1) GAMMA(3/5) sin(----) + 2 Pi|  /  |GAMMA(3/5) sin(----)|
                                        5          / /   \                5   /
                                                     -9
                       0.5300489452 + 0.5888958796 10   I
> evalf(Int(t^(5/2)*exp(t^(5/2)), t= 0..1));
                                  0.5300489453

@Axel Vogt 

By the way, we still will have to go down by hand to find it, as the broken comment link bug introduced with the changes of October 2013 has not been fixed yet...

I am browsing the threads of the day, and I see that the attach file bug persists, e.g. here:

http://www.mapleprimes.com/questions/201394-Setup-Of-General-Metric-With-Null-Vector

I mean the "attachements" made 12h ago ("Second Try"), after your announcement made 13h ago.

I observe also in this thread an example of the formating problem with some inserted worksheets. It is unclear to me whether such problem was covered by this update.

@ecterrab 

I do not see the example in your answer above (after "for example"). Independently of what the main issue is, a "general command for changing variables in Maple, in everything" seems, nowadays, out of place, and not so obvious to find, under PDEtools, and having a name begining with "d" (even taking into account the history, which I know rather well). Meaning that a reorganization of procedures/packages is needed, in my opinion.

@Carl Love 

These expressions f(a,b) are linear in the x[i] and y[j], with unit coefficients:

> expand(f(2,2));
                 x[1] y[1] + x[1] y[2] + x[2] y[1] + x[2] y[2]

So if the expanded expression is a homogenous polynomial with total degree 4:

> degree(myterm);
                                       4

And degree 2 in the x[i] and y[j], it has to be a homogeneous polynomial of degree 2 in the f's. That is, terms like f(a,b)*f(c,d), where the maximum of these arguments arises from the maximum of the indices. Further, requesting such a factorization with unit coefficients may set up enough constraints to recover the desired expression.