@Robert Israel 

Robert, I tried what you suggested using rifsimp for this wildly simple problem and received the error listed in the title.  Given the extreme simplicity of this example compared to my 'real-life' problems, I do not believe the rifsimp method would (currently) be useful.  The full output was "Error, (in DEtools/Rif/check_known) simplification of function {piecewise} not implemented".  There's not much of a ray of hope since the error message did not have "currently" between "not" and "implemented".  With reference to the .mw file I entered

sys := {eqn1}:

subs(DEtools[rifsimp](sys union {diff{xS(t),t$3) = r(t)},[[r],[xS]])[Solved],r(t))

right after the definition of eqn1.  Recall "fGrnd := t -> piecewise(xS(t)>=h,kGrnd*(xS(t)-h),0)" and "eqn1 := mStore - fGrnd(t) = mStore/gcc*diff(xS(t),t$2)" where gcc, mStore, h, and kGrnd are constants.

By the way, how do you 'copy and paste' input (or even better, output) from a Maple worksheet?  Simple copy and paste did not work for me, even after turning my anti-virus software off).

-Brian

@Robert Israel 

Robert, I tried what you suggested using rifsimp for this wildly simple problem and received the error listed in the title.  Given the extreme simplicity of this example compared to my 'real-life' problems, I do not believe the rifsimp method would (currently) be useful.  The full output was "Error, (in DEtools/Rif/check_known) simplification of function {piecewise} not implemented".  There's not much of a ray of hope since the error message did not have "currently" between "not" and "implemented".  With reference to the .mw file I entered

sys := {eqn1}:

subs(DEtools[rifsimp](sys union {diff{xS(t),t$3) = r(t)},[[r],[xS]])[Solved],r(t))

right after the definition of eqn1.  Recall "fGrnd := t -> piecewise(xS(t)>=h,kGrnd*(xS(t)-h),0)" and "eqn1 := mStore - fGrnd(t) = mStore/gcc*diff(xS(t),t$2)" where gcc, mStore, h, and kGrnd are constants.

By the way, how do you 'copy and paste' input (or even better, output) from a Maple worksheet?  Simple copy and paste did not work for me, even after turning my anti-virus software off).

-Brian

@Robert Israel 

Okay, thanks for your indefatigable assistance and your excellent explanations/instructions Robert.

Given your obvious skills with Maple, and with Mathematics in general, and the fact that provision was never given of defining a function such as

grndF := t -> fGrnd(t) ... replacing in the definition of fGrnd the solutions returned by dsolve

I will tentatively assume it is simply not possible unless one adds to the system submitted to dsolve.

I'll try to experiment, but do you know if it is possible to get different solution representations from dsolve without having to re-run the solution process?  That is, is there a way to get the 'output=procedurelist' form of the dsolve return if dsolve was submitted with the 'output=listprocedure' option, without making dsolve execute again?

-Brian

@Robert Israel 

Okay, thanks for your indefatigable assistance and your excellent explanations/instructions Robert.

Given your obvious skills with Maple, and with Mathematics in general, and the fact that provision was never given of defining a function such as

grndF := t -> fGrnd(t) ... replacing in the definition of fGrnd the solutions returned by dsolve

I will tentatively assume it is simply not possible unless one adds to the system submitted to dsolve.

I'll try to experiment, but do you know if it is possible to get different solution representations from dsolve without having to re-run the solution process?  That is, is there a way to get the 'output=procedurelist' form of the dsolve return if dsolve was submitted with the 'output=listprocedure' option, without making dsolve execute again?

-Brian

@Robert Israel 

That's very impressive Robert and I shall use it when I have constant coefficient, polynomial (and possibly non-linear) differential equations, which I typically do not.  Still, what you put together I think is excellent instruction.  I really like what you have revealed as a way of determining required initial conditons when they may not be obvious.

