@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?

I attempted to understand what it is that you aim to do but couldn't.  So far as I can see, you have a differential equation dg(x)/dt = f(x, g(x)), where f is given. You have boundary conditions g'(a)=0 and g'(b)=0, where a and b are unspecified.  What do you want to do then?

I have simplified your notation here, and I hope I have not changed the meaning.

You say "Im working on an assignment" and "Im supposed to implement", which is fine.  What do you have so far, and where do you need help?

Earl, I put together a tutorial on barycentric coordinates which may answer some of your questions.  Ask if other questions remain.  Here it is:  barycentric-coords-tutorial.mw

As to %T, that's Maple's notation for the transpose of a matrix or a vector.  Thus

u := < a, b >;

u^%T;

u^%T . u;

Carl: Ah yes, I was inattentive to the "otherwise" clause of the defintion.  Now the double-summation makes sense to me. 

I can't make sense of the math as it is presented.

To explain my confusion, let's forget about your problem for a moment.  Let's consider a real-valued function f defined on the interval [0,1] and another real-valued function g defined on the interval [5,6].  Question: What does the sum f(t) + g(t) mean?  Answer: The sum is meaningless—it makes no sense to add functions defined on different domains.

Now, going back to your problem, your functions b[n,m](t) are defined on generally non-overlapping subintervals, which leads to the question: What do you mean by that double-sum formula in your post?

To help others to help you, upload your worksheet.  Use the big green up-arrow that shows up in the window in which you type your response.

Since you have the result for one of the v values, what is preventing you from doing it for the other v values?

Consider uploading your worksheet so that people can see what you have done and what remains to be done.  To upload a worksheet, use the big green up-arrow that shows up in the window in which you type your response.

@I_Mariusz Your reaction is somewhat like saying a BMW coupe is not a powerful automobile because it can't do the job of a tank in a battlefiled.  Well, it can't, but that's not a good way to judge its usefulness.

@I_Mariusz Your equations are correct now, but unfortunately Maple is unable to solve them.

I haven't used Maple's PDE solvers at all, so I dug into the doucmentation to understand the cause.  So far as I was able to learn, Maple's numeric PDE solvers are not designed to solve elliptic PDEs.  Looking into MaplePrimes archives I found a few other requests for elliptic PDE solvers, and the respondants said that no such thing exists.

So I don't have a useful suggestion for you.  If I had to solve your problem, I would try one of the following:

1. Your domain is a rectangle, therefore implementing a finite difference scheme for a numerical solution should not be hard.
2. If I had more time and motivation, I would write a finite element scheme to solve the problem.
3. If I needed a solution immediately, I would use Comsol Multiphysics, but this would not be a useful option for you if you don't have access to Comsol.

@Ken_obi The title area is for the title of a message.  What you say should go in the body of the message, not in the title.

In particular, putting a link in the title doesn't do what you expect.