Not getting expected results from OpenRocket . . .

The Rocketry Forum

Help Support The Rocketry Forum:

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

Paul Thayer

New Member
Joined
Dec 22, 2019
Messages
4
Reaction score
0
Downloaded the RockSim file for the Apogee Research Express. Ran simulations with B6-4 and C6-5 motors. Didn't match results from Apogee website or from empirical evidence. :) Any ideas what I am doing wrong? (Note that I saved the simulations in ORK format.) Thanks in advance for any help!

--Paul
 

Attachments

  • research_express.rkt
    17.9 KB · Views: 16
  • research_express.ork
    2.6 KB · Views: 19
Why is the mass of the payload coupler overridden to over 50g?

Also, you say the results don't match. Can you give numbers?
 
Yep, I just saw those overrides, too. (I'm a rookie at all of this, so I'm learning more each day.) I weighed my own finished/painted Research Express (which includes a 3x3 "wadding" cloth), and it only weighs 41g without any motor installed.

I've seen weird (non-repeatable) behavior from OpenRocket. Initial sims. matched results from Apogee's website. Later results had changed. Not sure what I did to cause that. Then this morning, while clicking through various parts to see their weights, the rocket's overall weight changed, too. Time for a re-install, I guess. Maybe OpenRocket has some issues reading the RockSim format?

In any event, thanks to both of you for helping out! If I remove those overrides, results look reasonable.

Paul
 
The other thing RockSim does (which goes the other way) is assume everything is polished smooth. Here's what I get when take off the override for the coupler and change the surface finish to "regular paint".

Based on having LOTS of data flying alitimeters aboard the Estes Nova Payloader, which is a similar-sized model with bigger fins, I'd say these results are reasonable. One other setting to look at is the fin edges. I've left them square here. Screen Shot 2019-12-22 at 11.59.57 AM.png

And yes, it's not that unreasonable to only get a little more altitude with a Q-Jet D16. The extra total impulse gets spent with extra drag. This is a place were rounded fins will help.

Based on the B6 and D16 numbers though (and lots of Nova Payloader flights) that estimate for the Estes C6 is optimistic.
 
Bernard,

I got your exact results, so that's good.

When I look in the RKT file for the Research Express, on line 84, I see this: <KnownMass>52.447</KnownMass>. Line 91 has what I think is the correct mass: <CalcMass>1.332741373121493</CalcMass>. I have no idea why that "KnownMass" line is there, though. (Tim at Apogee answered my earlier email to say that this file worked fine in RockSim. I'll see if he answers my question about the mysterious "KnownMass" line.)

Maybe line 31, <UseKnownMass>0</UseKnownMass>, tells RockSim to ignore the "KnownMass" data. Maybe OpenRocket isn't correctly interpreting that flag.

It is nice that the RKT format is easily human readable. I wish the OKT format was similar.

Paul
 
It is nice that the RKT format is easily human readable. I wish the OKT format was similar.

Paul

The .ork is merely a zipped file. Open it in in WinZip and you will find another text file written in the same XML format.

When it comes to GUI layout, file structure, and pre/post-processing, OR pretty much knocked-off RockSim. So, there is likely an equivalent feature to whatever you are looking for.
 
Remember also that any closed-form approximation to reality will have some anomalies where the algorithm will "blow up" and give unexpected results - even if the model is right, if one of the intermediate terms in the calculation is very near to zero or the maximum value for the numeric type, the "finite" calculation may be far different from the real-world result. [Look up chaos theory and the theory behind numerical analysis of differential equations...]. In this case, it does sound more like there are some mass items that OpenRocket accounts for differently than RockSim. In any event - if you can't fix the computer model in OpenRocket for this particular vehicle, use something different. I think WinRASP is still out there too...as is the original G. Harry Stine RASP - I have a "translation" of it that's written in C, which I still use occasionally to confirm OpenRocket or RockSim results.

Mark J
Old-fart mathematician
 
Remember also that any closed-form approximation to reality will have some anomalies where the algorithm will "blow up" and give unexpected results - even if the model is right, if one of the intermediate terms in the calculation is very near to zero or the maximum value for the numeric type, the "finite" calculation may be far different from the real-world result. [Look up chaos theory and the theory behind numerical analysis of differential equations...]. In this case, it does sound more like there are some mass items that OpenRocket accounts for differently than RockSim. In any event - if you can't fix the computer model in OpenRocket for this particular vehicle, use something different. I think WinRASP is still out there too...as is the original G. Harry Stine RASP - I have a "translation" of it that's written in C, which I still use occasionally to confirm OpenRocket or RockSim results.

Mark J
Old-fart mathematician

It is highly unlikely that the algorithms are blowing up. These are fairly simple ODEs solved with robust 4th order Runge-Kutta schemes that allow pretty large time steps. OpenRocket and RockSim are far more advanced than 40 year old RASP codes that used first-order Euler method, constant drag, no atmospheric model, etc.

99% of these problems are user error.
 
Back
Top