@Markiyan Hirnyk Yes, of course.  It is within the context of the solution of that system of PDEs that diff(u,x)=0.  Outside of that context u is just an undefined symbol.  That's why I prefaced my original comment by saying "I assume that you are loading the PDEtools package because you intend to solve a PDE".  I thought that my intention was clear.

@Markiyan Hirnyk A PDE is defined over a domain—that would be an open subset of the (x,y,t) space in this case.  One specifies initial and/or boundary conditions on the domain's boundary to arrive at a well-posed problem.

@Markiyan Hirnyk By "throughout" I meant "throughout the domain".

@Carl Love Your suggestion is a good one for a conventional eigenvalue problem, that is, finding ω so that det(A - ω I) = 0, where I is the identity matrix, or the more general det(A - ω C) = 0, where C is any matrix. The problem posted in the first worksheet in this thread, that is, eign.mw,  is neither. It is a nonlinear eigenvalue problem which seeks the zeros of det(A - C(ω)) = 0, where C(ω) is a nonlinear function of ω.

The problem in this thread's the second worksheet, that is, 1.mw, is of the form det(A - ω^2 I) = 0, which is amenable to your suggested method, as vv has observed.

@Carl Love Your suggestion is a good one for a conventional eigenvalue problem, that is, finding ω so that det(A - ω I) = 0, where I is the identity matrix, or the more general det(A - ω C) = 0, where C is any matrix. The problem posted in this thread is neither. It is a nonlinear eigenvalue problem which seeks the zeros of det(A - C(ω)) = 0, where C(ω) is a nonlinear function of ω.

This may be operating system dependent.  I tried your code on Maple 2015.2 on 64-bit Linux.  The memory usage stayed at 20.18 MB throughout the computation with n=4, 5, and 6.  I did not even "restart"  between the tests.

@iman I know that you don't work in astronomy.  My point was to make you think about the meanings of the numbers that you are working with.  The error in your calculations is not related to Maple at all.  The error already exists when you arrive at your matrix q.  As soon as you see numbers such as 10^17 and 10^(-118) mixed together in a matrix, you should stop, think, and ask yourself what it is that you are doing wrong and how to fix it.  Continue with calculations only after you have resolved that issue.

Think about this:  The q[1,1] entry in the matrix matrix q in your eign.mw worksheet contains the term 1.717631735 x 10^17.  Why is this number specified to only 10 digits of precision?  It's because you don't know the next digit -- the one that comes after "5".

What you don't know can be important.  If you insert a "1" just after the "5", the value of your number changes by ten million because it gets multiplied by 10^17.  So your number is accurate within plus or minus 10 million at best.  In view of this, what is the significance of the term 3.864000000^(-105)*omega^26 which also appears in q[1,1]?

To compute successfully, you should readjust the mathematical model to avoid a mixture of ridiculously large and ridiculously small numbers such as 10^17 and 10^(-108).  Don't expect to get far without doing that absolultely essentiual initial work.

@Sana Gull

Thomas Richard's code works just fine on Maple 11 and produces a result identical to that of the latest Maple.  I expect that it should work on your Maple 13 as well.  Try again.

@MatthewsonT I still don't see what it is that you are asking. As I wrote before, since you say you can do the problem on paper, it may be a good idea to show us exactly what it is that you do, providing all the details.  Then someone may be able to tell you how to do that same thing in Maple.

In the harmonic motion generated by the equation x'' + w^2 x = 0, the frequency is independent of the amplitude, therefore I don't quite understand what you mean by depicting one against the other.  Perhaps there is a hidden assumption which you have omitted.

Since you say you can do the problem on paper, it may be a good idea to show us what it is that you do.

@Carl Love I like your revisions quite a bit.  Thanks!

@Kitonum Is there a reason to believe that the m vectors returned by Basis() contains the original n rows of the matrix?

@sideshow Your code attempts to solve the Poisson problem by mapping a semicircular domain into a rectangle through the usual Polar <-> Cartesian change of variables. You should know, however, that after such a mapping, the Laplacian operator is no longer u_rr + u_θθ. It changes to u_rr + (1/r) u_r + (1/r^2) u_θθ; see, e.g., Wikipedia.

If you want to push in that direction, you will have to change your finite difference scheme to handle this modified differential operator but I wouldn't advise it. The finite difference method works well for simple PDEs in simple domains. The finite element method was invented to handle more complex PDEs and geometries.

@sideshow The purpose of algo_12_1() is to solve a Poisson problem on a recangle [a,b]x[c,d], and the boundary condition g is expected to be the values of the solution along that rectangle's edges.  You can't use it to solve a problem on a semicircular domain.

The error message you are seeing arises because the procedure attempts to evaluate your g on the rectangle's boundary, but g returns unevaluated there, by design.

@Carl Love You are correct in focusing on the 10-digit software-float arithmetic versus hardware-float arithmetic.  The difference is of significance particularly in the sample problem solved (from the book) which sets TOL = 1e-10 for the stopping criterion, therefore necessitating higher than 10-digit precision to get meaningful results.

But that's not the only source of difficulty in OP's code.  There we have several stanzas of the type

if abs(w[i,m-1] - z) > NORM then
       NORM := abs(w[i,m-1] - z);
       w[i,m-1] := z;
 end if;

which should have been

if abs(w[i,m-1] - z) > NORM then
       NORM := abs(w[i,m-1] - z);
 end if;
 w[i,m-1] := z;

There may be other errors in that code, but as I noted earlier, I have not really attempted to debug it.