However, that seems like a great deal of work to get a function which I can plot, or for which I can get values for a particular value of t given that the function has for variables the 'left' sides of the list of equations returned by dsolve ( I made an error in input while experimenting and saw what dsolve actually returns, part of it at least, is very much more than the list of equations it displays after executing, which is no surprise).

Are you able to provide a way, without making it on object for which dsolve solves, of building a function of t for which I can get particular values of (the original) fGrnd(t), (which is piecewise object)?  Not only plot it (for which you provided a way very early on), but to get specific values of it for specific values of t?  And I mean without recreating the piecewise definition subsequent to dsolve, but (somehow) referncing the original definition of fGrnd(t) and 'telling' Maple to substitute the solutions into that reference?  It just seems to my 'gut' that there should be available a way to 'tell' Maple "take the entire list of what is returned from dsolve and substitute what is applicable into this previously defined object that uses some or all of those items in the list dsolve returns".  In Mathematica one simply does, for example to post-process fGrnd(t), grndF[t_] = fGrnd[t]/.sol[[1]], which would more or less translate to Maple as grndF := t -> evalf( subs(sol,fGrnd(t)) ), which I know does not work verbatim, but from reading help sure seems as if it should work since sol, what's displayed of it anyway, is a list of equations.

And I'm guessing you are not going to reveal how/where you obtained your advanced knowledge of undocumented items, e.g. "eventstop".

-Brian

@Robert Israel 

That's very impressive Robert and I shall use it when I have constant coefficient, polynomial (and possibly non-linear) differential equations, which I typically do not.  Still, what you put together I think is excellent instruction.  I really like what you have revealed as a way of determining required initial conditons when they may not be obvious.

However, that seems like a great deal of work to get a function which I can plot, or for which I can get values for a particular value of t given that the function has for variables the 'left' sides of the list of equations returned by dsolve ( I made an error in input while experimenting and saw what dsolve actually returns, part of it at least, is very much more than the list of equations it displays after executing, which is no surprise).

Are you able to provide a way, without making it on object for which dsolve solves, of building a function of t for which I can get particular values of (the original) fGrnd(t), (which is piecewise object)?  Not only plot it (for which you provided a way very early on), but to get specific values of it for specific values of t?  And I mean without recreating the piecewise definition subsequent to dsolve, but (somehow) referncing the original definition of fGrnd(t) and 'telling' Maple to substitute the solutions into that reference?  It just seems to my 'gut' that there should be available a way to 'tell' Maple "take the entire list of what is returned from dsolve and substitute what is applicable into this previously defined object that uses some or all of those items in the list dsolve returns".  In Mathematica one simply does, for example to post-process fGrnd(t), grndF[t_] = fGrnd[t]/.sol[[1]], which would more or less translate to Maple as grndF := t -> evalf( subs(sol,fGrnd(t)) ), which I know does not work verbatim, but from reading help sure seems as if it should work since sol, what's displayed of it anyway, is a list of equations.

And I'm guessing you are not going to reveal how/where you obtained your advanced knowledge of undocumented items, e.g. "eventstop".

-Brian

@Robert Israel 

Robert,

Now I'm a bit confused.  You first wrote "yes, this is actually using numeric differentiation as D returns unevaluated on one of the solution procedures; accuracy could be a problem in some instances, but is probably OK here." in response to my writing that

xtt := x -> evalf( D[1](rhs( sol[3])) (x) )

"worked" and I then wondered what was "unevaluated" and what the accuracy issues were (are).  And, do you know on which solution procedure D returns unevaluated ( sol[2]?, and if so, what is the implication)?  Note the above does not seem to fail, so it seems by your "D is the usual way to do symbolic differentiation of a procedure, ..." that D[1](rhs(sol[3])) does the symbolic differentiation, in t, of the dsolve-returned procedure for solution of d/dt(xS(t)) and then evalf does the floating point evalution at t=x.  But then you wrote "Neither of these [ D and codegen[GRADIENT] ] seem able to work on the procedures returned by dsolve.", which leads me to believe you hold that the above should fail.  I can only write that Mathematica returned the same as Maple for the xtt as I defined it above and does not seem to fail.

