Example
You have

ode1a := diff(a(t), t) = 1.342398800*10^5*a(t)+round(89591.20000)*b(t)+round(44647.44000)*c(t);

and want to solve

ode1a=exp(t)

so that would be

diff(a(t), t) = 1.342398800*10^5*a(t)+round(89591.20000)*b(t)+round(44647.44000)*c(t)=exp(t)

which is not an equation

at least with your boundary conditiions. if you try

restart;
ode1a := diff(y1(tt), tt) = 1.342398800*10^5*y1(tt)+89591.20000*y2(tt)+44647.44000*y3(tt);
ode2a := diff(y2(tt), tt) = 89591.20000*y1(tt)+89803.24000*y2(tt)+44901.60000*y3(tt);
ode3a := diff(y3(tt), tt) = 44647.44000*y1(tt)+44901.60000*y2(tt)+44859.24000*y3(tt);
dsolve([ode1a, ode2a, ode3a,y1(0) = 0, y2(0) = 0, y3(0) = 0]);

You will get {y1(tt) = 0, y2(tt) = 0, y3(tt) = 0}. Difficult to make an interesting plot with these functions!

The Crank-Nicolson method is an approach for the numerical solution of PDEs. This mehtod can be invoked in Maple by the command

pdsolve(PDE2, someOtherOptions,method=CrankNicholson);

However since your post does not even contain a PDE, I am at a loss trying to figure out what you are trying to achieve. Maybe you want to poduce your own version of the Crank-Nicolson method, rther than using the one which is built in to Maple?

In any case,I think that  the code which you do provide contains a number of problems. Check out my (highlighted) observations in the following. (Absolutely none of which have anything at all to do with the Crank-Nicolson method)

CK.mw

Kitonoum has shown how you can use the 'view' option to force the case where you want the axes (note not axis!!!) to extend over a greater spatial extent than the plot.

However (AFAIK) there is no way to force the axes to extend over a lesser spatial extent than the plot itself. So for example, if your plot extends from x=-5..5, y=-5..5, z=-5..5, but you only want axes from x=0..5, y=0..5, z=0..5, basically no way using built-in plot options.

However it is of course possible to define any 'lines' one wants with the plottools:-line() command, and any text one wants with the plots:-textplot3d() command - so one can essentially construct 'lines' and 'text' in arbitrary locations.

The probelm with this approach is "generalsing" it. This would probably involve writing moe-or-less a whole new plot inteface, whihc I have no intention of doing. On the other hand if the objective is to "prettify" one or two well-defined plots, then (with a bit of trial and error), some variation(s) on the following "toy example" could probably be made to work

l1:=plottools:-line([0,0,0],[5,0,0], color=red):
l2:=plottools:-line([-5,0,0],[0,0,0], color=blue):
l3:=plottools:-line([0,0,0],[0,5,0], color=red):
l4:=plottools:-line([0,-5,0],[0,0,0], color=blue):
l5:=plottools:-line([0,0,0],[0,0,5], color=red):
l6:=plottools:-line([0,0,0],[0,0,-5], color=blue):
t1:=plots:-textplot3d([[2,0,0,"2.0"], [3, 0, -1, "x"], [4,0,0,"4.0"]], align=below):
t2:=plots:-textplot3d([[0,2,0,"2.0"], [0, 3, -1, "y"], [0,4,0,"4.0"]], align=below):
t3:=plots:-textplot3d([[0,0,2,"2.0"], [-1, 0, 3, "z"], [0,0,4,"4.0"]], align=left):
p1:=plot3d( 3*sin(x)*cos(y), x=-4..4, y=-4..4, color=green, style=surface, transparency=0.5):
plots:-display( [l1,l2,l3,l4,l5,l6, t1, t2, t3, p1], axes=none);

As preben as pointed out, you have an equation. S the bext you can probably do is plot f, against Vx. However for many values of f, Vx is complex - and when Vx is not complext it doesn't *seem* to vary very much.

Consider

fsolve( eval(f1, f=100), complex);
fsolve( eval(f1, f=1000), complex);
fsolve( eval(f1, f=2000), complex);
fsolve( eval(f1, f=3000), complex);
fsolve( eval(f1, f=5000), complex);
fsolve( eval(f1, f=10000), complex);
fsolve( eval(f1, f=100000), complex);

which returns

 -1.291858535*10^6+5.348253556*10^(-9)*I,
 -1.291943497*10^6+4.670677819*10^(-8)*I,
 -1.292201081*10^6,
 -1.292630800*10^6,
 -1.294009375*10^6,
 -1.300542931*10^6,
  -2.228453937*10^(-14)+990104.5664*I

Since you do not provide any sort of matrix export comman it is a little difficult to be specific.

However your matrix is defined in terms of integers, and 'known' constants such as 'e' and 'Pi'. Maple will not evaulte expressions in these quantities to 'numeric' (ie floating point values) unless forced to do so. Such numeric values can be obtained with the addition of a simple evalf() wrapper in your seq command as in the attached

Download exportProb.mw

Note that this still doesnot 'export' anything. It simply produces a matrix whihc standard export methods such as ExportMatrix() now *ought* to be handle in the form you desire

As a side observation, your original worksheet uses the term matrix() rather than Matrix(), The former has been depreated for a very long time. Unless you are using a really old version of Maple, I suggest you avoide using deprectaed functions

If you can accept (as Markiyan has pointed out) that the only solution to first equation ie,

