Mathematica's DSolve with unspecified constant parameters

[Arijun]

I am trying to solve the general equation for a body falling in drag so I can apply it to many objects. But Mathematica seems to have problems with having anything but numbers and your independent and dependent variables as an argument. So if I want to leave the mass, a constant with respect to the DE, unspecified (to be supplied at a later date), it can't handle it.

Here is my most recent attempt:

Y[t_, m_, A_] := y[t] /. DSolve [{-m 1/2 Cw \[Rho] A y'[t]^2 + m g == y''[t], y'[0] == 0, y[0] == h}, y[t], t]

The delayed assignment was my attempt to get around the coefficients not being supplied. If I try to use that, by say, doing BB[t] = Y[t, .145, Pi .0366^2], mathematica throws the error

Solve::inex: Solve was unable to solve the system with inexact coefficients or the system obtained by direct rationalization of inexact numbers present in the system. Since many of the methods used by Solve require exact input, providing Solve with an exact version of the system may help

I was also thinking of using Assume, but as far as I can tell, you can't assume with DSolve. I am new to Mathematica so it's also possible that there is a simple solution I am unaware of.

 

[Bill Simpson]

I don't think it is the mass. Surprisingly, I don't even think it is your using decimal points and thus approximate constants like the warning message indicates.

I get similar, but different, warnings with this simplified example

DSolve[{- y'[t]^2 + g == y''[t], y'[0] == 0, y[0] == h}, y[t], t]

 

[Arijun]

Does that mean that you agree that this issue is either unsolvable or not easily solvable at all? That's disappointing...
To make sure we are on the same page, though, in my version, g, rho, and Cw had all been previously defined. the only undefined constants I had were the ones specified in the delayed assignment. I'm not sure but without context it looks like you just left off any definition of g in your example. Your version would be parallel to mine if you had a delayed assignment of Y(t_,g_) before your DSolve.

 

[Bill Simpson]

Temporarily, as an experiment and since your original attempt complained about your use of decimal approximate numbers, just try this with no decimal approximate constants defined:

DSolve [{-m 1/2 Cw \[Rho] A y'[t]^2 + m g == y''[t], y'[0] == 0, y[0] == h}, y[t], t]

See if your warning about decimal approximate numbers goes away.

You may find you get a different warning, but you may also get one or several potential solutions that you can consider and one of those might be what you can use.

Then you can substitute in your decimal approximate numbers and see if you can use the result.

 

[phyzguy]

I don't understand your issue. It seems to work fine when I do it (see the attached notebook). The only thing I added was to force it to take the first (real) solution. What happens when you run my notebook?

 

[Arijun]

OK, I've solved the problem. phyzguy, your notebook worked fine, until I cut and pasted it into mine. Long (~hour) story short, it turns out I had made gravity a double negative, and that was throwing the whole calculation way off. I've decided that tiny errors and typos are the worst things ever. So, turns out my formulation was fine, but my intellect was not.

A few comments (I guess for the future folks who have similar issues): the formulation I used worked fine and is generally good, except I couldn't prime my Y's, and as a rule, had to reassign them (B[t_]=Y[t,2,3]. I also tried it by changing Y[t_,m_,A_] to just Y[t_] and using the replace (/.) function when I invoked Y[t]. That evaluates DSolve first and then does the substitution, which in this case gives a more complex solution which still evaluates to the right answer but was not useful for me. Finally, making Y[...] an immediate assignment rather than a delayed assignment would yield one correct but convoluted answer along with several complex ones (which were not what I was looking for). Letting it assume m>0 and A>0 would still give me the complex answers.

Finally a parting question: it seems DSolve is useless inside of a function like Plot. It seems that Plot evaluates the expression inside of it every time it wants to get a new y value, rather than evaluating once for the dependent variable and storing that expression in memory. Is that the case?

 

[Bill Simpson]

Without seeing all your code and digging through the details it is impossible to even guess why you couldn't do some of the things you wanted to do.

Some users assume that Assume[] has much more power than it actually does. All Assume[] really does is just add some booleans to a list up on the wall. Many or even most Mathematica functions do not even look at that list on the wall, but users often assume everything from + on up only operate under the assumed conditions.

The depths and details of how and when Mathematica evaluates something is boundless. You might try wrapping your DSolve[] inside an Evaluate[] inside your Plot. But then you should be wondering just how Evaluate[] interacts with all the other evaluation steps.

In
http://reference.wolfram.com/mathematica/ref/Plot.html
under More Information it says

"Plot treats the variable x as local, effectively using Block.

Plot has attribute HoldAll, and evaluates f only after assigning specific numerical values to x.

In some cases it may be more efficient to use Evaluate to evaluate f symbolically before specific numerical values are assigned to x."

I will caution you that some parts of the help/documentation are very misleading. But in twenty years I've only gotten them to correct one small item, and that was just a blatant typo, not any of the more serious misleading entries. I believe once they have written the documentation it is next to impossible for a mortal to get them to fix it.

 

[Bill Simpson]

I'm guessing from your original posting that it is possible that all your variables are greater than zero, and thus real, and that the following might be useful to you

In[1]:= Union[Simplify[DSolve[{-m 1/2 Cw \[Rho] A y'[t]^2+m g==y''[t], y'[0]==0, y[0]==h},y[t],t], A>0&&Cw>0&&g>0&&m>0&&\[Rho]>0&&t>0]]

Out[1]= {{y[t]->h + (2*Log[Cosh[m*t*Sqrt[A*Cw*g*\[Rho]/2]]])/(A*Cw*m*\[Rho])}}

So there aren't actually real and complex solutions in that case.

I'm thinking this might still be true even if you loosen up the conditions a little more.