@vv 

It was not at all obvious !
Thank you for the answer

@Kitonum 
Lack of concentration at the beginning of this year.

Surely this would have been a better answer 
   NewList := proc(L::list, treshold::{integer, float})::list:
      map(u -> if treshold <u then 2*u else u end if, L):
   end proc:

Thanks for you exercised eye.
By the way, I use to use map instead of `if ` (contrary to what is usually done here) : are the twos equivalent or does it exist some subtleties ?

Happy new year
 

Point 1 : I guess (see Kitonum's reply) a[1], a[3], p[3] are arbitrary functions of t ?
In this case you should write your ode this way :
edo := diff(r(t), t)-(diff(a__3(t), t))*r(t)/a__3(t)+a__1(t)*p__3(t)-3*r(t)*r(t) = 0;

Point 2 : every time dsolve doesn't give an answer, use infolevel :
Here 
infolevel[dsolve] := 4:
dsolve(edo, r(t))

What happens ? Maple works hard but doesn't find any solution.
Let us rewrite your ode on the form  edo := diff(r(t), t)+f(t)*r(t)+g(t)+c*r(t)^2 = 0;
This a non linear first order edo of Ricatti type (use infolevel[dsolve] := 4 to verify) and the problem is that, apart from special cases, there is no general technique for obtaining a solution (you can refer to "Advanced Mathematical Methods for Scientists and Engineers", Bender & Orsazg, paragraph 1.6 [the one the red text here comes from] ).
In this reference you will see that "many Ricatti equations can be solved" ... as soon as you are able to "guess just one [particular] solution"
In your case the 3 functions a[1], a[3], p[3] not being in closed form, there exist no mathematical way to obtain a solution !
 

@Les 

just replace 

   DrawGraph(subs(DrawRule(M), M), style=tree, root="World") ;

by 
   DrawGraph(subs(DrawRule(M), M), style=tree, root="World") :
   PXY := GetVertexPositions(M, style=tree, root="World"):
   PYX := map(u -> [-u[2], u[1]], PXY):
   SetVertexPositions(M, PYX):
   print(DrawGraph(subs(DrawRule(M), M), scaling=unconstrained))

A last problem remains : the yellow boxes that contain the labels are not large enough for these labels to appear.
I do not see how to fix this in a simple way ... maybe you will find some way on your side ?
 

@Les 

I took your reply as an incentive to do better.
Here is a code that generates the permutation graph for any number of elements to permute.
If this number is large, it would be better to swap the X and Y coordinates before drawing the graph (the graph would extend from left to right, not from top to down)

The code is rather simple and still based on Robert Israel's trick.
I use here a "second trick" to avoid the complex management of the numbered vertices the original trick seems to impose : each vertex (a single letter) is extended by a random integer number.
For instance "a" becomes cat("a", rand()).
It works perfectly well ... while the same extended name is not generated twice !

One solution (as suggested before) is to construct recursively the permutation graph: but I'm not familiar with recursivity and it is always a pain for me to write recursive procedures.
So the code begins by constructing the trivial "order 1" permutation graph "World"--"a", and progressively augment it until all the elements ("b", "c", ...) are included.
I don't know if this  strategy icompares to a recursive one in terms of performances but, I believe it is simpler to read and maintain.
 

PermutationGraphs.mw

@Joe Riel 

Here is a copy paste from the Maple worksheet
X . Vector[column](3, [1, 1, -1]) ; 
X . Vector[column](3, [-1, 2, 0]) ;

By the way, does it exist a way to vizualize extra characters in a worksheet ?

@tomleslie 

I'm sorry :

two options :

1. You have read the description of the physical problem I gave to JhonS
   1. I misspoke and you misunderstood the problem: it's normal that you provide me a solution which does not correspond to the one I'm expected for.
      If it is so, my apologies for my poor explanations
   2. My explanations are correct but did not understand the problem and you keep going on your first idea  that I shouldn't have put the problem the way I did.
      In this case, with all due respect, I don't see any good reason to keep talking about it
2. You did not
   In this case I don't care about the solution you give in eventsProb.mw : it is not the solution of the problem I'm concerned with.

Thank you, however, for the yime you have devoted to me

@tomleslie 
Please look to my answer to JohnS, maybe it will enlighten you.


I just have two events.
The first one one [[x(t)=0, v(t)<0], [x(t)=0, v(t)=0]] plays the same role than the event described in the help pages for the bouncing ball test case. Excepted I do not reverse the velocity here, but just force it to be 0 (think not to a boucing ball but o an egg crashing on the floor).

The events are correctly specified: see help pages, example 1 :
dsn := dsolve({diff(y(t),t,t)+y(t)=0,y(0)=0,D(y)(0)=1}, numeric, events=[[[y(t),diff(y(t),t)>0],halt], [[y(t),diff(y(t),t)<0],halt]]);

You write "If I replace your 'events' option with the simpler events=[[x(t)=0, v(t)=0], [x(t)-CMAX, halt]] ..."  ... I will not solve correctly the problem (my reply to JohnS).
Why ? Because the event [x(t)=0, v(t)=0] : 

1. will preclude any initial movement of the mass as it is trivially verified by the initial condition
2. ... and even if you use some trick to "pass" this pathological case, the equation dv(t)/dt = f will make the velocity v(t) to evolve and then x(t) to become negative

You can also look also to this more complete mw file
ErrorWithDsolve-2.mw

The acceleration is a see-saw function.
The first pattern ranges from 0 to 4 with maximum amplitude 1.
The second pattern ranges from 4 to 8 with maximum amplitude 2

Given c and k, depending on the value of CMAX  :

1. x(t) = CMAX before t=2: the solution stops because of the event [x(t)-CMAX, halt]
2. x(t=2) < CMAX : the mass moves backward up to its wall position x=0 and stays still until the acceleration acc(t) (t>4) is large enough for the piston to move forward again
   Then : 
   1. either it reaches CMAX before the acceleration reverses and forces it to return to its wall position
   2. either it reaches CMAX and the solution stops because of the event [x(t)-CMAX, halt]

@JohnS 

Good remarks.

1. In the expression of f, there are only two effects : the acceleration, as you obeserved, and a linear spring of length L0 and mounting length Lm < L0. Given the stiffness k the spring develops a resustive force k(Lm-L0) I just wrote c
   So c is not some dampind coefficient.
   Note that in the problem of interest I also have a damping term
    
2. Why do you expect the condition x = v = 0 to occur ?These equations model the behaviour of a mass (here with value 1) contained in a box submitted toa given acceleration..
   At time 0 the mass is pushed against the bottom of the box by the spring (force of modulus c).
   If the acceleration is high enough to balance this force the mass begins to move to the opposite side of the box.
   This happens at some time Tdec__1 (at this time x(t) is obviously null)
   Two events can happen :
   1. the displacement of the mass equals CMAX and the system locks itself
   2. the acceleration diminishes and the spring forces the mass to return to its initial rest position x(t)=0
       in this case the system is no longer governed by an ODE and its state is trivialy x(t)=v(t)=0.
      This static equilibrium lasts until the acceleration increases again to balance the prestressing c.
      ​​​

So it is necessary to use events to monitor the differents situations the mass can face.

 

@acer 
I just thought it could have been a rather common situation, not case specific, and that the code/data was not necessary.

I'm sorry

@acer 
thanks for the advice.
(I will give you the answer here in a few days : the system team is responsible of this kind of operation)

... hum ... without imposing, would you have any suggestion about quesstion 2 ? 
I have observed that the garbage collector function (gc) only "cleans" unneccessary informations but doesn't free the memory.
Can I do this with some Maple command or should I look to system/ssystem commands ?

@Carl Love 
You're right, the problem essentially appears when P is very small (maybe also when N is very large ?)

Thank you for your contribution

@_Maxim_ 

Thank you for the "method=custom" tip.

 

@Carl Love  @Kitonum 

Very simple indeed.

Great thanks to both of you !

@acer 

I am sure too.
If there was any offence taken, it certainly was not intended.