You know quite a bit about what dsolve returns: I did a search in both the shipped and on-line Maple help systems for "eventstop" and came up empty in both, and when I evaluate sol[1](eventstop) the return is t(eventstop)=1, and since I know the simulation time to the eventstop is 0.066559..., the "1" returned must be interpreted as integer equivalent of a boolean true.  Anyway, for a user like me, "eventstop" is undocumented.  How do you know about it?  From where did you get your obviously advanced knowledge of dsolve?  Has your patience been stretched to the breaking point? (I guess I'll have an answer to the last question by whether or not you reply!).

-Brian

@Robert Israel 

Robert,

Now I'm a bit confused.  You first wrote "yes, this is actually using numeric differentiation as D returns unevaluated on one of the solution procedures; accuracy could be a problem in some instances, but is probably OK here." in response to my writing that

xtt := x -> evalf( D[1](rhs( sol[3])) (x) )

"worked" and I then wondered what was "unevaluated" and what the accuracy issues were (are).  And, do you know on which solution procedure D returns unevaluated ( sol[2]?, and if so, what is the implication)?  Note the above does not seem to fail, so it seems by your "D is the usual way to do symbolic differentiation of a procedure, ..." that D[1](rhs(sol[3])) does the symbolic differentiation, in t, of the dsolve-returned procedure for solution of d/dt(xS(t)) and then evalf does the floating point evalution at t=x.  But then you wrote "Neither of these [ D and codegen[GRADIENT] ] seem able to work on the procedures returned by dsolve.", which leads me to believe you hold that the above should fail.  I can only write that Mathematica returned the same as Maple for the xtt as I defined it above and does not seem to fail.

You know quite a bit about what dsolve returns: I did a search in both the shipped and on-line Maple help systems for "eventstop" and came up empty in both, and when I evaluate sol[1](eventstop) the return is t(eventstop)=1, and since I know the simulation time to the eventstop is 0.066559..., the "1" returned must be interpreted as integer equivalent of a boolean true.  Anyway, for a user like me, "eventstop" is undocumented.  How do you know about it?  From where did you get your obviously advanced knowledge of dsolve?  Has your patience been stretched to the breaking point? (I guess I'll have an answer to the last question by whether or not you reply!).

-Brian

@Robert Israel 

Do you know of another way to differentiate a procedure?  It seems to me Maple is returning interpolants ( on t, xS(t), and d/dt(xS(t)) ), each wrapped in a procedure.  I know I can define an interpolation function and easily differentiate it using diff, and thought maybe I could just use diff here too, but no.  I don't think anything but D can be used to differentiate a procedure, according to my minimal (and probably flawed) purusal of online Maple Help.  And it seems that what remains "unevaluated" as you put it does not matter, it is the procedure of d/dt(xS(t)) that does get differentiated, and I chose to differentiate sol[3] since it involved one differentiation, instead of two if I had chosen to differentiate sol[2], since, as you most likely know, differentiation exacerbates 'error'.

Perhaps using such a simple example has its drawbacks: my 'real-life' systems, many of them anyway, have no possibility of algebraically solving for some of the derivatives that do exist in the system of ODEs (thus for those systems I must use implicit=true), and, as I wrote before, a hybrid simplify such as rifsimp will likewise have no chance of finding a higher derivative that does not exist in the system of ODEs, unless coefficients that are nested piecewise definitions (the names used in some piecewise defintions are themselves piecewise defintions) fall into the category of polynomial non-linear ODEs.

Anyway, from what I could find in the help system, D is the only way to differentiate a procedure.  Perhaps using DEtools package might be a worthwhile approach, but I do not yet have nearly enough knowledge of Maple to pursue that, or even know if it is worth pursuing what capabilities might be available by using DEtools package.

-Brian

@Robert Israel 

Do you know of another way to differentiate a procedure?  It seems to me Maple is returning interpolants ( on t, xS(t), and d/dt(xS(t)) ), each wrapped in a procedure.  I know I can define an interpolation function and easily differentiate it using diff, and thought maybe I could just use diff here too, but no.  I don't think anything but D can be used to differentiate a procedure, according to my minimal (and probably flawed) purusal of online Maple Help.  And it seems that what remains "unevaluated" as you put it does not matter, it is the procedure of d/dt(xS(t)) that does get differentiated, and I chose to differentiate sol[3] since it involved one differentiation, instead of two if I had chosen to differentiate sol[2], since, as you most likely know, differentiation exacerbates 'error'.

Perhaps using such a simple example has its drawbacks: my 'real-life' systems, many of them anyway, have no possibility of algebraically solving for some of the derivatives that do exist in the system of ODEs (thus for those systems I must use implicit=true), and, as I wrote before, a hybrid simplify such as rifsimp will likewise have no chance of finding a higher derivative that does not exist in the system of ODEs, unless coefficients that are nested piecewise definitions (the names used in some piecewise defintions are themselves piecewise defintions) fall into the category of polynomial non-linear ODEs.

Anyway, from what I could find in the help system, D is the only way to differentiate a procedure.  Perhaps using DEtools package might be a worthwhile approach, but I do not yet have nearly enough knowledge of Maple to pursue that, or even know if it is worth pursuing what capabilities might be available by using DEtools package.

-Brian

@Robert Israel 

Robert,

Through brute force experimentation and reading the online Help (has a much 'smarter' search than found in the help system shipping with Maple), the following 'finds' the acceleration:

xtt := x -> evalf ( D[1] ( rhs ( sol[3] ) ) (x) )

I in a round about way I read that D can be applied to procedures, so I first checked the result of

type( rhs( sol[3], 'procedure' ) to which the return was 'true'.  I then tried the above with eval ... no 'luck', I then tried what you see above and ... voila.

I'll next work on how to define a function which uses the returned solution(s), and perhaps derivatives of the returned solution so I can find specific numerical values of the defined function for specific values of time t ... if you're interested I'll post results.

(I sure wish Maple had a way of showing unmatched parentheses as the user types ... ).

Thanks,

-Brian

@Robert Israel 

Robert,

Through brute force experimentation and reading the online Help (has a much 'smarter' search than found in the help system shipping with Maple), the following 'finds' the acceleration:

xtt := x -> evalf ( D[1] ( rhs ( sol[3] ) ) (x) )

I in a round about way I read that D can be applied to procedures, so I first checked the result of

type( rhs( sol[3], 'procedure' ) to which the return was 'true'.  I then tried the above with eval ... no 'luck', I then tried what you see above and ... voila.

I'll next work on how to define a function which uses the returned solution(s), and perhaps derivatives of the returned solution so I can find specific numerical values of the defined function for specific values of time t ... if you're interested I'll post results.

(I sure wish Maple had a way of showing unmatched parentheses as the user types ... ).

Thanks,

-Brian

@Robert Israel 

Thanks, once again, Robert.  Your knowledge of Maple is obvious.  At the risk of over-extending your patience, I have more inquiry.

I still have issues with using a 'hybrid' solve or simplify to obtain a higher order derivative than found in the system.  Some of my other, 'real-life' systems have many, many coefficients of a quite complicated nature, and involve, sometimes, piecewiese constructs nested a few levels deep (that is why I included the option implicit=true in my example: not needed for this very simple example but will absolutely be needed in my 'real-life' models/simulations where it will be impossible to symbolically backsolve for derivatives prior to initiating the discrete solution process).  Perhaps I'm hoping for a capability that does not exist yet in Maple.  Simply put: is it possible to 1) build functions from solutions returned by dsolve/numeric, 2) build a derivative of a primary dependent variable, where that derivative order is not not included in the returned solution?

Regarding 1): You showed me how to plot fGrnd(t), thanks for that.  But what if I want evaluations of fGrnd(t) at particular values of t?  Just entering fGrnd(0.1), for example, does not do anything except return the piecewise definition with t replaced by 0.1, that is xS(0.1) is not replaced by the solution and then the piecewise evaluated.  That's why I thought perhaps eval, or evalf would be involved in creating a (new?) definition for fGrnd.  I have not tried it (I'm not at the machine where Maple is installed), but something like

grndF := t -> eval( fGrnd(t), sol )

maybe with eval somehow 'told' to delay itself until t has a numeric value.  I'm just guessing here and will experiment when I have access to Maple.

If the above would work for defining grndF, then it seems as if I could do diff( grndF(t), t ), but in this case I would need to have t as a symbol, do diff, and then substitute numerical value of t.  Perhaps that could be implemented by using in the definition of grndF a combination of subs and eval with eval 'told' to delay itself until t had type numeric.  I'll just have to experiment if no one knows already, and will share it.

I'm tenacious on this point of not seeing why a simplify or hybrid solve is necessary because I am still holding onto the idea the returned solutions are effectively interpolants (wrapped up as Maple procedures) and therefore constructions using those interpolants, including constructions using derivative of those interpolants, should be possible, and pretty transparent to the user.

I guess I'll just have to brute force experiment.

-Brian

@Robert Israel 

Thanks, once again, Robert.  Your knowledge of Maple is obvious.  At the risk of over-extending your patience, I have more inquiry.

I still have issues with using a 'hybrid' solve or simplify to obtain a higher order derivative than found in the system.  Some of my other, 'real-life' systems have many, many coefficients of a quite complicated nature, and involve, sometimes, piecewiese constructs nested a few levels deep (that is why I included the option implicit=true in my example: not needed for this very simple example but will absolutely be needed in my 'real-life' models/simulations where it will be impossible to symbolically backsolve for derivatives prior to initiating the discrete solution process).  Perhaps I'm hoping for a capability that does not exist yet in Maple.  Simply put: is it possible to 1) build functions from solutions returned by dsolve/numeric, 2) build a derivative of a primary dependent variable, where that derivative order is not not included in the returned solution?

Regarding 1): You showed me how to plot fGrnd(t), thanks for that.  But what if I want evaluations of fGrnd(t) at particular values of t?  Just entering fGrnd(0.1), for example, does not do anything except return the piecewise definition with t replaced by 0.1, that is xS(0.1) is not replaced by the solution and then the piecewise evaluated.  That's why I thought perhaps eval, or evalf would be involved in creating a (new?) definition for fGrnd.  I have not tried it (I'm not at the machine where Maple is installed), but something like

grndF := t -> eval( fGrnd(t), sol )

maybe with eval somehow 'told' to delay itself until t has a numeric value.  I'm just guessing here and will experiment when I have access to Maple.

If the above would work for defining grndF, then it seems as if I could do diff( grndF(t), t ), but in this case I would need to have t as a symbol, do diff, and then substitute numerical value of t.  Perhaps that could be implemented by using in the definition of grndF a combination of subs and eval with eval 'told' to delay itself until t had type numeric.  I'll just have to experiment if no one knows already, and will share it.

I'm tenacious on this point of not seeing why a simplify or hybrid solve is necessary because I am still holding onto the idea the returned solutions are effectively interpolants (wrapped up as Maple procedures) and therefore constructions using those interpolants, including constructions using derivative of those interpolants, should be possible, and pretty transparent to the user.

I guess I'll just have to brute force experiment.

-Brian

Thanks Tim, indeed I missed that.  So you have revealed that, with my very first question, I'm not perfect!

-Brian