I know that you said "toolbox", but let's be sure that we're talking about the same thing here: You do mean specifically the Grid Toolbox (intended for distributed processing on multiple computers) rather than the Grid package (intended for parallel processing without shared memory on a single computer with multiple processors), right?

Does your computation involve complex communication between the multiple processes? Or could the majority of it be expressed as a loop such that the iterations could be performed independently and the final results assembled at the end?

Can you estimate the memory (bytesalloc not bytesused) required per processor and/or the overall memory required? If that amount is large, is that due to memory that is temporarily used for the computation (and then "garbage collected")? Or does your final result itself require a lot of memory? 

Could you make a reduced-size example of your computation such that we could practice with the Grid package before delving into the Grid Toolbox? 

@Wilks If I translate the input (not the evaluated output) of your expression w into 1D input, I get this:

w := (g*(-m[1]*delta1 - m[2]*delta2 - m[3]*delta3 - m[4]*delta4 - m[5]*delta5 
- m[6]*delta6 - m[7]*delta7 - m[8]*delta8 - m[9]*delta9 - m[10]*delta10 - 
m[11]*delta11 - m[12]*delta12 + (-F2*delta*F[2] - `δF1`*F[1] - 
`δF3`*F[3] - `δF4`*F[4] - `δF5`*F[5] - `δF6`*F[6])/g)/
(m[1]*delta1^2 + m[2]*delta2^2 + m[3]*delta3^2 + m[4]*delta4^2 + 
m[5]*delta5^2 + m[6]*delta6^2 + m[7]*delta7^2 + m[8]*delta8^2 + m[9]*delta9^2 +
 m[10]*delta*10^2 + m[11]*delta11^2 + m[12]*delta12^2 + (`δF1`^2*F[1] +
 `δF2`^2*F[2] + `δF3`^2*F[3] + `δF4`^2*F[4] + 
`δF5`^2*F[5] + `δF6`^2*F[6])/g))^(1/2);

There are two places in that expression where you've unintentionally entered delta as a separate variable. This can sometimes happen because you unintentionally pressed the space bar. The first place is -F2*delta*F[2] (should be -`δF2`*F[2]); the second is m[10]*delta*10^2 (should be m[10]*delta10^2).

Not only does 2D Input make it very easy to make these errors, it also makes them difficult to find.

I believe (but I'm not sure) that even if numeric values were supplied for all the parameters, stochastic functional optimization such as this (is stochastic calculus of variations a known term?) is well beyond the capability of Maple. However, you may be able to run simulations with the Finance package.

These are some anomalies that I've spotted in your worksheet. I don't know whether these have anything to do with your excessive-time problem.

1. Both of your Quantile functions use parameter z, but z does not appear in their bodies.
2. I have suspicions about the use of and in the piecewise condition. Mathematically it makes sense, but it may cause unnecessary complexity in the computation.
3. You seem to have used { } instead of ( ) in a few places. This is certainly incorrect, but I don't know whether it has anything to do with the computation taking a long time.

@Mac Dude  Your corrected expression still has juxtaposed subexpressions in two places. Surely this does not express the intended meaning in either 1D or 2D Input.

Here's an example of a procedure that you can use instead of odetest:

restart
:
TypeTools:-AddType(ODEsol, function(name)=algebraic):
TypeTools:-AddType(ODEsols, {ODEsol, set(ODEsol)}):
MySimplifier:= (e::algebraic)-> (s-> `if`(is(s=0), 0, s))(simplify(e))
:
MyOdetest:= proc(
    sol::ODEsols, 
    ode::`=`(algebraic), 
    Simp:= MySimplifier, 
    TL:= 30 #default 30 second timelimit
)
    if sol::set then map(thisproc, [sol[]], args[2..])
    else
        local r:= eval((lhs-rhs)(ode), sol);
        try timelimit(TL, Simp(r)) catch: r end try
    fi
end proc
:
#Example (one you posted a few days ago):
ode:= diff(y(x),x) = 
    (y(x)^3 + 2*x*y(x)^2 + x^2*y(x) + x^3)/(x*(y(x) + x)^2):
sol:= dsolve(ode, y(x)):
MyOdetest({sol}, ode);
                           [0, 0, 0]

The above is intended to handle single ODEs of any order, expressed as an equation, without initial or boundary conditions, with a solution or set of solutions explicitly expressed.

I propose that there be a named type for structures that are necessarily syntactic subunits of any expression in which they occur. I propose molecular, by analogy with atomic.

@acer Do you have enough knowledge of the "rendering" to have an opinion about the possibility of my PDF idea working? Perhaps if the people at MapleSoft are too busy to fix this the MapleNet way, this idea could at least be a quick-and-dirty solution. Even when inlining was working (for most people, but alas not for me), it was quite dirty anyway, as we've both already noted. 

@acer Thank you for the Reply. Hopefully my wording of the concepts will provide the OP with additional insight. Alternate wording often helps me understand. I managed to do all that without reading the OP's originally attached worksheet. This problem that MaplePrimes won't display the worksheets is becoming quite a burden, especially since about half the time I'm just using my phone.

You've said things several times over the years that indicated to me that you had some detailed knowledge of how worksheets are "rendered" for display on MaplePrimes ... well, at least more-detailed knowledge than the vast majority of the MaplePrimes regulars. So, I'd like to ask you something: Since Maple can export worksheets as PDF, and since (I assume) it's very easy to display a PDF in a web browser, wouldn't that mechanism make for a much-easier way to display the worksheets here? At the very least, if every attached worksheet were also attached as a PDF, I'd be able to read them without needing Maple, because my phone can easily display PDFs.

@Wilks 

Regarding the error message: The dsolve command is complaining because it can't decide which Y2 to solve for: Y2(x) or Y2(L[2]). This is totally obvious to us, but not to dsolve. The solution is to tell it which function is the primary in dsolve's 2nd argument:

dsolve({...}, Y2(x));

where ... is exactly what you already have inside the { }.

Regarding your question about constants of integration: If you do indefinite integration with int, it doesn't supply a constant of integration^[*1], as you already know. The command dsolve can also do both indefinite and definite integration, but in the indefinite case it will supply the constants. To see this (just an an instructional example; it's definitely not actually needed here), simply remove one or both initial conditions from the dsolve command. In the definite case, the issue of the constants is handled internally. I suppose that in many cases it does exactly the same steps that you'd do "by hand": First include the constants, then use the initial conditions to solve for them. I'm not sure about its exact internal process, but it is internal, so you do not need to concern yourself about the constants.

