@Bendesarts This most recent version of your equations still contains many of the syntax errors that were pointed out by Carl.  Pay attention!  Details matter!

After you have fixed those errors, you will find out that the graph produced by Maple is nowhere near what you have shown.  The reason is that there is a sign error in your eqz.  The plus sign in front of w should be a minus.

Here is the fixed version:

restart;
r := sqrt((x(t)/a)^2+(z(t)/b)^2);
eqx := diff(x(t),t)=alpha*(1-r^2)*x(t)+w*a/b*z(t);
eqz := you do it
params := alpha=1, beta=1, a=0.4, b=0.2, w=1;
EqSys := eval([eqx,eqz], [params]);
xmax := 0.5;  zmax := zmax; tmax := 8;
ic := [x(0)=0.5, z(0)=zmax], [x(0)=0.01, z(0)=0];           # see the note below
DEtools[DEplot](EqSys, [x(t),z(t)], t= 0..tmax, [ic],
    linecolor=black, thickness=1, stepsize=tmax/(3*48),
    x(t)=-xmax..xmax, z(t)=-zmax..zmax, scaling=constrained);

Note: To specify the initial conditions systematically, see my "Starbucks girl" post.

@Markiyan Hirnyk The value of x0 is immaterial.  In fact, just let x0 be 1:

z := x^2/(1 + (1-x^2)^2)^(3/2);

int(z, z=0..infinity);

simplify(%);

∞

This is in Maple 2015.1.

@nhungnhung 

restart;
with(Student[Calculus1]):
SurfaceOfRevolution(x^2+x-1, x=-3..1, axis=vertical,
    output=plot, transparency=0.4, axes=boxed);

"It does not work" does not tell me what it is that you see.  Can you be more specific about what goes wrong?

It would help if you explained what it is that you want to achieve with those calculations because as written, much of it makes no sense.

1. You define a function H and claim that it is constant.  How do you know that?  In fact, it isn't because omega is not constant.
2. You plot what appear to be orbits in the the q-p phase space, but they are not because omega is not constant.
3. You are calcuating the area under the supposed orbits.  Why do you need the area?
4. The meaning and significance of t* is unclear.
5. You should not assign to the letter I in Maple because I in Maple stands for sqrt(-1).

The main source of confusion is in treating a non-autonomous equation as if it were autonomous.  Some of the issues noted above arise due to that confusion.  The techniques you are attempting are not applicable to non-autonomous equations.

If you are not familiar with the terms autonomous and non-autonomous, you may safely think of an autonomous equation as one whose coefficients do not depend on time.  Your differential equation is non-autonomous since the coefficient omega depends on time.

@snowww Your "(now corrected)" version makes mathematical sense, however I don't trust it since it is dimensionally inconsistent.

The differential equation implies that F and K have dimensions of 1/x.  But if so, then the condition

    1 = C - F*dC/dx     at x=0

is dimensionally inconsistent.  I suspect that what you want is the dimensionally correct

    dC/dx = F*(C-1)     at x=0.

@snowww Boundary conditions specify conditions at boundaries.  What is x doing in DC(0)=F(C(x)-1)?

The expression F(C-1) in the boundary condition makes no sense.  Probably you meant something else.

@der Uwe I haven't used the VectorCalculus package but I would like learn about it.  As a practice problem I attempted to express the Navier-Stokes equations in cylindrical (not torroidal) coordinates in Maple but was unable to derive the well-known answer.  I would be interested in seeing how you did your calculations so that I may learn something from it.  Would you mind posting your worksheet?

@Robert Israel Thanks for confirming and reporting this bug.

@tomleslie You cannot compute dx/dt out of a numeric solution.  To see what goes wrong, look at the simple illustration:

restart;
de := diff(x(t),t) + x(t) = 0;
dsol := dsolve({de, x(0)=1}, numeric);
plots:-odeplot(dsol, [[t,x(t)], [t,diff(x(t),t)]],
    t=0..3, color=[red,blue], thickness=3);

@Markiyan Hirnyk I just added a note in the web page that you have referred to. The term (V . Nabla)~(V)) that occurs in the Navier-Stokes equations on that page is calculated incorrectly in Maple.  I have zero experience with the VectorCalculus package, so I can't tell whether this is a bug or a "feature" associated with Nabla.  In any case, the usual formula for the Navier-Stokes equations needs to be adjusted to account for Maple's unexpected behavior.

Robert, I stumbled upon this post from long ago because there was a recent reference to it on MaplePrimes.

The term (V . Nabla)~(V)) that appears in the Navier-Stokes equation in your post is not calculated correctly in Maple—none of the denominators, that is, sqrt(v1^2 + v2^2 + v3^2), should be there.  See the attached worksheet:

mw.mw

Maple 16 and Maple 2015 both give the same wrong results.  Perhaps Maple has a different interpretation of the Nabla operator than what is commonly understood in mathematics.  If so, the expression for the Navier-Stokes equations in your post need to be adjusted accordingly.

@Earl Glad to hear that you found the information useful.  As to your question about polygons, the answer is no—within planar shapes, barycentric coordinates are specific to triangles.  As Carl has pointed out, however, you may subdivide a polygon into triangles and apply barycentric coordinates to each triangle.

Aside: Barycentric coordinates do generalize to n-dimensional simplexes.  For example, the interior of an ordinary tetrahedron may be parametrized by four barycentric coordinates λ₁ through λ₄.

I  suppose that by

    "m (lambda_high) and n (lambda_low) are given"

you mean that

    "m and n are given".

I have no idea how to go about solving this problem.  Perhaps the proof that you have aluded to contains clues?