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

@Mariusz Iwaniuk 

Damn !
I'm just going to complete my answer to waseem.

Thanks for the reference.

@waseem 

I can't find a free version of the article but I'm suppose that you study the stationnary laminar flow of a non-newtonian (incompressible) fluid along a duct of radius r(z) ?
In cylindrical coordinates (with adhoc auxiliary assumptions) stationnary Navier Stokes equations for a newtonian fluid 
write for a duct of constant section (Poiseuille's flow)
(1/r) * diff( mu * r * diff(u(r,z), r), r) = diff(P(z), z)

By comparing this equation to your equation (1) it comes to me 
1/ that the right hand side of (1) should be written diff(P(z), z) (pressure gradient along the axis of the "duct" (artery, vein).
    ... or at least P(z)
2/ u should be written as a function of r and z

But ...
If the radius of the duct is a function of z, then the field of the axial velocity u(r, z) cannot be the same in every cross section of the duct. Then :
1/ either the duct has a constant radius, in which case your boundary conditions (3) and (6) should be written "at r = R" (where R is some strictly positive value).
2/or either some terme invoking diff(u(r,z), k) should be present on the left hand side of (1) (unles adhoc assumptions)

Last but not least ...
Isothermal NS (Navier-Stokes) equations consist in two conservations equations, one for mass conservation, the other por impulsion conservation.
Equation (1) is obviously the impulsion condition
Without mass conservation equation you can't obtain a solution and I doubt the authors of the reference you gave were able to ...

On your second reply you say "they got the results in terms of bessels".
Viewed from a distance, if we omit the term "1" in the most inner part of (1), you have a bilaplacien operator of the type encounterd in vibration of circular plates ... which as a solution in terms of the Airy function

Could you provide me the correct set of equations written in Maple ?

@Carl Love 

Your Question mentions "base 10" three times. This problem has nothing whatsoever to do with base 10.
Absolutly, we could imagine the same matrices expressed in any other base, hexadecimal base for instance.
"do c = a+b just as if a and b were numbers in base 10."
Right, it was only to say that we are not doing all the operations in Z/pZ (p being the base) but that some steps are done in an another base (in fact the base in which the elements of the matrices are written)

See also my second Reply to Tom below.
Apologies, I royally missed it.

The main problem with multiple contributions from multiple contributors is to reconstruct correctly the timing of the events and to follow the  thread you think is the most advanced and which is the most promising.
So I recognize that I let go Tom's contributions or the exchanges you had directly with him.

@tomleslie 

Hi, 
apologies for not having reply sooner to your post.
I was studying the last contributions CarlLove had sent me and, to be honnest, I thought that only Carl was racking his brain on the subject ...

Considering your code: yes,  your answer (906) is correct, Carls' wans't.
But this was the state 8 hours ago.
Meanwhile I went to sleep and this morning I discover the last Carl's post (3 h ago).
(Please have a look to the answer I sent him 2 h ago)

I observed the last Carl's code had corrected an error (probably due to a vagueness from my part about the" carry/not carry"  rule (Carl"'s question 13 h ago, my answer 12 h ago) and maybe some comparison with yours.

In any event, thank you for your contribution.




 

@Carl Love 

For information.

Please find attached the file containing the performances of the different procedures used to build a "Base=5, K=2" matrix
Codage_Temps_CPU.mw