After the solve command, do

assign(%);

O(...) is special when it occurs as part of a series structure (which includes any output from taylor), which I think is the case here. If you just want to get rid of O(...) and expand, try

expand(convert(Q(h), polynom));

The oddly named command convert(..., polynom) is for converting series structures to ordinary algebraic structures, regardless of whether they're polynomial.

Like this:

`Δx`

Like this:

expr:= expand(alpha[-2]*(f(x) - 2*D(f)(x)*h + 2*(D@@2)(f)(x)*h^2 + O(h^3))/h + alpha[0]*f(x)/h + alpha[3]*(f(x) + 3*D(f)(x)*h + 9/2*(D@@2)(f)(x)*h^2 + O(h^3))/h):

InertForm:-MakeInert(expr);

This will work even if expr is entered in 2D Input using implied multiplication.

To use assuming in list form, do

`assuming`([odetest(sol,ode)], [x::real, x>0]);

I can't find any documentation on an assume option to odetest. Where did you see it? I guess that it's just being totally ignored, which is the default behavior for extra arguments that match no declared parameter.

I find this confusing also. Put your cursor on the "Section 1" header and press Ctrl-Period (or menu Insert => Section). Then a new section will open under Section 1 with the same level of indentation as Section 1.

Here are procedures for both of your sequences:

Seq1:= proc(N::posint) #N = number of terms
local 
    S:= Array(1..1, [1]), #the sequence
    SD:= 1, #its digit sum
    C:= 1, #its concatenation
    Used:= table([1= ()]), #terms used
    k, j, C1, SD1
;
    for k from 2 to N do
        for j from 2 do
            if not assigned(Used[j]) then
                C1:= Scale10(C, length(j)) + j;
                SD1:= SD + `+`(convert(j, base, 10)[]);
                if igcd(C1, SD1) = 1 then
                    C:= C1; SD:= SD1; Used[j]:= (); S(k):= j;
                    break
                fi
            fi
        od
    od;
    seq(S)
end proc
:   
CodeTools:-Usage(Seq1(99));
memory used=3.60MiB, alloc change=0 bytes, cpu time=31.00ms, real time=30.00ms, gc time=0ns

1, 3, 7, 2, 4, 5, 9, 6, 13, 8, 19, 11, 15, 21, 10, 17, 22, 23, 
  12, 24, 25, 14, 27, 16, 20, 28, 26, 31, 29, 18, 33, 37, 35, 39, 
  40, 41, 34, 42, 44, 43, 32, 45, 30, 46, 47, 36, 49, 38, 48, 51, 
  55, 53, 61, 50, 57, 60, 63, 52, 59, 64, 62, 66, 67, 54, 65, 58, 
  68, 69, 70, 71, 73, 75, 77, 79, 80, 81, 72, 82, 83, 76, 84, 86, 
  87, 78, 88, 89, 85, 93, 95, 91, 99, 101, 97, 105, 107, 103, 
  111, 56, 109

Seq2:= proc(N::posint)
local S:= Array(1..1, [1]), C:= 1, Used:= table([1= ()]), k, j, C1;
    for k from 2 to N do
        for j from 2 do
            if not assigned(Used[j]) then
                C1:= Scale10(C, length(j)) + j;
                if irem(C1, j) = 0 then
                    C:= C1; Used[j]:= (); S(k):= j;
                    break
                fi
            fi
        od
    od;
    seq(S)
end proc
:
CodeTools:-Usage(Seq2(99));
memory used=1.07MiB, alloc change=0 bytes, cpu time=16.00ms, real time=8.00ms, gc time=0ns

1, 2, 3, 5, 10, 4, 8, 6, 11, 20, 13, 7, 9, 12, 15, 18, 14, 25, 
  30, 24, 16, 32, 40, 29, 50, 100, 26, 52, 39, 21, 28, 35, 42, 
  17, 34, 51, 23, 46, 27, 36, 45, 43, 19, 38, 68, 48, 60, 75, 90, 
  54, 56, 58, 22, 44, 33, 55, 97, 125, 200, 64, 80, 69, 66, 88, 
  70, 41, 82, 37, 74, 79, 63, 84, 96, 72, 85, 136, 128, 92, 105, 
  31, 62, 93, 120, 150, 71, 142, 108, 124, 155, 179, 113, 164, 
  123, 205, 223, 140, 65, 78, 104

Regarding your first question with Grid:-Run and Grid:-GetLastResult: There seems to be a minor bug regarding "raw-form" assignment statements passed as strings to Grid:-Run: The assigned value is not considered to be a "result" or "return value". In this way, they act more like the assign command than the := operator. Here are 3 workarounds:

Grid:-Run(0, "a:= 2; a;");
#or # Grid:-Run(0, "(()-> (:-a:= 2))();");
#or # Grid:-Run(0, x-> (:-a:= x), [2]);
Grid:-Wait(0);
Grid:-GetLastResult(0); 
            2