POL[0] := .42810/(.65429+c[-2]) ;

which will be interpreted by Maple as

.42810/(.65429+c[-2]) =0

is c[-2]) =+/-infinity. Then most of your difficulties go away. It is trivial to solve the rest of you equations given that c[-2]=infinity.

However, without this observation, all that really happens in the DirectSearch() solution process is that

1. The square-sum residual isn't very good.
2. The square-sum residual gets better as the number of allowed function evaluations is increased.The values of c[-1], c[0], c[1] don't vary very much.
3. As the allowed number of function evaluations increases, the obtained value for c[-2] increases - as it heads for infinity!

See the attached

Download numsols.mw

In your command

The problem arise when I define theta below
> theta := at(f(y)-(1/2)*Pi, diff(f(y), y));

I suspect that the problem is that f(y), and diff(f(y),y) are quantities in the solution (nans?) of some ODE. Tricky to be specific, becuase you do not provide 'nans' or the ode(system?) which gives rise to it. If 'nans' is analytic solution to an ODE, then this will probbaly be some kind of list/set, of which f(y) will be an entry, so should be accessed somthing like rhs(nans[2])

If nans is a numeric solution of an ODE(system?) for which f(y) is one of the returned functions - then again some kind of appropriately structured call to nans() will be necessary in order to obtain f(y)

Easiest way to solve this problem is if your provide the ODE system, and the dsolve() command which your are using so that the form of the solution in 'nans' becomes obvious. Given that I'm pretty sure all subsequent calculations can be done

Does the 'vector' to be defined have some geometrical significance, or is the word 'vector' here being used as shorthand for a 1-D container? Both are equally valid - but the optimal definition may depend on what you are going to do with this entity. Consider the distinctions between

p:=[3,6,-1]:
 q:=[4,-2,2]:
 V0:=Vector(p-q);
 VectorCalculus:-About(V0);
 V1:= VectorCalculus:-Vector(p-q);
 VectorCalculus:-About(V1);
 V2:= VectorCalculus:-PositionVector(p-q);
 VectorCalculus:-About(V2);
 V3:= VectorCalculus:-RootedVector(root=p, q);
 VectorCalculus:-About(V3);

that the 'best' method is to generate plot(s) and then extract data from the plot(s). The functions being plotted can be expressed as quantitities depending on the variable 't' and the number of terms in the summations. These functions can be computed for any combinations of these values, and tables(matrices) of the results can be computed.

See the final two execution groups in the attached

numData.mw

The reason that fsolve() returns unevaluated is either

1. No solution exists
2. A solution exists but fsolve() cannot find it

In addition to trying fsolve(), I also tried the DirectSearch:-SolveEquations() command. This is somewhat more 'flexible' than fsolve(), in that it ptoduces the 'best' solution it can find, even if that solution is not very good.The solution provided by DirectSearch() had rather high 'residuals' - indicating that the located solution was a bit rubbish.

To me, this suggests that there is no 'exact' solution for your system of equations

With the definitions you have provided, it seems that x(t) is entirely arbitrary (although I think it has to be differentiable).

This doesn't seem to get you very far|??.

But in any case check out the attached, and try to work out what I might be doing wrong, or (more likely), where you have incorrectly specified the problem

odeSys.mw

perhaps depending on how old your Maple installation is.the linalg[diag] command has been deprecated since Maple6. A 'diag' command still exists within the current MTM package (and works). ALthough as Kitonum has already siad the recommended way would be to use the LinearAlgebra:-Diagonal command.

The attached shows all three options, for a "toy" symbolicc matrix

Download matDiag.mw

on the size of the monitor and the display rersolution. My default for running Maple(and everything else)  is a 27-inch monitor with a native resolution of 2560 by 1440 and in terms of readability, this is acceptable (and my eyes are old!!!). The only thing I change for Maple is on the interface settings where I check the box at Tools->Interface->Large Toolbar Icons.

Now I still had some font size issues with these settings. My pet hate was that text in the Maple debugger was too small and could not be resized by any known means. This particular issue was fixed in either Maple 2017.1 or Maple 2017.2 (can't remember which, but probably the latter). I didn't observe any other font size problems being fixed at the same time (but they might have been).

The basic problem for software user interfaces (including Maple) is that many fonts/menuStuff etc was defined to be a fixed number of pixels. So as the display resolution goes up, the apparent  'size'' of these fonts goes down. This problem is made worse increased use of laptops with smaller screens. A pixel, on a 15-inch laptop screen with 2560x1440 resolution is a lot smaller than a pixel on 27-inch monitor running at the same resolution - so any text (in menus, whatever) will be correspondingly smaller

The obvious solution for this problem is that 'important text' (menus whatever) should be defined in terms of 'fractionOfScreenSize' rather than absolute pixels. However, historically, most user interfaces were not written that way - absolute pixels were used. So many software packages which did not anticipate the arrival of small (ie laptop), high-resolution monitors, now have visibility problems. This is not just a Maple issue - it applies to several other packages I use (eg Matlab)

Until softwre providers get ther act together and write user interfaces in terms of percentageOfScreenSize rather than absolute pixels, there is no good answer to the readability problem. The best I can suggest is to decrease the display resolution. On a Windows OS, this can be achieved by a right-click on the desktop, select 'screen resolution', then decrease it. Each decrease in screen resolution will cuase a corresponding increase in displayed font sizes. One possible drawback with this approach is that resulting fonts may look a litlle 'blurry' :-(