Simulating short, wide rockets in OpenRocket

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

MetricRocketeer

Member of the US Metric Association
TRF Supporter
Joined
May 31, 2018
Messages
690
Reaction score
186
Location
Maryland
Hi TRF colleagues,

I was reading the thread entitled "LOC Warlock Build. Rocket for my Level 1." In that thread, Post #41 by @Banzai88 reminded me of the technique for simulating short, wide rockets by adding a zero-weight cone of certain dimensions to the aft end of your rocket. I myself am hoping to purchase and build a LOC Warlock and someday to use that rocket for an L2 attempt. Thus, I thought that I should add the cone to my LOC Warlock design that I made in OpenRocket.

Proceeding to do that, I encountered a problem. I made the cone by adding to the aft end of the rocket a transition which has its narrow end (that is, a point) forward and its wide end in the back.

Then, however, OR gave me a discontinuity warning. And I could not just ignore the warning, because I was now unable to run any simulation.

So, please, what should I do? How can I add this cone and still be able to run simulations in OR?

Thank you.

Stanley
 
Hi TRF colleagues,

I was reading the thread entitled "LOC Warlock Build. Rocket for my Level 1." In that thread, Post #41 by @Banzai88 reminded me of the technique for simulating short, wide rockets by adding a zero-weight cone of certain dimensions to the aft end of your rocket. I myself am hoping to purchase and build a LOC Warlock and someday to use that rocket for an L2 attempt. Thus, I thought that I should add the cone to my LOC Warlock design that I made in OpenRocket.

Proceeding to do that, I encountered a problem. I made the cone by adding to the aft end of the rocket a transition which has its narrow end (that is, a point) forward and its wide end in the back.

Then, however, OR gave me a discontinuity warning. And I could not just ignore the warning, because I was now unable to run any simulation.

So, please, what should I do? How can I add this cone and still be able to run simulations in OR?

Thank you.

Stanley
You only use the "cone" to get stability. After you know it is stable, delete the cone for flight simulation.


On a side note, I also have never had a discontinuity warning stop me from simming something.
 
You only use the "cone" to get stability. After you know it is stable, delete the cone for flight simulation.
I think you are supposed to leave it in - especially if adding wind to the sim.

I know the cone is an operational hack to move the effective placement of the base drag to slightly behind the rocket, rather than right at the base. But I don’t think it doubles up the base drag. I suppose it might incorrectly add extra frontal / transition drag.
 
I seem to get more realistic Sims leaving the base drag cone in there....but my sample size is low and I'm using an Estes altimeter, so scientific my results are not.
 
I seem to get more realistic Sims leaving the base drag cone in there....but my sample size is low and I'm using an Estes altimeter, so scientific my results are not.

I always leave the cone in place during the simulation. Don't forget to override the mass of the cone to zero.

If the design is marginally unstable without the cone, it may still simulate without the cone in place, but the data is bogus.
If the design is very unstable without the cone, the simulation will show it as such and the simulation will show an erratic flight when you look at the plot.

Let's use Red Columbine rocket as a case study.

I built this rocket and it passed a swing test. It then flew successfully on a D12 and was recovered undamaged. The flight was very stable, with a guestimated apogee of about 300 feet... just as the simulation shows with the base drag hack cone in place.​

2022-11-15 ORSimWith Base Drag Hack.jpg
2022-11-15 ORSim PLot With Base Drag Hack.jpg

Now let's remove the base drag hack cone. That simulation shows an unstable flight with an apogee of about 100 feet. The rocket ground hits before the chute is ejected. The simulation does not represent what actually occurred during the flight.​

2022-11-15 ORSim Without Base Drag Hack.jpg
2022-11-15 ORSim PLot Without Base Drag Hack.jpg

Here are the links to the Apogee Peak Of Flight Newsletters that explain how to do the simulations:

___________________________________________________________________________________________________________________________________​
002.JPGColumbine Launch 004.jpg




Columbine Launch 006.JPGColumbine Launch 007.JPG
 
Last edited:
I greatly enjoy rehashing this issue over and over.

OR already calculates base drag and factors it into the simulation. What it does *not* do is calculate the effect of base drag on CP. Therefore it is most "correct" to use the hack to determine stability, and then remove it for simulation. Otherwise you are adding extra drag... I do not know how much effect this has in practice, although for @bobbyg23 's rocket it seems to have made quite a big difference.

