@jefryyhalim 

Suppose your ode has an independent variable x and a dependent y(x).
When you write ic or bc (see the dsolve help page), you write them on the form (here is a notional example) y(0) = 0, D(y)(0)=0, (D@@2)(y)=0, and so on.
The meaning of y(0) is obvious.
If you want to impose an initial condition on the first derivative of y(x) at point x=1 you write D(y)(0) = something.
Imposing an initial condition on the derivative or order 2 at point x=1 writes  (D@@2)(y)=0.
Here (D@@2) means "differentiation operator D applied twice", this is the equivalent to the mathematical notation (D o D).
...

-----------------------------------

If I'm not mistaken the 5 ode u-in the "Longitudibal Behaviour" section are homogeneous (no source term). and form an autonomous system.
More than this your boundary conditions are of the type (here F is any of your 5 unknowns)

F(0) = 0, F(L) = 0, (D@@2)(F)(0)=0, (D@@2)(F)(L)=0

There are homogenous too.

Then a trivial solution is F = 0 where F  is any of your 5 unknowns.

Can you verify that ?

Line 4 : 
np:=2:

Vup1(x) (for instance) is one of your unknown functions defined by an ODE system.
You write  eq3:=subs(x=0,Vup1(x))=0: , why not simply  eq3:=Vup1(0)=0: (which seems to be a boundary/initial condition about Vup1 ... cf Rouben's reply)  
The same observation applies to all the other unknown functions:  eq1, ...eq21 are bc/ic (with the blue like expression given above .. .cf Rouben again) .
Then yourODE system is not {deq||(2..6)} but {deq||(2..6)} union {eq||(1..21)}
This will remove (if the solution exists and it's found) those integration constants _C1, _C2, ...

What I suggest  is that you define the equations eq1, ..eq21 BEFORE executing dsolve
The correct syntax should be 
eq2 := Eup*Ixxup1*(D@@2)(Vup1)(0) = 0;
eq3 := Vup1(0) = 0;
eq4 := Eup*Ixxup1*(D@@2)(Vup1)(L) = 0;
eq5 := Vup1(L) = 0;
eq6 := Ep1*Ixxp1*(D@@2)(Vp1)(0) = 0;
(sorry, I don(t have the time to go further on)

Once this done, execute 
sol_L:=evalf(value(dsolve({deq||(2..6)} union {eq||(1..21)} , {Vup1(x),Vp1(x),Vp2(x),Vlp1(x),Vlp2(x)})));

I think you will have a more reliable basis to understand what happens in your code.

@Carl Love 

I have a translation problem and I'm not sure to understand correctly "Twice differentiable with finitely many inflection points on its support."

Does it mean "Twice differentiable excepted on a numerable set of points" ?

Generally it's better to speak in terms of distribution function (the cdf) than in terms of pdf because the pdf doesn't always exist.
For it exists the cdf (or the associated RV) must be absolutly contnuous.
The cdf of very discrete distribution is infinitely differentiable out of a countable set of points (so "would be the pdf") but the pdf doesn't exist (that is why we speak of mass function instead, even Maple is less rigourous on this point and has no hesitition to return the pdf of a Bernoulli RV) 


see for instance  https://utd.edu/~metin/Probability/Folios/continuousRandomVariables.pdf

One draw a sample from a distribution, not from a function (that's the meaning Carl Love's answer)
Sampling a function is not the same thing: mehdi jafari proposed a solution, a simpler one is the regular sampling (that's what a digitalizer does) of a time signal for instance.

I think your question would require some precisions to receive the "correct" answer (as Tomleslie implicitely suggested)

It's probably better "to say thank" once the job is done.
Not that I'm waiting after that to be happy, but I think I've lost my time with you.

By the way: the scheme is order one, meaning not better than a classical forward Euler, and significantly worse than a simple Runge-Kutta scheme of order 2.

Hi, 

You're right, some leading terms have a coefficient <> 1:

seq(print(u), u in LeadingTerm(GBs, plex(x[1], x[2], x[3], ya[0], ya[1], ya[2], yd[0], yd[1], yd[2])))

This also happens for other orders (grles and tdeg at least, I didn't verify for the others).

The command showstat(Basis) displays the corresponding code. But it is far too complex to me to understand if it does the reduction step.
The default option is the Buchberger's algorithm which, per se, doesn't produce a reduced Groebner Basis. Generally the reduction step is an "extra" operation. My guess is that Basis (with option Buchberger) never delivers a reduced GB and that you obtaining a reduced GB in your previous post was just accidental.

I think it would be interesting to look at what the other algorithms implemented in "Basis" (fgb, maplef4, ...) produce
 

NewtonLagrange2.mw

The plot is disabled (the file takes 8.8 Mo with the plot)

@Carl Love 

Carl, here is a screen capture of the alert window I get with Maple 2015.2 (2D Input)
ScreenCapture.pdf

This is a simple info: I repeat I never use this mode.

@Carl Love 


What the OP has written is correct when used in 2D Input :
Not in Maple 2015.2

The text in the pop-ip window says "some parts of the expression are ambiguous, please correct them according to one of the suggested possibilities.

My mystake was that 0<=r<=R was not correct in 2D input too
In fact V(r) := ... is not correct in Maple 2015.2

Once modified as V := r -> piecewise(0<=r<=R, ...) the syntax becomes right

@Carl Love 

I didn't know.

In fact I have decided a few years ago to  abandon this 2D input mode.
The reasons: at my office, maybe due to a poor installation, this mode is "unstable" and very slow.

"Unstable" means, for example, that sometimes a character in normal font becomes italic. It happens for instance when you suppress a character and replace it by another one and the result is dramatic.

For instance, if I've written ab := 23 instead of ac := 23 and if I correct this typo error, the result sometimes appears as
ac := 23 (italic c) and further down the page something like if ac > 1 then ... returns an error which means that Maple doesn't know ac (because it knows ac !)
If I open a terminal window (Windows) or if I've ran  Maple in background (Linux), I get an incredible lenghty warnong messages coming from Java. 
Let me say that a friend of mine, teaching in a university, faces the same problems and advices to her students to use the "old fashioned Maple input mode.

Why did I say "Slow": because if you have a rather long document in 2D input mode, in which you want to replace all occurences of some text by another one, or just find for some string, the process takes a lot of time. 

I don't blame Maple here.
Years ago people from MapleSoft came into our company and I evoked this problem.
The answer was something like "You have to use the Java version recommanded for your Maple version".
Easy to say if you work with your own laptop but verry difficult to realize if thousands of people in your company use applications invoking Java: ahving a Java version dedicated to Maple becomes impossible.

Nevertheless, thanks for the info
 

@radaar 

1-------------------
How to define a "function" (an "arrow procedure")
function.mw

See also the help pages
help(function)
help(operators,functional)

What you have done is just to say that there exists some function V which, for a value "r" of its argument, takes a value piecewise(0<=r<=R,-VV,r>R,0).
It is strictly equivalent to define a variable V equal to this same value.
But this is not, strictly speaking, the definition of a function.
In your case it works because you use V(r) in your ode.
But suppose you relace r by z in this ode: this will non longer work because V(z) (= the value of function V at point z) is not defined

2-------------------
Look to the attached file: you will see that the assignment
v := r -> piecewise(0<=r<=R,-VV,r>R,0);

is not correct (Maple 2015 at least, read again my previous answer)
With Maple 2015 (I will be able to test on later versions tomorrow) the correct syntax is 
v := r -> piecewise(0<=r and r<=R,-VV,r>R,0):
Piecewise.mw

In the attached file you will see (yellow highlighted text) 3 screen captures of sol_L (plus the one of the output) obtained by executing the code four times (click on the !!! button)

All these four solutions seem to be the same.

What are exactly the ouputs thar differ from one run to the next one? 

SP1JH7reply.mw

@Preben Alsholm 

Right, I didn't pay attention to that

@Preben Alsholm 

I think it's more a problem linked to the way Maple handles the piecewise function than a problem of dsolve.
Look to this:

restart;
ode:=diff(x(t),t)=`if`(t=1, 0, x(t));
sol:=dsolve({ode,x(0)=1});
odetest(sol,ode);
plot(rhs(sol),t=0..2,caption="The symbolic solution is right");

@Preben Alsholm 

restart;
gap := proc(t) 
 if t=1 then 0 else 1 end if:
end proc;

proc(t)  ...  end;
ode:=diff(x(t),t)=x(t)*gap(t);
sol:=dsolve({ode,x(0)=1}, x(t));
plot(limit(rhs(sol), epsilon=0), t=0..2);