@Earl  Page 212 of that book reduces the solution of the problem to solving a system of differential equations for the unknown functions r(m*) and F(m*)  [ equations (3) and (4) ]  subject to the boundary conditions in (2).

The rest of that page muddles things up by attempting to establish an analogy with harmonic oscillations.  The analogy is quite confusing since there is no time-dependence in this problem—we are looking at the steady-state rotation of a stretched spring (unvarying length) about an axis.  There is not much to animate here.

Here I will show how to solve the equations noted above in Maple.  The note at the top of page 213 does the same thing, therefore the confusion of page 212 was not necessary at all.
 

Download mw.mw

@imparter I know that alpha is a parameter that you want to vary.  The problem is, the code that you have shown has a few dozen of ohter symbols whose meanings are known only to you and the author of the book that you are reading.  I can only guess what those symbols mean.  In fact, I can only guess what the code is attempting to solve because you have not even provided me with the mathematical statement of the problem.

That said, I have made a best effort to guess what you have in mind and have produced this worksheet:  fixed-alpha.m which plots the solution curve at t=0.2 as you have asked, but for alpha=1 only.

To plot the curve for other values of alpha you have two choices:

Choice #1. Copy and paste the entire code (but not the "restart" line) in the worksheet (thus doubling the number of lines in the worksheet).  Set the value of alpha in the second half, execute the entire worksheet.  Then you will have two graphs, the original one (with alpha=1) and the second one with whatever value of alpha you want. 

Copy/paste some more to produce additional graphs with other choices of alpha.  Then you may produce a composite graph by applyting plots:-display.

Choice #2. Instead of copying/pasting, you may wrap the entire code in a proc which takes alpha as a parameter.  Then you may execute that proc any number of times with the desired values of alpha.  This second approach is the right way of doing it but it needs some elementary knowledge of Maple programming.  I cannot tell how much of Maple programming you know.  If you don't, then go with Choice #1.

@imparter The plot the curves based on the code that you have shown requires reading the book to understand what the various variables mean. But I don't have the book. Sorry.

@imparter In my previous message I showed how to plot the solution at time t=0.2 for alpha = 0.1, 3.0 and 5.0. Those are the curves drawn in red, green, and blue.  Isn't that what you are asking?

@AhmedRahby The first step in changing the order of integration, is to draw an accurate picture of the domain of integration as I did in my answer to your previous question.  Did you see that?

It can't be done without pictures.

@Carl Love Thanks for the complement. I, too, teach multiple integrals that way.  Some students see the idea right-away and have an easy time.  For some others it never clicks because they have difficulty in connecting analysis with the underlying geometry.

@AhmedRahby  Do you realize that a multiple integral expresses integration over a certain domain?  The integration limits specify the domain.  Can you sketch the integration domain for your integral?  There is no point in playing around with integration if you don't see that connection.

You have terminated some of the crucial parts of the code with colons and therefore deprived yourself of the chance to visually inspect what Maple is doing.  Don't do that!  Terminate commands with semicolon and verify that Maple echos what you expect.

If you change colons to semicolons, you will see that pde1 contains the undefined variable ρA and ibc1 contains the undefined variable ℓ. Correct those!

After those corrections your problem is well-posed and should have a solution.  Unfortunately Maple's pdsolve is unable to find it.  The fact that we have v(t) rahter than v(x,t) is not the cause of the failure (see the worksheet below.)  The problem arises due to the terms w(0,t) and w(ℓ, t) that occur in pde2 which to Maple looks like a boundary condition rather than a PDE, and therefore it complains about insufficient number of equations.  I don't see a workaround.  If you really need a solution, you may write your own finite difference solver for it.

The much simpler system in the worksheet below suffers from the same issue.

Download mw.mw

@acer Thanks for confirming the issue and the very nice workaround. I had not even noticed the axis label, and I agree with you that it should not be there.

I will file an SCR.

Alt+F4 works as intended in Linux Maple 2019.2.  

@Christian Wolinski 

You are correct; only one light source may be specified, and that's a shame.  I pointed this out in a message not long ago.  Improved 3D lighting is high on my wish list of Maple improvements.

The inflection point of discrete data is not a well-defined concept, therefore there is no definitive answer in general.  But if the data is sufficiently "nice", then perhaps something specific to that data can be worked out.  Post your data to get useful answers.

@one man That's cool.  Thanks for the explanation.

@ecterrab Thanks for pointing out this out.  I didn't know that.

I see that passing a vector/matrix to dsolve works even when boundary conditions are supplied, as in:

S := diff(Phi,t) =~ A . Phi + B;
ic := < phi[1](0)=3, phi[2](0)=5 >;

Then both of the following produce the solution of the inital value problem:
dsolve(<S, ic>);
dsolve({S, ic});

It's also possible to specify the initial condition as a sequence:

IC := phi[1](0)=3, phi[2](0)=5;
dsolve({S, IC});

I pointed this out when 2019.2 was announced. The response was "we are investigating".  I expect a fix to come out soon. in the meantime, users should stick to 2019.1.