that you have an IVP, then you can control the number of solution points, and hence the number of terms in the PW output by using the maxstep option. For example if you range is 0..1, and you provide maxstep=10, your PW output *ought* to have 13 "regions". Two of these will be 'undefined' (ie outside range). Check the difference between

dsolve(MyOde, numeric, range=MyRange, method=rosenbrock, output=piecewise, maxstep=10)

dsolve(MyOde, numeric, range=MyRange, method=rosenbrock, output=piecewise, maxstep=20)

The number of steps you want will be specific for your ODE

Your ODE is trivially solved (with three unknown constants) by using

restart:
ode:=diff(y(x),x$3)+2*diff(y(x),x$2)-9*diff(y(x),x)-18*y(x)=18*x^2-18*x+22;
dsolve(ode);

Just try it!

In order to progress further some initial conditions would be useful!. After all you state that it is an IVP - so provide some 'IV'

Like Preben, I have no idea why you think something like

Digits := 18;
with(LinearAlgebra);
f := proc (n) -----;

derivative

g := proc (n)----- ;

is even vaguely relevant to anything. This is just pointless garbage

If you really want an *inaccurate* quadratic fit, rather than the accurate fit which Acer has provided, then try the attached.

The first half is Acer's original worksheet. The second half shows one way to fit a simple quadratic

poorFit.mw

p1 := plot(x, x=0..1, labels=[x*Unit('m'), y*Unit('m')]):
p2:=  plot(sqrt(x), x=0..1, labels=[x*Unit('m'), y*Unit('m')]):
plots:-display([p1,p2]);
plots:-display(<p1|p2>);

prints the axes-labels correctly in Maple 2017, but has the issue specifed by the OP in Maple 2016.

Obvious work-around is just to construct strings, which are processed correctly. So the following works in both Maple2016 and Maple2017

restart;
p1 := plot(x, x=0..1, labels=["x m", "y m"]):
p2:=  plot(sqrt(x), x=0..1, labels=["x m", "y m"]):
plots:-display([p1,p2]);
plots:-display(<p1|p2>);

Just because, I think that

1. Kitonum's response allows a '0' term within a factor, and does not verify that factors in the final list are relatively prime
2. John's response does not allow terms -9..-1 within a factor, and does not check that the gcd of terms within a factor is 1

So my answer is 'sort of' an amalgamation of the two previous ones

restart;
with(RandomTools):
with(Algebraic):
p:=[ $ -9..-1, $ 1..9]:
k:=1:
do
   a:=Generate(choose(p));
   b:=Generate(choose(p));
   if   igcd(a, b)=1
        #
        # Proceed only if a, b have no
        # common factor
        #
  then if   k=1
            #
            # Check that current candidate
            # is not a multiple of any
            # factor obtained previously
            #
       then L[k]:=a*x+b:
                k:=k+1:
       else if      { seq( Divide( L[j], a*x+b),
                                   j=1..numelems(L)
                                )
                        } = {false}
               then L[k]:=a*x+b:
                        k:=k+1:
               fi:
       fi:
  fi:
  if       k=5
        #
        # Bail out when I have enough factors
  then break
  fi:
od:
convert(L, list);

The attached is your code with

1. your timing commands commented out. I don't believe they are providing any useful information
2. the final execution group is now embedded within a CodeTools:-Usage() command, which provides information on "cputime" and "realtime"

Threads.mw

Now this code will still provide the output you want, but also provides some interesting statistics. Be careful. These are machine-dependent (your cpu, how much ram, clock speeds etc). So the following is a result for my machine - yours may differ (a lot?). The output of the CodeTools:Usage() command was

memory used=2.67GiB, alloc change=124.81MiB, cpu time=68.30s, real time=18.57s, gc time=5.16h

############################################################################################

