pdsolve is for partial differential equations.  This is a system of ordinary differential equations.  And pdsolve doesn't allow initial conditions (except for numerical solutions).  dsolve is the way to go. 

The following result is not very pleasant, but I have no reason to believe that it can be simplified very much.

> dsolve([op(sys),op(IC)]);
   simplify(%, size);

pdsolve is for partial differential equations.  This is a system of ordinary differential equations.  And pdsolve doesn't allow initial conditions (except for numerical solutions).  dsolve is the way to go. 

The following result is not very pleasant, but I have no reason to believe that it can be simplified very much.

> dsolve([op(sys),op(IC)]);
   simplify(%, size);

The system may look real, but if there are complex initial conditions the variables that have those initial conditions will be complex.
If your system is linear with real coefficients, there will be separate equations for real and imaginary parts of the variables.  If it is nonlinear, you'll have equations in which the real and imaginary parts will be coupled.

The system may look real, but if there are complex initial conditions the variables that have those initial conditions will be complex.
If your system is linear with real coefficients, there will be separate equations for real and imaginary parts of the variables.  If it is nonlinear, you'll have equations in which the real and imaginary parts will be coupled.

Why are not all loops by default converted to C ?

1) Because not everything is numerical computation.  Only a limited subset of Maple procedures can be successfully translated to C.
Moreover, it may not be possible to know in advance whether compiling will be suitable (e.g. the procedure might be called with parameters of different types, or results may produce an overflow in integer arithmetic).

2) Because the compiling is a lot of overhead, so it wouldn't be worthwhile for a procedure that won't be called very often.

On the other hand, in many cases the reason that later invocations are faster is that Maple is using a remember table, so the real work may only be done the first time.

It's best to avoid document mode and 2D input.  Set the defaults to Worksheet mode and "Maple Notation" input. 

In 1D input, varpi is `ϖ`.

To find this out, I did the following.

1) switch temporarily to 2D input with Ctrl-R.

2) click the symbol in the palette, press Enter.

3) At the next input prompt, enter

> lprint(%);

It's best to avoid document mode and 2D input.  Set the defaults to Worksheet mode and "Maple Notation" input. 

In 1D input, varpi is `ϖ`.

To find this out, I did the following.

1) switch temporarily to 2D input with Ctrl-R.

2) click the symbol in the palette, press Enter.

3) At the next input prompt, enter

> lprint(%);

The iterates of your new function x*x*x + r*x with starting point 1/2 go to infinity for r in the intervals you're using.

The iterates of your new function x*x*x + r*x with starting point 1/2 go to infinity for r in the intervals you're using.

It;s certainly a bug in MultiSeries:-limit.  I don't know where it comes from.  Particularly puzzling is the fact that MultiSeries:-series gets it almost right (there's a branch-cut problem, but the result is correct for h > 0).

> MultiSeries:-series(G(1-h^2), h, 3);

-1+sqrt(2)*sqrt(exp(1)*exp(-1))*h-(2/3)*exp(1)*exp(-1)*h^2+O(h^3)

I don't think that's right.  I think you're trying to solve a pair of equations for e1 and e2, helping fsolve by using initial values for e1 and e2.
You could e.g. do this:

>   fsolve({Total[force](e1,e2,As1,As2), Total[moment](e1,e2,As1,As2)},{e1 = -0.2e-2,e2=0});

{e1 = -.1421321716e-2, e2 = .5845397886e-3}

I don't think that's right.  I think you're trying to solve a pair of equations for e1 and e2, helping fsolve by using initial values for e1 and e2.
You could e.g. do this:

>   fsolve({Total[force](e1,e2,As1,As2), Total[moment](e1,e2,As1,As2)},{e1 = -0.2e-2,e2=0});

{e1 = -.1421321716e-2, e2 = .5845397886e-3}

An expression in Maple is in whatever format it is in.  The display is (hopefully) a faithful representation of the internal form.  It could be in the form

a + b*I 

or it could be

polar(r, theta).

You can convert from the first to the second using convert(..., polar), or from the second to the first using evalc. 
But to automatically display one when what you really have is the other would be horribly confusing, to my way of thinking.

An expression in Maple is in whatever format it is in.  The display is (hopefully) a faithful representation of the internal form.  It could be in the form

a + b*I 

or it could be

polar(r, theta).

You can convert from the first to the second using convert(..., polar), or from the second to the first using evalc. 
But to automatically display one when what you really have is the other would be horribly confusing, to my way of thinking.