Note the Grid:-Wait: Since the computation on node 0 is running at the same time as your next computation is processed in the "master" node (the one that you're typing in), you need to make sure that that computation on node 0 is finished before you can ask for its result. Hence, Grid:-Wait(0).

Regarding your second question: a has been set to 2 on node 0 only. The a in the master node has no value. Your Grid:-Send(1,a) is sending that a (with no value) to node 1.

1. Regarding the question implied by the error message shown in your attached file: An equation that specifies the value of a parameter (in your case, l= 1) is not an "initial condition", and thus it's not something that should be passed directly to dsolve. It shouldn't be put in the sequence ics.

2. Regarding the message "Global variables are deprecated": It occurs when you're trying to dsolve an initial-value problem (IVP) numerically and the problem has parameters that have neither been assigned numeric values nor declared in a parameters option.

Example, incorrect:

Sol:= dsolve({diff(y(x),x) = y(x), y(0)=A}, numeric):
Warning, The use of global variables in numerical ODE problems is deprecated, and will be removed in a future release. Use the 'parameters' argument instead (see ?dsolve,numeric,parameters)

Example, corrected:

Sol:= dsolve({diff(y(x),x) = y(x), y(0)=A}, numeric, parameters= [A]):
Sol(parameters= [A=1]):
plots:-odeplot(Sol, [x,y(x)], x= 0..2);
 

We do your new 5th order BVP by setting 3 parametric initial conditions at -1 and "shooting for" the desired values of (D@@2)(F)(0), F(1), and D(F)(1).

restart;
Digits:= 5:
(t, S, R):= (-1, 1, 9):

EQ:= diff(F(x),x$4) + R*(diff(F(x),x)*diff(F(x),x$2) - F(x)*diff(F(x),x$3)) + 
    R*t*(F(x)*diff(F(x),x$5) - diff(F(x),x)*diff(F(x),x$4)) - 
    R*S^2*diff(F(x),x$2) = 0:

IC:= D(F)(-1)=0, F(-1)=-1, (D@@2)(F)(-1)=d2, (D@@3)(F)(-1)=d3, (D@@4)(F)(-1)=d4:

dsol:= dsolve({EQ,IC}, numeric, parameters= [d2, d3, d4], relerr= 1e-7):

Fsol:= proc(d2, d3, d4)
option remember;
    dsol(parameters= [d2, d3, d4]);
    [eval(diff(F(x), x$2), dsol(0)) - 0,
    (eval([F(x), diff(F(x), x)], dsol(1)) -~ [1, 0])[]
    ]
end proc:

for k to 3 do Fsol||k:= subs(_k= k, (d2,d3,d4)-> Fsol(args)[_k]) od:
fsolve([Fsol||(1..3)]);
         [3.44668196807, -5.31525372043, 3.16576851540]

dsol(parameters= %):
plots:-odeplot(
   dsol, [[x,F(x)],[x,diff(F(x),x)],[x,diff(F(x),x$2)]], 
   x= -1..1, legend= [F, `F '`, `F ''`]
);

Achieving more digits of accuracy may require more subtlety.

You are mistaken about two things: NULL is an "actual" value, and it can be (and very often is) the return value of a procedure. However, it can't (in its "naked" form) be a member of a sequence, in particular a sequence of return values for a multiple assignment statement. But, it can be done with unevaluation quotes, like this:

P:= proc()
local a:= 1, b:= NULL, c:= 3;
    `if`(a=NULL, 'NULL', a), `if`(b=NULL, 'NULL', b), `if`(c=NULL, 'NULL', c)
end proc
:
(a, b, c):= P();
                     a, b, c := 1, NULL, 3

evalb(b=NULL);
                              true

My personal coding preference is to replace NULL (which is a named constant, and thus requires evaluation) with its evaluated form, (). This avoids a few unneeded evaluations. The code above becomes: 

P:= proc()
local a:= 1, b:= (), c:= 3;
    `if`(a=(), ''()'', a), `if`(b=(), ''()'', b), `if`(c=(), ''()'', c)
end proc
:
(a, b, c):= P();
                      a, b, c := 1, '()', 3

evalb(b=NULL);
                              true

evalb(b=());
                              true

The answer to your first question is yes.

The answer to your second question is yes, even though this interupts the usual flow control implied by the return in the catch clause.

So, what are you trying to accomplish in the finally clause? They are rarely used.

Acer's statement beginning "One point..." needs to be amended: The finally clause is executed if any of these occur (Acer left off #3):

1. There is no error.
2. An error is caught.
3. An error occurs that would've been caught had there been a catch clause for it.

So, the finally clause is a weird and powerful thing that should probably be reserved for things like closing files.

In light of point #3 above, you could do this instead:

try
   ...
catch "time expired":
   return ...
catch: #any other error
   #what used to be in your finally clause
end try;

This isn't the same as your original because of point #1, but it may be what you actually want.

Both the R and Maple histograms are wrong, and for the same reason: You have only 16 bins, but 17 discrete values (0 - 16), so one of the bins must be used to count 2 of the values. R happens to lump 0 and 1 together in the first bin, while Maple lumps 15 and 16 together in the 16th bin. To get a correct histogram for a discrete data set:

Statistics:-Histogram(
    subscribers, discrete, bincount= 17,
    frequencyscale= absolute, 
    labels= ["subscribers", "frequency"], labeldirections= ["horizontal", "vertical"], 
    thickness= 20, view= [-1..17, default]
);

The code of a module's "body" (those things that are neither locals nor exports of the module) is not stored in the .mla (nor is it stored anywhere else). So your code that reset currentdir and :-libname was not stored. If there is certain code that you want executed whenever the module is retrieved from the .mla, put that code in a procedure named ModuleLoad, which can be a local or export of the module. Usually, this should be done with any code that changes global variables. Calls to TypeTools:-AddType should also be put there. 

Often, when you're done with the module, it's a good idea to restore the global state to what it was before the module was retrieved from the .mla. The code to do that should be put in a procedure named ModuleUnload.

While it's very common to use a ModuleLoad to change globals, doing that with libname seems strange to me.

In order to facilitate the development phase of the module, the module body should consist of the single command ModuleLoad() so that it'll work when the module is not being retrieved from an .mla.

Unfortunately, generating Taylor series coefficients is a bad example of something to be done with Threads. Because memory is shared by the parallel processes, most Maple commands are not "threadsafe" and can't be used with Threads (see help page ?index,threadsafe).

Please go back to your earlier Question and let me know if you understand my "divide-and-conquer" Answer.