RockSim and Open Rocket Bugs

The Rocketry Forum

Help Support The Rocketry Forum:

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

jqavins

Слава Україні
TRF Supporter
Joined
Sep 29, 2011
Messages
11,933
Reaction score
8,039
Location
Howard, NY
The purpose of this thread is to share documented, demonstrated bugs in TS and OR. Preferably their latest versions.

In another thread there began a discussion of some simple test cases that prove bugs these programs. Let's start collecting these (without hijacking other threads.)

This not about griping please. Let's keep it to just the facts (mam). And question, clarifications, etc. about the facts.

The posts in that other thread are here. I'll duplicate the ones I made in this thread shortly.
 
A couple of things I've heard about and would like to understand better:
1. There was an article somewhere about how RockSim has problems with CP estimation when the front of the rocket is very thin (e.g. the escape tower on a Saturn V) Does anyone remember details of this?
2. People talk about the "base drag hack" where they put some fake geometry at the base of the rocket to get better results for fat body shapes. What's up with that? Is there an "official" version of the hack? Is there any theoretical justification for it?
 
I was having trouble with Rocksim Cluster Wizard. I wanted a 2 motor cluster, but it kept trying to make it a 4 motor cluster and the tubes were spaced out so they did not fit the airframe. I just ended up loading the file in Rocksim 9 and the cluster Wizard worked fine.
 
As a software developer, it's hard to deal with a mass of different problems all in one lump. Usually, different problems have different causes and require different changes to fix.

If you're serious about reporting a bug in a way that is actionable, I suggest:
  • one problem per thread
  • clear explanation of what you expected and what happened
  • simple reproduction steps from scratch
  • text inputs rather than screenshots
  • skip how important the issue is or how disappointed you are
 
A couple of things I've heard about and would like to understand better:
1. There was an article somewhere about how RockSim has problems with CP estimation when the front of the rocket is very thin (e.g. the escape tower on a Saturn V) Does anyone remember details of this?
2. People talk about the "base drag hack" where they put some fake geometry at the base of the rocket to get better results for fat body shapes. What's up with that? Is there an "official" version of the hack? Is there any theoretical justification for it?

Base Drag Hack
Basically, when the ratio between rocket length and diameter is less than 10:1, a base drag adjustment is made by adding a conical nosecone at the bottom of the rocket which has length of PI * D and a diameter of D (where D is the body diameter at the base). If the rocket has a tail cone, then the length of the tail cone is subtracted from PI * D and D is the body diameter before the tail cone.

Apogee discussed this issue in three newsletters:
Newsletter 154, Newsletter 158, and Newsletter 164
There is also a discussion of how to determine the actual Cd for a specific rocket here: Newsletter 303

FYI: OpenRocket 15.03 and Rocksim 10 simulators DO NOT calculate a base drag adjustment for short wide (fat or stubby) rockets.
 
Last edited:
I think combining both apps into a single thread will make it way too difficult to follow. I don't use RockSim so none of that matters to me. Trying to wade through a bunch of posts and figuring out if they are RS or OR just seems like a lot of extra work for no benefit. It's a good idea, but I think two separate threads would be far better.

FWIW, OR still has serious issues when switching between 2D and 3D views.


Tony
 
This forum is supposed to be the support site for OpenRocket, so how is this thread going to be any different than the last 10 years?

Rocksim info needs to get back to Apogee, so how does that happen? They already collect feedback.

I agree, combining the two software probably doesn't make sense.

I do like the idea of simple, "benchmark" problems to illustrate issues and to document cases in an organized manner. The usual posts of "OpenRocket won't simulate pods" or "Rocksim predicted more altitude than my altimeter" are very tiresome.
 
FWIW, OR still has serious issues when switching between 2D and 3D views.
For most people there are no issues. However, there seem to be some graphics drivers that give it or the underlying JVM fits. Unfortunately, those situations are frequently very hard to reproduce, and therefore hard to fix.

If there is a specific problem you can report, please do so.
 
I disagree with the reasoning behind the Base Drag Hack. The reason a flat plate has an effective CP behind the plate is not anything going on in the wake. In the inviscid, irrotational approximation where the computation predicts no wake at all the plate has an effective CP at negative infinity, so wake effects actually bring the CP forward not back. The plate wants to face into the airstream because it generates lift and the center of lift is in front of the geometric center of the plate. It's basically a fin operating at a very high angle of attack.

As a practical matter, it's easy to find cases where the Base Drag Hack gives bad answers.

Consider a spherical rocket. By symmetry a sphere should be neutrally stable, so it's CP is at the geometric center. Here's what the Base Drag Hack says about it:

Screen Shot 2020-09-28 at 9.55.52 PM.png
The CP is way too far back.

I'm pretty sure the problem with fat rockets is not about base drag, it's a combination of mishandling the behavior of fat noses and neglecting the effect of body lift.

Also, I really enjoy saying "consider a spherical rocket". Also also, anyone working on aerodynamic modeling of rockets should really run some basic geometries with known behavior (spheres, flat plates, cylinders, cones, etc) through the widget and see what they get.
 
