At one level I know what is "wrong" with you code, but I don't kow how to fix it

The required number of boundary conditions is determined by the degree of the derivatives in the problem. For arbitary (non-zero) values of L (with k[1]=entries of L) you have two differential equations, which have degree 4 in diff(f(nu), nu) and degree 2  in diff(theta(nu), nu) - so you need 6 boundary condtions (which you have provided)

On the other hand, if one of the entries of L[] is zero, then the value of k[1] is zero in one of your equations and the resulting two differential equations are now of degree 3 in diff(f(nu), nu) and degree 2 in diff(theta(nu), nu) - so now you only need 5 boundary condtions - but you are still supplying 6

You have to ask yourself - when I only need 5 boundary conditions, whihc 5 of the 6 available are required???

Not a solution but when  I started digging into this problem, I cam up with a couple of things which surprised me - and I wonder if they surprise you???

I break down your code to the following which allows me to look at intermediate answers to determine where the fundamental problem might be occuring: so for m=3

restart:
Digits :=30:
m := 3: g :=0.3: nu := 0.2: a := 1:
w := sum(b[n]*cos(n*r), n = 1 .. m):
W := simplify( subs( solve( { subs(r = 1, diff(w, r$2)+nu*diff(w,r))},{ b[1] }),w));
d1:=diff(W,r):
d2:=diff(d1,r):
F:= int( ((d2+d1/r)^2-(2*(1-nu))*d2*d1/r)*r*(1+g*r/a)^3,r = 0 .. a) /int( d1^2*r,r = 0 .. a):
sys:={seq(subs(r=n/m,diff(F,b[n])),n=2..m)}:
sols:=solve( {seq(subs(r=n/m,diff(F,b[n])),n=2..m)},{ seq(b[j], j = 2 .. m) });
FW:=seq( subs(j, F), j in sols);

This shows two "interesting" properties

1. There are actually two solutions for m=3: namely FW=6.11860004299491357506825515146, and FW=49.0940627065525249895619507177. Do you expect to have two valid solutions when n=3 ???
2. In determining the solution, the value of b[3] is arbitrary, since the value of sols in the above code returns

{b[2] = -.849418844753342623748963269117*b[3], b[3] = b[3]},
{b[2] = -3.34852240958993384432900236873*b[3], b[3] = b[3]}

so b[3] is arbitrary, and depending on which of the solutions for b[2]  one uses, one gets the two solutions for FW quoted above

If I run the same code for m=4, then the problem is that sols:=solve(blah_blah_blah) returns nothing because solve cannot find any solutions! Neither does fsolve(), fsolve(,complex), nor DirectSearch[SolveEquations] - all running with default options.

From this I conclude that there are two possibilities

1. The most likely answer: for m=4, ther are no solutions for b[2..4] - so the problem cannot be solved
2. On the other hand if one can constrain the search space for b[2...4] it is just possible that solutoin may exist and can be found - unfortunately, I have no criteria for restricting the search space, because I do not understand the background of the problem.

