NDSolve: Wrong Diagnosis as Delay Differential-Algebraic Equations
- To: mathgroup at smc.vnet.net
- Subject: [mg105820] NDSolve: Wrong Diagnosis as Delay Differential-Algebraic Equations
- From: blamm64 <blamm64 at charter.net>
- Date: Sun, 20 Dec 2009 06:55:30 -0500 (EST)
Hi All,
Firs let me express my gratitude to all those who responded to my
previous post regarding a more efficient way to "knock holes" in list
of lists, your responses, both on and off-line, were truly impressive.
I'm still dealing with an analysis of a pneumatic/hydraulic system. I
have advanced it to modeling the hydraulic side, and therein lies my
current issue.
Before I modeled hydraulics, I was specifying a (piston) displacement
via an integration of a velocity profile. The velocity v[t_] profile
was: zero (inches/second) from zero seconds to 1/10 second, a linear
rise from 1/10 second to 2/10 second to a value of 1 inch/second, 1
inch/second from there to 4.5 seconds, and from there dead stop (back
to zero inches/second). I then described the displacement as xP[t_] =
Integrate[v[s],{s,0,t}], making sure t was not set anywhere in the
notebook. I did it that way because I knew I was going to incorporate
a hydraulic component that regulated volumetric flow rate constraining
xP'[t], and therefore also constraining xP[t]. Now the reason I did
not use NIntegrate is because I have some forcing functions and xP[t]
dependent deformable control volumes taking xP[t] as arguments in my
(ordinary, non-linear) differential equations in time t, and
SetDelayed with NIntegrate would have been no help (I believe) since
in the differential equation xP[t] would be evaluated, and being still
symbolic at that point NIntegrate would have bombed. I don't know how
to delay that evaluation until the diffeqs are submitted to NDSolve.
First question: how could I do that? (use NIntegrate such as xP[t_] :=
NIntegrate[v[s], {s,0,t}] and then delay the evaluation in a
differential equation such as eqn = ... forcingFunc[xP[t]] ... == 0,
until the differential equation is submitted to NDSolve).
Once I incorporated hydraulics, there is one component that regulates
volumetric flow rate as a function of pressure *difference* across
it. I have the performance characteristic for that component
(volumetric flow rate versus pressure difference). I import the
performance characteristic data and create an InterpolationFunction,
and call it qFCon. So qFCon[p1[t] - p2[t]] would yield the volumetric
flow rate at the instant t of the pressure difference p1[t] - p2[t]
across it.
To make it easier, for me, I define another function: qFC[tau_] = qFCon
[ (p3[tau] - p4[tau]) ], since p3 and p4 are always the pressures to
be "differenced" across it. Since I'm not yet including the bulk
modulus of the liquid (captures slight compressibility of hydraulic
fluid which yields pretty dramatic effects once entrained air is
considered), absolute incompressibility mandates the relationship xP
[t_] = Integrate[qFC[s],{s,0,t}]/areaPh, where areaPh is the area of
the hydraulic side of the piston pushing fluid through this flow
regulating device ("pressure compensated flow control valve"). areaPh
does not change with time t. Again, I still have xP[t] dependent
control volumes (they change volume as the piston moves, three of
them, in fact) and xP[t] dependent forcing functions (loads on the
piston), so I'm still in the "integrate" situation I had before
incorporating hydraulics. I should add the stuff I did before
incorporating hydraulics worked just fine and the results looked very
reasonable.
Now I have five pressures that are the (time) dependent variables and
I have *four* diffeqs and *one* algebraic equation; the last pressure
(p5[t]) has no derivative term (since I'm not yet modeling bulk
modulus effects). No big deal, I think, since before incorporating
hydraulics I've submitted the (non-hydraulic) diffeqs both with
"SolveDelayed -> True" and "SolveDelayed -> False" and never received
an issue from NDSolve.
With my new hydraulics stuff incorporated, if I submit the 5 diffeqs
to NDSolve with "SolveDelayed -> False" NDSolve comes back with one of
the functions has a zero order derivative so the set will be treated
as a system of differential-algebraic equations. So far so good since
that's correct. The next message I get is NDSolve does not currently
solve *DELAYED* differential-algebraic equations! and quits with an
echo of the submission to it. I looked (and looked and looked)
through the echo and *nowhere* in sight is there a term with
somefunction[somevariable[t - c]], where c is a constant.
Yeah, sure, there are some terms in the echoed diffeqs that have
something like " InterpolatingFunction[ ... ,<>] [p3[t] - p4[t]] " and
" InterpolatingFunction[ ... ,<>] [p3[t] - p4[t]] (p3'[t] - p4'[t]) "
in them, and some with that integral expression with p3[s] - p4[s] in
it (with limits zero and t), but absolutely, unequivocally no delay
terms.
As I wrote above, the integral terms never gave NDSolve problems
before, so I don't think that's where NDSovle is "tripping up" and
making, I believe, a mistake.
Now, has *anyone* experienced that??
Does *anyone* have an idea why NDSolve would "think" some or all the
equations are delay type when in fact NOWHERE is there an explicit
delay argument? What else besides an explicit delay argument might
lead NDSolve to decide (incorrectly in my opinion) it's been handed
delay differential-algebraic equations?
Last note: when I do use "SolveDelayed -> True", NDSolve skips the
first message about this set being differential-algebraic, and goes
straight to the bomb off of it does not currently solve delay
differential-algebraic equations.
Once again, if you waded through this, thanks. And if you care to
respond with assistance, it would be greatly appreciated.
-Brian L.