I disagree with the reasoning behind the Base Drag Hack. The reason a flat plate has an effective CP behind the plate is not anything going on in the wake. In the inviscid, irrotational approximation where the computation predicts no wake at all the plate has an effective CP at negative infinity, so wake effects actually bring the CP forward not back. The plate wants to face into the airstream because it generates lift and the center of lift is in front of the geometric center of the plate. It's basically a fin operating at a very high angle of attack.

As a practical matter, it's easy to find cases where the Base Drag Hack gives bad answers.

Consider a spherical rocket. By symmetry a sphere should be neutrally stable, so it's CP is at the geometric center. Here's what the Base Drag Hack says about it:

View attachment 433305
The CP is way too far back.

I'm pretty sure the problem with fat rockets is not about base drag, it's a combination of mishandling the behavior of fat noses and neglecting the effect of body lift.

Also, I really enjoy saying "consider a spherical rocket". Also also, anyone working on aerodynamic modeling of rockets should really run some basic geometries with known behavior (spheres, flat plates, cylinders, cones, etc) through the widget and see what they get.

Way over my pay grade, I simply answered the question being posed... I’ll let those more knowledgeable that me duke this one out.;)
 
Consider a spherical rocket. By symmetry a sphere should be neutrally stable, so it's CP is at the geometric center. Here's what the Base Drag Hack says about it:

View attachment 433305
The CP is way too far back.
I thought the base drag hack only applies to flat trailing surfaces, such as the end of a body tube, not a rounded tail cone (if I may call it that) like that one.
 
I thought the base drag hack only applies to flat trailing surfaces, such as the end of a body tube, not a rounded tail cone (if I may call it that) like that one.

That isn't what the Apogee newsletter article suggests. This contains some detailed instructions for handling tail cones, etc: https://www.apogeerockets.com/education/downloads/Newsletter158.pdf

Of course, disagreeing with the article doesn't necessarily make you _wrong_...

As far as bug reporting goes, I'm thinking there are two very different kinds of problems we're talking about:
1. traditional software bugs, where it's clear what the program is supposed to be doing and it doesn't do it. Definitely these should get filed in the bug tracking system.
2. Applied rocket science stuff, where the program is trying to estimate CP, CD, max altitude, etc and it's either getting a bad answer or it's not clear whether the methodology is correct. I'm not sure what the best way to handle these might be, because solving them isn't primarily a software engineering problem it's a rocket R&D problem.
 
For most people there are no issues. However, there seem to be some graphics drivers that give it or the underlying JVM fits. Unfortunately, those situations are frequently very hard to reproduce, and therefore hard to fix.

If there is a specific problem you can report, please do so.
In additional to a variety of Windows computers, I have three Macs in my house:

MacBook Pro (15-inch, Mid 2012), 16GB RAM, Nvidia Geforce GT 650M 1GB RAM
Late 2015 Retina 21.5" iMac, 16GB RAM, Intel Iris Pro Graphics 6200
MacBook Pro (15-inch, 2018) 32GB RAM, Radeon Pro 560X 4 GB

On all three Macs, I can open a rocket model, switch to a 3D view, and switch back to 2D view and it will crash the program instantly. This is using the packaged version of the installer, on different versions of MacOS with three different video cards. On my Windows laptop (Nvidia 1050 ti card) I don't have that issue.

So, at least on the Mac, not hard to reproduce.


Tony
 
On all three Macs, I can open a rocket model, switch to a 3D view, and switch back to 2D view and it will crash the program instantly. This is using the packaged version of the installer, on different versions of MacOS. On my Windows laptop (Nvidia 1050 ti card) I don't have that issue.
Are your graphics preferences set like this?
1601403739611.png
 
They are now! Any reason that is not the default set of preferences?
I honestly don't know. I'm guessing they didn't know it was going to cause Mac crashes the way they had it... :)

I suffered with this problem for a long time (and submitted it as an issue) before someone told me about the fix. I'll try to make sure the new release has this as default.
 
Thanks from another Mac user! I love the 3D unfinished view in OR, but I rarely use it because it crashes every time I switch back. This is a huge help.
 
Hi Folks

this partially addressed my problem. The software no longer crashes when switching between various view - as noted above. Yay!

alas, I get a completely black window that obscures the rocket render when I choose the 3D finished setting. Everything else is visible in the various windows, just not the 3D finished view. Boo!

is this alike glasses that go black when looking at something scary, or are there other solutions?

thanks
 
Hi Folks

this partially addressed my problem. The software no longer crashes when switching between various view - as noted above. Yay!

alas, I get a completely black window that obscures the rocket render when I choose the 3D finished setting. Everything else is visible in the various windows, just not the 3D finished view. Boo!

is this alike glasses that go black when looking at something scary, or are there other solutions?

thanks
Unfortunately I still get the all black screen if I switch to 3D Finished. Interestingly, when using the example files, the Finished 3D view works fine for the 'High Power Airstart' model, which is a Patriot with decals. But most of the other models fail.


Tony
 
Back
Top