ACCEPTED SOLUTION
Accepted Solutions
Look at the parentheses around P and P.tank. They denote 1x1 matrices! Why did you do that??
If you fix this you still get a "variable not defined" error. This error stems from the numeric engine because it misses a guess value for P.tank and could be ignored if the result is evaluated and used only for symbolic calculations.
Main problem is the fact that P.tank is not a simple variable but rather a function. "Find" will only solve for variables and you seem to try to solve an integral equation, which Mathcad is not capable to do.
You might try to turn the equation into a differential equation if possible and then try your luck using the numeric odesolve.
As you tried to symbolically evaluate P after the solve I guess that you expected to see a symbolic solution for your integral equation. You won't get a symbolic solution even if the above suggestion may work because Mathcad can't solve integral equations and will solve (some) differential equations only numerically - you will never see a symbolic function equation when you use odesolve.
Looking further in your sheet I guess you already solved the ODE for P.tank and the subsequent failing solve block wih the integral equation was introduced because you wanted to see a symbolic function definition of the derived solution, right?
This must fail because Odesolve is a numeric method only - it basically returns just a function which interpolated discrete values which were found using a numerical approximation algorithm like Euler's.
Prime just started to be able to solve some very basic ODEs also symbolically but I doubt that it will be able to give you the result you are looking for. As @ttokoro seems to already have converted the sheet he may be able to give it a try and tell us, if Prime 9 would be able to symbolically solve the ODE for P.tank.
The error in the new sheet is not "variable undefined" as you initially wrote, but rather "too few initial conditions"!??
Some things I noticed:
You sure should put
in before solve block and don't let the solve block solve for P.BP
You have only a first order ODE so you can't use P.QA(0)=... and P.QA'(0)=... as IC. Delete the latter.
There is no IC for neither DP.QA and DP.BP. And there is no ODE for both of them , too - guess odesolve does not like this?
Anyway, I guess all you have is just one first oder ODE for P.QA and I thought hat the approach shown in the picture should do it.
But I get a rather meaningless error message and don't know what the problem may be.
I also noticed that when I just omit the one highlighted P.BP(t) (replaced it by 1), the solve block seems to work OK.
Have no clue how to fix that at the moment but I attach the modified sheet anyway
Hmm, crazy! Seems to have to do with the initial condition.
If I just add 0.5 to large value P.QA0 the solve block works OK.
have no explanation ...
Werner. Thanks for your assistance.
When you were tinkering you typed in the function highlighted in yellow in the attached sheet, i.e.
When I disable this function to include the halfsine transient in BPP(t), it throws an error in Odesolve "this function cannot be used here". I have struck this problem earlier and it disappeared when I reduced the magnitude of "tend".
When I shorten tend to tend=0.06 it solves, but the answer looks very suspect as, whilst the half sine transient is seen in PQA, the response is delayed in reference to the decreasing PBP . When I plot PBP and its derivative DPBP before the solve block, the changing slope of the transient does not correspond to the start/finish of the derivative. I have no idea why this should occur? Do you have any clues why the solve only works to 0.06 seconds? And also why there is a mismatch between PBP and its derivative DPB?
Cheers
Ross
Sorry, the assignment BPP(t):=PP(t) was a leftover from me playing with the sheet - I think I got the "function cannot be used here", too, and tried a simpler function. Then I forgot to undo.
Unfortunately I have no explanation for the strange effects you describe.
Maybe its due to the small t-values and large function values that the numeric derivative shows this unusual behaviour and is not OK for the full interval from tpulse to 2*tpulse.
Because of the way the function is defined the symbolic derivative fails and can't be used
And I also have no idea why the odesolve block fails for end values even very slightly larger than 0.6 and why it only works when we add a small amount like 0.5 at the initial condition.
P.S.: I had rewritten your function p(t) using the Heaviside unit step
(the "if" is the reason why the symbolic fails) but now the derivative includes the Dirac Delta, which is a symbolic only function and available for numeric use like plotting.
I used a very bold (and not recommended) "fix" by setting Delta to constant 0 (and even constant 1 worked).
As you can see assigning DP.BP the result of the symbolic derivative gives the expected results
Instead of using the symbolic evaluation you may also use the optimize option you get when you right click the assignment expression.
Here a comparison of this new, correct derivative and the old (numeric) one.
So I would conclude that you ran into a crude numerical inaccuracy of the implemented numeric derivative algorithm.
I am not sure it the reason is the discontinuity of the derivative or the discrepancy between the small x and y values. I don't know how the implemented Ridder algorithm (according to the help) works.
But I am not sure how to repair the numeric derivative as it seems not to be affected by CTOL or TOL (at least lowering these two system variables had no effect concerning your plots).
Maybe a user-written function to do the derivative may help, but I am not sure how it would deal with discontinuities in the derivative. I remember that in the past ever so often user complained about the numeric derivative being to inaccurate for some special function and self-written function to do the derivation were offered (and sometimes solved the problem). Maybe you can find something useful using the search function here in the forum.
We also sometimes had the effect here in the forum that odesolve would only work OK up to a specific end value and not beyond, but the reason usually was the the function shoots up asymptotically vertically near that last allowed end value but that seems not to be the case with your function. So I am out of ideas 😞
OK, at least I found a workaround for the inaccuracy problem with the derivative.
Lets stretch the curve in x and y direction by a factor "scale" before we apply the derivative and scale it back afterwards.
The missing vertical at tpulse in the left plot can be "fixed" by defining a finer range for t to be used in the plot
Werner,
Many thanks again for your persistence. It seems I will have to construct a function for BP(t) with some smoothing functions that are more easily differentiable. The half sine transient was an attempt to generate a dummy file that is representative of my actual measured BP data (below).
I will try some curve fitting to see if I can generate a function that looks similar to the test data.
Cheers
Ross
