The usual Euler-Bernoulli differential equation for deflection of a beam would involve the fourth derivative of the deflection, not the second.  See e.g. en.wikipedia.org/wiki/Euler-Bernoulli_Beam_EquationThis would allow your four boundary conditions.

It looks like n has not been assigned a value.

It looks like n has not been assigned a value.

... but there may be some subtleties.  Ordinarily, a sum of squares should always be nonnegative, even taking rounding error into account.  But if the squares get expanded, roundoff error could make the result negative.  For example:

> A := (.9057919371*x-.1269868163*y)^2;
  eval(A, {x = .1159866921,y = .8273284860});

0.

However:

> B:= expand(A);
  eval(B, {x = .1159866921,y = .8273284860});

-.1e-10

I don't get a crash under Windows Vista, either in Maple 12.02 or Maple 13.01.  It just returns NULL.

Actually, it's a Vector, not a vector.  To keep K as a Vector of the same type, but set all entries to 0, try

> ArrayTools[Fill](0, K);

Actually, it's a Vector, not a vector.  To keep K as a Vector of the same type, but set all entries to 0, try

> ArrayTools[Fill](0, K);

But see this in the help page ?multithreaded:

Limitations
Multithreaded programming is more complex than single-threaded programming.  In addition, code that is written in a single-threaded environment is often not safe to run in a multithreaded environment.  At this point, most of the Maple library is not safe to be used when multiple threads are executing.  The Maple kernel is thread-safe, so any operation that is implemented in the kernel should be safe to run in the multithreaded mode. Maple 13 is an early release of the multithreaded mode.  As such, it has not been fully optimized.  This means the multithreaded mode can be slower than the single-threaded mode.  This, combined with the Maple library limitations, means that the multithreaded mode is not really appropriate for general usage
 

You might try the Task Programming Model (see ?TaskProgrammingModel).  On my computer (Core 2 Duo P8400 under Windows Vista) the Task-based example of adding integers 1 to 10^8 took about 21 seconds (by stopwatch) while add(i,i=1..10^8) took about 31.

But see this in the help page ?multithreaded:

Limitations
Multithreaded programming is more complex than single-threaded programming.  In addition, code that is written in a single-threaded environment is often not safe to run in a multithreaded environment.  At this point, most of the Maple library is not safe to be used when multiple threads are executing.  The Maple kernel is thread-safe, so any operation that is implemented in the kernel should be safe to run in the multithreaded mode. Maple 13 is an early release of the multithreaded mode.  As such, it has not been fully optimized.  This means the multithreaded mode can be slower than the single-threaded mode.  This, combined with the Maple library limitations, means that the multithreaded mode is not really appropriate for general usage
 

You might try the Task Programming Model (see ?TaskProgrammingModel).  On my computer (Core 2 Duo P8400 under Windows Vista) the Task-based example of adding integers 1 to 10^8 took about 21 seconds (by stopwatch) while add(i,i=1..10^8) took about 31.

I don't see why isolve shouldn't be able to handle a quadratic forms in two variables.  But it seems like it can't.  Pell-type equations (involving x^2 and y^2) with no x*y term seem to be ok.  But with an x*y term, isolve can't handle them, even though the standard "completing the square" trick should work.   

It's not necessary to create the directory: I'm just assuming you want to put the file into some directory somewhere (probably one that you already have).

In this case there's no reason to extract the data from a plot, especially since plot (as opposed to plot3d) does not divide the interval into equal subintervals.  You can do something like this:

> outfile := "c:/tmp/myfile.csv":
   for i from 350 to 1500 do
      fprintf(outfile, "%d,%f\n", i, n(i)); 
   end do:
   close(outfile);

The resulting .csv (comma-separated values) file should be readable by any version of Excel (or any other modern spreadsheet, for that matter)..

It's not necessary to create the directory: I'm just assuming you want to put the file into some directory somewhere (probably one that you already have).

In this case there's no reason to extract the data from a plot, especially since plot (as opposed to plot3d) does not divide the interval into equal subintervals.  You can do something like this:

> outfile := "c:/tmp/myfile.csv":
   for i from 350 to 1500 do
      fprintf(outfile, "%d,%f\n", i, n(i)); 
   end do:
   close(outfile);

The resulting .csv (comma-separated values) file should be readable by any version of Excel (or any other modern spreadsheet, for that matter)..

Also interesting is the fact that the copy-and-paste into 1D input loses the n=0 and infinity.

The first problem is that you're not giving it the file name properly.  You had

Q := Import("<C:\MOSES CANADA\Boyer\Civil\Steel_column>", "CSA_W.xls", "A5:AJ281");

which presumably should be something like

Q := Import("C:/MOSES CANADA/Boyer/Civil/Steel_column/CSA_W.xls", "W", "A5:AJ281");

But in this case there still seem to be problems.  I was able to save a copy of the "W" sheet in a separate .xls file and Import it from there.

The first problem is that you're not giving it the file name properly.  You had

Q := Import("<C:\MOSES CANADA\Boyer\Civil\Steel_column>", "CSA_W.xls", "A5:AJ281");

which presumably should be something like

Q := Import("C:/MOSES CANADA/Boyer/Civil/Steel_column/CSA_W.xls", "W", "A5:AJ281");

But in this case there still seem to be problems.  I was able to save a copy of the "W" sheet in a separate .xls file and Import it from there.