Backsolving for variable(s) is it possible using MathCad Solve Blocks?

[MarkBuckton]

I have written with Werner's help a reasonably complicated worksheet which solves a coupled ODEs within a solve block. The ODEs are themselves nested functions. To get the answer I desire it normally take many runs because the output functions are dependant on many input variables. I have read that a competing product TKSolver can do backsolving for the input variables in order to achieve a desired output function which describes the goal. I have looked at making the ODE solve block into a function and passing back the initial conditions but that is not what is desired because the nested functions are "bound up" as part of the ODE definition.

What is needed is some way of defining a goal output within the solve block and somehow (maybe via external program control) changing the input variables to achieve that goal. The goal in my case is just one variable but it is a dependant on other variables particularly height which the coupled ODE is solves for. I have seen examples in the forum where ODEs can be functions but usually they have discrete parameters within the ODE which can be changed by passing the changed function parameters back to the ODE and then recalculating the solve block. In my case the ODE functions within the solve block are complex i.e. (have no separable discrete parameters) as all input parameters are defined outside the solve block. Obviously the ODE equations are dependant on those inputs but as I see it one can not changes those inputs in a dynamic sense to arrive at a revised output to achieve the desired goal. My question is has someone achieve what I am describing by using MathCad. Indeed can it be done with MathCad and if so has someone an example worksheet that they are willing to share, from which I can discern the methodology that has been used to achieve that end. If it is possible would this make the ODE very unstable i.e. "hunt" or is there a way to avoid such a situation?

Kind regards, Mark

[AlanStevens]

Attached is a simple projectile program that changes the input variable to alter the solution obtained from an ODE solve block to meet a specified target output (It's in MC15 format I'm afraid, as I don't have Prime 3). It's possible this might point you in the right direction. However, I can't tell if this is really what you are looking for without seeing the detail of your problem.

Alan

[MarkBuckton]

Alan;

Even this "simple" example is somewhat mind bending to me at least. I think I know what you are doing but how you worked out the form of these functions and how they actually produce output is impressive. I will see if I can do something similar with my example but if I fail I may need further help.

Thank you, Mark

[AlanStevens]

Mark Buckton wrote:

Alan;

Even this "simple" example is somewhat mind bending to me at least. I think I know what you are doing but how you worked out the form of these functions and how they actually produce output is impressive. I will see if I can do something similar with my example but if I fail I may need further help.

Thank you, Mark

I've attached the same problem, but with a few more words of explanation, which might help.

Alan

Edit: Slightly improved file

[MarkBuckton]

Alan et al.

As suspected I did indeed run into trouble. As you can see I am confident that that the solve block is now working as it should see output graphs. So what I have done is simply duplicated the previous solve block and used your method so that I can find a new function for height which I thought I could then use to find Y i.e. the height of water at a particular outflow i.e. Qscout. Note that Qscout is a piecewise function and is defined by way of a program block. I don't know if this is the problem as to why I am getting "the value must be a scalar" error. I note however that if you change the inital conditions to certain values one can under some circumstances achieve an answer, so I don't know what the problem is or if the way dependant equations have been structured is the problem. Werner helped me with setting up this problem so I assume the mathematics are sound but in saying a solution seems to be more luck that science, for example if you change the length of the tank to a smaller value no solution is found.

Kind regards, Mark

[Werner_E]

Your function ans() returns a 2x1 vector with the two heights in both chambers. You take this vector as argment for the function Q.SCout(), but this function expects a single height value as argument, not a vector of two.

So you may either rewrite your function ans() so that it simply returns SC(tau) and not the vector of two, or you write Q.SCout(ans(tau,Y)[0) to select just the first element of the returnvector as input for Q.SCout.

The simple evaluation of ans(1 min, 200 mm) takes quite long. I guess the solveblock you are trying to set up will run literally endless.

BTW, do you really think the problem has a unique pair (tau,Y) of solution? I could imagine that for a lot of values of Y (if not for any) we can find a time, where the flowrate is Q.target. But then, I may be wrong.

[Werner_E · Accepted solution]

Played around a bit I and guess that with the data and equations given there will be no solution. QScout seems to never get as high as 6.4 L/s. At least not with values of Y the odesolveblock will like, as it fails for higher values of Y. Look at the attached - the graph for Qscout looks a bit strange to me.

[MarkBuckton]

Werner;

Thank you once again. I think you would agree that this is an interesting problem as it seems to tax Mathcad solvers, but do believe you are correct and that any values above 5.976 L/s will fail as this flowrate value is a real physical constraint of the system. The water in the small chamber (given the unique input values) length width and so on, never gets above 442 mm. So I can only assume at 6.4 L/s discharge the actual height of water that must be achieved to drive the water from the small chamber must be in excess of 422 mm which is physically impossible. What I do not understand however is why this problem is so numerically unstable. For example if you turn on multithreading for example Mathcad will fail to converge to an answer. I don't know if this is a Mathcad bug or something in the way the problem has be cast. If it is a bug it probably should be reported to PTC. Also as you have remarked previously if one decreases the length of the tank even just for from 12 m in length to 10 m in length Mathcad fails to produce an answer. All these things don't make sense to me especially if Mathcad is using the state of the art numerical solvers.

Kind Regards, Mark

[Werner_E]

For example if you turn on multithreading for example Mathcad will fail to converge to an answer. I don't know if this is a Mathcad bug or something in the way the problem has be cast.

If Prime gives you an answer with multicore turned off and fails when its turned on (with nothing else changed), then there sure is something wrong (either the answer you got in the first place or the failing).

If it is a bug it probably should be reported to PTC.

Agreed. I think it would help if you succeed in creating a much shorter, simpler sheet, showing the same behaviour, when you report this.

What I do not understand however is why this problem is so numerically unstable.

The secret sure lies in the underlying equations, but as they are rather complicated, nested and contain a lot of discontinuities, its sure not easy to find the sore spot.