@Christian Wolinski Thanks for the fix and a thumb up!

I puzzled over this for a couple of hours.  It appears to be a bug unless there is a deeper reason hidden behind it.

Carl and Acer, thanks for your solutions.  Here is the final result for everyone's amusement!

Download penny.mw

penny-obverse.png:  

penny-reverse.png:  

In ODE5 you have I(t).  What is it?

Note that I is the unit imaginary number in Maple.

It is not hard to see that the solution of the problem is even in x, that is, u(x,t) = u(-x,t).  Therefore it suffices to solve the problem on the half-domain 0 < x < Pi and then reflect the result.  The symmetry implies that the x derivative of the solution along the line x=0 is zero.

Maple's pdsolve produces the wrong answer on the domain -Pi < x < Pi, but it does produce the correct answer on the half-domain 0 < x < Pi;  see the calculations below.  Perhaps the solver assumes that one end of the domain is always at zero.  I seem to recall a similar bug from some years ago.

Download mw.mw

It will help if you post your worksheet.

@permanoon123 
plot(f(L/2,t), t=0..T);

@Carl Love The sequence of the orders, which goes like 

1, 2, 3, 3, 5, 6, 4, 4, 9, 6, 11, 10, 9, 14, 5, 5, 12,...

is the sequence number A003558 in The On-Line Encyclopedia of Integer Sequences.  There is an extensive discussion there of the contexts in which the sequence arises, and some of the its properties.  In particular, search in that page for "milk shuffle", and also for the line where it claims 

a(n) <= n. - Charles R Greathouse IV, Sep 15 2012

As far as I can tell, there is no formula for the a(n) (the order of the permutation).  However you may have already observed in your calculations that a(2^k) = k + 1.   For example, the permutation order of a string of length 2^10 is 11.

@Fereydoon_Shekofte You don't need a computer to decode the string.  Doing it by hand is quite trivial and fast.  You can even do it in your head.  I will illustrate this by an example but the method is general.

The Arabic Cipher encodes the string ABCDEFG as DECFBGA.  To decode, read every other character in the encoded string, from right to left, beginning at the string's end (I have marked those characters in red):

D E C F B G A

That yields ABCD.  Then read the remaining characters from left to right.  That yields EFG.  Put the two parts together to get the decoded string ABCDEFG.  That's all!

Equivalently:

Read characters from right to left in the encoded string, and pile them into two groups, like this.

The first two characters read are A and G:
A  <−>  G

The next two characters read are B and F.  Insert them as shown:
AB  <−>  FG

The next two characters read are C and E. Insert them as shown:
ABC  <−>  EFG

The remaining character is D.  It can be inserted in either the left or the right group, doesn't matter which:

ABCD  <−>  EFG

Join the two groups to obtain the decoded string:
ABCDEFG

@vv I assume that by the Order of a permutation p you mean the smallest integer m>=1 so that p^m is the identity.

If so, then taking P[n] as you have defined, we seem to have order(P[n]) <= n.  I have checked that for n from 1 to 600.  I don't understand why you say Order(P[n]) >= n.

In particular:

1. Order(P[17]) = 12, that's why Fereydoon_Shekofte's example of applying the cipher to the string "FereydoonShekofte" (17 characters) recovers the original string in only 12 steps.
    
2. Order(P[42]) = 8, not 131072.
    
3. Order(P[995]) = 180, and not the enormous number that you have cited.
    

But perhaps I have misunderstood you.

@tomleslie The culprit is not the lack of brackets in the subs.  In the context of this question the presence or absence of the brackets is immaterial.  The problem lies in the first input line where the := assignment to f has been entered but not executed as is evident in that line's output.

Maple docs on the web are not reliable.  You shouldn't be learning from them.

I don't mean that they contain errors.  What I mean is that they have been obtained by translating Maple's native help pages into html and, as it happens with any translation, some significant parts can get garbled.

The web page that you have referred to says: "To define a derivative, use the diff command."  But then we see that there is no "diff" in the example that follows.  That part has been lost in translation.

So how to get around the problem?

After you get a bit more used to Maple, you will have no need to go to google for help.  Maple comes with its own built-in documentation and that's the preferred place to look.

However, if at this stage of your learning you prefer to look things up on the web, I offer the following advice.

The web page that you have cited documents Maple's "dsolve" command as you can see by looking at the very top of that page.  Once you know that it is "dsolve" that you are looking for, skip the web page and read Maple's built-in documentation on "dsolve".  The built-in documentation does not suffer from translation issues.

@acer May thanks for pinpointing the source of trouble and the suggested remedies.  Also thanks for submitting a bug report on this.

Additonally, since the complaint arises from odeplot, it would have been more user-friendly to have an error message of the sort
Error, (in odeplot) invalid range
instead of that shown.

I see at least two problems in your code.

The first is a Maple syntax issue.  You have
pdsolve({dsys, ics}, type = numeric);
That should be
pdsolve(dsys, ics, type = numeric);

The second is a math issue.  You have
ics:= {Q[1](0,0) = 0, Q[2](0,0) = 0, D[1](Q[1])(T[0],0) = 0, D[2](Q[2])(0,T[1]) = 0};

The first two of these four conditions look suspicious.  For the first one I would have expected something like Q[1](T[1],0)=0.  I don't see how you have arrived at Q[1](0,0) = 0.  Same goes for the second condition.

@vv Thanks for the illustration.  Actually I did not think of the Fourier series solution because the real problem I am interested in is more complex.  I provided the example in my post as a stripped-down case to demonstrate the numerical noise issue.

I can't tell how pdsolve,numeric handles boundary conditions but in the help page ?pdsolve,numeric, under the heading "Details", we read:

Note: A first order accurate accurate boundary condition (the default) can be used for second order accurate method, and still provide a solution of second order accuracy.

That statement bothers me.  It appears that pdsolve applies second order accurate finite differencing to the derivatives in the interior, but only first order finite differencing at the boundary.  That can let inaccuracies to creep in.

When I have the time, I will code a finite difference solver from scratch and compare its results to those of Maple's.

@DLESOS It's telling you that you haven't paid yet for the product.