Maple 12 and 15 and most likely all the versions in between and prior to 12 that work with the code give one numerical answer. 

Seeing Maple 16 showing a different value could mean 3 things ...

   1 - All Maple versions prior to 16 were carrying some kind of numerical bug.

   2 - Maple 16 has some kind of numerical bug
or
   3 - Since the pdsolve command for Maple 16 is slightly changed, there were probably a few more calculations and loops involved carrying numerical values through causing a slight value change.

I suppose if we increased the number of digits involved we would improve the accuracy and get better correlation between the numbers.  Maybe someone with M16 could verify that it is indeed what is occurring?

@pagan So you think that's okay?

I still say mapleprimes 1 had the best layout. 

The layout and functionality of mathoverflow is terrible.  I would be more upset if Mathematica echoed the old mapleprimes 1 as they would have much success with it.  Having mapleprimes 2 try to emulate after some other website wasn't the best idea. 

One would want to use as simple as possible secondary pde

using pde:=diff(u(x,t),t)=u(x,t)^2 works fine however setting it to a constant or u(x,t) the solution works as the old way with the wrong answer. 

One would want to use as simple as possible secondary pde

using pde:=diff(u(x,t),t)=u(x,t)^2 works fine however setting it to a constant or u(x,t) the solution works as the old way with the wrong answer. 

Thanks Preben.  It works great!  I do not know what I was doing wrong, I'll find my error later, thanks again.

**edit ** I found that my error was a typo on the secondary pde.  The choice of your secondary pde however independent of the original should also be valid.

Thanks Preben.  It works great!  I do not know what I was doing wrong, I'll find my error later, thanks again.

**edit ** I found that my error was a typo on the secondary pde.  The choice of your secondary pde however independent of the original should also be valid.

So by solving a second pde (that has nothing to do with the one you are trying to solve) along side the original PDE you want a solution for, you are able to arrive at the correct solution?  That's interesting.

I cannot manipulate your workaround to work properly with the original 2010 problem.  Can you please show explicitly?  I still get newton iteration is not converging.

Error, (in solnproc) unable to compute solution for t>1.39999999999999990:
Newton iteration is not converging

So by solving a second pde (that has nothing to do with the one you are trying to solve) along side the original PDE you want a solution for, you are able to arrive at the correct solution?  That's interesting.

I cannot manipulate your workaround to work properly with the original 2010 problem.  Can you please show explicitly?  I still get newton iteration is not converging.

Error, (in solnproc) unable to compute solution for t>1.39999999999999990:
Newton iteration is not converging

Be able to have the same worksheet opened in two separate windows.

Thanks Preben for looking into this.  Much appreciated.

I had access to Maple 16 the other day and tried a 5th order of T(x,t) for which it also complained about a solution that is not converging. 

Thanks Preben for looking into this.  Much appreciated.

I had access to Maple 16 the other day and tried a 5th order of T(x,t) for which it also complained about a solution that is not converging. 

In this case it looks like Maple scales vector graphics seperate from graphical objects rather than as one completed piece.  (the vector graphic being the line you inserted)

I think the only work around here, I think,  is to add another vector graphic line (white so it doesn't show printed) below the black line to trick it to sizing the black line.  Of course it'll have to be trial and error to get the black line to size right.  Not sure it'll work but it's worth a try.

I recalled a different bug trying to figure out why when I printed the printing was so big.  I found out that printing in draft rather than standard mode on my cannon printer caused the printed format size to go large rather than diffuse the printing to extend ink life.  I believe that part, luckily, was fixed.  Hopefully in your case a 16.02 update will be released. 

Just out of curiosity.  July 20,2011 was when this bug was being worked on and there was no 15.02 update for Maple 15.  It went straight to Maple 16.  I am certain this was fixed before Maple 16 started it's Beta testing so why were no further updates initiated prior to the release of Maple 16?

Now my question is this - Is there a threshold number of bugs that need to have been reported / fixed before an update is considered?  I'm guessing probably yes.  It's almost as if the fixes were made and a decision was instead to have it included in the newer Maple version rather than to compile an update for the users. 

That would be zero benefit to any Maple 15 user but what sort of added value is that for Maple16 when a plethora of other commands are already being included.  In my opinion, I don't think the overall benefit is substantial where-as a Maple 15.02 update would have been seen as a tremendous welcome from the Maple community and the added value seen as more valuable than being added in the newer version. 

Do you mean after execution, you want to delete the parts in the output lines?

        You can't do that.  If that is what is happening you need to supress them or as Patrick has mentioned to do something earlier in the code.