OpenRocket Inconstistencies?

[RocketScientists]

I've been using OpenRocket for a while now and I have noticed that there appear to be some inconsistencies when calculating maximum velocity and altitude, particularly with the Ogive nose. If I switch between shape factor values (aside from 0) the values change. Why does this happen and where else would I find these incosistencies? I understand that drag calculations tend to be complicated, however if the equations are the same, then shouldnt the values remain consistent?

 

[TopRamen]

It' just a sim, and though it is a really great sim in my opinion, my actual launch data is never dead on with what OR predicts, so I don't sweat the small stuff. Doing that can stall a build or discourage a design from ever reaching fruition, where as I prefer my design/build stalls to be my fault or the fault of extenuating circumstances beyond my control.
If your talking about for HPR, then I can understand the desire to nail down every last thing, do to the cost and resources involved and lack of actual availability of airspace to fly in, but for anything else I would let something like that slide and base my design judgements on what is known about the general characteristics of the different common profiles of nose cones.
My actual launch data which I generally get from watching the video afterwards as I have yet to employ avionics save for an 808 camera, typically at best match OR's sim data to within 7%, and more generally fall into the 10-15% range.
Sometimes OR is off by a long way, but as long as I have a SAFE launch, it is still all good, and things are learned.


Oh, and welcome to the forum!!

 

[dhbarr]

It also seems the 6DOF calculations involve Monte Carlo or some other technique.

To see this, build something near an edge of one of the performance envelopes, add a tiny mass object at the CG, then watch it go nuts for a bit as you add and remove less than a gram.

Or shorten some tubefin a mm at a time until the acceleration suddenly jumps.

 

[Buckeye]

I've been using OpenRocket for a while now and I have noticed that there appear to be some inconsistencies when calculating maximum velocity and altitude, particularly with the Ogive nose. If I switch between shape factor values (aside from 0) the values change. Why does this happen and where else would I find these incosistencies? I understand that drag calculations tend to be complicated, however if the equations are the same, then shouldnt the values remain consistent?

Don't understand. More details, please.

Nose cone shape changes > drag changes > altitude and velocity change. What is inconsistent about that?

 

[K'Tesh]

Something that might help us is if you were to upload screen grabs and/or .ork files of your project, so we could see what may be going on.

However, Buckeye is correct, changing the shape of the nosecone can have a profound effect on the performance. You might also want to look at how the mass of the NC changes with your changes to the shape. More surface area will translate into more material being used to make it, weight goes up accordingly.

Oh, and... Welcome to the forum! (Post Pics :wink

 

[RocketScientists]

Wow guys thanks for the quick replies and the warm welcomes, this is amazing! Sorry for being unclear, I just read through it again and it doesn't make much sense lol.

I'm actually building a H-class rocket for my masters project with a group and I'm still in the process of re-designing a model created last year (they're missing a lot of information). I wanted to see how changing different factors would affect the altitude and velocity and when I started playing around with the ogive nose cone, I found this inconsistency. I've made an example with the simple model rocket template and I know I'm being a little picky, but I get the feeling that this could make a greater difference for bigger rockets.

 

[RocketScientists]

It' just a sim, and though it is a really great sim in my opinion, my actual launch data is never dead on with what OR predicts, so I don't sweat the small stuff. Doing that can stall a build or discourage a design from ever reaching fruition, where as I prefer my design/build stalls to be my fault or the fault of extenuating circumstances beyond my control.
If your talking about for HPR, then I can understand the desire to nail down every last thing, do to the cost and resources involved and lack of actual availability of airspace to fly in, but for anything else I would let something like that slide and base my design judgements on what is known about the general characteristics of the different common profiles of nose cones.
My actual launch data which I generally get from watching the video afterwards as I have yet to employ avionics save for an 808 camera, typically at best match OR's sim data to within 7%, and more generally fall into the 10-15% range.
Sometimes OR is off by a long way, but as long as I have a SAFE launch, it is still all good, and things are learned.


Oh, and welcome to the forum!!

Yea I completely understand, there's no point in letting an anomaly waste your time. I'm actually asking this more out of curiosity so I have something more I can talk about. It's a general need of mine to look at every little thing when it comes to experimental projects, particularly in the field of aerospace engineering, given that so much of it is based on approximations, previous data and assumptions.

 

[Buckeye]

Wow guys thanks for the quick replies and the warm welcomes, this is amazing! Sorry for being unclear, I just read through it again and it doesn't make much sense lol.

I'm actually building a H-class rocket for my masters project with a group and I'm still in the process of re-designing a model created last year (they're missing a lot of information). I wanted to see how changing different factors would affect the altitude and velocity and when I started playing around with the ogive nose cone, I found this inconsistency. I've made an example with the simple model rocket template and I know I'm being a little picky, but I get the feeling that this could make a greater difference for bigger rockets.

View attachment 303303View attachment 303304

Multiple switching of settings back and forth produced some small numerical round-off. The answer is the same.

 

[Banzai88]

It's a sim. It's FREE. It's NOT perfect. The "inconsistencies" that you're showing are well within the variability of the motor itself. Run the sim 100 times and you're going to get a bell curve of results, and that's been more than good enough for 99.9% or more of sport rocketry applications.

If you need better fidelity, it's going to run you some coin.

 

[Buckeye]

The OP is simply showing how OR does not repeat itself when the GUI is reset to the same inputs. I think. Yes, nit-picky. Small differences occur in the results due to accumulated round off errors as the settings get switched back and forth. This is likely a just a little sloppy programming, and not a problem with any simulation algorithm. I have seen similar things happen in other software (including my own), especially when doing unit conversions. There is a proper way to code this and maintain the correct significant digits when the user iterates on these values.

 

[RocketScientists]

The OP is simply showing how OR does not repeat itself when the GUI is reset to the same inputs. I think. Yes, nit-picky. Small differences occur in the results due to accumulated round off errors as the settings get switched back and forth. This is likely a just a little sloppy programming, and not a problem with any simulation algorithm. I have seen similar things happen in other software (including my own), especially when doing unit conversions. There is a proper way to code this and maintain the correct significant digits when the user iterates on these values.

Ah I see, thanks for the explanation. Yea I just wanted to get an idea of where exactly this was coming from, as opposed to actually fixing it or anything. It's good to be aware of where these changes come from. Thank you.