Both examples run fine on Linux.  I tried them in GUI and also in a character-based terminal.

Since Mac is really a unix clone under the hood, your error may stem from the stacksize limit in your unix shell.  I have no experience with Macs, so I don't know what sort of a shell is its defaul.  If it is something like the classical csh or tcsh, type "limit" at a terminal to see what your stacksize is. Mine says "stacksize 8192 kbytes".  You may raise the stacksize if needed.  If your shell is something like sh or bash, the command is "ulimit".

@ogunmiloro You have a linear system of 11 differential equations in 11 unknowns. For the equilibrium to be stable, all eigenvalues of the coefficient matrix should be on the left-hand side of the complex plane. The Routh-Hurwitz criterion (look it up in Wikipedia) provides necessary and sufficient conditions for that. 

In the attached worksheet I have extended my previous calculations to analyze the locations of the eigenvalues through the Routh-Hurwitz criterion. In the end, we see that the stability of the system is determined by two easy-to-verify explicit inequalities that should hold among the system's parameters. We also see that the inequalities may or may not hold, depending of the relative magnitudes of those  parameters.

Have a look at those inequalities and see whether you have enough information about your model to justify their validity.  In the worst case, you will need to supply numerical values for the parameters to verify that the inequalities hold.

This site refuses me to display the contents of my worksheet.  You will need to download it and view it in Maple.

Download worksheet: mw2.mw

The entries in your K matrix are large numbers such as 1.6123642440×10¹⁶. To handle such large numbers you are forced to increase Digits. As a result, Maple has to switch from hardware to software floating point calculations which greatly slows down your work.

Is there a way around this?  Sure!  Consider that you may express the distance from the Earth to the Sun as 150×10⁶ kilometres, or 150×10¹² millimetres, or 8 light-minutes, or 1 astronomical unit.  They all mean the same thing, but calculating with the distance set to 1 results in a much more stable numerical calculations than setting it to 150×10¹².

Consider changing the units of measurements in your model so that the coefficients reduce to a reasonable range, ideally things that are comparable to 1. Then you won't have to increase Digits and all the calculations will be done in hardware, speeding things up tremendously. There is nothing sacred about the use of meter or kilogram for the units of measure. Pick you own units.

You are likely to receive better responses if you provide a specific example that you are interested in. Examples made up by others may not do what you want.

The problem you have outlined is obviously too complex for a first attempt.  I suggest that you begin with a simpler problem in order to get used to both the mathematics of the problem, and the corresponding implementation in Maple.

Begin with finding out about (1) forward Euler scheme versus backward Euler scheme; (2) The CFL (Courant-Friedrich-Lewy) stability condition.  [These are mathematical concepts, not Maple.]

Once you have understood the above concepts, try solving the simplest diffusion equation:

There is no point in struggling with your original problem if you cannot solve this significantly easier one.

@JAMET Near the top of the code, change L := 5*R to L := 3*R.  And also change a=1.3*H to 1.8*H.

If that doesn't do what you want, and you want further input, then please post your maple worksheet (the *.mw file) as I had asked before.  I won't be able to spend any more time with the kind of code that you are posting.

@JAMET You may add any object that you wish to the skeleton.  Here I have added a rather arbitrary polygon,  Edit/change as needed.

In the worksheet I have highlighted the changes (which are very few) relative to the previous "skeleton" version.

Worksheet: pump-head.mw

@ANANDMUNAGALA Text typed in all-capital letters is used to express SHOUTING.  Do it if you really mean to shout.  Generally people are turned off or even offended when they are shouted at.

@Katatonia I made the following changes to your worksheet:

1. Replaced all t[1] with t__1
2. In the definition of x, replaced 10 with T
3. Split off the definition of the differential equation into a line of its own
4. In the dsolve command, removed the space in p (T) 
5. Added assuming t>0, t<T, T>t__1 to the dsolve command

It is clear that in your definition of x(t) you meant t to range over the interval [0,T], and T to be greater than t__1. But Maple doesn't know that.  It has to be told by the "assuming" qualifier.

Extra observation (perhaps a bug?)

Separating the definition of the differential equation from the dsolve command (in step 3 above) is necessary for getting an answer. I don't understand why.  Compare:

# this one works
de := diff(p(t), t) = 2*h*x(t);
dsolve({de, p(T)=0}, p(t)) assuming t>=0, t<=T, T >= t__1;

versus

# this one doesn't work (why?)
dsolve({diff(p(t), t) = 2*h*x(t), p(T)=0}, p(t)) assuming t>=0, t<=T, T >= t__1;

@nm Your calculations are on the right track, however something is wrong there since the points that you have obtained are not critical points. Add the options
view=[-2..2,-2..2,-15..15], style=surfacecontour, contours=30
to your display() command to see that.

I haven't tracked down the error.  It may be something simple.

@Carl Love Yes, in the alternate version that I provided, the spacing between the symbols is not exactly right as I am relying on implied multiplication to separate them.  That's why I said that the code works if one does not mind a little bit of cheating.

@Carl Love If one doesn't mind a little bit of "cheating", this one produces an okay output:

for i from 0 to 3 do
    e := cat(`<`,i,`>`);
    print(A^e*``((x^e)*``(0))=Mat(i));
end do:

@vv Yes, I should have included that line in the worksheet. Thanks for pointing it out.

I have that line in my Maple's initialization file so that it's always executed when I start up Maple. It's for that reason that it was absent in the worksheet.

@nm You wrote:

Since Mapleprimes does not  provide notification telling one they had reply or a comment, how is one supposed to know?

I would have expected that you, an active user of this forum, would have figured out the answer to that question by now.

When you ask a question or reply the someone else's, there is a Subscribe checkbox right underneath the editing window.  Check that box.  Then you will be notified by email whenever there are new replies/answers in that thread.

@C_R Producing animations in Maple is a matter of creating individual frames and then showing them in sequence through
    plots:-display(frame_1, frame_2, ... frame_n, insequence);
The frames are displayed at equal time intervals. It's possible to produce faster or slower animations by adjusting the fps (frames per second) through Maple's interactive menu. Maple does not allow, however, varying the speed from frame to frame.

But we do need variable frame speed for an effective animation.  Observe that in the animation in my original post there are pauses in several places, mostly when words appear, in order to permit the viewer to read the text. Otherwise, the text will flash in and out in a very small fraction of a second.

Here is how I inserted the pauses there.

1. Exported Maple's animation (with a fixed frame rate) as a GIF file.
2. Exploded the GIF file into individual files, one file per frame.
3. Reassembled the frames back into a GIF file by inserting delays where needed.

Steps 2 and 3 were performed with the help of the free and open source ImageMagick image manipulation command-line utilities.

I didn't post the Maple code for that animation because without that post-processing what you would see within the Maple worksheet would not be quite the same.

That said, here is the Maple code to satisfy your curiosity. This code is slightly different from what produced the original animation because the original was done some years ago and I have edited it a few times in the interim.

Here is the animation produced by that code, without post-processing. The lack of pauses is very noticeable and disconcerting.

Source code: cones2.mw