OpenRocket Shall Serve The Oddroc Scum

[Jeff Lassahn]

I'm thinking about doing a little work on OpenRocket in my infinite spare time.
Most of the times that I have problems using OpenRocket, either because it can't easily do the thing I want, or because it flat-out has a bug, the reason is that I'm trying to work on some ... unusual ... rocket geometry. So I thought I'd start a discussion about what's missing from OR that's useful for oddroc design.

A couple of items to start:

1. not-so-great CP calculations for shapes that aren't long an narrow. People end up using various "Base Drag Hacks" to work around this, with varying degrees of success, and saucer or spool rockets are basically doomed from a simulation standpoint.

2. If you want a geometry with lots of lumps and protrusions and fiddly bits, you can use Pods (PODS ARE AWESOME) but you often need extra "fake" elements to act a scaffolding to put stuff where it needs to go. I tend to end up with lots of zero size body tubes, stages that aren't really stages, etc to hold all the real pieces in place.

So, what do other people think? What are the most important improvements to OR that would make designing your ill-advised flights of fancy better?

 

[grapetang]

Do tractor designs & bottle rocket designs sim properly?
How about asymmetric drag (colonial viper, Klingon battle cruiser, jet-shaped rockets w/ cockpits & ordinance, etc)?

For the base drag hack, it would be good to flag that status so the correction isn't doubly applied.

 

[cls]

#1 is Barrowman. That's how the models work. I'm sure you can make some FEA CFD software for any arbitrary shapes, but that won't run on ordinary home computers.

#2, get over it. The extra parts are just an "idiom" for the software, an effect of #1. Folks understand this and look past it.

 

[lakeroadster]

I read a lot of folks here talking about the base drag hack. What's the big deal, just add it?

I used Open Rocket to sim my Red Columbine, it's and oddroc, I'm oddroc scum. I built the rocket, launched it and it performed just as Open Rocket simulated it.

Part of the fun of oddroc's is all the work arounds and unknowns. If the program took all the guess work out of the equation, it would make the process less fun, IMO.

 

[Kelly]

The problem with the base drag hack (besides the fact that it is a hack, not an accurate representation of the aerodynamics) is the amount of fiddling it requires - you need to calculate/add the base cone to do a simulation which will give you an answer to the Cp/stability question, and then remove the cone and re-simulate to get an answer to the altitude/velocity question. If you change the motor or any thing else in the design, you need to do this fiddling again.

