I don't believe there is a way to use more than one core; dsolve/numeric is not designed to be multi-threaded.

Have you tried using a different solver, say rosenbrock? 

Pagan's suggestion is probably what you want.  However, if you happen to be sorting a large list, a faster approach is to sort with attributes. For example,

 map(attributes,sort([seq(setattribute(evalf(x),x),x in a)]));
                          1/2   1/2     1/2    1/2    1/2
                       [-5   , 2   , 2 2   , 26   , 39   ]

Here is a simple procedure that converts a Vector to a tilde matrix:

tilde := proc(V :: Vector)
local T;
    T := Matrix(3, 'shape=skewsymmetric'):
    T[3,2] := V[1];
    T[1,3] := V[2];
    T[2,1] := V[3];
    return T;
end proc:

V := <x,y,z>:
tilde(V);
                                            [0     -z    y ]
                                            [              ]
                                            [z     0     -x]
                                            [              ]
                                            [-y    x     0 ]

Because H(z) is not defined, I don't see how you can get a numerical solution.

If that is all you want to do, a fairly simple way is to the following one-liner:

plots:-display(seq(plot(2*x+i/2,x),i=0..10));

To do this with a loop, you should save each plot in a table and then make a call to display to plot them at once.

for i from 0 to 10 do
     y := i/2;
     f := 2*x + y;
    P[i] :=  plot( f, x, color=black);
end do:
plots:-display(seq(P[i], i=0 .. 10));

The  custom component generates one positive pulse of a sinewave with frequency 200 and amplitude 235.  One way to generate the same signal without a custom component is to multiply the output of a sinewave with a step function that transitions from 1 to 0 after a half period of the sine wave.

The most likely problem is that the number of lines in the file is not what you expect. Change your code to

N := iquo(nops(Data),3);
Data := convert(Data,Array);

Also, rather than using the deprecated array structures, and later converting to Vectors, just initially assign them as Vectors:

coords_x := Vector(1..N):
coords_y := Vector(1..N):
Ex := Vector(1..N):
Ey := Vector(1..N):
Ez := Vector(1..N):

and remove the final conversions.  Here's the code I used:

restart:
with(plots):
file := fopen("900MHz.dat",READ):
Data := readdata(file,7):
N := iquo(nops(Data),3);
Data := convert(Data,Array);

coords_x := Vector(1..N):
coords_y := Vector(1..N):
Ex := Vector(1..N):
Ey := Vector(1..N):
Ez := Vector(1..N):
t := 1:
for i to N do
    coords_x[i] := Data[t,1]:
    coords_y[i] := Data[t,2]:
    Ex[i] := Data[t,6]:
    Ey[i] := Data[t + 1,6]:
    Ez[i] := Data[t + 2,6]:
    t := t + 3:
end do:
field := Vector(1..N):
for i from 1 to N do
    field[i] := sqrt(Ex[i]^2 + Ey[i]^2 + Ez[i]^2):
end do:
pointplot3d(coords_x, coords_y, field, 'axes=normal, title="Near field plot"');

Trying simplifying the problem and then comparing with a known result.  For example, remove the losses from the end, so the boundary conditions are 

IBC := {NULL
        , -lambda*(D[1](T))(L, t) = 0
        , T(0, t) = 1573
        , T(x, 0) = T0
       };

The time-constant of the model is rho*cp/lambda*L^2 ~ 12 hours.  A distributed RC model should reach about 90% of the input step after one time-constant.  Here pdsolve gives 88.6%.  So that seems to be working.  You should check that against your Matlab/FEA simulations.

?DynamicSystems[Linearize] returns a sequence of four expressions.  The first expression is what you want.  In the first example, you can access the state-space matrix a by doing, say, linm[1]:-a;
 

It sounds to me that an rtable (Vector or one-dimension Array) is what you want, not an expression sequence.  The reason being, an rtable is mutuable.  That is, you can change an element of it. An expression sequence (and associated constructs lists and sets) is not mutuable.  That is, to record a change to an element of an expression sequence, a new data structure has to be created.

One approach is to use ?frontend.  For example,

(**) z := y^2*diff(y(x),x)^3;         
                                    2 /d      \3
                              z := y  |-- y(x)|
                                      \dx     /

(**) frontend(diff, [z,diff(y(x),x)]);
                                   2 /d      \2
                                3 y  |-- y(x)|
                                     \dx     /

Here is a post describing some of the subtleties of using frontend.

Maybe the easiest is

y := 3/8*2^(1/3)*k^(4/3): 
eval(y, k = sqrt(k^2));
                                   1/3   2 2/3
                                3 2    (k )
                                --------------
                                      8

See Acer's recent post, which is really about that procedure and its effect on the speed of some computations.

John's solution is interesting, but I wouldn't want a worksheet to mess with my initialization file. There is another way to do what you want, however, as with most things, it is easy to do in linux, and a bit more challenging in Windows. 

If you launch the Maple gui from the command line, you can use the -c option to assign a command that the Maple engine executes when it starts up, and reexecutes following a restart.  So if you wanted to load a package few packages you could do (in linux)

$ maple -x -c 'with(plots)' -c 'with(LinearAlgebra)'

The -x option says to launch the gui, each -c option defines a command that is executed. For a more complicated sequence of commands, you could put them into a text file, say restart.mpl, and then do

$ maple -x -c 'read("restart.mpl")'

The Maple commands in restart.mpl will be read and executed at startup and following each restart.

Getting this to work in Windows is doable, I believe, though I don't use Windows so cannot verify.

The time is not spent in the Maple kernel. The length of the returned message is 25 kB.  On my machine I monitored the network speed while executing X1, it was receiving at 25 kB/sec, so was taking approximately 1 second per call, which matched precisely with how long it took.

One possibility is that google only serves an individual request so fast. To partially test this, I created a small shell script that calls the Maple script, each executing X1 10 times.  I then ran 8 of those scripts in parallel.  The total time required is the same as it takes to run one script.  That indicates that the bottleneck isn't the network (not surprising, I can download considerably faster than 25 kB/s).