SOLVED: Issues with OpenRocket simulations after upgrade

[BDB]

I'm a big fan of OpenRocket, and I was excited about the new release because I'm working on a project that involves booster pods. But after upgrading to the newest version of OpenRocket, my simulations have been embarrassingly bad. I have also been flying two new rockets, so I don't have apples-to-apples comparisons, but I'd appreciate some help sorting this out.

I'm attaching a .ork file of an extended Wildman Punisher I have flown twice this year--once on a Loki J474 and once on a CTI K530. Both flights overperformed by large amounts, with nearly disastrous consequences. Before this year, my sims were much more in line with actual flight data. If anything, my flights often underperformed the sims. Now, the exact opposite is true.




Motor: Loki J474
OR Sim: 2115 ft
Actual: 2986 ft

Motor: CTI K530
OR Sim: 5529 ft
Thrusctcurve prediction: 5780 ft
Actual: 8363 ft!!!!

After the first flight, I suspected that something was off, so I double-checked with Thrustcurve for the second flight. The second time, the overperformance was even worse.

The consequences of not getting this right are huge. I nearly unintentionally violated the club's waiver!!!
I hope this is an isolated problem, but please tell me if others are experiencing something similar.

 

[BDB]

Here is the sim file for the other rocket I have been flying lately. It's a Madcow/Composite Warehouse X-celerator. The sims from my current version of OpenRocket are comically bad compared to those from my friend @TheTank who ran the same file on his older version of OR. Needless to say, the sims on the older version are closer to actual.

Motor: CTI K530
My OR sim: 1438 ft
Old OR sim: 4303 ft
Actual: 5200 ft.




My sims with the new version of OR:



@TheTank's sims of the same file with an older version of OR:

 

[NTP2]

Strange… Maybe it’s something with the file since no one else has had that problem?

 

[neil_w]

I'm sorry you got bit by this, I don't recall hearing about it from anyone else in the 9 months since release. Anyway, here's your issue:


Check that box and I believe your sims will return to "correct". The reason thrustcurve matched the new OR results is probably because you plugged in the mass number OR was reporting in the rocket figure display, which was way too high.

I don't have a copy of 15.03 anymore to even see how that might have been different then, or why the file didn't come across correctly, but I will look into it.

Sorry again. We will try to make it so it is much harder or impossible to make that mistake, right now it's way too easy. I've opened issue #2393 on Github; we will address this as soon as possible.

 

[Buckeye]

Keep in mind that Thrustcurve cannot simulate a tailcone and its tremendous drag reduction.

I get 6423 ft on the K530 in TC with the corrected mass on the Punisher and Cd = 0.6

 

[BDB]

Keep in mind that Thrustcurve cannot simulate a tailcone and its tremendous drag reduction.

I get 6423 ft on the K530 in TC with the corrected mass on the Punisher and Cd = 0.6

Good point. I thought about that too--unfortunately after I nearly busted the waiver.

 

[neil_w]

Keep in mind that Thrustcurve cannot simulate a tailcone and its tremendous drag reduction.

It can if you take the Cd reported by OR and plug it directly into thrustcurve. Should then get very similar results.

 

[BDB]

I'm sorry you got bit by this, I don't recall hearing about it from anyone else in the 9 months since release. Anyway, here's your issue:
View attachment 614403

Check that box and I believe your sims will return to "correct". The reason thrustcurve matched the new OR results is probably because you plugged in the mass number OR was reporting in the rocket figure display, which was way too high.

I don't have a copy of 15.03 anymore to even see how that might have been different then, or why the file didn't come across correctly, but I will look into it.

Sorry again. We will try to make it so it is much harder or impossible to make that mistake, right now it's way too easy. I've opened issue #2393 on Github; we will address this as soon as possible.

Thanks so much, Neil!

 

[Buckeye]

It can if you take the Cd reported by OR and plug it directly into thrustcurve. Should then get very similar results.

Yeah, sometimes. I had to put an overall Cd = 0.3 in Thrustcurve to match OR. That's pretty low.

 

[neil_w]

Yeah, sometimes. I had to put an overall Cd = 0.3 in Thrustcurve to match OR. That's pretty low.

Hmm, OR reports about 0.4... more of a difference than I'd expect. I'll have to fiddle.

 

[OzHybrid]

I'm sorry you got bit by this, I don't recall hearing about it from anyone else in the 9 months since release. Anyway, here's your issue:
View attachment 614403

Check that box and I believe your sims will return to "correct". The reason thrustcurve matched the new OR results is probably because you plugged in the mass number OR was reporting in the rocket figure display, which was way too high.

I don't have a copy of 15.03 anymore to even see how that might have been different then, or why the file didn't come across correctly, but I will look into it.

Sorry again. We will try to make it so it is much harder or impossible to make that mistake, right now it's way too easy. I've opened issue #2393 on Github; we will address this as soon as possible.

The mass was overridden for the stage. The stage IS all subcomponents. You shouldn't have to select the "override for all subcomponents" box if you are overriding the mass at the STAGE.

 