To give you an example of the kind of infomation which might be useful in determining a solution - would you expect abs(b[[4])<abs(b[3])< abs(b[2])? Would you expect the value of b[2] for the case m=4 to be similar to that for m=3? Are there any other criteria which might restrict teh search space for b[2..4]??

I have just run the above code in Maple 2015.1 for m= 4 and m=5

In both cases "plausible" output is obtained -

1. for m=4 one gets an expresssion in terms of b[2]..b[4]
2. for m=5 one gets an expresssion in terms of b[2]..b[5]

When you say

for m>=4 It dosent work!

what exactly do you mean?

This is primarily a technical forum: you now appear to be asking a lega/commercial question on which I am not qualified to comment - suggest you read the relevant EULAs

OK  - on reflection I think I might be able to come with an argument by induction which would demonstrate that the product rule for differentiation applies to matrices of arbitrary size - but I have no plans to do so!

@Rouben Rostamian  

Basically I agree with you - hold the thought because I'm really not looking for an argument!

Essentially te OP's question boils down to - does the product rule in differential calculus apply to matrices? Inuitively, yes. But you make the statement (emphasis added)

The matrix elements do not come into play.  We need not even know the matrix sizes. The boxed formua is true for any set of nxn matrices.

The obvious question arises, leaving aside intuition how do we know/prove that the above emboldened statement is true without considering matrix elements? I mean that I know it is true, but since I can't assume it - how do I prove it without considering matrix elements?

the following works for me - but I'm pretty sure that you are not going to like it!!!

desol.mw

Since yu define your problem in terms of three "nested" functions, I thought you might be interested in a solution constructed in the same way, as in

h:= (a, b, c) -> b!*(a+c)!*add(F(a,c,n), n=0..c):
F:= (x, y, z) -> (-1)^z*binomial(y, z)*N(x, z):
N:= (x, y) -> (-1)^(x+y)*evalf( ln(2)+ add( (-1)^(x+k)/(x+k), k=0..y)):
h(1,2,3);

So far as I can tell for h(p, q, r), this gives exctly the same answers as Carl's code - which only shows that there is always more than one way to do it!

@Boby 

You ask me to produce a plot which my original code already generates - why?

What is wrong with my original?? Particularly when you are incapable of reading Maple error messages and correcting your syntax accordingly. If you really want to use the above code rather than my origianl stuff then you need to correct it to

with(plots):
p1:=plot(exp(x^3), x=-5..5, style=point, color=red, view=[-5..5, -20..20]):
p2:=plot(approx, x=-5..5, style=line, color=green, view=[-5..5, -20..20]):
plots[display](p1,p2);

This will produce a plot which is essentially identical to that in my original worksheet produced by the statement

plot( [rhs(exact), approx],
         x=-5..5,
         color=[red, blue],
         view=[-5..5, -20..20]
       );

@aamirkhan 

As I explained earlier you have 6 equations in 32 unknowns: your statements such as

i.e. "ud","vd","wd","rd" are assumed to be known.

are entirely meaningless to Maple. As in "assumed" by whom, why: where is this assumption codified. The assumption may exist in your mind, but  nothing in your original worksheet expresses this assumption. As far as Maple is concerned all 32 unknowns have equal status.

I have given you a worksheet which determines solutions for pd, qd, rd, ud, vd, wd in terms of other "parameters" which you claim are "known" - so if I have produced expressions for pd, qd, in terms of "known" quantities, so pd, qd are now determined.

So I don't understand your problem

@Preben Alsholm 

However the OP uses the longform command

GraphTheory:-Graph(data);

so his/her procedure works, even although the with() command isn't really doing anything.

I probably should have fixed this as well in my original response:-(

@Glowing 

The i7-3770k is 4-core/2T per core. Windows device manager reports this as "8 processors", as does the task manager performance monitor.

Interestingly the Maple command kernelopts(numcpus) returns 8, which appears to contradict the relevant Maple help page which states (my emphasis)

Returns the number of CPUs that Maple
will automatically optimize for.  By
default this will be the actual number
of CPUs that the machines has (treating
hyperthreaded CPUs as 1 CPU).  This
value can be set.

If I run Carl's test code with the argument [20$8], which ought to run for a total cpu of ~20secs across 8 threads, I get

memory used=1.34GiB, alloc change=0 bytes, cpu time=20.62s, real time=3.93s, gc time=51.68m
                    [8, 8, 8, 8, 8, 8, 8, 8]

So on this test my multithreading speed-up is about a factor of 5.

I thought I'd check whether increasing the overall time would change this by much (by reducing any set-up/tidy-up effects??) So modifying Carl's original code slightly to

restart;
interface(rtablesize=11):
Waste:= proc(N)
                      local st:= time();
                      while time() - st < N do
                      end do;
                      kernelopts(numactivethreads)
              end proc:
Array([ [cpuTime, realTime],
             seq( [CodeTools:-Usage
                                       ( Threads:-Map[tasksize= 1]
                                                       ( Waste, [j*20$8] ),
                                                          output=['cputime','realtime'],
                                                          quiet
                                        )
                    ],
                    j=1..10
                 )
          ]
        );

returns

So on this test my multithreaded speed-up factor seems to hover around 6x-7x

If I run the unthreaded version of your code, ie

restart;
#with(Threads):
t := time[real]():
seq(i+i*cos(i), i = 1 .. 3*10^6):
time[real]()-t;

It takes about 40secs on my 8-core i7-3770k machine: Interestingly however, it *seems* to be spread across all 8 cores, but none of these hits a cpu usage of much more than about 30%.

So I have to assume that if one has a multicore setup, then the underlying OS (in my case 64-bit win7) will still multithread operations, even if not requested by the application. Makes sense if you think aboout it, because how many applications allow the user to determine the number of threads being used???

Have you tried runnning the above "unthreaded" version, whilst monitoring cpu usage??

On the other hand if I run the threaded version

restart;
with(Threads):
t := time[real]():
Seq(i+i*cos(i), i = 1 .. 3*10^6):
time[real]()-t;

it runs in about 20secs across all 8 cores, with CPU usage on each hitting around 80%

Based purely on the amount of cpu usage in the two cases, I would have expected a speed-up somewhere between 2.5x-3x, aand I only got 2x. On the other hand there must be an overhead in task splitting, result reassembly etc, so maybe 2x is not unreasonable??

So I wouldn't agree that this is a "bug" in Maple 2015.1

On the other hand this doesn't explain why yours actually gets *much* slower. First thing I would do is check execution time/cpu usage when using unthreaded Maple code, against threaded code, both on your new machine

@Sagar 

Quoted her for your convenience

The attached worksheet (using 1-D math input) corrects these. However a quick plot of the resulting function shows that it has a singularity within the range of integration (at 0.6304942112 in fact). Since the value here is infinite, straightforward integration (numeric or otherwise) is not going to be possible.

Just because you want to integrate something does not mean that it can be integrated!!

Execute the worksheet I posted previously and take a long hard look at the function you want to integrate.

There seem to be a number of syntax problems in the 2-D input - missing multiplication signs, and use of the name 'e' rather than the function exp() for exponentiation

The attached worksheet (using 1-D math input) corrects these. However a quick plot of the resulting function shows that it has a singularity within the range of integration (at 0.6304942112 in fact). Since the value here is infinite, straightforward integration (numeric or otherwise) is not going to be possible.

I am reluctant to investigate further until you confirm that the syntax corrections mentioned above, do in fact produce the function you want

See the attached

unt.mw