# Open Rocket d(m*V)/dt Calculation

## Time rate of change of Momentum calculation is d(m*V)/dt = Summation of Forces.

• ### d(m*V)/dt = m*dV/dt + V*dm/dt - should it include the second term?

• Total voters
1

#### Darrell Weber

##### Member
Newton's Second Law is the time rate of change of Momentum equals the summation of forces (which is a vector equation).
It appears that Open Rocket calculates d(m*V)/dt = m*dV/dt.
Is this correct?
Should it be d(m*V)/dt = m*dV/dt + V*dm/dt?
If not, why not?

The first form as used by Open Rocketry is correct.

#### Bat-mite

##### Rocketeer in MD
If I read correctly, the OP is looking for the "why."

#### Darrell Weber

##### Member
If I read correctly, the OP is looking for the "why."
Yes, I am looking for why the changing mass term is not included.

#### Homer_S

##### Well-Known Member
Assuming constant mass allows treating mass as a scalar. This is valid as long as the propellant mass is low compared to the total mass. So this works for BP and composite motors. Transitioning to hybrid, you might need more sophistication. Ditto for SpaceX...

Homer

Sometimes the second way is written in physics text books, which is a simple application of the product rule for processing derivatives. You could do this, but it involves some interpretation. For example, writing the second way for a closed system makes sense, if you say there is no "net force" and the change in total momentum of the system is zero, i.e.,

m dv/dt + v dm/dt = 0
or
m dv/dt = - v dm/dt

which is saying the rocket moves forward by expelling mass backward (assuming no gravity or air drag). It is more practical for model rockets simulations to say F = m dv/dt or F=ma and then find a formula or thrust-time curve for the rocket motor and include air drag and gravity to find the net force.

#### Darrell Weber

##### Member
I looked over various links cited above, and the F = m*a =m*dV/dt is a simplification to get reasonable answers.

Many years ago I wrote a trajectory analysis code in fortran that employs similar equations that Open Rocket uses. Clearly Open Rocket is an ideal Model Rocketry design tool with its visual and ease of inputting components and calculating results. So when I came across Open Rocket two years ago, and read its documentation, I started using it.
Recently I decided to compare the results of Open Rocket with my Trajectory analysis code, and I always found that my maximum velocity and drag were higher than Open Rocket. So after thoroughly investigating the thrust curves, the 1976 US Standard Atmosphere, the drag calculation procedure, and the numerical integration scheme I am using, I was baffled that even though all the parts were producing similar results (even about the same Cd) the overall answer was different.
So I decided to omit the m*dV/dt part of the equation. Once I did that, my results and Open Rocket results came in to close agreement (still slight differences in Cd and therefore V(t) and h(t)).

So I now have two options in my old Fortran Trajectory code:
First, what I have been using d(m*V)/dt
Vip = [ mi * vi + sum of Forces( Thrust, Gravity & Drag ) * delta time ] / mip
and
Second, what Open Rocket uses, m*dV/dt, omitting the V*dm/dt term
Vip = vi + sum of Forces( Thrust, Gravity & Drag ) * delta time ] * 2 / ( mip + mi )

As I see it, the second option is a simplification, that will produce reasonable results, but the first option should be the more accurate analysis.
If I am wrong it would be helpful for me to understand why.

#### tHoagland

##### Rocket Builder
TRF Supporter
Assuming constant mass allows treating mass as a scalar. This is valid as long as the propellant mass is low compared to the total mass. So this works for BP and composite motors. Transitioning to hybrid, you might need more sophistication. Ditto for SpaceX...

Homer
Isn't mass always a scalar? There is no direction associated with mass...

#### Darrell Weber

##### Member
Isn't mass always a scalar? There is no direction associated with mass...
Yes, mass is a scalar and velocity as well as forces are vectors. I think the statement is that if mass is reasonably constant (small engine propellant mass compared to overall rocket and engine mass) then the V*dm/dt can be neglected.

#### Darrell Weber

##### Member
Isn't mass always a scalar? There is no direction associated with mass...
Yes, mass is a scalar and velocity as well as forces are vectors. I think the statement is that if mass is reasonably constant (small engine propellant mass compared to overall rocket and engine mass) then neglecting the V*dm/dt is ok.

#### tHoagland

##### Rocket Builder
TRF Supporter
Agreed, I just wanted to make we clarified that mass is always a scalar, but not always a constant.

The governing equation for non-relativistic motion is:

m dv/dt = F - D - g

where F is thrust, D is air drag, and g is the acceleration of gravity

#### cerving

##### Owner, Eggtimer Rocketry
TRF Supporter
Since OR knows the thrust curve of the motor and presumably the mass of the propellant, wouldn't it be reasonable to reduce the total mass in each time interval by the propellant mass expended in that time interval? Yes, for an Estes BP motor it's not relevant, however for a large MD rocket that mass can be very significant. For all I know, they already do that...