Regarding restart (which you didn't ask about): It's almost essential (as well as being standard practice) that you begin every worksheet with restart. Although this particular worksheet seems to work without it (in precisely its current state), you will almost certainly eventually cause some error by not using it. These errors will not manifest until you re-execute the entire worksheet in the same session.

The commands Y1:= 'Y1' and Y2:= 'Y2' aren't needed (yet) in this worksheet, but if they had been needed, it would be much more likely that such an absence-of-restart error would occur. I usually see the presence of these commands as a sign of sloppy programming because their presence obscures potential sources of error.

Congratulations! With much perserverance over a month or so, we've finally made this worksheet into a readable document.

[*1] The reason that int doesn't supply a symbolic constant is that the mathematical constant (such as the +C that's ubiquitous in calculus textbooks) is only truly constant when the integrand is continuous. In the discontinuous case, it needs to be a piecewise-constant function that branches at the discontinuities.

@Kitonum Although this is probably obvious to anyone who's worked extensively with indexed structures (in any language), it should be pointed out for naive readers that what you show beginning with the line L1:= ... can only work if the entries are distinct, i.e., if the structure represents a bijection between its indices (which are necessarily distinct) and its entries. Or, in slightly less-technical language, an indexed structure has a pointwise inverse^[*2] structure iff it represents an invertible function.

Nonetheless, it's easy (and remarkably efficient) to construct the setwise inverse^[*1] table for any table or rtable by using ListTools:-Classify, as in this example:

M:= LinearAlgebra:-RandomMatrix((9,9), generator= rand(0..9)):
M_inverse:= ((op@[lhs]~)~@ListTools:-Classify)(rhs, [indices](M, ':-pairs')):
#Remove op@ from above command if you want explicit sets.
M_inverse[7];
             [1, 8], [1, 9], [3, 3], [4, 2], [4, 3], [9, 1], [9, 5]

In other words, the end result of the above is all pairs (i, j) such that M[i,j] = 7.

[*1] My terminology setwise inverse is perhaps nonstandard. Thus: Definition: Given a function f: A -> B, the setwise inverse of f is the function g: B -> 2^A defined by g(y) = {x in A | f(x) = y}. The set g(y) is called the preimage or inverse image of y under f. Note that any indexed structure can be thought of as a function of its indices. All symbols and words in these footnotes mean what they commonly mean in set theory, which is not necessarily what they mean in Maple.

[*2] By "pointwise inverse structure (or function)", I simply mean inverse function is the ordinary sense. I just used pointwise in contrast to setwise.

@Rouben Rostamian What you suggest---op(node[...])---would only work if node[...] were an unassigned name, not a table or rtable entry.

@nm With all due respect, I disagree with your opinion about posting the problem as a picture. It's best for the OP's own learning to type it in correctly. It also makes copy-and-paste easier for the respondents. Responders usually don't want to type in a whole problem from a picture.

In this case, the OP seems too lazy to correct the typing of their problem, despite numerous corrections from responders here.

If you'd care to amend your suggestion to "post a picture AND type it in (or at least try to)", I'd agree with you.

@ogunmiloro Due to your Maple version, just use interface(rtablesize= infinity). Individually setting the allowed number of rows and columns is a rather recent innovation. 

@Wilks The fact that you no longer want the constants of integration to be 0 makes no difference. There's no need for any solve, int, or intat; there's no need to ever see or even name the constants. All of that can be replaced by a single call to dsolve. The constants will be determined from the initial conditions, which are passed in the first argument to dsolve.