Quantcast

RockSim and Open Rocket Bugs

The Rocketry Forum

Help Support The Rocketry Forum:

jqavins

Joseph Avins
TRF Supporter
Joined
Sep 29, 2011
Messages
4,007
Reaction score
1,476
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.
 

dhbarr

Amateur Professional
Joined
Jan 30, 2016
Messages
6,613
Reaction score
1,152
FWIW:

Note this doesn't mean there are 90 things wrong with OR -- these are just some things in the to-work-on pile.
 

Jeff Lassahn

Well-Known Member
TRF Supporter
Joined
Jul 5, 2020
Messages
177
Reaction score
199
Location
Portland OR
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?
 

n3tjm

Papa Elf
Joined
Jan 21, 2009
Messages
7,381
Reaction score
226
Location
Penns Creek, PA
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.
 

JohnCoker

Well-Known Member
Joined
Apr 13, 2013
Messages
1,847
Reaction score
499
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
 

H. Craig Miller

Well-Known Member
TRF Supporter
Joined
Sep 8, 2020
Messages
52
Reaction score
89
Location
Placer County, California
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:

manixFan

Not a rocket scientist
Joined
Feb 15, 2009
Messages
1,882
Reaction score
856
Location
TX
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
 

Buckeye

Well-Known Member
TRF Supporter
Joined
Sep 6, 2009
Messages
2,479
Reaction score
339
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.
 

neil_w

Chuffed as ninepence
TRF Supporter
Joined
Jul 14, 2015
Messages
9,814
Reaction score
2,921
Location
Northern NJ
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.
 

Jeff Lassahn

Well-Known Member
TRF Supporter
Joined
Jul 5, 2020
Messages
177
Reaction score
199
Location
Portland OR
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.
 

H. Craig Miller

Well-Known Member
TRF Supporter
Joined
Sep 8, 2020
Messages
52
Reaction score
89
Location
Placer County, California
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.;)
 

neil_w

Chuffed as ninepence
TRF Supporter
Joined
Jul 14, 2015
Messages
9,814
Reaction score
2,921
Location
Northern NJ
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.
 

Jeff Lassahn

Well-Known Member
TRF Supporter
Joined
Jul 5, 2020
Messages
177
Reaction score
199
Location
Portland OR
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.
 

manixFan

Not a rocket scientist
Joined
Feb 15, 2009
Messages
1,882
Reaction score
856
Location
TX
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
 

neil_w

Chuffed as ninepence
TRF Supporter
Joined
Jul 14, 2015
Messages
9,814
Reaction score
2,921
Location
Northern NJ
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
 

neil_w

Chuffed as ninepence
TRF Supporter
Joined
Jul 14, 2015
Messages
9,814
Reaction score
2,921
Location
Northern NJ
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.
 

Jeff Lassahn

Well-Known Member
TRF Supporter
Joined
Jul 5, 2020
Messages
177
Reaction score
199
Location
Portland OR
I was also having this crash on my Mac, and those graphics settings fix it for me, too. Thanks neil_w!
 

manixFan

Not a rocket scientist
Joined
Feb 15, 2009
Messages
1,882
Reaction score
856
Location
TX
Yes, thank you Neil for that very simple fix, greatly appreciated!


Tony
 

BDB

Absent Minded Professor
Joined
Aug 22, 2015
Messages
2,120
Reaction score
378
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.
 

Red Phenix

Well-Known Member
Joined
Feb 3, 2014
Messages
67
Reaction score
12
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
 

manixFan

Not a rocket scientist
Joined
Feb 15, 2009
Messages
1,882
Reaction score
856
Location
TX
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
 
Top