Solving an ODE with nested functions

[MarkBuckton]

Attached is my MathCad Prime 3 worksheet. The ODE solve block is not producing an answer can someone look at this example and explain to me why or how? Maybe I have not specified h(t) correctly but all plots seem OK!

Thanking you in advance,

Mark

[Werner_E]

1) Q is used as a function of length in that solve block, but Q is not a function but a constant with unit L/sec.

2) You have to write depth:=odesolve(... instead of depth(t):=...

[MarkBuckton]

Werner;

Thanks Werner, if only I had your math ability. I realised that it is not Q but rather Qout that I am interested in. Q as you say is a previously defined constant. But Qout is actually also a function of Ht,t and V or the nested function Qout(Ht(t),V) but if you multiply the Ht(t),V you get units of s^3 or if you include t then units are s^4, which is not correct. Qout as you say should be in units L/s. Somehow I think I must relate Ht(t) and Q directly but I thought this is what the ODE was attempting to do but its seems not to be the case. The solve block dosen't like Qout(Ht(t),V) or for that matter Qout(Ht(t)). Maybe I have just lost the plot here as I am a bit tied today. Also I don't understand why just the depth variable is depth also a funtion of t i.e. not depth(t) but have have changed it as recommended but still no joy?

King regards, Mark

[Werner_E]

Also I don't understand why just the depth variable is depth also a funtion of t i.e. not depth(t)

Thats the syntax of "odesolve()", look it up in the help and expamples.

When you use this function later in the plot or elsewhere, ocourse you have to add the argument. writing ht(t) or Ht(5s)= or whatever.

[MarkBuckton]

Werner,

Do you know why the odesolve is still complaining see my latest attachment?

Message was edited by: Mark Buckton For example why is it asking for 2 arguments for the ODE

[Werner_E]

See my reply to your other post.

Message was edited by: Mark Buckton For example why is it asking for 2 arguments for the ODE

This is explained in my answer to your other post, but I am surprised that you get this (correct) error message. For me your solve block just throws and "undefined error".

[MarkBuckton]

Werner,

I tried to simplyify the ODE syntax and checked variable names being used but now I a getting an even more confusing error. Can you resque me from my ignorance.

Kind regards, Mark

Message was edited by: Mark Buckton

[Werner_E]

Think you will have to decide first what you want to do at all.

1. Main error seems to be that Q.out is defined as a function with 2 arguments and you attempt to use it with just 1. That can't work. The arguments of Q.out are a function name and a value with dimension velocity. The function passed as first argument will also take one argument of dimension velocity. The result of Q.out would be volume per time which would be what is needed here.
   You need e.g. in place of Q.out a function with 1 argument of dimension length and result volume per time to make your problem work. Or more general: Anything which results volume per time and is used correctly will do good here, but its you who has to know what exactly is right at this place.
2. Why do you define a variable h (as vector) just before the solve block when the solve block should result a function of the same name h??
3. You have to write d h(t) /dt = ... and not d h/dt=... The latter would try to take the derivative of the vector h you defines just before and that the errormesage you get.

Admittedly the error messages which are thrown by solve block very seldom are helpful.

I attach I file with a working ODE solve block. I just used Q.out in a correct way, passing H.f as first and h(t)/seconds as secon parameter. This uses the function in a correct way with correct units but it sure is NOT the solution to your problem - its just messing around. Its you who has to know which ODE he wants to solve really!

[MarkBuckton]

Werner,

Your advice produced answers that look credible and the method appears sound. As you can see in the latest incarnation of this worksheet I found a specific expression for velocity which reduced the complexity of the solve block ODE which now works. So thank you. However, I have run into yet another problem (see integrated outflow results) which for some strange reason presents the units as [s m3] but should be just [m3]. Why are time [s] units appearing in the result? The units mismatch which to me appears as a bug messes up the rest of the calculation. I am so close but yet so far from completing this.

Regards, Mark

[Werner_E]

However, I have run into yet another problem (see integrated outflow results) which for some strange reason presents the units as [s m3] but should be just [m3].

Prime is perfectly right - if you integrate a volume (Q.out(length)) over time (dt) you get dimension volume*time.

Why are time [s] units appearing in the result?

because you variable of integration is time.

The dimension of Int(a, db) is dimension_of_a * dimension_of_b. You may look at the integral as the summation of an (infinite) number of very small rectangles. In your case the "height" of those rectangles is measured in liter or m^3 (Q.out) and the (infinitesimal small) width dt in seconds.

You see the same effect in your sheet with the integral of I over time. I has dimension volume/time und so the integral has dimension volume.

Are you really sure about feeding h(t)/s into Q.out in the odesolve block? I just did it to show that using the correct units makes the solve block work but I never thought this would make any sense looking at the physics of the problem.

If it really should make sense (which I doubt) you get you desired units by using depth(t)/seconds when calling Q.out in your integral.

But I would urge you to doublecheck your formulas for consistency.

[MarkBuckton]

Werner;

Would you not agree that Qout(V) is the same as Qout(h(t)/s). V is a function of water depth from centerline of outlet to the water surface which in my case is varying with time because of the varying inflow i.e. similar to draining tank using Bernoulli's Equation see: http://www.efunda.com/formulae/fluids/draining_tank.cfm

but inflow is not constant. Since water is incompressible is that not the same as the rate of change of depth over the tank outlet with time i.e. h(t)/s i.e. the velocity at which the water surface falls when the tanks is draining but because of this change in depth the outflow from the pond/tank also changes with time. Granted the velocities are different because the area of the pond/tank is large relative to the pipe outlet but the continuity equation must hold i.e. Atank x Vtank = Apipe x Vpipe. h(t)/s is velocity but you are correct in saying these velocities are different depending on the the ratio of areas Vtank=Apipe/Atank x Vpipe in otherwords for the continuity equation to hold the Velocities cannot be the same. That said I haven't been able to get the solve block to work with any other combination of variations other than what you have discovered but your right I have also got a sense that the answer is incorrect, Where to now? See my latest version attached.

[Werner_E · Accepted solution]

Mark, I never bothered to look at your sheet at a whole or to consider what you trying to calculate and how. I just looked at an odesolve block which didn't work or an integral which supposedly yields wrong units and attempted to find the reason for it in terms of math and Mathcad. In both cases in some way the cause was wrong usage of units. Being able to use units in calculations is a great plus of Mathcad and doing so can show us pretty soon in the calculation steps that we have an error. Thats the reason I was suspicious and doubted the correctness of the used formulas when we began to mess aoround adding units here and there just to make the whole calculation work in Mathcad on an abstract level.

As a first step the math model of the problem to be solved has to be correct, then we can try to use Mathcad as a tool to deal with the math. Only adding units and using different variables just because this makes Mathcads unit consistency check happy simply made me a bad feeling and was the only reasons I doubted the results. So I suggested to go back to the beginning and check the math model again for plausibilty.