#### daveyfire

##### Piled Higher and Deeper
I haven't dug into the code at all, but I'm guessing Chris is right; m is updated at the beginning/end of the timestep and so, within each timestep when dv/dt is being computed, dm/dt = 0 so v(dm/dt) = 0. Eh? That's how I've written my simulations in the past, but I'm pretty simple (i.e., I just do Euler integration and a quick grid convergence check for reasonableness vs. using a predictor-corrector method like OR probably does).

#### Buckeye

##### Well-Known Member
TRF Supporter
Since OR knows the thrust curve of the motor and presumably the mass of the propellant, wouldn't it be reasonable to reduce the total mass in each time interval by the propellant mass expended in that time interval? Yes, for an Estes BP motor it's not relevant, however for a large MD rocket that mass can be very significant. For all I know, they already do that...
Yes, they do that. Plot mass vs. time to see.

So, OR is calculating (numerically):

m(t)*dV(t)/dt

which is good enough? I'm not sure.

#### Buckeye

##### Well-Known Member
TRF Supporter
I haven't dug into the code at all, but I'm guessing Chris is right; m is updated at the beginning/end of the timestep and so, within each timestep when dv/dt is being computed, dm/dt = 0 so v(dm/dt) = 0. Eh? That's how I've written my simulations in the past, but I'm pretty simple (i.e., I just do Euler integration and a quick grid convergence check for reasonableness vs. using a predictor-corrector method like OR probably does).
I'm sure OR uses 4th order Runge-Kutta, which is the most popular method for ODEs. It is more straightforward than predictor-corrector, and while explicit, is easily stable for our rocket trajectory solution.

If OR is solving numerically the differential equation:

m dv/dt = F - D - g

which is ma = sum of forces, then it is correct. If it is solving something else, then it is wrong.

#### Darrell Weber

##### Member
I really appreciate all of the discussions, comments, and suggestions. This has been very helpful to me. Thanks to all of you for taking the time to discuss this with me.

I have been using a Predictor corrector method of solving ODE's in my Fortran Trajectory code. But have used Runge-Kutta in a variety of other numerical solutions.

And yes, Open Rocket uses m(t)*dV(t)/dt.

I was getting as much as a 6% difference in Vmax, and 2% difference in Hmax across a spectrum of engines (18mm, 24mm and 29mm - A8-3, B6-4, C6-5, D12-5, E9-6, E12-6, E16-6, F10-7, F15-6, F26-6, F30-7, F5-6, G40-7 and G80-7) when I used d(m(t)*V(t))/dt vs m(t)*dV(t)/dt.

#### OverTheTop

##### Well-Known Member
TRF Supporter
Since the simulators break up the time continuum into small dt values, ie limit of dt approaching zero, the change in mass is quite small (as cerving said) relative to the entire mass of the rocket, so simplifying by dropping the second term is probably a valid approach most of the time. May introduce more errors in high mass-fraction rockets as has been mentioned I think.

The correct equation is m dv/dt = F - D - g. It doesn't make a difference if it is a small model rocket with a small mass change or the Falcon 9 with a very large mass change.

#### Homer_S

##### Well-Known Member
Yes, mass is a scalar and velocity as well as forces are vectors. I think the statement is that if mass is reasonably constant (small engine propellant mass compared to overall rocket and engine mass) then the V*dm/dt can be neglected.
Agreed... I should have said "constant".

Homer

This is an attempt to answer the "why" at the beginning of this thread. One could go back to the equation:

m*dv/dt + v*dm/dt =0

in an inertial reference frame with a velocity that is instantaneously the same velocity as the rocket. In this case the velocity in the second term needs to be the exhaust velocity or v = ve and the equation becomes

m*dv/dt + ve*dm/dt =0

This may not be what the original question was asking, but this equation works. Note that "m" in the first term is the instantaneous rocket mass.

A more conventional approach would be to use F = ma = m*dv/dt for the rocket in any inertial reference frame and the rocket thrust:

F = -ve*dm/dt + Ae (Pe - Pa)

where Ae = exit area, Pe=exit pressure, and Pa=ambient or atmospheric pressure. The equation for the rocket thrust can be made much longer using 1-D gas dynamics and the perfect gas law. If the rocket is operating in a vacuum, then Pe=Pa. Assuming no gravity the equation becomes:

m*dv/dt = -ve*dm/dt

This equation can be integrated analytically to yield the universally accepted Tsiolkovsky equation.

https://en.wikipedia.org/wiki/Tsiolkovsky_rocket_equation

#### rcktnut

##### Well-Known Member
This is my attempt to answer the why at the beginning of this thread: Because this is a hobby, nobody is going to put their rockets into orbit or towards a deep space target, that's why. Calcs are good enough for us.