So, yes, I think it would be very helpful to have a big, obvious checkbox somewhere that says "use base drag hack for Cp calculation" which would take care of the above automatically - add the cone for Cp calculation, remove it for flight simulation. You could have the length of the cone default to π*d, and be configurable to other lengths (though, I've never heard of anyone using anything but π*d).

 

[lakeroadster]

The problem with the base drag hack (besides the fact that it is a hack, not an accurate representation of the aerodynamics) is the amount of fiddling it requires - you need to calculate/add the base cone to do a simulation which will give you an answer to the Cp/stability question, and then remove the cone and re-simulate to get an answer to the altitude/velocity question. If you change the motor or any thing else in the design, you need to do this fiddling again.

So, yes, I think it would be very helpful to have a big, obvious checkbox somewhere that says "use base drag hack for Cp calculation" which would take care of the above automatically - add the cone for Cp calculation, remove it for flight simulation. You could have the length of the cone default to π*d, and be configurable to other lengths (though, I've never heard of anyone using anything but π*d).

The cone is simulating the actual drag the rocket will see during flight. Why would removing it make sense?

The answer is you don't need to remove the base drag hack cone. Override the mass and the drag and leave it there.

Try it. You'll see that running the sim with the cone at the default drag setting yields that same result as running the sim with the cone base drag override set to zero.

I've heard other folks say to remove the base drag cone for the simulation. Yet when I go back and read the articles about "The Base Drag Hack" I have yet to find anywhere that is says to remove it.

 

[neil_w]

For reference: https://github.com/openrocket/openrocket/issues?q=is:issue+is:open+label:"Feature+request"

 

[Kelly]

The cone is simulating the actual drag the rocket will see during flight. Why would removing it make sense?

So, "Cp location" and "drag" are two completely different calculations, agreed? While we know that the Barrowman equation doesn't account for base drag, it has always been my assumption that the equations used for calculating drag already 'get' the implications of a wide base - just as they understand the drag associated with a boattail, or a profiled fin. If this is true, that's why you remove the hack for a simulation.

I guess it would be good to get some confirmation from the developers on how this works? @neil_w

 

[neil_w]

I have already confirmed this in the past. Make of it what you will.

P.S. I won't get involved in this particular discussion any further, it's already been beaten to death (and then some).

 

[BigMacDaddy]

I am actually not totally sure about how OR handles drag and pods... For example can I trust this simulation?



Should I add base drag cones to simulate base drag?

 

[lakeroadster]

I am actually not totally sure about how OR handles drag and pods... For example can I trust this simulation?

View attachment 526140

Should I add base drag cones to simulate base drag?

View attachment 526141

I'd make the base drag hack just one cone.... how does that change the simulation?

 

[lakeroadster]

So, "Cp location" and "drag" are two completely different calculations, agreed? While we know that the Barrowman equation doesn't account for base drag, it has always been my assumption that the equations used for calculating drag already 'get' the implications of a wide base - just as they understand the drag associated with a boattail, or a profiled fin. If this is true, that's why you remove the hack for a simulation.

I guess it would be good to get some confirmation from the developers on how this works? @neil_w

The issue I have had is with oddrocs that won't simulate as stable without the base drag hack. You remove the cone, run the simulation and the rocket is a skywriter and the data you get is worthless. That's when I tried leaving the cone on, and then got a valid, non-skywriting, simulation.

On my Red Columbine that I flew about a week ago, the simulation with the cone showed a 370 foot apogee. Without the cone the simulated apogee was 167 feet. So, like a 2:1 difference.

The actual flight apogee was much more than 167 feet.

 

[neil_w]

I am actually not totally sure about how OR handles drag and pods... For example can I trust this simulation?

Base drag for each of those pods should be calculated and incorporated (I will double-check this, but am pretty sure of it). Effect on CP will *not* be incorporated, so you should use the hack.

I believe that the zillion-cone hack you illustrated should work, and a single cone hack based on the size of the whole assembly should come pretty close as well.

The issue I have had is with oddrocs that won't simulate as stable without the base drag hack. You remove the cone, run the simulation and the rocket is a skywriter and the data you get is worthless. That's when I tried leaving the cone on, and then got a valid, non-skywriting, simulation.

I said I wasn't going to comment on this any further, but... just to put a cap on this one, you need to override CP to force the rocket stable get a proper simulation. Yes, the moment of inertia is screwed up in that case, but hey there's a reason we call this a "hack", and why it would be much better for it to be intelligently incorporated into OR rather than requiring all the tedious back-and-forth by the user.

*Now* I'm done.

 

[lakeroadster]

I said I wasn't going to comment on this any further, but... just to put a cap on this one, you need to override CP to force the rocket stable get a proper simulation. Yes, the moment of inertia is screwed up in that case, but hey there's a reason we call this a "hack", and why it would be much better for it to be intelligently incorporated into OR rather than requiring all the tedious back-and-forth by the user.

*Now* I'm done.

The moment of inertia being incorrect will lead to the program incorrectly calculating other "Export Data" values.

Garbage in - Garbage out

 

[Kelly]

The moment of inertia being incorrect will lead to the program incorrectly calculating other "Export Data" values.

Garbage in - Garbage out

I think there's another hack, where you can simulate with (say) a 1000' long launch rod. Now the program doesn't care whether it's stable, and will simulate the entire flight.

 

[lakeroadster]

I think there's another hack, where you can simulate with (say) a 1000' long launch rod. Now the program doesn't care whether it's stable, and will simulate the entire flight.

Which, if all you care about is apogee, gets you what you want.

Have you used the "Plot /Export" function? The amount of data is impressive. My Thunk! rocket has canted fins that induce roll. Using the "Plot /Export" function revealed the calculated rpm's for the entire flight.

There's also pitch and yaw rates, as well as a plethora of other data.

​

Here's the Export data for Thunk!. Not all of the exported data is shown in this view.

​

 

[BigMacDaddy]

Ugh... fell victim to the bug that CP/CG does not update when viewing 3D...

EDIT: Single base drag cone does not have as much of an effect as the multiple cones. Other strange issue, when I put rear transitions on the pods (.875mm long and 0 diameter at rear) these transitions wipe out the CP contribution of the pods unless you leave base drag hack.


Regardless, I am feeling better about being able to make this work since all the extra body tubes and 3D printed parts will be heavy -- having to add nose weight was going to kill things...

 

[Jeff Lassahn]

I guess the fact that everyone jumped on the "lets talk about the base drag hack" instead of coming up with other unrelated things they want OpenRocket to do means that CP calculations are a productive area to focus on.

So...

There's a bunch of stuff to say about the actual algorithmic changes that might be needed, but lets put that aside for the moment and talk about some software engineering stuff.

A big problem lurking in the background here is how to handle compatibility between versions of the calculation. If I do a design on version X of OR, then there are changes to the CP calculator on version X+1, even if the new version is in general better than the old one updating might invalidate my design. So is there a general consensus about how OR should handle this?

My suspicion is there should be a selectable algorithm. Users can choose between different CP solvers, and the list is likely to grow over time.

 

[BigMacDaddy]

One of the biggest issues for me that is indirectly related to oddrocs (or maybe directly depending on how you look at it) is the ability to import RockSim files that use pods. I really thought that when pods were added to OR that they would allow us to import RKT files with pods but pods are ignored on import just like before. Many oddrocs use pods and lots have RKT files out there already.

 

[neil_w]

A big problem lurking in the background here is how to handle compatibility between versions of the calculation. If I do a design on version X of OR, then there are changes to the CP calculator on version X+1, even if the new version is in general better than the old one updating might invalidate my design. So is there a general consensus about how OR should handle this?

This topic has come up before. Our approach has been to improve the algorithms and fix bugs as we find them, and not to try to "preserve" old (and possibly buggy) algorithms.

Example: in this release, @JoePfeiffer totally rewrote the tube fin algorithm, replacing the "3-fin hack" with a more true and accurate model of tube fins (he can offer the details if he's inclined). We did not offer an option to use the old tube fin calculation.

To this point, I think this has been the correct approach. I suppose at some point there might be a sufficient divergence in a new version that we will need to offer some sort of options, but honestly that's an extra layer of effort that I don't think we can afford right now.

 

[neil_w]

One of the biggest issues for me that is indirectly related to oddrocs (or maybe directly depending on how you look at it) is the ability to import RockSim files that use pods. I really thought that when pods were added to OR that they would allow us to import RKT files with pods but pods are ignored on import just like before. Many oddrocs use pods and lots have RKT files out there already.

Unfortunately, until we offer equivalent pod functionality to Rocksim, importing them is going to be problematic. Definitely not going to happen this release, but I do hope we'll get to it in the next release or two (which will not take 7 years ).

 

[Jeff Lassahn]

This topic has come up before. Our approach has been to improve the algorithms and fix bugs as we find them, and not to try to "preserve" old (and possibly buggy) algorithms.

Example: in this release, @JoePfeiffer totally rewrote the tube fin algorithm, replacing the "3-fin hack" with a more true and accurate model of tube fins (he can offer the details if he's inclined). We did not offer an option to use the old tube fin calculation.

To this point, I think this has been the correct approach. I suppose at some point there might be a sufficient divergence in a new version that we will need to offer some sort of options, but honestly that's an extra layer of effort that I don't think we can afford right now.

That seems like a good answer, both because it's easier short-term and for the longer term health of the code. Assuming it doesn't cause lots of practical problems for users.

 

[Jeff Lassahn]

#1 is Barrowman. That's how the models work. I'm sure you can make some FEA CFD software for any arbitrary shapes, but that won't run on ordinary home computers.

A couple of things here:
Barrowman's equations aren't some kind of special magic, they're a set of approximations that strike a particular compromise between ease of calculation and accuracy. There's a whole range of options for modifying those calculations so they strike different compromises. If the models work in a way that doesn't make us happy for a particular situation, we can change them.

Depending on what you mean by CFD, there's plenty of options that can realistically run on people's home computers. We're not going to do cutting-edge full turbulent flow calculations, but something like a panel method flow model with a thin boundary layer step is very doable with normal amount of computer power. It's the kind of thing that people used supercomputers for back in the '80s and now we have that much computer in a big phone.

 

[BigMacDaddy]

I guess the fact that everyone jumped on the "lets talk about the base drag hack" instead of coming up with other unrelated things they want OpenRocket to do means that CP calculations are a productive area to focus on.

For me the most important thing in OR is the ability to accurately predict CP. If I cannot do that then there is no reason to model it here. I am not sure that the base drag hack covers all/most of the drag-based stability oversights in OR. I am pleased that when I stick pods off the rear of the model (assuming they have nose cones and no rear transitions) that these move the CP back.

Ring tails are one other thing that I understand OR cannot handle that covers another type of oddroc.

Also asymmetry, which someone else mentioned (but some more thoughts):
- Asymmetrical drag as well as and how this affects rocket stability (and trajectory).
- Asymmetrical fins (is there something besides the most conservative CP estimate that would be appropriate or helpful to show)
- Possibly combining asymmetry with role/spin to consider stability of asymmetrical rolling rockets (might be a rare case)
- Off-center motor mounts

<< flies straight but it was just a guess that adding the bottom elements would even out drag against top elements.

Canted motor mounts - it would actually be nice to see a visual of how canted angle lines up with CG to create most stable clusters.

<< I had to add fake fat fins to simulate the CP impact of those long canted motor tubes.

What about gap staging? Any chance of predicting size and placement of hole and likelihood of this leading to issues? (just brainstorming here)

I do think that ignoring body tubes in CP calculation seems to be an issue when you add body tubes in pods. For example, here is a 3-pod version of what I shared previously. Making the side pod tubes 2x as long does not move CP. I would think that those side tubes would act like fins to stabilize the rocket and keep it from turning.

 

[Jeff Lassahn]

Catching up on some comments from above:

Do tractor designs & bottle rocket designs sim properly?
How about asymmetric drag (colonial viper, Klingon battle cruiser, jet-shaped rockets w/ cockpits & ordinance, etc)?

For the base drag hack, it would be good to flag that status so the correction isn't doubly applied.

There's no problems with simulating tractor motors in OR. Sometimes tractor designs just happen to have other weird geometry that causes simulation problems, but it's not the tractor motor's fault.

Bottle rockets are tricky. If you represent the stick as a body tube they don't work. If you represent the stick as a long fin, they don't work. If you represent the stick as a crossed set of regular fins, or as a single tube fin, you get a plausible looking answer. No idea how well it matches reality though.

For me the most important thing in OR is the ability to accurately predict CP.

I feel the same way. Sometimes overly so in that I forget that things like the drag calculation even exist and get confused when people complain about how they're working. I should read the drag algorithms some day...

Ring tails are one other thing

I model a ring tail as a single tube fin attached to a virtual body tube on a pod or something. It looks good and it does something sort of plausible for CP simulation. I don't know if there's problems where the aerodynamics are inaccurate because it's assuming there's a body tube on one side or something. Probably worth looking into the details a bit more.

It's one of the things where I'd like a cleaner way to add them without so many fiddly bits.

Off-center motor mounts

Don't off-center motor mounts just kind of work already? I played with them a few months ago in a early beta and there were a few bugs with how the CG position updated side-to-side with motor weights and stuff but it was basically working. I've been assuming this was basically a done deal.

I would like to make off-center holes in my centering rings to go along with them, though.

Canted motor mounts

Oooooh. That would be cool. Probably hard, but cool.

I do think that ignoring body tubes in CP calculation seems to be an issue

I agree. The whole "lift from the body tube is negligible" thing gets increasingly less true as you add more and bigger tubes.

 

[Jeff Lassahn]

I believe the "base drag hack" is not the correct approach for improving the CP calculations for fat rockets, and I've got a different suggestion.

The Barrowman equations make several approximations based on the idea that the body is "thin".
The calculation proceeds in two steps: 1. estimate the pressure distribution over the body, and 2. turn the pressures into torques and balance them to find the pivot point.
One of the "thin body" approximations is to assume in step 2 that the torque caused by the pressure is always in the horizontal direction, when it is actually perpendicular to the surface.
For fat shapes, this approximation puts the CP of the nose too far forward, and the CP of any tail cones too far back.