Base-drag hack: Why not always use it?

[MetricRocketeer]

Hi TRF colleagues,

Over the last several hours, I have conducted many OpenRocket tests using the base-drag hack. (To a lesser extent, I have also been testing this issue with RockSim.)

For sure, when you have a short, wide rocket — a rocket whose length measures much less than 10 times its diameter — the base-drag hack yields significantly different results, and presumably of course those results indicate the rocket’s stability more accurately.

So far, so good.

But why stop with short, wide rockets? Perhaps applying the base-drag hack improves the stability accuracy results of any rocket. I can say that the wider the rocket is compared to its length the more the base-drag hack affects the stability reading. However, I have now determined that applying the hack to even a long, narrow rocket yields different results, although the results deviate proportionally less than they do for a short, wide rocket.

Incidentally, I understand that a rocket having a tail cone provides an exception. For example, applying the hack to the V2 would yield incorrect results, unless you truncate the aft cone used in the hack. (See Peak of Flight newsletter, Issue 157 [14 Mar 2006], pages 3–4.)

Bottom line: I thnk that I am suggesting to always use the hack. I suppose that one could counter the argument by saying that doing so would be more trouble than it’s worth.

Anyway, just a thought.

Thank you.

Stanley

 

[lakeroadster]

Always.. except rockets with tail cones.. as you discussed.. and except for cases such as .

Why muddy the waters? The 10:1 ratio provides a good rule of thumb.

 

[lakeroadster]

https://www.rocketryforum.com/threads/the-rocksim-openrocket-base-drag-trick.169558/

 

[BigMacDaddy]

Lately I have found a couple of models that simulated closer to my real-world experience with the base drag hack (even if they had boat tails). For example: https://www.rocketryforum.com/threads/agm-12c-bullpup-b.170306/

 

[Banzai88]

Always.. except rockets with tail cones.. as you discussed.. and except for cases such as .

Why muddy the waters? The 10:1 ratio provides a good rule of thumb.

Yup, been hashed out time and time and time again. I've even run the numbers recently and provided it to the OR development crew for the latest release.

Bottom line is that using the hack on greater than 10:1 rockets has shown in real world performance to be "not recommended "

 

[lakeroadster]

Lately I have found a couple of models that simulated closer to my real-world experience with the base drag hack (even if they had boat tails). For example: https://www.rocketryforum.com/threads/agm-12c-bullpup-b.170306/

Do you use an altimeter?

 

[BigMacDaddy]

Do you use an altimeter?

In this case it was just about stability not about altitude achieved.

Also I recessed engine slight so not sure how much GDS impacts CP.

Too many variables and broken assumptions.

 

[lakeroadster]

In this case it was just about stability not about altitude achieved.

Also I recessed engine slight so not sure how much GDS impacts CP.

Too many variables and broken assumptions.

I just bought an altimeter... pretty hard to judge how accurate Open Rocket simulations are without hard data.

In regard to stability... a bullpup has a lot going on.. tail cone, big fins, fin stand offs, multiple transitions and canards.

 

[Alan15578]

Hi TRF colleagues,

Over the last several hours, I have conducted many OpenRocket tests using the base-drag hack. (To a lesser extent, I have also been testing this issue with RockSim.)

For sure, when you have a short, wide rocket — a rocket whose length measures much less than 10 times its diameter — the base-drag hack yields significantly different results, and presumably of course those results indicate the rocket’s stability more accurately.

Stanley

Really? How did your tests compare to real instrumented wind tunnel testing?

I am not saying Tim's hack is completely useless, but it is badly named. What is the name of Barroman is the normal force coefficient slope of base drag?

 

[SolarYellow]

Incidentally, I understand that a rocket having a tail cone provides an exception. For example, applying the hack to the V2 would yield incorrect results, unless you truncate the aft cone used in the hack. (See Peak of Flight newsletter, Issue 157 [14 Mar 2006], pages 3–4.)

Just to save others some hassle, the relevant issues are #154 and #158.

 