In order to check whether you are getting any benefit from using multiple threads, the two important numbers to check are cpu time and real time. If you are running on one thread (and assuming that you don't have any other processes burning cpu in the background), then these two numbers ought to be (roughly) equal.

If you have some other process "eating" cpu, then it is perfectly possible that the cpu time will be way less than the real time. This is to be expected. After all if you are burning 75% of your cpu time installing the latest OS update, then you may have a relatively small cpu time on the Maple problem. But if, in  a real time of 100 secs, you are only getting 10 secs of cpu time for the Maple problem (cos your "game" is eating the rest of the cpu time) then the real time for the Maple problem could be waaaaay longer than the cpu time.

On the assumption that you aren't running any other significant cpu-eaters, then you are benefitting from a multi-threaded approach when the output of the CodeTools:Usage() command indicates that the real time is substantially reduced from the cpu time (as it is in the output I posted above).

Very (very!) roughly speaking, you can think of cpu time as real time * numberOfThreads. But you have to be wary of this - it is very much a best case, and will probably never be achieved. My machine has 8 threads, but in the example whose output is quoted above, the real time is only about 4X better than  cpu time. The reason is that there is an overhead in splitting the problem into threads and then reassembling the results of these threads. So you gain on the threaded calculations, but lose on the split/reassembly part - better be sure that the former is greater than the latter!!

There are other scenarios where going multi-threaded can actually cost you time. The obvious one is shortage of ram. It is perfectly possible that a single-threaed calcuation will run in say (4GB) of ram, but each of eight threads will require 4GB of ram - a total of 32GB, and if you only have 16GB on your machine then you are going to start using SSD/HDD storage and speeds will plummet and ypu would probaly be better off running single-threaded

I thing you just won 'bug of the week'!

1. The proc() 'Errors' only when when there are multiple readstat() statements.
2. The 'Error'  disappears if one puts a (pointless, but valid) command, eg lprint() immediately after each readstat()
3. But you can't use any 'pointless' command - replacing the pointless lprint() with the equally pointless whattype(), the Error reappears.

Ceck the attached

Download readProb.mw

You can specify the size of what you call the 'viewport' by using the 'size' option in any plot() command.

However (after some experimentation) it seems that the extent of the actual plot within the 'viewport' (set by the size command) is then fixed - ie it is automatically scaled to fit within the size you have specified as the 'viewport' - like maybe 95% of the viewport (in either dimension?). So don't imagine that youo can set the 'viewport' size, and then the size of the plot within the 'viewport'. It isn't going to happen!

Your ultimate objetive would seem to be to allow some space for 'annotation'. Genersaally this would be done using the textplot() command (probably with the typeset () option). This gives you just so many scales/sizes/variables to deal with, that I canno begin to cover them here. Have a seroius play with the atached, read the manual: work out the impications of such options as 'scaling=constrained' etc. Trust me it isn't simple!

plotStuff.mw

It is generally very bad practice in Maple to use names such as 'a[0]' and 'a' unless you expect these quantities to be related

If you define a[0]:=2 then you are (implicitly) creating a table named 'a' of which the zeroth entry is 2. If you subsequently define a:=.5 then you will change the name of the table to '0.5', so a[0] will become 0.5[0] - which I'm guessing you really do not want.

For your specific case the simplest solution is just to change references to a[0] to something harmless (and unrelated to the subsequent use of 'a') by usiing 'a0' or 'a__0', so either of the following will work

restart;
u := a0-12*sqrt(mu)*(1+lambda*sqrt(mu)*tan(A-sqrt(mu)*(x+y+4*mu*t)))/((a+b)*tan(A-sqrt(mu)*(x+y+4*mu*t)));
a0 := 2;
mu := 1.5;
lambda := 2;
a := .5;
b := .5;
A := 1.5;
y := 0;
plot3d([abs(u)], x = -3 .. 3, t = -3 .. 3);

or

restart;
u := a__0-12*sqrt(mu)*(1+lambda*sqrt(mu)*tan(A-sqrt(mu)*(x+y+4*mu*t)))/((a+b)*tan(A-sqrt(mu)*(x+y+4*mu*t)));
a__0 := 2;
mu := 1.5;
lambda := 2;
a := .5;
b := .5;
A := 1.5;
y := 0;
plot3d([abs(u)], x = -3 .. 3, t = -3 .. 3);

Use maximise() on your objective function to obtain the location/value of the desired point

Use pointplot() to plot a "blob" or sometrhing else at this point

Use display() to overlay your original plot and the output of pointplot() above

but this will work

   restart;
   with(LinearAlgebra):
#
# All of this just to provide a matrix with a few
# guaranteed zero rows and columns
#
   M:= RandomMatrix(10,10):
   M[2,..]:= Vector([seq( 0, j=1..op([1,1],M))]):
   M[5,..]:= Vector([seq( 0, j=1..op([1,1],M))]):
   M[7,..]:= Vector([seq( 0, j=1..op([1,1],M))]):
   M[..,3]:= Vector([seq( 0, j=1..op([1,2],M))]):
   M[..,4]:= Vector([seq( 0, j=1..op([1,2],M))]):
   M[..,6]:= Vector([seq( 0, j=1..op([1,2],M))]):
   M;
#
# Now eliminate zero rows
#
   M:= Matrix( <seq(`if`(convert(j, set)={0}, NULL, j), j in Row(M,1..op([1,1],M)))>):
#
# Now eliminate zero columns
#
   M:= Matrix([seq(`if`(convert(j, set)={0}, NULL, j), j in Column(M,1..op([1,2],M)))]);

In Maple 2017.2 it only seems to happen if you paste to a 2-D input region. If you paste to a 1-D input region, then it works

In Maple 2016.2 it doesn't matter whether you paste to a 1-D or 2-D input region.

Reason I stated earlier that I could not reproduce this problem, was that I was pasting to a 1-D input region in Maple2017.2

So far as I am aware, there is no Maple utility for comparing/highlighting difference between Maple files, whether these are .mpl, .mw,. .mla, whatever. SO give up on ths one

If one is talking .mpl files (pure text), then any 'serious' editor (emacs/notepad++?) will perform a diff() operation -(AFAIK notepad++ needs a plugin)

If one is talking .mw files, then these are XML (more or less) so again any 'serious' editor will allow you to perform a 'diff' operation

Without a 'serious' editor (and assuming Windows OS) - you could try using the FC command (from a command window). Just type "windows FC" into your search engine of preference. Depending on switches which you set, this will allow comparison between text files, binary files - whatever

Consider the command

M1 := Import(evalf[2]("E:/A_PhD2017/Export_TO_Maple1.xlsx", "Sheet1", "A2:U8"));

Now for the moment, just strip off the Import() part, which leaves

evalf[2]("E:/A_PhD2017/Export_TO_Maple1.xlsx", "Sheet1", "A2:U8")

From which it is fairly obvious that you are passing three arguments to evalf[2](). I assume that what you actually want is

with(ExcelTools):
M1 := evalf[2]~(Import("E:/A_PhD2017/Export_TO_Maple1.xlsx", "Sheet1", "A2:U8"));

Consider your third equation, ie

eq3 := diff(phi(z), z, z)-.35*diff(W(x), x, x);

Now Maple will interpret this as

eq3 := diff(phi(z), z, z)-.35*diff(W(x), x, x)=0;

which can be rearranged to produce

eq3 := diff(phi(z), z, z) = .35*diff(W(x), x, x);

Now think about this very carefully. The left-hand side is a function of the independent variable 'z' and the right-hand side is a function of the independent variable 'x', and yet these two functions in two different variables are always equal. This can only true if both sides of the this equation are equal to the same constant. (This argument is most commonly used when justifying the use of separation of variables in solving a PDE, but the principle is the same.) So far, no big deal, it jut means that this equation is equivalent to the pair of ODEs

eq3 := { diff(phi(z), z, z) = k

             .35*diff(W(x), x, x)=k

           };

which has the obvious pair of solutions

{  W(x) = (10/7)*k*x^2+_C1*x+_C2,
   phi(z) = (1/2)*k*z^2+_C3*z+_C4
}

Now the above is certainly true, but beyond this point, problems occur. Your boundary conditions on phi(z) are

phi(-(1/2)*h) = 0, phi(-(1/2)*h) = 2

In other words, by some miracle, the value of phi() with argument -h/2 is equal to two different things - I don't think so! This may be a simple typo - mabe one of the arguments is meant to be +h/2, rather -h/2. But as written, this is just downright wrong.

A second problem occurs when considering the solution obtained above for 'W(x)'. It is second order in the independent variable 'x', with three arbitray constants. The first difficulty occurs because any differential of W(x) or order higher than two will be identically zero. This means that several terms in your eq2 will be identically zero, since they contain differential terms of order 4 and 6, This may not be the behaviour you expect, but it is not mathematically incorrect. The area where you will have a mathematical difficuly is that W(x) contains only three undefined constants, and your list of boundary conditions on W(x) contains six conditions

W(0) = 0, W(L) = 0, (D@@1)(W)(0) = 0, (D@@1)(W)(L) = 0, (D@@2)(W)(0) = 0, (D@@2)(W)(L) = 0

You can only reasonably expect  to be able to use three of these - so maybe you better figure out which three!