@stefanv 

Wrong.
If you work in worksheet mode, not in document mode, the writeto function from Maple 2015 & 2016 redirects only the output, not the input.
In this without invoking interface(echo=0).

With Maple 2018 (run on a Windows 7 PC ... I'll give you tomorrow the exact version of Maple 2018 I use at office, for I'm now at home and I'm going to sleep), even if I put interface(echo=0) in a separate block just after the restart, I recover the input in the file.

 

@acer 

I've forgotten to say I'm working with the preferences described in the attached file

Capture_d’écran_2018-06-27_à_22.16.27.pdf

(sorry for giving you this environment in french but I'm here at home and french is the default language for my personal license).
Furthermore, I always work in worksheet mode, never in document mode

 

@Preben Alsholm 

Thanks for all these advices 
They seem very interesting at the first reading, but I need to test them by myself to re-appropriate the full material.

You said "I succeeded in some attempts (after restarting) and other times it took too long for my patience" ... please don't worry about that, you have already done more that i ever expected !

Looking forward to read you soon on other topics.
Have a nice weekend

@Preben Alsholm 

Before sending my answer ro  mehdibaghaee I had tried to obtain an explicit solution of the this ODE system:
     dsolve(...);
     allvalues(%);

The result allvalues returned was extremely lengthy, but a quick look revealed some facts:

1. from the result of  dsolve(...) we can observe that the term  RootOf(_Z^4+9*_Z^3+4*_Z^2-19*_Z-5, index = SomeInteger)  is recurrent. 
   Unfortunately allvalues(RootOf(_Z^4+9*_Z^3+4*_Z^2-19*_Z-5) ) is dramatically untractable because, as a rule, Maple always represents (except in obvious cases) the formal solution of equations ot the 3rd or 4th degree that Maple rin a complex form, even if the roots are real.
   Does it exist some "already implemented feature" to force Maple to return roots under a real form if they are indeed real ?
   One might think of some analysis of the discriminant.
   Or, for 3rd degree equations, one might use the  "trigonometric resolution" which gives expressions in temrs of hyperbolic trig. functions when only one root is real, or in terms of cosine if the 3 roots are real.
    
2. The second question has probably already been asked here.
   Because the explicit solution for, let's say,  phi__1(t) contains many times the same term, for instance 
   (4*(3268+(3*I)*sqrt(10275765))^(2/3)+211*(3268+(3*I)*sqrt(10275765))^(1/3)+1876)/(3268+(3*I)*sqrt(10275765))^(1/3)
   or 
   (3268+(3*I)*sqrt(10275765))
   I have had the idea, in order to have a more readable solution, to susbtitute some repetitive pattern by, let's say, a few auxiliary variables U, V, W, ...
   What I tried was
          dsolve(...):
          sol := allvalues(%):
          subs(SomePattern=U, rhs(sol[1]))
   Unfortunately this subsitution did not always apply, leaving unchanged some terms which nevertheless contained the pattern "SomePattern".
   For instance, if SomePattern := (3268+(3*I)*sqrt(10275765))^(1/3): changes occur in expressions invoking SomePattern but not 1/SomePattern (wich comes from the fact that 1/SomePattern is in fact  (3268+(3*I)*sqrt(10275765))^(-1/3) , or even in exp(SomePattern) ...
   
   Do you that functions such as select/remove, patmatch ... could help to do the substitution everywhere SomePattern appears ?

I would be pleased to have your opinion about these two "by-problems".
Thanks in advance

@tomleslie 

Sh... It's not the first time that I get taken this way !
Sorry for asking this question for I knew perfectly that the restart had to be put in a separate block.

Thanks for reminded me how volatile my memory is :-)

If you have some hints about x you can do this 

@panke 

in dsolve[numeric], the bouncing ball example uses 2 events
[[y(t),diff(y(t),t)>0],halt] and [[y(t),diff(y(t),t)<0],halt]

for events is a list of events, the syntax for the bouncing ball problem is  
events=[ [ [y(t),diff(y(t),t)>0], halt],  [ [y(t),diff(y(t),t)<0], halt] ]

Both events here is a list of two objects : the trigger and the action.
A trigger MUST be a list only if it is made of more than one condition.
If the trigger is "simple", ypu MUST NOT put it between square brackets.

In the help page (topic "event specification") look to the difference between 

y(t): simple root finding trigger       and       [f(t,y(t)),c(t,y(t))<0]: root finding with a conditional trigger

For your triger s(tau)-const is "simple", it must not be enclosed between square brackets
The event is then [s(tau)-const, halt], and you must write   events = [ [s(tau)-const, halt] ]

@panke 

First of all :  I am used to dsolve a set of equations, not a list of them (I don't know if Maple handles this correctly, but it seems weird for me to speak of "list of equations"). So I have taken the liberty to replace  [ic, odes, odex], by {ic, odes, odex},

Second point :  ta..te is an invalid range for neither ta nor te are numbers.
2 ways to fix that :1/ give them numerical values (0..1 below) or, 2/ use the option "parameters" (have a look to dsolve[interactive].

Last point : the syntax for the event is not correct (ok, there a lot of recurrent complaints about the corresponding help page) 

Finally, try this with your own range
dsolve({ic, odes, odex}, type = numeric, range = 0 .. 1, events = [[s(tau)-1, halt]])

@acer @Carl Love 

Great thanks to both of you for this detailed discussion.
To summarize and clarify a few questions :

• acer/  "but I interpreted the original question as being more about how to write the procedure so that the calls to H could be written with just the short form of the name":
  Absolutely: I wrote "f" first, observed it didn't worked as expected, then tried "g", became happy it worked correctly but remained upset for the syntax orthopoly:-H(...) is obviously heavier than just "uses orthopoly;..... H(...)"
   
• acer/  thanks for the solutions you provided in your first answer
   
• Carl Love/  about the "semantics of :-" ... I didn't know about this way to access an entry of a table. If I correctly understand what you said, it is some kind of undocummented feature ?
  It has one funny consequence: for instance (attached file), the syntax T:-N (where T is a table and N one if its indices) avoids using eval to visualize T[N] if N is itself a table.
  
  HowToAvoidUsingEval.mw
   
• Carl Love/  Thanks for having explained "why procedure g works" 
   
• both of you/  I understand I should use the "correct coding" acer provided while avoiding the "T:-N" syntax pointed by Carl 

Thanks for your help and your

@acer 

Thanks for the advice.
I'll do the test since I get back from my holidays.
I'll see you again around 9-10 June

 

@Carl Love 

I copy-and-pasted the last(?) code.
I get an error.
I think it's because I'm at home with Maple 2015.2 (no Iterator package ; Maple 2016 and Maple 2018 at the office) a

I'm in vacation and I won't be able to do some tests of performances within one week.
I'll see you around 10 June.

IsThisTheGoodCode.mw

@acer 

Unfortunately I'm in vacation for a week and I won't have access to Maple in 12 hours.
I'm going to try to extract the "real time" by doing a few things at home.
A point is: the code Carl Love provided me  is a module including a procedure with a remember option (the [non optimal] procedure I had written myself doesn't have this option and the cpu times assessed by the two procedures are roughly equal).
I will do some supplementary tests and I will keep you informed about their results as soon as possible.

Thanks

@acer 

Thanks for the precisions.

By the way, I have an other thread open with Carl Love as the main contributor.
Catrl wrote different procedures to adress the same problem an I did some comparisons of their performances (mainly the cpu time).

Before your previous answer here ("use option iterations")  I used the procedure below to assess the mean cpu time over 100 runs of the same code.

Procedure 1 :
 T := NULL;
for r from 1 to 100 do
   T := T, CodeTools[Usage](Code(...), output=cputime)  # from your answer to the "other" thread
end do:
add(T)/100

Once you made me discover the option "iterations" I wrote this second procedure.

Procedure 2 : 
 CodeTools[Usage](Code(...), output=cputime, iterations=10

Here are the performances I got.

Results
  indicator                Proc 1                   Proc2            

 cpu time/run             16.9 s                     32.75 s             

memory size            0.95 GiB                  0.95 GiB

I repeated this twice and obtained the same ratio of 2 between the cpu times.
For proc1 the 10 times range between 15.49 s and 18.08 s

Do you have any idea about where this difference could come from ?
Do you think it is "intrinsic" to the CodeTools[Usage] procedure or it comes from the way Code(...) is written ?

Thanks for answer

PS : this reply is close to the one I sent to Carl Love in the other thread

@waseem 

Thanks.
But the reference provided by Mariusz is more complete and I used it.
I can't obtain a solution for the system described in the reference paper by using pdsolve.

There remain some points to fix:

1/ For NS equations, the pression is only defined up to an arbitrary constant. I think P(0,0)=0 is a reasonable boundary condition (bc).

2/ bc n° 10 and 11 cannot be handle with pdsolve.

3/ The writting P(z) xauses problems: the system has 2 unknowns u and P and each of them has to be defined in terms of r and z : u --> u(r, z) and P --> P(r,z).
Of course this induces some complexification s because we need to account for the equation diff(P(r,z), r) = 0

I think it will not be possible to obtain a solution by using "blindly" pdsolve.
A solution strategy (for instance solve equation 5 and plug it in equation 7) seems necessary.
It will probably take some time to do that and, very honestly, I'm not sure I will be capable of that in a reasonnable time.

I will keep trying to solve this problem, but do not count on me too much.

 

@Mariusz Iwaniuk 

Be happy !
It works pretty well with Maple 2015.2 and Maple 2016.1 too