[Back_at_it]

For what it's worth. I use OR primarily for stability and selecting delays. beyond that I use it for kicking around ideas for paint schemes.

That said I do find that the altitude predictions are pretty accurate for simple rocket designs. It tends to be a bit on the conservative side most of the time even if you enter in things like smooth paint, rounded fins etc. As an example, I have a fondness for the Bertha style rockets and have flown a ton of them. They are large enough to put an altimeter into and they fly well on everything from B6 to E20's. I've compared altitudes with the onboard altimeter and the actual recorded altitude is often 10% higher then the estimate.

 

[BigMacDaddy]

Ultimately for me I just wish that drag was incorporated into stability estimates -- drag of all components, depending on location on rocket.

I don't really care about altitude -- except for extreme cases like a rocket going less than 100' up.

 

[Alan15578]

Ultimately for me I just wish that drag was incorporated into stability estimates -- drag of all components, depending on location on rocket.

I don't really care about altitude -- except for extreme cases like a rocket going less than 100' up.

Well yes, but you should also care about extreme cases that tickle the waiver limit.

For me, I wish simulation programs would better estimate the drag, stability, and trim angle of attack of cameras strapped to the side of a rocket, and other asymmetries.

 

[lakeroadster]

Ultimately for me I just wish that drag was incorporated into stability estimates -- drag of all components, depending on location on rocket.

I don't really care about altitude -- except for extreme cases like a rocket going less than 100' up.

Well yes, but you should also care about extreme cases that tickle the waiver limit.

For me, I wish simulation programs would better estimate the drag, stability, and trim angle of attack of cameras strapped to the side of a rocket, and other asymmetries.

Open Rocket has so many awesome features and is invaluable IMO. Probably the most important is stability, followed by selecting the correct motor delay.

But back to the OP's question, adding the base drag hack to a rocket that exceeds the 10:1 length/diameter ratio is a valid question, but should not be assumed to be a good practice unless some validation work is done ahead of time.

 

[SolarYellow]

For what it's worth. I use OR primarily for stability and selecting delays. beyond that I use it for kicking around ideas for paint schemes.

That said I do find that the altitude predictions are pretty accurate for simple rocket designs. It tends to be a bit on the conservative side most of the time even if you enter in things like smooth paint, rounded fins etc. As an example, I have a fondness for the Bertha style rockets and have flown a ton of them. They are large enough to put an altimeter into and they fly well on everything from B6 to E20's. I've compared altitudes with the onboard altimeter and the actual recorded altitude is often 10% higher then the estimate.

This might be a good topic to split out into a different thread, but I've noticed an interesting "conflict" in OR. @neil_w

All the literature says that for substantiallly subsonic rockets like most LPR stuff, an elliptical nose cone has the lowest drag. But I recall it seeming that Open Rocket treats them as having more drag, not less, than a similarly-dimensioned ogive or other "pointy" shape. Have kind of wondered about that, but it's been awhile since I've worried about it.

Now I want to do some A-to-B testing. Pretty sure I have the parts around.

 

[neil_w]

I’ll defer that one to @JoePfeiffer.

 

[Back_at_it]

This might be a good topic to split out into a different thread, but I've noticed an interesting "conflict" in OR. @neil_w

All the literature says that for substantiallly subsonic rockets like most LPR stuff, an elliptical nose cone has the lowest drag. But I recall it seeming that Open Rocket treats them as having more drag, not less, than a similarly-dimensioned ogive or other "pointy" shape. Have kind of wondered about that, but it's been awhile since I've worried about it.

Now I want to do some A-to-B testing. Pretty sure I have the parts around.

Agreed. This spring I'm all for doing some back to back testing using one of my Bertha's. I can find a handful of C6-5's from the same lot and do back to back testing. Do three flights with the stock cone then swap over and do three more with a pointed cone and average the results.

Ya know..... All in the name of science or course. Won't take any enjoyment from it at all

If you guys would like to see that, let me know.

 

[neil_w]