[neil_w]

The mass was overridden for the stage. The stage IS all subcomponents. You shouldn't have to select the "override for all subcomponents" box if you are overriding the mass at the STAGE.

I agree completely. But that's the way it is for now.

 

[BDB]

I'm sorry you got bit by this, I don't recall hearing about it from anyone else in the 9 months since release. Anyway, here's your issue:
View attachment 614403

Check that box and I believe your sims will return to "correct". The reason thrustcurve matched the new OR results is probably because you plugged in the mass number OR was reporting in the rocket figure display, which was way too high.

I don't have a copy of 15.03 anymore to even see how that might have been different then, or why the file didn't come across correctly, but I will look into it.

Sorry again. We will try to make it so it is much harder or impossible to make that mistake, right now it's way too easy. I've opened issue #2393 on Github; we will address this as soon as possible.

One more follow-up question...since I have also overridden the CG, should I check the box to override it for all subcomponents too?

 

[neil_w]

One more follow-up question...since I have also overridden the CG, should I check the box to override it for all subcomponents too?

Yes. Getting that wrong won't aways totally mess up your flight sim results, though, the way the mass thing will.

 

[JoePfeiffer]

The mass was overridden for the stage. The stage IS all subcomponents. You shouldn't have to select the "override for all subcomponents" box if you are overriding the mass at the STAGE.

The way it's set up now lets you either override the stage completely, or add a "bias" to the stage mass to allow for something like paint. We definitely want the functionality we've got now; I'd be open to better wording.

 

[JoePfeiffer]

I'm a big fan of OpenRocket, and I was excited about the new release because I'm working on a project that involves booster pods. But after upgrading to the newest version of OpenRocket, my simulations have been embarrassingly bad. I have also been flying two new rockets, so I don't have apples-to-apples comparisons, but I'd appreciate some help sorting this out.

I'm attaching a .ork file of an extended Wildman Punisher I have flown twice this year--once on a Loki J474 and once on a CTI K530. Both flights overperformed by large amounts, with nearly disastrous consequences. Before this year, my sims were much more in line with actual flight data. If anything, my flights often underperformed the sims. Now, the exact opposite is true.

Do you by any chance still have the .ork, as saved by 15.03 (the one you posted -- thanks! -- was saved by 22.02 or 23.09.beta.01). I want to make sure that there isn't a problem with designs saved with 15.03 not being opened correctly with newer versions.

 

[BDB]

Do you by any chance still have the .ork, as saved by 15.03 (the one you posted -- thanks! -- was saved by 22.02 or 23.09.beta.01). I want to make sure that there isn't a problem with designs saved with 15.03 not being opened correctly with newer versions.

Sorry. I don't have the 15.03 version. I overwrote the file after upgrading.

 

[OzHybrid]

The way it's set up now lets you either override the stage completely, or add a "bias" to the stage mass to allow for something like paint. We definitely want the functionality we've got now; I'd be open to better wording.

IMHO overriding the stage should be the complete thing. This is where you override the mass and the CG to the finished rocket. A subcomponents box in the stage override is not intuitive. I don't think allowing for paint is a good enough reason for making it non intuitive. You could just as easily change the weight for the mass override to allow for paint.
Are you saying that at present, what the stage mass override is doing is providing a mass for additional unspecified bits( like paint) UNLESS the "apply to subcomponents" box is ticked. That's not going to be backwardly compatible with older files that have the mass overridden. This does explain a few anomalies I've seen. I'll see if I can find the files.

Also in stage. Override CG position and ticking" for all sub components", is changing the total flight mass rather than just the position of the CG. So something strange going on there too.

 

[4regt4]

The mass was overridden for the stage. The stage IS all subcomponents. You shouldn't have to select the "override for all subcomponents" box if you are overriding the mass at the STAGE.

Hmm..

That's where I put in a typical 2oz penalty for paint and glue. I don't want it to override, I want it to be additive. Which it currently appears to be.

Hans.

 

[OzHybrid]

Hmm..

That's where I put in a typical 2oz penalty for paint and glue. I don't want it to override, I want it to be additive. Which it currently appears to be.

Hans.

So how then do you ACTUALLY override the stage weight to be the ACTUAL built weight? Because if you use it for paint and then tick the override for all sub components your rocket now weighs 2 oz. I get that it's convenient for paint. But that's a limited convenience compared to the inconvenience.
If 2 people use the options 2 different ways we now get files that are not easily useable by someone else.
Imagine RocketReviews which is the repository of most rocket sims with differing methodology across all the sims. It's important the methodology is compatible. And known to all.

 

[JoePfeiffer]

IMHO overriding the stage should be the complete thing. This is where you override the mass and the CG to the finished rocket. A subcomponents box in the stage override is not intuitive. I don't think allowing for paint is a good enough reason for making it non intuitive. You could just as easily change the weight for the mass override to allow for paint.
Are you saying that at present, what the stage mass override is doing is providing a mass for additional unspecified bits( like paint) UNLESS the "apply to subcomponents" box is ticked. That's not going to be backwardly compatible with older files that have the mass overridden. This does explain a few anomalies I've seen. I'll see if I can find the files.

