@Axel Vogt

doing:

plots:-display( all_plots[2], all_plots[3], all_plots[1] )

will not work. Note that all_plots is not a list of plots... it's a PLOT object created by plots:-display. One has to disassemble it.. reorder, then create a PLOT object after.

If it was just a list, then of course this is a non-issue as you point out.

@Kitonum

thanks for your answer... but the point was that all_plots was "given" - i.e. some function returned it in an exact form i showed in the post.

@dohashi

thanks for the info Darin. I updated my main post with a "fix" that so far seems to work for my particular code - just a one liner that forces the full set of 'user' variables to get copied over to the other processes.

@dohashi 

thanks for your answer.

In the meantime, is there a simple way to collect all the variables that define the current mserver's state? i.e. some simple way to define a list of everything, that I could just pass to Launch. I imagine it would would be fairly straightforward to writa a special-case Map that would work for me, but that is the only thing that is holding me back.

@dohashi 

...so in the spirit of making this thread the longest on mapleprimes (are we getting there?!)....

... do you have an idea of a time frame to get Grid:-Map working with 1) anonymous procedures and 2) for complicated examples with full memory state copy possibly required ?

I think this could be a very useful functionality for many people if things "just worked". As long as the computation of a single iteration takes longer than the time required to copy things over to other processes (which will be fractions of a second on modern computers), one can trivially gain a factor of a "few" speedup - which is great!

thanks

@Mac Dude 

> PS: order and Order are already taken in Maple and protected. RTFM.

ouch!... as i explained above, i RTFM but just couldn't find an operation like that (as in one not necessarily called "order" but one that does what I discussed)... of course I've since learned from this thread that is because it does not exist.

@Alejandro Jakubi

that seems to be the nicest solution, thanks.

@acer

by built-in, i meant a command say "order" written by maplesoft that would do this - thought maybe just couldn't find it in the docs.

@Carl Love

yes, i am aware of that.

but for say a very complicated expression (and for higher cutoff) calling series, will force maple to really compute a series expansion!

That is not needed here..  an optimal way would be for maple look at an expression and simplify disregard terms of some order or higher (and not compute anything!).

no big deal really, but thought this would be a common operation.

@Alejandro Jakubi

..if by any chance you'd be willing to share those text files and how you use them, I'm sure many would find them useufl!

(No big deal if for any reason you'd prefer not to of course)

you probably have some global variables that remember their state from a previous run. you should make sure that all the variables in your code are reset properly at the beginning of a "run".

NOTE: this is just a guess without seeing or knowing anything about your actual code.

@Carl Love

Hi Carl: yes i do have global variables, composing both of other functions/procs as well some parameters. I did a quick refactor of the parameters and put them all in the wrapper function, but that doesn't help.

Maybe at one stage i should put all the function definitions into the wrapper function as well, or use a module as you suggest....  but maybe this will get sorted out by the devs sooner rather than later.

@dohashi 

thanks Darin.

regarding the issue with not all the variables being properly copied over to the new processes, I would propose a (maybe non-default) option for all these wrapper grid commands  that copies over the full memory state of node 0, before the call. 

This could be a serious overhead for say big worksheets, but for many problems one could still see a significent speed up - also if documented, people could structure their calls appropriately. The advantage would be that these calls would 'just work'. 

@Carl Love

thanks Carl.

it seems like for more complicated "named procedures" things are also broken. In my real code, myFun() takes various other paramerters, but either with or without a wrapper function (to make things look as similar to the example above as possible), i can't get any parallel execution with Grid:-Map.

@dohashi

Hi Darin:

I think I understand what is happening - just not sure why.

This is (effectively) what I was doing:

restart:
myFun:=proc(some_val, max_n:=10000)
    local i, result:=0:
    print(cat("myFun: node=", Grid:-MyNode(), " some_val is ", some_val));
    for i from 1 to max_n do
        result:=result+1;
    end;
    result:
end:

data_list:=[seq(i, i=0..10, 1 )]:

result_data:=Grid:-Map(item->myFun(item, 100000), data_list):
result_data; #here we're printing... but I would "use" the data in my code


From the MyNode() call it seems like all execution is on node 0.
But by changing the last two lines to this (semicolon in first line, second line commented out):

result_data:=Grid:-Map(item->myFun(item, 100000), data_list);
#result_data; #here we're printing... but I would "use" the data in my code

it's clear that the map call is not really evaluated. The evaluation only happens if now one calls (say)
result_data;

... and NOT in parallel!

However, getting rid of the lambda function-like syntax, and using this

result_data:=Grid:-Map(myFun, data_list);

seems to work, and the map command is executed righ away on all four nodes.

So it would seem like using the -> operator causes Grid:-Map not to execute the code right away on multple nodes.

Is this a bug, or am I missing something?

thanks

*EDIT*

i should note that the code you posted above breaks when one changes the Grid:-Map line to:

Grid:-Map(x->f(x), L );