After you remove the hack, the rocket may no longer be stable, and then it won't sim correctly. So, after removing the hack, you should override CG to achieve equivalent stability as when the hack was installed. Changing the CG itself could affect the sim, but for a stable rocket on a typical flight (where the rocket is not rotating around it's CG) it shouldn't matter.

Of course, anyone is free to use the program any way they want, using whatever method works best for them. But that is the theory behind it.

This whole process is obviously gross, and the operation should be built into the program so you don't need to go through all these shenanigans and we don't need to be having this discussion over and over. One day, I hope it will be.
 
I greatly enjoy rehashing this issue over and over.

OR already calculates base drag and factors it into the simulation. What it does *not* do is calculate the effect of base drag on CP. Therefore it is most "correct" to use the hack to determine stability, and then remove it for simulation. Otherwise you are adding extra drag... I do not know how much effect this has in practice, although for @bobbyg23 's rocket it seems to have made quite a big difference.

After you remove the hack, the rocket may no longer be stable, and then it won't sim correctly. So, after removing the hack, you should override CG to achieve equivalent stability as when the hack was installed. Changing the CG itself could affect the sim, but for a stable rocket on a typical flight (where the rocket is not rotating around it's CG) it shouldn't matter.

Of course, anyone is free to use the program any way they want, using whatever method works best for them. But that is the theory behind it.

This whole process is obviously gross, and the operation should be built into the program so you don't need to go through all these shenanigans and we don't need to be having this discussion over and over. One day, I hope it will be.

You're comments about removing the massless cone, and then moving the cg to obtain the same stability as when the massless cone is added.... yields the exact same results as leaving the massless base cone. :dontknow:
 
You're comments about removing the massless cone, and then moving the cg to obtain the same stability as when the massless cone is added.... yields the exact same results as leaving the massless base cone. :dontknow:
To what roughness do you set your massless cone? And do you do pi or three?
 
You're comments about removing the massless cone, and then moving the cg to obtain the same stability as when the massless cone is added.... yields the exact same results as leaving the massless base cone. :dontknow:
Not in open rocket. When you leave the cone on, it greatly reduces the altitude. If you over ride the cg, the altitude stays the same.
 
One of you is using an odd roc to demonstrate, one of you is using a 3FNC (which is what the OP is asking about). Odd Roc vs. 3FNC = MIGHT be apples/oranges with the sims?

I've never built nor simmed an Odd Roc short stubby, but I know for certain that with a conventional 3FNC, I've always done it as neil_w and bobbyg23 = install the phantom cone to adjust the CP, remove the cone and manually override the CG to achieve similar stability margin, and then run the sim for altitude and motor eject delay predictions, and been spot on for drilling motor eject timing.

When I first started and left the cone on for altitude and delay prediction sims, I had early ejection every.single.time. and zippered/destroyed a few rockets and parachutes. I gave up and figured that short stubbies were going to be beyond my skill level and ability to understand.

Once an old timer told me to remove the cone for altitude and motor eject delay predictions, I've not since had an early ejection (or a late one) and have not had a zipper due to early eject.

YMMV, but I know what works for me.
 
Last edited:
I greatly enjoy rehashing this issue over and over.

OR already calculates base drag and factors it into the simulation. What it does *not* do is calculate the effect of base drag on CP. Therefore it is most "correct" to use the hack to determine stability, and then remove it for simulation. Otherwise you are adding extra drag... I do not know how much effect this has in practice, although for @bobbyg23 's rocket it seems to have made quite a big difference.

After you remove the hack, the rocket may no longer be stable, and then it won't sim correctly. So, after removing the hack, you should override CG to achieve equivalent stability as when the hack was installed. Changing the CG itself could affect the sim, but for a stable rocket on a typical flight (where the rocket is not rotating around it's CG) it shouldn't matter.

Of course, anyone is free to use the program any way they want, using whatever method works best for them. But that is the theory behind it.

This whole process is obviously gross, and the operation should be built into the program so you don't need to go through all these shenanigans and we don't need to be having this discussion over and over. One day, I hope it will be.

Not in open rocket. When you leave the cone on, it greatly reduces the altitude. If you over ride the cg, the altitude stays the same.

