Hi @Alan15578,
With all respect, should you even be calling it "Tim's hack"? After all, Tim Van Milligan wasn't even the author of the article, although he may agree with its thesis.
Stanley
Base-drag hack: Why not always use it?
- Thread starter MetricRocketeer
- Start date
Help Support The Rocketry Forum:
With all respect, should you even be calling it "Tim's hack"? After all, Tim Van Milligan wasn't even the author of the article, although he may agree with its thesis.
Stanley
Hi TRF colleagues,
Since I made the first post on this topic, about one week has passed. I believe that my post has generated a useful discussion.
As I see it, many rocketeers — but not all, I acknowledge — believe that the base-drag hack yields a more accurate simulation for the flight of a rocket whose length-to-diameter ratio is less than 10:1.
Now, I would like to draw attention especially to neil-w’s comment.
Proceeding from that position, I say that always applying the base-drag hack, irrespective of a rocket’s length-to-diameter ratio, is not unreasonable. You may well argue that applying the hack to a rocket whose length-to-diameter ratio exceeds 10:1 is not worth the effort.
Nonetheless, I contend that applying the hack always yields a more accurate simulation.
Stanley
Since I made the first post on this topic, about one week has passed. I believe that my post has generated a useful discussion.
As I see it, many rocketeers — but not all, I acknowledge — believe that the base-drag hack yields a more accurate simulation for the flight of a rocket whose length-to-diameter ratio is less than 10:1.
Now, I would like to draw attention especially to neil-w’s comment.
Here is what I take from this statement — choosing a 10:1 ratio, or any ratio for that matter — is arbitrary.
Proceeding from that position, I say that always applying the base-drag hack, irrespective of a rocket’s length-to-diameter ratio, is not unreasonable. You may well argue that applying the hack to a rocket whose length-to-diameter ratio exceeds 10:1 is not worth the effort.
Nonetheless, I contend that applying the hack always yields a more accurate simulation.
Stanley
Last edited:
- Joined
- Jul 15, 2015
- Messages
- 3,959
- Reaction score
- 2,725
No way can you make an educated unqualified statement like that without empirical evidence (extraordinary claims require extraordinary proof), and frankly it's marginally dangerous to do so lacking such evidence since the CP shift can be nearly 1 full caliber!
The line had to be drawn somewhere with regards to L : D, and without contacting the author of the original paper, anyone is just speculating on why that was chosen, never mind rationalizing with a fringe "what if".
Using it all the time will, soon enough, put you into somewhere you should not be stability wise. Historically, erring in the side of safety has been the norm for rocketry, especially HP rocketry. The common use calculations from OR and RS have been very conservative and served us well for over a decade.
Best bet would be to run some actual flights before declaring it as a "must do", as even just running the numbers on it will show that moving things around on >10:1 rockets moves the "adjusted" CP significantly enough that, if you're wrong about applying it 'always', you just created an unstable flight when you 'thought' you had 1CP stability.
I've actually run the numbers, many times, and shared them with some of the OR developers who worked on the latest release, as well as sharing the sims that I did with many members here.............. and what many have concluded is that until there is actually some empirical proof with flights that show that moving the CP is a GOOD thing on EVERY rocket, I am HIGHLY circumspect that it's an "always" adjustment that should be made.
If it turns out that USING the hack all the time is warranted to actually plug a hole in the Barrowman of OR/RS math, worst case scenario for NOT using it (thus accepting the equations as presented in OR as-is) is that is that you will have a rocket that's (on average) one caliber MORE stable.....and more stability is probably a good thing for the average rocket/rocketeer/rocket club.
Last edited:
That is a fair point. Although, Tim owns RockSim, and chose to publish the article, as well as promote its use.
Hi @Alan15578,
You are correct on all of that. And indeed Tim probably does support using the hack.
Stanley
So obviously the base drag hack is most commonly applied (or maybe always applied) based on the body tube's base surface area. However, what other drag inducing elements are appropriate to estimate the drag for with the base drag hack?
For example, do the wedge-shaped X-15 fins generate more drag? Should they be modeled? What about the side pods?
More recently I am modeling the Moonliner. Should I be estimating the surface area of the rear side of the struts to estimate drag with base drag hack?
For example, do the wedge-shaped X-15 fins generate more drag? Should they be modeled? What about the side pods?
More recently I am modeling the Moonliner. Should I be estimating the surface area of the rear side of the struts to estimate drag with base drag hack?
Got a chance to look at it more closely, and the interpolator does provide a pressure CD estimate of 0 at Mach 0, and calculates a function that matches the value and derivative at the first data point. So without real data in that region it looks like it's doing the closest thing possible to right.
MY vote, if it matter to anyone, is as follows:
That these "techniques" be CLEARLY MARKED in the code so as to be easily found and replaced with proper math/routines, etc. and placed on a list for elimination. I am not far enough down the road to comprehend what all is involved, but I sincerely believe that the ultimate goal needs to be a sim that addresses "real world" math and shrugs off the use of kludges, hacks, tricks, & such.
That these "techniques" be CLEARLY MARKED in the code so as to be easily found and replaced with proper math/routines, etc. and placed on a list for elimination. I am not far enough down the road to comprehend what all is involved, but I sincerely believe that the ultimate goal needs to be a sim that addresses "real world" math and shrugs off the use of kludges, hacks, tricks, & such.
- Joined
- Aug 6, 2022
- Messages
- 3,275
- Reaction score
- 2,974
I could use some help with judgement/experience regarding how to apply the hack to a rocket. I treed it on Saturday, apparently due to being overstable and kinda slow off the rod in fairly strong wind, powered by a D12-7 and the slowness due at least partly to the excess nose ballast. It curved up in a graceful, rainbow trajectory about 30 degrees away from straight into the wind, with a recorded apogee of 800 feet. If it had gone straight up, it would likely not have ended up in the trees. And would have gone quite a bit higher.
The original build of the rocket came out more nose-heavy and heavy overall than intended because I set the ballast before it was painted. Ended up with waaay too much paint on it due to not enough sanding layers off, so I wanted to rebuild it anyway.
The rocket is simply a Baby Bertha tube and nose cone glued to a Booster-60 fin can that has had the cardboard ring peeled off the front and most of the glue sanded off. https://www.hobbylinc.com/estes-bt60-model-rocket-booster-stage-2256 It has an overall length/diameter ratio of 8.07, so it's a candidate for the base drag hack. I'm playing around in OR and trying to decide on a balance target.
The motor retainer cap is 1.346 in. diameter vs. 1.638 for the fin can itself (a few thou larger than BT-60 tubing). The cap protrudes 0.724 behind the fin can, which may be long enough to kinda interact like a stepped "boat tail," or not. I have reviewed both of the apogee newsletters regarding how to apply the hack. I figure there are probably two reasonable ways to apply it:
1. Use the 1.346 diameter of the cap as a basis and put the point of the pi() cone on the end of the cap, which will be on the end of the threaded spigot the way I've built the model, 0.224 further forward than the end of the cap.
2. Use the 1.638 diameter of the can as a basis and put the point of the pi() cone on the end of the can, which means a 0.159 fore diameter on the end of the pi()cone transition at the back of the threaded spigot.
The OR-calculated CP is at 9.974 inches from the tip of the nose cone for method 1 and 10.209 inches for method 2.
Method 2 allows me to use less ballast in the nose cone to achieve a 1-caliber target, which gets me a higher apogee (as well as better speed off the rod). Does that seem to be an appropriate application? Does the threaded motor retainer cap protruding out behind the fin can interfere with the base drag aerodynamics, or can it be safely ignored?
The original build of the rocket came out more nose-heavy and heavy overall than intended because I set the ballast before it was painted. Ended up with waaay too much paint on it due to not enough sanding layers off, so I wanted to rebuild it anyway.
The rocket is simply a Baby Bertha tube and nose cone glued to a Booster-60 fin can that has had the cardboard ring peeled off the front and most of the glue sanded off. https://www.hobbylinc.com/estes-bt60-model-rocket-booster-stage-2256 It has an overall length/diameter ratio of 8.07, so it's a candidate for the base drag hack. I'm playing around in OR and trying to decide on a balance target.
The motor retainer cap is 1.346 in. diameter vs. 1.638 for the fin can itself (a few thou larger than BT-60 tubing). The cap protrudes 0.724 behind the fin can, which may be long enough to kinda interact like a stepped "boat tail," or not. I have reviewed both of the apogee newsletters regarding how to apply the hack. I figure there are probably two reasonable ways to apply it:
1. Use the 1.346 diameter of the cap as a basis and put the point of the pi() cone on the end of the cap, which will be on the end of the threaded spigot the way I've built the model, 0.224 further forward than the end of the cap.
2. Use the 1.638 diameter of the can as a basis and put the point of the pi() cone on the end of the can, which means a 0.159 fore diameter on the end of the pi()
The OR-calculated CP is at 9.974 inches from the tip of the nose cone for method 1 and 10.209 inches for method 2.
Method 2 allows me to use less ballast in the nose cone to achieve a 1-caliber target, which gets me a higher apogee (as well as better speed off the rod). Does that seem to be an appropriate application? Does the threaded motor retainer cap protruding out behind the fin can interfere with the base drag aerodynamics, or can it be safely ignored?
Maybe share some screen shots and/or the actual ORK file.
- Joined
- Aug 6, 2022
- Messages
- 3,275
- Reaction score
- 2,974
.ork files. These are close enough for sim purposes, not meant to be art pieces the way K'Tesh does. Based on a bunch of measurements with calipers and weighing parts with a 0.1 or 0.001 resolution gram scale. The fin can and nose cone have been modified from how they are shipped by Estes, so don't take these parts and use them in a sim and expect them to come out right for the standard parts.
- Joined
- Aug 6, 2022
- Messages
- 3,275
- Reaction score
- 2,974
.orks posted and no response in two days. Would have thought someone might at least have a thought or comment.
lakeroadster
When in doubt... build hell-for-stout!
FWIW: I'd use your method 2 with the 1.638 body tube.
Items that need attention:
- You need to override the mass, cg and drag for the base drag cone in your simulations
- I deleted both cones and there's a weight discrepancy between the (2) simulations.
The screen shots below are your sim's, I changed nothing. The differences between the sims is pretty small. I would suggest you not expect such a high degree of accuracy from the Open Rocket Simulation.
- Stability 1.01 caliber vs 1.04 caliber
- Apogee 1094 ft vs 1049 ft
____________________________________________________________________________________________________________________________________________________________________
- Joined
- Aug 6, 2022
- Messages
- 3,275
- Reaction score
- 2,974
The 3gm difference in mass between the methods is intentional; it's actually the point of asking the question. The difference is in the ballast added to the nose cone to get to the respective stability factors with the two different base drag hack implementations. The drag cones themselves should have zero wall thickness and therefore zero mass.
The apogees calculated with the drag cones in place include the drag calculated for the cones, so they are inaccurate and not meant to be used when applying the hack. I haven't messed with a drag override, but that seems like it would defeat the purpose of having the drag hack cones in the first place. They can't shift the CP if they don't generate drag. To see an accurate simmed apogee, you need to delete the drag cones. Then you see that the lighter rocket, because everything else is identical and it's over optimum mass, goes higher.
The apogees calculated with the drag cones in place include the drag calculated for the cones, so they are inaccurate and not meant to be used when applying the hack. I haven't messed with a drag override, but that seems like it would defeat the purpose of having the drag hack cones in the first place. They can't shift the CP if they don't generate drag. To see an accurate simmed apogee, you need to delete the drag cones. Then you see that the lighter rocket, because everything else is identical and it's over optimum mass, goes higher.
lakeroadster
When in doubt... build hell-for-stout!
Base drag hack isn't applicable to anything you have proposed.
lakeroadster
When in doubt... build hell-for-stout!
3 grams... your splitting hairs and expecting to much from the program.
What version of Open Rocket are you using? If you are using 22.02 leave the cone in place, override the mass, cg and drag.
This reflects a misunderstanding of how this all works.
OpenRocket already calculates and incorporates the base drag of the rear end of the rocket. However, it does not calculate the effect of that base drag on CP. The base drag CP hack is purely a way to add that effect on CP by adding a component that is believed to have an equivalent effect on CP, which in this case is a cone with diameter = aft end of airframe and length = Pi * that diameter. You do *not* want the base drag cone to be contributing anything to mass or drag, *only* CP. Therefore, the most "correct" implementation of the hack is to override the mass and Cd to zero. If you make the wall thickness of the cone equal to 0 that will also take care of the mass.
By setting the mass and drag of the cone to zero, you completely remove its effect on flight simulation, other than CP position. So you can leave it in all the time. I also like to set its opacity close to zero, so I can just barely see it in 3D view but it doesn't distract me from my view of the rocket.
It would not be, if OR took into account drag in stability calculations. However, since OR does not take into account drag in stability calculations then draggy rear elements that help stabilize a rocket need to be taken into account. Is there another way to take this into account in OR? Why would a base drag cone not be appropriate to simulate the drag of wide struts on the rear of a rocket, for example.
Last edited:
lakeroadster
When in doubt... build hell-for-stout!
Struts will have some drag, sure... But not "Base Drag". The Base Drag Hack was created to address the abrupt ending of a body tube on a rocket which has a Length to Diameter ratio that is less than 10:1.
Wide struts kicked out at an angle have little in common with that.
FWIW....
I learned on my Cygnus Probe that struts and draggy pieces aren't as draggy as I thought, and that the Base Drag Hack can be fickle on rockets that aren't just a smooth body tube.
I used the Base Drag Hack in the simulation and it was stable. I swing tested it and it was stable. I flew it and it was stable under thrust, but not during the coast phase.
@neil_w questioned early on in the design phase of the rocket if using the Base Drag Hack was applicable... and he was right, it wasn't.
Last edited:
- Joined
- Aug 6, 2022
- Messages
- 3,275
- Reaction score
- 2,974
After trying it, I'm not convinced that setting the CD of the cone to zero is the right way to go.
With Method 1, when I override the base drag hack cone CD to zero, OR predicts an apogee of 1400 ft.
When I delete the base drag hack cone completely, OR predicts an apogee of 1234 ft.
With Method 2, when I override the base drag hack cone CD to zero, OR predicts an apogee of 1425 ft.
When I delete the base drag hack cone completely, OR predicts an apogee of 1252 ft.
That statement doesn't seem to be supported by the results above. I am not sure what the effect caused by the presence of the zero-drag cone is doing in OR's overall drag calculations, but I am inclined to expect that the apogee predicted with no cone will likely be the more accurate.
With Method 1, when I override the base drag hack cone CD to zero, OR predicts an apogee of 1400 ft.
When I delete the base drag hack cone completely, OR predicts an apogee of 1234 ft.
With Method 2, when I override the base drag hack cone CD to zero, OR predicts an apogee of 1425 ft.
When I delete the base drag hack cone completely, OR predicts an apogee of 1252 ft.
That statement doesn't seem to be supported by the results above. I am not sure what the effect caused by the presence of the zero-drag cone is doing in OR's overall drag calculations, but I am inclined to expect that the apogee predicted with no cone will likely be the more accurate.
There is a bug in the base drag calculation when the following component has its drag coefficient overridden. Our testing should have caught it but didn't; see https://github.com/openrocket/openrocket/pull/2117 for the gory details.
Edit -- superceded by PR 2119
Edit -- superceded by PR 2119
Last edited:
lakeroadster
When in doubt... build hell-for-stout!
So moving forward, users should not over ride drag coefficient, correct.
No, not so simple.
Here is the component analysis without (left) and with (right) the base drag cone:
You can see that the base drag cone is adding significantly to the Cd.
The simplest recommendation I can make right now is to note the Total Cd of the rocket without the base drag cone, and then override the Cd of the entire rocket to this value. I just tried this and it seems to work as desired.
The downside is that if you'll need to remember to redo this whenever you make a change to the exterior design of the rocket. I'm going to see if I can figure out a better way to do it, but in the meantime that is my recommendation. And it'll be fixed in the next release so you can go back to overriding the cone Cd to zero.
I can't believe I never really knew about how great and useful the Component Analysis tool is until just recently.
lakeroadster
When in doubt... build hell-for-stout!
No, not so simple.
Here is the component analysis without (left) and with (right) the base drag cone:
View attachment 568998
You can see that the base drag cone is adding significantly to the Cd.
The simplest recommendation I can make right now is to note the Total Cd of the rocket without the base drag cone, and then override the Cd of the entire rocket to this value. I just tried this and it seems to work as desired.
The downside is that if you'll need to remember to redo this whenever you make a change to the exterior design of the rocket. I'm going to see if I can figure out a better way to do it, but in the meantime that is my recommendation. And it'll be fixed in the next release so you can go back to overriding the cone Cd to zero.
I can't believe I never really knew about how great and useful the Component Analysis tool is until just recently.
You lost me...
Last edited:
Sorry, working too fast here.
1) Start with the rocket *without* the base drag cone. Go to Tools -> Component Analysis, then click on the middle tab "Drag characteristics".
2) Note the value for Total CD for the rocket:
3) Now override the CD of the whole rocket to this value (overriding all subcomponents).
4) Now add the base drag cone. You only need to ensure that its mass is zero, because drag is overridden globally.
5) Now go back and explore the "Component Analysis" tool because it's cool.
lakeroadster
When in doubt... build hell-for-stout!
Sorry, working too fast here.
1) Start with the rocket *without* the base drag cone. Go to Tools -> Component Analysis, then click on the middle tab "Drag characteristics".
2) Note the value for Total CD for the rocket:
View attachment 569017
3) Now override the CD of the whole rocket to this value (overriding all subcomponents).
4) Now add the base drag cone. You only need to ensure that its mass is zero, because drag is overridden globally.
5) Now go back and explore the "Component Analysis" tool because it's cool.
Revised See Post #62
Thanks Neil.
I
Last edited:
user 30299
L2 - NAR & TRA
- Joined
- Nov 6, 2019
- Messages
- 963
- Reaction score
- 904
What was the range of body tube diameters for your rockets?
lakeroadster
When in doubt... build hell-for-stout!
Last edited:
Similar threads
