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.

Get a good copy from https://www.maplesoft.com/ but you need to pay for it.

I run Maple on Ubuntu Linux and I am not unhappy with the default look and feel.  Does it really look awful on Arch-Linux?  Post a screenshot to let people know what it is that you see.  It will also help if you describe what it is that bothers you.  Otherwise it is difficult to provide useful advice.

@Earl Since you said that you want to animate the solution, you may be interested in this which I am posting without its Maple code.

The help page on the sign function says

    The sign function works for polynomials with coefficients of type `numeric`.

Applying it to expressions other than polynomials goes against sign's intended purpose.

Despite what the legend says, the graph that you have shown is that of the tan function, not the inverse tan.

Moreover...

Tickmarks in the form of multuples of Pi makes sense on the horizontal axis but not on the vertical.

@vv That's a very nice .  It also explains why understanding that object is not so intuitive.

Consider these two objects:

#1. A thick/solid mobius strip printed on a 3D printer

#2. A construction of your drawing, made of paper

Object #1 is a one-sided surface in the sense that it's impossible to color it in two colors without discontinuities

Object #2 is a two-sided surface!  It can be colored continuously in red on the side of the paper to which the arrows are glued, and in a different color on the reverse side of the paper.

It's the dichotomy between #1 and #2 that makes it difficult making conclusions without a careful drawing such as yours.

@vv The mathematical zero-thickness mobius strip is certainly not orientable, and therefore it cannot have a continuous normal.  But a "thick" mobius strip is different.

If you follow the normal vector as it turns one round around the thick strip, it ends up in a point opposite its starting point but at a distance T away from it where T is the strip's thickness.  The vector's orientation is reversed but its point of application is not the same as that of the starting point, so there is no discontinuity.

If you continue traveling with that vector for another round, it will arrive at the starting point and regain its original orientation.

I have printed a few mobius strips on 3D printers.  They pose no difficulties.

@JoshuaLeiter I cleaned up my Maple code and presented it as a Post.

The code does parametrized surfaces only.  Unfortunately it cannot handle implicitly defined surfaces.

@Kitonum I have used essentially what you have shown in order to produce 3D objects on a 3D printer.  Let's name your plot P. We save it as an STL file in Maple through
Export("filename.stl", P);
Then send the file to the 3D printer.

That method works sometimes, and fails at some other times.  Here is why.

The STL file is expected to contain a triangulation of the object's surface.  Maple's Export()  produces that triangulation.  The STL file is also expected to include an outward unit normal associated with each triangle.  Maple's Export() fails to do that — some of its normals point outward and some point inward. That obviously confuses the printer which then produces junk.

One can import the STL file produced in Maple into the freely avaiable mesh viewing/manipulation program MeshLab.  In MeshLab, surfaces which have properly defined outward unit normals are rendered in white.  Surfaces whose normal are incorrect are rendered in black.  I exported your Maple plot to STL and loaded into MeshLab.  Here is what we see:

We see that half of the surfaces and edges are in black, indicating that their normals are incorrect.

I gave up in using Maple's Export() for 3D printing some time ago and wrote my own triangulation and export routines.  They work quite well and I have printed a lot of 3D objects using them.  My Maple code, however, is undocumented and disorganized. I have been meaning to clean it up and post it at some point. Perhaps this discussion will motivate me to do so.

@nm Regarding the two differential equation
diff(y(x),x)^2 + y(x)^2 = 1
in my previous message, I must point out that of Maple's solutions y=1, y=−1, y=sin(x+c) and y=−sin(x+c), the last two are actually the same sin(x+Pi)=−sin(x).

Furthermore, there are infinitely many other solutions that one may piece together from those. For instance, the colored part of the diagram below represents a solution of the differential equation:

Similarly, in the case of the second differential equation
y(x) = x*diff(y(x),x) + 1/2*diff(y(x),x)^2
whose solutions are y=−x^2/2 and y=cx+c^2/2, we may produce infinitely many other solutions by piecing together the graphs of the regular and singular solutions, as shown here:

This latter example has an interesting implication — it allows solving a two-point boundary value problem such as
y(−2)=a,  y(+2)=b
for reasonable choices of a and b.  This is rather unusual since the equation is of the first order!