Massless cone vs the cg moved. Looking at the data in a real world perspective, the difference between the two simulations is "nearly" identical.

CG Moved vs Massless Cone.jpg
2022-11-15 ORSimWith Base Drag Hack.jpg
2022-11-15 ORSim With Modified CG to simulate Base Drag Hack.jpg
 
One of you is using an odd roc to demonstrate, one of you is using a 3FNC (which is what the OP is asking about). Odd Roc vs. 3FNC = MIGHT be apples/oranges with the sims?

I've never built nor simmed an Odd Roc short stubby, but I know for certain that with a conventional 3FNC, I've always done it as neil_w and bobbyg23 = install the phantom cone to adjust the CP, remove the cone and manually override the CG to achieve similar stability margin, and then run the sim for altitude and motor eject delay predictions, and been spot on for drilling motor eject timing.

When I first started and left the cone on for altitude and delay prediction sims, I had early ejection every.single.time. and zippered/destroyed a few rockets and parachutes. I gave up and figured that short stubbies were going to be beyond my skill level and ability to understand.

Once an old timer told me to remove the cone for altitude and motor eject delay predictions, I've not since had an early ejection (or a late one) and have not had a zipper due to early eject.

YMMV, but I know what works for me.
Interesting. Can you post up the data that shows the differences in delay?
 
Last edited:
This is a MadCow cowabunga. 4 inch diameter, 28 3/4 inches long, putting it within the 'stubby' definition of less than 10:1 Length to Diameter
Motor is a conservative H125 classic for a flight above 2000 feet, about perfect for a pop and drop at one of my home fields.



1 rocket no motor no cone.JPG

Rocket no motor no cone static stability .937

2 rocket motor no cone.JPG

Rocket no cone motor installed stability .5

3 rocket no cone flight.JPG

Rocket flight no cone (forgot to adjust the cg, but simmed fine) to 2693 feet optimum delay 10.3 seconds.

4 rocket cone no motor.JPG

Rocket with cone static stability 1.59

5 rocket cone motor.JPG

Rocket with motor with cone stability 1.15

6 rocket cone flight.JPG

Rocket flight with cone 2027 feet optimum delay 8.29 seconds.

Difference in predicted altitude = 666 feet
Difference in optimum delay = 2.01 seconds

Make of it what you will, but in actual rocket flight of THIS rocket it made a difference between the zipper I got 2 flights in a row, and NO ZIPPER EVER AGAIN after I repaired it the second time and started using sims for delay and altitude prediction REMOVING the cone.
 
Last edited:
Anecdote; my Minie Magg (Beaker) with H130.

OR w/ base drag cone: 827' - 5.6s delay
OR w/out base drag cone: 943' - 6.2s delay
Thrustcurve: 746' - 5.2s delay

Flight. Altimeter failed to record. Definitely not 943' and closer to 827' or 746'. Chute release was set to 500'. Thrustcurve may have been closest on altitude and OR w/ base cone closest on delay. I had the delay drilled for 6s. Looks like it came out closer to 7.

My 4" Big Daddy and 4" Alien Space Probe seem closer to reality (and to Thrustcurve) with the cone in place.

The main lesson I have from this is I need to get a better altimeter so I can be certain of what I'm looking at :)
 
This is a MadCow cowabunga. 4 inch diameter, 28 3/4 inches long, putting it within the 'stubby' definition of less than 10:1 Length to Diameter
Motor is a conservative H125 classic for a flight above 2000 feet, about perfect for a pop and drop at one of my home fields.



View attachment 546457

Rocket no motor no cone static stability .937

View attachment 546458

Rocket no cone motor installed stability .5

View attachment 546460

Rocket flight no cone (forgot to adjust the cg, but simmed fine) to 2693 feet optimum delay 10.3 seconds.

View attachment 546461

Rocket with cone static stability 1.59

View attachment 546462

Rocket with motor with cone stability 1.15

View attachment 546463

Rocket flight with cone 2027 feet optimum delay 8.29 seconds.

Difference in predicted altitude = 666 feet
Difference in optimum delay = 2.01 seconds

Make of it what you will, but in actual rocket flight of THIS rocket it made a difference between the zipper I got 2 flights in a row, and NO ZIPPER EVER AGAIN after I repaired it the second time and started using sims for delay and altitude prediction REMOVING the cone.

