In the worksheet pdsolve.mw which you loaded all boundary conditions are zero.

In other words V(x,y)=0 on all boundaries. However V(x,y)=0 also satisfies the differential equation

diff(V(x,y), x, x)+diff(V(x,y), y, y)=0

Hence it is difficult to see how one could generate anything other than the zero solution (either numerically or analytically) from the way the problem is posed.

I have attached a worksheet, the first part of which produces an analytic solution for Laplace's equation (in more or less textbook form), with no boundary conditions applied. This part ought(?) to be useful, when solving the problem with other boundary conditions. The second part of this worksheet, substitutes in the specific boundary conditions which you specified and demonstrtaes that indeed, the answer is always zero.

LapEq.mw

Reason I'm surprised is that (unless I'm badly mistaken), you have produced Laplace's equation in 2 dimensions. I would have thought that Maple should be able to handle this particular pde without much help - cos (if I'm right about the classification), this is a 'standard, textbook' pde.

I know that (given sensible boundary conditions, which yours seem[?] to be) there are methods for solving Laplace's equation.

It's been a long time (>40years) since I did this from first principles, so I'm going to have to dig out a textbook from somewhere, in order to guide Maple to a solution

Watch this space - or check out soluion methods for Laplace's equation for yourself!

I have made multiple corrections to the worksheet you supplied. In many places I have had to *guess* your intent, and my guesses are quite likely to be wrong! So read the comments in the attached worksheet very VERY carefully to ensure that the changes I have made are what you actually desire

Kernel8_Corr.mw

If you do a little manipulation on your original equation

diff(u(x, t), t, t)-c^2*(diff(u(x, t), x, x))-cos(x) = 0

you will obtain

c^2*(diff(u(x, t), x, x))-diff(u(x, t), t, t) = -cos(x)

and the latter is the classical form of the inhomogeneous wave equation. Check out the Wikipedia page

https://en.wikipedia.org/wiki/Wave_equation

The Wikipedia article starts with the homogeneous wave equation, and moves on to the inhomogeneous version. It explains the general form which solutions must take, but is fairly clear that there is no general analytic solution.

In your particular example, if you apply the boundary conditions and ask Maple for an analytic solution by using

A:=5:B:=9:c:=1:
PDE := diff(u(x, t), t, t)-c^2*(diff(u(x, t), x, x))-cos(x);
IBC :={u(0, t) = A, u(1, t) = B, u(x, 0) = 0, (D[2](u))(x, 0) = sin(x)};
pdsolve({PDE} union PDE);

You will find that the solution is separable, ie u(x, t) = _F1(x) + _F2(t), with a few additional constraints. However Maple still cannot find an explicit analytic solution.

I think you have  to accept that (despite what textbooks suggest) the vast majority of PDEs (and ODEs) cannot be solved analytically.

Somewhere in your code there has to be an assignment

par_eff_post:= equation or list/set of equations

Nothing you have posted shows such an assignment. It has to be an assignment rather than a procedure with no arguments, because in the latter case it would be used as 'par_eff_post()' rather than 'par_eff_post'

You need to find this assignment, and ensure that it occurs before 'par_eff_post' is used in any eval() statement. If you cannot find this assignment, then that explains your problem.

There are two main ways to use the command 'eval()', which are

eval(e, x=a) and

eval(e, eqns)

In order to get the error message

Error, invalid input: eval expects its 2nd argument, eqns, to be of type
{integer, equation, set(equation)}, but received par_eff_post

then somewhere you have a command

eval(someExpression, par_eff_post)

but at the point this command is evaluated, 'par_eff_post' is unassigned. In other words it does not evaluate to either an equation or list/set of equations - it just evaluates to itself, ie the symbol 'par_eff_post', which means that the eval() command fails

All I can suggest is that prior to any comand of the form eval(someExpression, par_eff_post), you need to be absolutely certain that 'par_eff_post' has been assigned to something appropriate

I have added a few commands to the end of you file to illustrate the use of the methods generated by the

pdsolve(...., numeric)

construct. See attached

SolvePDE_extra.mw

Everything seems to be working just fine - so what is your problem/question?

As in

pdesys:={ diff(J(x,t),x)=epsilon*J(x,t)*C(x,t),
                diff(C(x,t),t)=phi*epsilon*J(x,t)*C(x,t)
              };
OPsols:={ J(x,t)=J__0*exp(J__0*epsilon*phi*t)/(exp(J__0*epsilon*phi*t)+exp(C__0*epsilon*phi*x)-1),
                C(x,t)=C__0*exp(C__0*epsilon*phi*x)/(exp(J__0*epsilon*phi*t)+exp(C__0*epsilon*phi*x)-1)
             };
