@rit The Wikipedia article that you have quoted pertains to vector fields.  Can you identify the vector field that you wish to examine?

Hint: As Preben Alsholm has pointed out in the earlier version of your question,  your system of differential equations is nonautonomous, therefore it does not define a (stationary) vector field, and consequently the concepts of source and sink are not applicable.

@mskalsi You have written u with a subscript x to denote the derivative of u with respect to x.  That's a common mathematical syntax, and therefore I understand what you mean, but that's not how Maple looks at things.  It expects diff(u(x,y),x) instead, which, among other things, makes it explicit that u is a function of x and y.  Similarly the mixed x and y derivative would be diff(u(x,y),x,y), etc.

Fix your worksheet and try again.

@tomleslie The derivation of the differentiation formula (A . B)' = A' . B + A . B' for matrices A an B is identical to that of the scalar version.  We have

[A(t+h) . B(t+h)  - A(t) . B(t)]/h
=
[A(t+h) - A(t)]/h . B(t)  +  A(t+h) . [B(t+h) - B(t)]/h.

We take the limit as h goes to zero and get

[A(t) . B(t)]' = A'(t) .B(t) + A(t) . B'(t).

@tomleslie I don't quite agree with your statement that "If you were to do this with pencil and paper, then you would proceed by comparing Matrix elements in your final expression. No other option is possible."

If I were do that with pencil and paper, I would do what the original poster has shown in the posted image, and would arrive at the equation boxed in red.  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 point is, Maple is not capable of doing formulas like that.  Compare that with the scalar case which Maple handles with ease:

f := t-> g(t)*h(t);

diff(f(t),t);

@TomM I tried out your three execution groups (in Maple 2015.1) which altogether produce 4 plots.  The first is a thumbnail.  The last is full-sized.

Curiously, the two middle ones are variable-sized -- they grow and shrink as I resize the Maple window.  When I maximize the window, the two middle ones are actually larger than the fourth plot.  When I reduce the window size, the two middle one can shrink to be as small as a thumbnail.

This does not bother me, and until you brought this up, I was oblivious to the issue.

As to your last paragraph where you write "What I do not need is a lot of space being taken up by the thumbnail just to get this verification", I don't quite see what you are saying.  If you want verification, use semicolon.  If you don't, use colon.  But perhaps you have something else in mind.

As far as I can tell, what you are asking is not possible in Maple, unfortunately.  See this old discussion on the issue.

I think I recall seeing a behavior such as you have described, but I can no longer reproduce it.  Perhaps that is because I have upgraded from Maple 2015 to Maple 2015.1.

With Maple 2015.1's default configuration, p := plot(...); displays a thumbnail.  Subsequently, p; displays a normal-sized plot.

If you don't want to see the thumbnail, replace the semicolon with a colon, as in p := plot(...):

@max125 We know that the (-1)^x is +1 if x is even, and -1 if x is odd.  Now, what do you expect to get if x is neither odd nor even? Think of x = Pi.

@rit I don't understand the question at all.  Perhaps someone else who can understand it may respond.

I have no idea what it is that you are asking.  The expressions that you have shown are correct Maple syntax.  What do you want to know about them?

@Z1493 pdsolve computes its solutions by searching among expressions fitting certain special simple patterns. Those patterns are far from spanning the complete solution space in general. In your case, for instance, the functions

f1(x,t) = A*sin(x+t) + B*cos(x+t),   f2(x,t) = A*cos(x+t) - B*sin(x+t)

are also solutions of the PDEs for any constant A and B, but they are not captured by pdsolve. Note that, in partiular, A=1 and B=-1, produces your "initial conditions", indicating that your ics is insufficient to identify a solution uniquely.

@Z1493 Partial differential equations are much more subtle than ordinary differential equations.  You cannot just throw together a random set of equations and expect a solution.  Seemingly small changes, such as going from

d^2 u/ dx^2 + d^2/dy^2 = 0

to

d^2 u/ dx^2 - d^2/dy^2 = 0

can have drastic effects on what kinds of boundary or initial conditions may be prescribed, and how the solutions bechave.

What you have called ics in your message is not in any way meaningful in the context of the corresponding equations, so you should not expect a solution.  In practice, partial differential equations often arise from physical models which provides a guide to the appropriate initial and/or boundary conditions, and that's where I suggest that you should begin.

Is there a reason to expect anything other than the zero solution?

@Carl Love Yes, the expression you have obtained is good and correct.  However the solution produced by solving the ODE looks better. In particular, it makes it clear that y(x) = x + an oscillation.

By the way, the equation tan(y) = a*tan(x) arises in the modeling of a universal joint, shown as an animation near the top of the web page <https://en.wikipedia.org/wiki/Universal_joint>.

@Raluca84 As to "the whole article is useful for a good understanding", that's an understatement.  To understand that article, one needs to read a bunch of other references first.  For instance, the article does not explain the meaning of the article's very first equation, (2.1).  Rather, it refers to the articles [1-4].  I am not interested enough in the subject to chase those references.

Here is something you can do to help.  Consider the recurrence equation (2.1), which is:

x(t+1) = A(t) x(t),   t in N^m,

where 1 = (1,1,...,1).  I think x is in R^n and A(t) is an nxn matrix, although the article does not say.

Now, suppose m=3 and n=1.  Can you explain what is meant by solving that recurrence?  Can you provide an algorithm?