Did you run a simulation with no cone at all, but where you moved the cg to obtain the 1.15 stability margin?

That's what @neil_w and others are proposing as the correct method.
 
Anecdote; my Minie Magg (Beaker) with H130.

OR w/ base drag cone: 827' - 5.6s delay
OR w/out base drag cone: 943' - 6.2s delay
Thrustcurve: 746' - 5.2s delay

Flight. Altimeter failed to record. Definitely not 943' and closer to 827' or 746'. Chute release was set to 500'. Thrustcurve may have been closest on altitude and OR w/ base cone closest on delay. I had the delay drilled for 6s. Looks like it came out closer to 7.

My 4" Big Daddy and 4" Alien Space Probe seem closer to reality (and to Thrustcurve) with the cone in place.

The main lesson I have from this is I need to get a better altimeter so I can be certain of what I'm looking at :)

Did you run a simulation with no cone at all, but where you moved the cg to obtain the same stability margin as shown when the simulation has the cone?

That's what @neil_w and others are proposing as the correct method.

Base Drag Hack Moving the CG.jpg
 
Last edited:
Did you run a simulation with no cone at all, but where you moved the cg to obtain the 1.15 stability margin?

That's what @neil_w and others are proposing as the correct method.
Adjusted CG as you requested, with no cone but with the CG manually adjusted to provide the same stability margin as show WITH a cone.

Essentially the same result!

Predicted altitude 2689
Optimum delay 10.1 seconds

Screenshot 2022-11-16 192210.png

I had simply forgotten to do that earlier, but since the rocket was sufficiently stable, it didn't matter for the sim.

And my notes show that my various ride along altimeters are always within about 5% (usually much less, average of about 2%) of my sims. So, that's why I remove the cone to estimate what I need to drill the delay to and what altitude I can expect. Since I rarely launch these rockets over 3K feet, the entire flight is well within what I can see with the naked eye throughout the flight, and timing is always spot on (within the tolerance of the delay).

All mind/computer sim aside, ever since I started doing it this way, I have had zero issues with early ejection in nose pop short stubby 3 or 4 FNC rockets.

YMMV, but I'm solid that it works for me in my rockets.
 
Last edited:
Adjusted CG as you requested, with no cone
Predicted altitude 2689
Optimum delay 10.1 seconds

View attachment 546513

I had simply forgotten to do that earlier, but since the rocket was sufficiently stable, it didn't matter for the sim.

And my notes show that my various ride along altimeters are always within about 5% of my sims.
Thanks!

For the successful flights, what were those actual altimeter readings and which delays did you use?
 
Thanks!

For the successful flights, what were those actual altimeter readings and which delays did you use?

I always use the delay suggested by OR WITHOUT the cone.

Estes and JL altimeters have always shown within 5% (usually within 2%) of predicted altitude WITHOUT the cone.
 
Without the cone... and without the cg correction?
Without the cone, with the CG correction (in the above example in post 20 where I forgot to transpose the CG correction, the rocket was already sufficiently stable to sim just fine, might not be the case with all rockets, especially OddRocs. The adjusted CG sim is shown in post 26 and represents nearly identical results).

The whole point of the cone is to get the CG correction. Delete the cone, transpose the CG with the manual override, and then run the flight sim.

Leaving the cone on (for me) has ALWAYS resulted in early deployment. Thus, I use it as a data collection tool to advise about design, NOT to advise about flight.
 
Without the cone, with the CG correction (in the above example in post 20 where I forgot to transpose the CG correction, the rocket was already sufficiently stable to sim just fine, might not be the case with all rockets, especially OddRocs. The adjusted CG sim is shown in post 26 and represents nearly identical results).

The whole point of the cone is to get the CG correction. Delete the cone, transpose the CG with the manual override, and then run the flight sim.

Leaving the cone on (for me) has ALWAYS resulted in early deployment. Thus, I use it as a data collection tool to advise about design, NOT to advise about flight.
Thanks, much appreciated.

My only issue with moving the cg is that can cause other sim data, such as pitch rate, to be incorrect. But for picking delays, it sounds like moving the cg is the accurate approach.
 
Here's an example with it left in.
Sim...
1668646537927.png

Sim vs Proton: sim is the red line, Proton is the blue. The difference is in the burn length of the motor
1668646714848.png
 
Back
Top