pdetest(OPsols, pdesys);

"residuals" returned by pdetest() are the same as those obtained by user vv.

My original response stands

Either you have a typo in the definition of 'pdesys' which you supply or "people at Institute of Mathematics, Uppsala University, Sweden" don't know what they are doing

On Windows 7, 64-bit, Home Premium (with all 'important' OS updates, to present date)

Maple 18.02,        produces [12, [x = 1, y = 2]]
interface(version)   Standard Worksheet Interface,
                             Maple 18.02,
                             Windows 7,
                             October 20 2014
                             Build ID 991181
kernelopts(version) Maple 18.02,
                             X86 64 WINDOWS,
                             Oct 20 2014,
                             Build ID 991181

Maple 2015.02,     produces [12, [x = 1, y = 2]]
interface(version),   Standard Worksheet Interface,
                              Maple 2015.2,
                              Windows 7,
                              December 21 2015
                              Build ID 1097895`
kernelopts(version)  Maple 2015.2,
                              X86 64 WINDOWS,
                              Dec 20 2015,
                              Build ID 1097895`

Maple 2016.1,       produces [12, [x = 1, y = 2]]
interface(version),   Standard Worksheet Interface,
                              Maple 2016.1,
                              Windows 7,
                              April 22 2016
                              Build ID 1133417