Well, I find it completely intuitive. You've got a component tree; anything with children can override them.

Changing the mass override to account for paint (or whatever) without allowing subcomponents to not be overridden means you need to make a note of what the stage weighs, manually add your paint penalty, and set the override. Now when you change the dimensions of your fins (or whatever) you need to do it again. And again... Much easier to simply add a couple of ounces to the stage and let the program deal with it.

That override subcomponents box has been there since at least 15.03 (you can now decide separately for mass and CG instead of having an all-or-nothing). There should be no change in behavior from earlier versions; if there is, either we've fixed a bug I don't remember or we've got a new one.

Also in stage. Override CG position and ticking" for all sub components", is changing the total flight mass rather than just the position of the CG. So something strange going on there too.

If overriding CG is overriding flight mass then there is a bug that needs to be addressed.

 

[OzHybrid]

Well, I find it completely intuitive. You've got a component tree; anything with children can override them.

Changing the mass override to account for paint (or whatever) without allowing subcomponents to not be overridden means you need to make a note of what the stage weighs, manually add your paint penalty, and set the override. Now when you change the dimensions of your fins (or whatever) you need to do it again. And again... Much easier to simply add a couple of ounces to the stage and let the program deal with it.

That override subcomponents box has been there since at least 15.03 (you can now decide separately for mass and CG instead of having an all-or-nothing). There should be no change in behavior from earlier versions; if there is, either we've fixed a bug I don't remember or we've got a new one.


If overriding CG is overriding flight mass then there is a bug that needs to be addressed.

Screenshots of OP's first file see rocket weight change in window.
,
For paint, add a mass object called PAINT, close to your CG. Do the same for GLUE. It makes NO performance difference where it is added as long as the Cg remains in front of the Cp And once actually painted you need to override the stage mass for the painted object too. This means you need to change the stage mass override from the 2oz for your paint/glue to the real weight of the completed rocket and tick the subcomponents box.
Overriding the mass for some unspecified nameless thing and using the STAGE object to facilitate that is not a good idea for the file design inter compatibility reasons mentioned. Come back to it in 6 months and you probably won't even remember what the unspecified un-named mass overridden thing is..... A lot like uncommented programming lines. You know what it is when you're creating it........

 

[JoePfeiffer]

View attachment 614535View attachment 614536View attachment 614537
Screenshots of OP's first file see rocket weight change in window.

There is a problem there... Mass should have gone up in the second window.

 

[OzHybrid]

There is a problem there... Mass should have gone up in the second window.

For a say bodytube it has a material, density, shape, mass distribution and therefore a Cg position.
For the stage Cg override and then "all subcomponents" where are the relative positions. How can I override the position of a stage cg, if it has no known location? Or is the stage located entirely at the nose tip?

 

[4regt4]

So how then do you ACTUALLY override the stage weight to be the ACTUAL built weight? Because if you use it for paint and then tick the override for all sub components your rocket now weighs 2 oz. I get that it's convenient for paint. But that's a limited convenience compared to the inconvenience.
If 2 people use the options 2 different ways we now get files that are not easily useable by someone else.
Imagine RocketReviews which is the repository of most rocket sims with differing methodology across all the sims. It's important the methodology is compatible. And known to all.

Easy peazy.. Check the box that says the setting overrides the sub-components.

Hans.

 

[OzHybrid]

Easy peazy.. Check the box that says the setting overrides the sub-components.

Hans.

No..... If you are using that section for your paint....... doing that makes your entire rocket weigh what your paint weighs.... 2 oz.
You need to change the value to your final weight AND tick apply to sub components.

 

[neil_w]

If you do use the above method for paint mass then you need to use a mass object to bring the whole rocket up to measured mass, which is how some people do it anyway, for various reasons.

One thing I’ve learned is that folks use the program in all different ways, and usually it’s fine. Our job is to make sure that using it the “standard” way is clear and intuitive (where I think we could be doing better here), while not precluding all the other stuff.

This particular case is a bit thorny. We’ll get it sorted.

 

[CalebJ]

No..... If you are using that section for your paint....... doing that makes your entire rocket weigh what your paint weighs.... 2 oz.
You need to change the value to your final weight AND tick apply to sub components.

I must be misinterpreting what you're saying...

If I open one of my OR models (in 22.02) and go to a booster stage, then do a mass override (with or without ticking the sub components option), it does -not- make my entire model weigh the amount of the override.

 

[JoePfeiffer]

I must be misinterpreting what you're saying...

If I open one of my OR models (in 22.02) and go to a booster stage, then do a mass override (with or without ticking the sub components option), it does -not- make my entire model weigh the amount of the override.

It should be making that booster weigh the amount of the override if the subcomponents option is clicked.

 

[CalebJ]

It should be making that booster weigh the amount of the override if the subcomponents option is clicked.

Thanks for clarifying, that was my understanding but it's good to have confirmation. So I'm thoroughly confused by post#26.