Open Rocket bug or is it me?

[Dan Kusmer]

2 questions for a single stage Open Rocket analysis:

1. Figure 1 shows the ejection charge happening 5 seconds after apogee. Figure 2 shows the ejection charge happening 5 seconds before apogee. Note that the vertical velocity and acceleration (circled in red) are not affected (they stay the same). Why?
2. Figure 2 and 3 shows the rocket free fall (terminal velocity before main chute deploys) at 50 ft/s. Figure 2 shows a cd = 1.55 main chute and figure 3 shows a cd = 0.10 main chute (more like a streamer). In figure 2 after the main chute deploys at 500 ft the decent slows down to 33 ft/s (slowing down was expected). In figure 3 after the main chute deploys at 500 ft the decent increases to 140 ft/s which is more than the rocket free fall. Why?

Thanks,
Dan Kusmer

 

[JoePfeiffer]

On the second one, when you're coming down on some recovery device the simulation only considers drag from the recovery device. So with a sane device, you end up with a little bonus from the rocket's drag. With an extreme case (like you're using here) it ends up being inaccurate.

I'll have to give some thought to the first question.

 

[H. Craig Miller]

Posting the OpenRocket design file may allow others to provide additional information in answer to your questions.

 

[Dan Kusmer]

Joe, are you saying that between apogee and 500 ft (chute not deployed) OpenRocket uses the rocket drag to calculate the decent rate and that between 500 ft and touchdown (chute deployed) OpenRocket only uses the chute drag and does not add in the rocket drag to calculate the decent rate?

H. Graig, attached are the 3 OpenRocket files.

Thanks, Dan Kusmer

 

[H. Craig Miller]

1. Figure 1 shows the ejection charge happening 5 seconds after apogee. Figure 2 shows the ejection charge happening 5 seconds before apogee. Note that the vertical velocity and acceleration (circled in red) are not affected (they stay the same). Why?

As to your first question, I opened Fig 1.ork and Fig 2.ork, and looked at the following tab: Motors & Configuration>Recovery where I observed that the deployment of the 20" parachute in each is set to "Altitude 500 ft + 1 sec". Deployment using this setting ignores (overrides) the motor ejection charge; OpenRocket cannot discern what the motor ejection gas is being utilized for, the software implements your setting when you enter the actual point/time that the parachute will be deployed.

2. Figure 2 and 3 shows the rocket free fall (terminal velocity before main chute deploys) at 50 ft/s. Figure 2 shows a cd = 1.55 main chute and figure 3 shows a cd = 0.10 main chute (more like a streamer). In figure 2 after the main chute deploys at 500 ft the decent slows down to 33 ft/s (slowing down was expected). In figure 3 after the main chute deploys at 500 ft the decent increases to 140 ft/s which is more than the rocket free fall. Why?

In addition to the comments of JoePfeiffer above, I compared two simulated flights, the one on the left with parachute deployment at 500 ft + 1 sec and the one on the right with parachute deployment at apogee +1 sec:

​

The ground hit velocity of the Fig 2 left simulation is 124 ft/sec and the Fig 3 right simulation is 136 ft/sec. But, a comparison of the plots does confirm your observation that the freefall velocity of the left is less than the ground hit velocity of the right simulation. One explanation for this outcome may be the fact that once a rocket reaches apogee and begins to freefall, it may not be oriented perpendicular to the ground for some time, or for reasons based upon many other factors.

More important for accurate simulations is the use of realistic drag coefficient (Cd) parameters. The average performance parachute has a Cd of about .80. The average performance streamer has a Cd of about .09. Unless you are using some type of mesh, it is improbable that any parachute would have the unusually low Cd of .10 that you entered. If you change your parachute parameters to a streamer with a Cd of .09, then the descent rate in Fig 2 and Fig 3 are both 124 ft/sec., as would be expected.

As to your 33 ft/sec descent rate in Fig 2, most descent rates are between 14 and 20 ft/sec. At 33 ft/sec, a significant amount of damage is likely.

 

[JoePfeiffer]

Joe, are you saying that between apogee and 500 ft (chute not deployed) OpenRocket uses the rocket drag to calculate the decent rate and that between 500 ft and touchdown (chute deployed) OpenRocket only uses the chute drag and does not add in the rocket drag to calculate the decent rate?

Yes. The expectation is that the rocket won't be adding much to the drag from the parachute, so it's ignored. This does mean that if you have an unreasonably small parachute the results get pretty inaccurate.

I believe Craig has found the issue with the early/late delay charge.

 

[Dan Kusmer]

H. Graig and Joe, thanks for your time and responses on this. The +1 sec was an accident, inconsequential, and I've since switched it back to 0 sec.

I switched the recovery device to "never deploy" and ran 3 simulations, one with ejection 5s after apogee, 5s before apogee, and no ejection charge. As you can see from graphs Fig 4a, Fig 4b, and Fig 4c the velocity and acceleration curves don't change. I assume the ejection charge as no affect in this situation. Do you agree? It does have an affect if linked to the chute/streamer deployment, and perhaps dual deployment, 2 stage, etc. which I'm just starting to get into.

a streamer with a Cd of .09, then the descent rate in Fig 2 and Fig 3 are both 124 ft/sec., as would be expected.

Fig 4d shows the rocket freefall at a constant 50 ft/s between 1400 and 500 ft. At 500 ft a streamer (cd=.09) deploys and the decent speeds up until it hits the ground at 186 ft/s. I did not expect this. My intuition says if the freefall is 50 ft/s and a streamer is deployed, the rocket decent rate will either slow down or worst case remain the same (streamer is ineffective).

it may not be oriented perpendicular to the ground

However, your rocket orientation comment got me to thinking. Fig 4e shows the rocket vertical orientation over time (didn't know this was available until today). I always thought that at apogee (2000 ft) the rocket was horizontal (0 deg, flat). According to OR it's at 60 deg and doesn't reach 0 deg (flat, pancake) until 1400 ft and remains flat until 500 at which point the orientation curve disappears. I'm assuming once the streamer is deployed the rocket re-orientates to vertical (0 deg) thus reducing rocket drag and assuming the streamer contributes negligible drag the decent rate will probably increase.

I did a few calculations. The rocket weighs 5 pounds (fuel spent) and has a side profile area of 166 in^2. At 50 ft/s this gives the rocket coefficient drag (when its flat) of Cd=1.45. The rocket cross-sectional area is 7.6 in^2 (3.12"OD), a circular plate has a drag coefficient of Cd=1.12, so the rocket decent rate in this configuration calculates to 265 ft/s.

 

[JackC]

I entered a Rocksim file for a Performance Rocketry 5.5 inch Nike Smoke and converted it into Open Rocket. The program simulated the rocket to Mach .85 on an M1419. I flew it today and it bettered the sim altitude by 2000 feet and achieved Mach 1.6. Has anyone else run into a discrepancy like this?

 

[dhbarr]

I entered a Rocksim file for a Performance Rocketry 5.5 inch Nike Smoke and converted it into Open Rocket. The program simulated the rocket to Mach .85 on an M1419. I flew it today and it bettered the sim altitude by 2000 feet and achieved Mach 1.6. Has anyone else run into a discrepancy like this?

Sure. The #1 divergence I see is usually mass, #2 is roughness/finish.

Did your as-built mass match the sim?

Were your sim fins set to airfoil?

What was the finish set to on all your parts?

 

[manixFan]

I entered a Rocksim file for a Performance Rocketry 5.5 inch Nike Smoke and converted it into Open Rocket. The program simulated the rocket to Mach .85 on an M1419. I flew it today and it bettered the sim altitude by 2000 feet and achieved Mach 1.6. Has anyone else run into a discrepancy like this?

Not to derail the thread too much, but to follow on to what dhbarr said, the finish setting plays a huge part in the estimated altitude, especially as the rocket speed increases and drag becomes a bigger factor in performance. The default value for the finish is 'Regular paint', which tends to underperform altitude in actual flights. I find that with my MD rockets, where I take a fair amount of effort to get a good finish, I have to use the polished setting to get a good estimate. The results can vary by 20% or more based on finish and expected speed, so it's import to adjust this setting. As you adjust it to smooth and then polished, rerun the sims and see which one gives you a better concordance.


Tony


you can see the available finish settings below - choose the appropriate one and then use the 'Set for all' button to apply to the entire rocket:

 

[JackC]

Sure. The #1 divergence I see is usually mass, #2 is roughness/finish.

Did your as-built mass match the sim?

Were your sim fins set to airfoil?

What was the finish set to on all your parts?

I followed your advice and I think it worked. I think the altimeter gave me an erroneous velocity reading. Thanks for your help!

 

[JackC]

Not to derail the thread too much, but to follow on to what dhbarr said, the finish setting plays a huge part in the estimated altitude, especially as the rocket speed increases and drag becomes a bigger factor in performance. The default value for the finish is 'Regular paint', which tends to underperform altitude in actual flights. I find that with my MD rockets, where I take a fair amount of effort to get a good finish, I have to use the polished setting to get a good estimate. The results can vary by 20% or more based on finish and expected speed, so it's import to adjust this setting. As you adjust it to smooth and then polished, rerun the sims and see which one gives you a better concordance.


Tony


you can see the available finish settings below - choose the appropriate one and then use the 'Set for all' button to apply to the entire rocket:
View attachment 504618

Thanks!