Yup, been hashed out time and time and time again. I've even run the numbers recently and provided it to the OR development crew for the latest release.

Bottom line is that using the hack on greater than 10:1 rockets has shown in real world performance to be "not recommended "

At the same time, it makes no sense to apply the hack to a rocket with 9.999:1 ratio, and remove it for a rocket with 10.001:1 ratio. They are basically the same rocket and will have very different CP calculations.

If it is true that there is a value of aspect ratio that divides the "apply"/"don't apply" regions, then it should also be true that there is some sort of smooth transition between the two regions, which has (to my knowledge) never been defined.

It makes much more intuitive sense that the base drag effect on CP would apply equally to all rockets, except it would inherently contribute more meaningfully for stubbier rockets than for skinnier ones.

 

[JoePfeiffer]

All the literature says that for substantiallly subsonic rockets like most LPR stuff, an elliptical nose cone has the lowest drag. But I recall it seeming that Open Rocket treats them as having more drag, not less, than a similarly-dimensioned ogive or other "pointy" shape. Have kind of wondered about that, but it's been awhile since I've worried about it.

Hmmm, there may be an error here. The tech docs say subsonic pressure drag on a nose cone should be 0 for any reasonable shape. The code (it's in core/src/net/sf/openrocket/aerodynamics/barrowman/SymmetricComponentCalc.java) indeed shows a pressure drag of 0 up to various values near Mach 1 for most of them, but shows a CD of 0.110 for ellipsoidal up to Mach 1.2.

A comment in the code references a NASA tech report (R-100) for transonic and supersonic values; tracking down the reference I don't see any data in the graph for an ellipsoidal nose cone at speeds below Mach 1.2 (and it looks like about .11 at Mach 1.2).

It looks for all the world like there should be a point in the interpolator with Cd 0 at Mach 0.8....

https://github.com/openrocket/openrocket/issues/2061

 

[JoePfeiffer]

My reading of the argument in the POF article is that the base drag effect on stability actually applies to all rockets, it just gets more important as the rocket gets shorter and stubbier. Not sure about boat tails.

I'm not quite sure how people would test this with flight data. It isn't going to change the altitude of a flight, except in the sense that if a rocket is unstable it isn't going to go very high. The only test I can imagine is something like fly a rocket that shows unstable without the hack and stable with it, and see if it starts skywriting....

It seems like verifying it would be a great Science Fair project for an enterprising high school student with access to a wind tunnel.

 

[neil_w]

I'm not quite sure how people would test this with flight data. It isn't going to change the altitude of a flight, except in the sense that if a rocket is unstable it isn't going to go very high. The only test I can imagine is something like fly a rocket that shows unstable without the hack and stable with it, and see if it starts skywriting....

Yes, it's important to emphasize this yet again: when applied correctly, this hack only affects CP calculation (and hence stability), not drag (and hence apogee). It is, as Joe says, not easy to verify.

 

[SolarYellow]

Hmmm, there may be an error here. The tech docs say subsonic pressure drag on a nose cone should be 0 for any reasonable shape. The code (it's in core/src/net/sf/openrocket/aerodynamics/barrowman/SymmetricComponentCalc.java) indeed shows a pressure drag of 0 up to various values near Mach 1 for most of them, but shows a CD of 0.110 for ellipsoidal up to Mach 1.2.

A comment in the code references a NASA tech report (R-100) for transonic and supersonic values; tracking down the reference I don't see any data in the graph for an ellipsoidal nose cone at speeds below Mach 1.2 (and it looks like about .11 at Mach 1.2).

It looks for all the world like there should be a point in the interpolator with Cd 0 at Mach 0.8....

https://github.com/openrocket/openrocket/issues/2061

Pressure drag is only one component of drag. Any nose cone having a total Cd of 0 at any speed has to be an error.

I've scanned some chunks of TR R-100 and haven't seen any charts with Cd of any nose cone indicated at 0 yet.

 

[lakeroadster]

My reading of the argument in the POF article is that the base drag effect on stability actually applies to all rockets, it just gets more important as the rocket gets shorter and stubbier. Not sure about boat tails.

I'm not quite sure how people would test this with flight data. It isn't going to change the altitude of a flight, except in the sense that if a rocket is unstable it isn't going to go very high. The only test I can imagine is something like fly a rocket that shows unstable without the hack and stable with it, and see if it starts skywriting....

It seems like verifying it would be a great Science Fair project for an enterprising high school student with access to a wind tunnel.

I'm looking forward to flying my P-40 with an altimeter to see if the altitude is closer to the Open Rocket simulation with the cone left in place, or the cone deleted and the CG overridden and moved.

@neil_w has stated numerous times that the cone should be removed and the CG over-ridden in the simulation for accurate results

I feel it should be left in place for accurate results... it's massless and has no drag, why remove it?

Manually overriding the CG changes pitch and yaw rates, which means the simulation isn't realistic.

A few flights with an altimeter should put that difference of opinion to rest. Is the apogee nearer to 638 ft., or 772 ft?

Well... unless the altimeter reads 705 ft....

 

[neil_w]

@neil_w has stated numerous times that the cone should be removed and the CG over-ridden in the simulation for accurate results

I feel it should be left in place for accurate results... it's massless and has no drag, why remove it?

The guidance to remove the cone for flight sim was from when Cd override was not available. Now that it is, the base drag cone Cd should be overridden to zero and left in place.

 

[lakeroadster]

The guidance to remove the cone for flight sim was from when Cd override was not available. Now that it is, the base drag cone Cd should be overridden to zero and left in place.

Here's the OR 15 data... will the altimeter show closer to 690 ft or 810 feet?

One thing I do find a bit concerning is the OR 15.03 stability caliber of 1.05 -vs- the OR 22.02 stability caliber of 0.724

 

[JoePfeiffer]

Pressure drag is only one component of drag. Any nose cone having a total Cd of 0 at any speed has to be an error.

I've scanned some chunks of TR R-100 and haven't seen any charts with Cd of any nose cone indicated at 0 yet.

Sorry, apparently I wasn't clear. Of course the interpolator is only being used for pressure drag; friction drag is calculated elsewhere. The relevant figure from the report (12b) is, like everything else I'm referring to here, for pressure drag.

 

[MetricRocketeer]

... when applied correctly, this hack only affects CP calculation (and hence stability), not drag (and hence apogee).

Hi @neil_w and everyone else,

On the basis of your statement, would calling this technique a "stability hack" be better terminology than calling it a "base-drag hack"?

Stanley

 

[Alan15578]

Hi @neil_w and everyone else,

On the basis of your statement, would calling this technique a "stability hack" be better terminology than calling it a "base-drag hack"?

Stanley

Yes, but even as a "stability hack", it is on shaky ground. I prefer to simply call it Tim's hack.

 

[neil_w]

Hi @neil_w and everyone else,

On the basis of your statement, would calling this technique a "stability hack" be better terminology than calling it a "base-drag hack"?

"Stability hack" is very vague and doesn't connect specifically with base drag. But your implication is correct: simply calling it "base-drag hack" may lead some to think that the purpose is to add in base drag that is not being calculated, which is incorrect.

Yes, but even as a "stability hack", it is on shaky ground. I prefer to simply call it Tim's hack.

Well, base drag obviously does provide stability, otherwise saucers wouldn't fly... there should be *some* way to map that into an equivalent effect on CP. I'm not qualified to evaluate whether the "official" base drag CP hack is the best way to do it, but it seems to at least be in the ballpark, which is better than nothing I think.

 

[Gus]

Guys, I just want to say thanks for this fascinating thread. I rarely design stubby rockets but have been working on one lately and found when I added noseweight to get to stability margin of 1.0, the rocket is actually way more stable in swing tests than I would have thought. I kept reducing noseweight and retesting and was surprised at how much noseweight I could remove and remain string-test stable. This discussion helps me understand why. Again, thanks for such a nice informative discussion.