@Carl Love Many thanks again.  I will test it over the weekend and let you know. Could you explain what rcurry does and why it is faster?

@Carl Love Many thanks.  I will use the wrapper from now on.   

@Carl Love Many thanks. I don't know how I could miss making M local (Sorry for wasting your time).   Once M was made local, Threads:-Map returned the same number of elements.  Some more tests are needed though.   

Normally order is important for me but not in this case. I guess I am used to putting the monomials in lists and don't think much about it.  

@Carl Love, First of all, thank you for the comment. I came across an example that seems to show what you mentioned in your comment.   If I use Grid-Seq instead, Maple returns the same result as in map. But when I try to use it with a much larger input (list or set),  the calculations with the nodes went rather okay (2 hours), but when collating the results the memory jumped from 50Gb to 200 GB, and it is still running (more than 12 hours).   

@ecterrab Many thanks.   I wasn't aware of hastype.  I should have checked "See also".  Sorry for wasting your time.   

@acer Many thanks.   I could not find the slider in the first option.  I can see the controls but not the slider. 

The second option, there is no slider (as you said).  

The third option has everything I need.  Many thanks.  

@acer Many thanks. Great alternatives that I can easliy follow. 

 As I said that was the first time I tried to use plots in Maple.   Although, after the alternatives, a plot is created I could not see a slider (or something like that) that I can use to change the values of a.  Am I missing something here?   

@Carl Love Many thanks. 

@Carl Love Many thanks.    

• The way to delay the evaluation is to use single quotes, right?
• I agree, it is definitely awkward.  The use of a function is way more elegant.
• I could not figure out how to change a (that is, there is no animation).

My wish has to do with Grid and Threads packages:

1) Efficient usage of memory -   Once a grid command finishes the memory allocated should return to Maple (I am not sure whether this is possible or not). There is a post in the list showing that, in some calculations using Grid, Maple hangs for no apparent reason.

2) A clear explanation in the help files (examples) on which variables should be Grid:-Set and which don't.  (Although I have received help from tops users on the list and from maple support, the answers are not the same in some cases).

3) CodeTools:-ThreadSafetyCheck - Some of the functions that are threadsafe checked by this command causes Maple to hang.  Is the list of threadsafe functions updated?  

@Kitonum Many thanks.   I can't believe I have missed allsolutions.   

@nm Many thanks.   The problem I am experiencing is definitely very similar to what you have described but there is a twist.  In my case, even though I left the job running overnight, maple did not move to the next iteration.  Perhaps I will have to wait longer to see if Maple goes to the next iteration, but I don't have the patience.  I wrote the code having in mind this issue, so it is very easy for me to kill the job and restart it from where it stopped.    

Another issue that bothers me is Grid memory demand.  From one iteration to the next, Grid does not seem to release the memory used in the previous iteration and demands probably the same amount of memory on top of the used one. That forces me to again kill the job and restart it from where it stopped. 

@nm and @Carl Love I have a similar problem when I use Grid with timelimit to be sure that Maple won't get stuck in any of the calculations.   Somehow Maple hangs in one of the loop iterations without any warning (all 36 cpus go from 100% to 0% and the allocated memory sits there until I kill the job - I am using the command line instead of the usual interface).   If the job starts from scratch there is a good chance that Maple will hang at the same point (the job takes two or three days to finish so I cannot be 100% sure).  Fortunately, the job can be started from the previous iteration and, when it does  Maple won't hang at the same point. 

Maple 2020.1 on Linux (with plenty of memory left).   

@Carl Love Many many thanks.  Thanks to you and @acer the part of try-catch in my code is working as intended (and much faster).   However, I am still struggling with Grid demands for memory.  

@acer Many thanks.  I think I have now a better understanding of how to use try-catch