kernelopts(version)  Maple 2016.1,
                              X86 64 WINDOWS,
                              Apr 22 2016,
                              Build ID 1133417`

Sorry - but I can't make it fail!!!

I'm prepared to believe Kitonum (smart guy), that it fails for him on Maple 2015 and 2016.1. Only obvious difference would seem to be that I'm 64-bit for both OS and Maple, and he's 32-bit!!??

Re-read my original response

Why are you still using the construct S[m][n](t) - what do you think it means? Since dsolve() can find no solution for the equations in S[m][n](t) which you define - do I assume that finding no solution is the "answer" which you want?

Trust me, there are much quicker ways to come up with no solution at all!!

Why are you still using Q__mn(t) in the final pair of loops. As you define it, dsys2 will only ever consist of a single equation, which Maple will then solve. I assume that it is only this single equation which you wish to be solved, and the whole dual-loop which you are using at this point is completely pointless, irrelevant and stupid.

If you think I am joking add the following to the end of your worksheet

myEq:=diff(Q__mn(t), t, t, t)+xi[MM]^2*(diff(Q__mn(t), t, t))+(-U1*U2+eta__n^2)*(diff(Q__mn(t), t))+xi[MM]^2*eta__n^2*Q__mn(t) = -2*BesselJ(0, xi[MM]*b)*U1*U2*b__m*(1-exp(-xi[MM]^2*t))/(BesselJ(1, xi[MM]*a)*Pi*xi[MM]^3);
dsolve(myEq);

This will provide the same "answer" as you obtained - but is it the correct answer, or completely meaningless, on the basis that so much of the input defining the problem is complete and utter garbage - so no sensible being would ever believe the output

@acer 

I read the previous post - and decided not to bother helping on that one: there were just way too many errors

This time (s)he caught me on a Sunday when I wasn't doing too much, so I thought I'd try a spot of education. I'm already going off the idea!

I'll give him/her one (or maybe two) more tries before I bail out

Why are you still using

with(MTM)

in the second line of your worksheet!

I explained all the problems this was causing - why are you still loading this package?

Why?

Why?

Why?

I didn't even bother reading the rest

To make things clear I am providing examples using Maple's 1-D input mode.

You have an execution group comprising a loop which computes expressions for K0[m], KK0[m], K1[n], KK1[n]: namely

for m to MM do
    K0[m] := proc (r, m)
             options operator, arrow;
             BesselJ(0, xi[m]*r)*BesselY(0, xi[m]*b)-BesselJ(0, xi[m]*b)*BesselY(0, xi[m]*r)
             end proc;
    KK0[m] := proc (r, m)
              options operator, arrow;
              diff(K0[m](r, m), r) end proc;
    K1[n] := proc (r, n)
             options operator, arrow;
             BesselJ(1, eta__n*r)*BesselY(1, eta__n*b)-BesselJ(1, eta__n*b)*BesselY(1, eta__n*r)
            end proc;
    KK1[n] := proc (r, n)
              options operator, arrow;
              diff(K1[n](r, n), r)
              end proc
end do

This will compute procedure definitions for K0[1], K0[2]..K0[MM] and so on. But you are also defining K1[n] and KK1[n]. Now 'n' is not a loop variable: at this point in your code 'n' has the fixed value 0. So you loop is going to define K1[0] and KK1[0] several times. The definition of 'K1[n]', contains the argument 'eta__n'. The former is an indexable quantity, and the latter is an inert subscript - in 'eta__n' the quantity 'n' will not be evaluated to anything apart from the letter 'n' .

So seeing all these problems with indexable quantities - what do you actually want this loop to do: becuase I can't work it out!!!!

A couple of execution groups later, you have the group

m := 0;
for m to MM do
    M__m := int(r*K1[m](r, m)^2, r = a .. b);
    bb__m := 1/M__m
end do

Notice that neither M__m nor bb__m are indexable quantities. You might be expecting to get M[1], M[2], M[3] etc as this loop executes, but you won't get it. The __m indicates an inert subscript which is not dependent on the loop variable, so you will assign the same  M__m several times. Same argument for bb__m

When you define the differetnial equations - the first one (in 'S' contains a constuct I have never seen before: in 1-D code it translates to η__η__n__ and is rendered as eta with an inert subscript eta, where the subscript eta has a further subscript n. The whole hierarchy of subscripts is inert. You also have quantities such as xi[m], and indexable quantity dependent on loop variable and xi^2*[m], in which 'xi' is not an indexable quantity. I suppose you might have two different 'xi' variables, one indexable and one not, but I doubt it

In the second loop definition of differential equations, you are using

Q__mn(t) # inert subscripts, nothing to do with loop variables

xi[m]  # indexable quantity, dependenet on loop variable m

eta__n # inert subscript, nothing to do with loop variables

b__m # inert subscript, nothing to do with loop variables

Like I said before you have such a mixture of indexable quantities (ie using active subsripts and non-indexable quantities (using inert subscripts) that I cannot work out what you want. I suggest you read the manual on the difference between P[n] and P__n and then rewite your code appropriately using only the type of subscripts you actually need!

There are way too many syntax errors in this code for me to even guess what you are trying to achieve. Im just going to list a few, and you are going to have to figure out what you actually mean

You use with(MTM): I have no idea why you wish to mix Maple and MATLAB commands/syntax, because this is causing all kinds of chaos!

The firs example is that you are defining Bessel functions using both bessel() and Bessel(). The first of these will use the Matlab Bessel-function definition and the second will use Maple(). Why do you want both?

The most obvious example is when you start to use diff() expressions to define your differetnial equations. diff() is a command in both Maple and Matlab. Since you have used with(MTM), Maple will use the Matlab interpretation: so diff(f(x), x, x) will return the x-th derivative of f(x) with respect to x. The Maple interpretation of diff(f(x), x, x) would be the second derivative of f(x) with respect to x. Now which of these do you want?

A similar problem occurs with all derivatives greater than first order

Because you have loaded the MTM package, the dsolve() command (which is generating your first outright syntax error), is actually Maple's interpretation of the Matlab dsolve() command. The syntax for Matlab dsolve() is subtly differetn from the syntax for the in-built Maple dsolve(). Why are you using it??

My first recommendation would be to completely avoid loading the MTM package unless you can come up with a very good reason why you need it

My second recommendation is that you you give some serious consideration to the correct use of subscripts/indexes. As an example, consider your use of S[m][n](t), this will define the n-th entry in the indexable quantity m. Now you are using m as loop variable at this point, so unless you mean to have two different quantities 'm', one indexable, and one not, this doesn't make much sense - I suspect you mean S[m,n](t)?

In a similar way are you sure that 'xi', 'eta' etc are indexable quantities?? Sometime these are - but sometimes these are used with the '__' structure, which provides an inert (non-indexable subscript): which do you want??

Like I said at the start - syntax is too confusin for m to fix it!

Don't believe that you obtained solutions for "AA=-0.2,0,0.2,0.4,...;" - for the following reasons

1. You do not provide the dsolve() command which you are using
2. 'etainf' is not defined in the code which you posted - hence it is regarded as an 'variable' - this makes the boundary conditions (D(f))(etainf) = 0, theta(etainf) = 0, phi(etainf) = 0, meaningless as boundary conditions. They cannot be evaluated to numeric values
3. Setting etainf:=1, just to check what else might be wrong gives problems with the other boundary conditions, since none of (D(f))(0) = 1+AA.((D@@2)(f))(0), theta(0) = 1+BB.(D(theta))(0), phi(0) = 1+CC.(D(phi))(0) is a "valid" boundary condition - in fact each of these is an ODE
4. Do not use '.' for simple multiplication. As the manual explains '.' is the "operator for noncommutative or dot product multiplication" and I'm pretty sure that is not what you mean!