ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

[Dane Ronnow]

I'm sorry to say CD overrides are completely broken at present.

Are you talking about overriding the sustainer Cd? Or overriding anything?

I'm overriding the nose cone Cd in beta 4 to bring my sim altitudes down to what they were in v15, which were very close to actual flights recorded by FlightSketch. It works.

 

[Dane Ronnow]

@JoePfeiffer, @neil_w --

I wanted to put up screen shots of the simulations before and after Cd adjustment on the nose cone (see post above), and found what appears to be a bug.

Here's the simulation before adjusting nose cone Cd, with an apogee of 2822:



Then I go to design view and change the Cd to .09, which brings the apogee in the design view down to 2621. But when I switch back to the simulation view, I find that the apogee in the first simulation has changed to the the new value.

I ran the second simulation (after Cd adjustment), and they're identical.



When I first downloaded beta 4, I changed the preference in the Simulation tab to NOT update simulations when I open the simulation view. That change was made before running any simulations.



I rechecked that box and ran the simulations again (before and after Cd change), and found the only difference was that when I switched to simulation view, a progress bar popped up showing that the sims were being updated.

With the box unchecked, the sims are still updated, just without the progress bar popping up.

Bug?

[Edit] I'm on Win 8.1. I downloaded the v22 beta 4 package installer. The v15.03 that I still use was downloaded back in July 2020 as a JAR file. (I have no problems running that one.)

 

[Dane Ronnow]

Just to make sure that sim update wasn't caused by a bug in the Cd adjustment, I ran the same test before and after changing the weight of the nose cone. Same results (previous sim changing to match the new sim):





I did notice that there is one difference in the two sims—Ground Hit Velocity. Everything else is the same.

 

[H. Craig Miller]

Just to make sure that sim update wasn't caused by a bug in the Cd adjustment, I ran the same test before and after changing the weight of the nose cone. Same results (previous sim changing to match the new sim):

View attachment 525166

View attachment 525167

The preference setting to "Run out-dated simulations. . . " refers to Flight configurations that are not selected. For example. without that preference checked, if you have 10 simulations and simulation 5 is shown as the current flight configuration, a component change will update only simulation 5 (if you set the current Flight configuration to No motors, none of the simulations will be updated); with that preference checked, if you have 10 simulations, a component change will update all 10 simulations regardless of which simulation is the current flight configuration. OpenRocket always updates a selected Flight configuration.

 

[Dane Ronnow]

[Edit]

 

[Dane Ronnow]

The preference setting to "Run out-dated simulations. . . " refers to Flight configurations that are not selected. For example. without that preference checked, if you have 10 simulations and simulation 5 is shown as the current flight configuration, a component change will update only simulation 5 (if you set the current Flight configuration to No motors, none of the simulations will be updated); with that preference checked, if you have 10 simulations, a component change will update all 10 simulations regardless of which simulation is the current flight configuration. OpenRocket always updates a selected Flight configuration.

I realize I've kind of taken over this discussion, and I apologize. And tempted as I am to just leave it where it is and walk away, I want to understand exactly what you're saying here, and why I'm missing it. Please forgive me if I seem to be beating a dead horse; I don't mean to.

Let me show you the steps I'm taking, then, if you would, please show me precisely what I'm doing wrong. (By precisely, I mean by using my steps, not a random example of 10 simulations. Please.)

The design is open in v22b4, with all simulations deleted and the preference to run outdated simulations unchecked:



Then I run five simulations back-to-back, for five different motors:



I switch from Flight simulations to Rocket design, and following your instruction—"...(if you set the current Flight configuration to No motors, none of the simulations will be updated)..."—I select No motors under Flight configuration, then open the Nose cone editor and change the Cd to 0.09:



Then I switch back to Flight simulations:



All previous simulations are outdated.

Now I want to run a simulation using the G10 motor (simulation 3) to compare the data from that motor before and after the Cd change. But as soon as I select the motor in the Edit simulation window, the previous G10 flight is updated to show the new flight data, before I actually run the simulation:



After running the new simulation:



Both G10 sims are the same.

All I want is to compare the two G10 flights—before the Cd change, and after.

Again, I apologize if it appears I'm taking over this discussion of OpenRocket v22b4. I started by replying to @JoePfeiffer's comment that Cd overrides were "completely broken at present" by showing how I changed the nose cone Cd to effect a change in apogee (to which Joe never responded), only to discover this issue with simulations updating when I don't want them to.

I never had this happen in v15, and in fact relied on being able to see flight data before and after a component change.

If you— @H. Craig Miller —or anybody else (@neil_w or @JoePfeiffer?) could explain what I'm doing wrong using my example in this post, I'd appreciate it more than I can say. Thanks very much.

 

[JoePfeiffer]

Again, I apologize if it appears I'm taking over this discussion of OpenRocket v22b4. I started by replying to @JoePfeiffer's comment that Cd overrides were "completely broken at present" by showing how I changed the nose cone Cd to effect a change in apogee (to which Joe never responded), only to discover this issue with simulations updating when I don't want them to.

I'm sorry it's taken me so long to respond; I've had an interesting couple of weeks: one week helping at Spaceport America Cup (which is a grueling exercise!) followed by a week with covid which I'd picked up at SA Cup. So at the moment I'm just trying to get caught up on stuff...

Anyway, when I said Cd override was completely broken, I didn't mean there were no circumstances under which specifying an override would result in a visible change to a simulation. However,

1 I'd already figured out I was going to be rewriting it, so when I refactored Cd calculations I didn't worry about it in the friction drag calculation. There's every chance (I haven't actually checked this... I've got to go through all the relevant code anyway, so there's no reason to) that when you adjust a component's Cd you'll just adjust the pressure Cd, and the calculated friction Cd (and maybe even base Cd) may get added to it.

2. There's no sense of a hierarchical override, like CG has. You can't say "I want to set the Cd of the subtree of components rooted at this body tube to .2. You have to do something like set the Cd of the body tube to .2, and all the subcomponents to 0. Yuck.

3. Related to the above, there's no way to set the Cd of an entire stage or rocket, which is what 99% of all users will want to do with a Cd override.

Those are the problems with it that immediately jump to mind. If there's more wrong besides, it wouldn't surprise me at all.

 

[Dane Ronnow]

I'm sorry it's taken me so long to respond; I've had an interesting couple of weeks: one week helping at Spaceport America Cup (which is a grueling exercise!) followed by a week with covid which I'd picked up at SA Cup. So at the moment I'm just trying to get caught up on stuff...

I appreciate the reply, Joe. Sounds like you've got your hands full. Sorry to hear you caught COVID. I hope it doesn't wipe you out for weeks like it has so many others I know.

Thanks for explaining the Cd problems with the new release. I now understand it's not a simple matter of clicking my way to an accurate simulation in v22.

The bigger problem for me is why I can't preserve previous launch data when I make a change to a component. @H. Craig Miller tried explaining it to me, but I'm missing something, because no matter how I run the simulations (motor selected, no motor selected), the previous data changes. My response to him is the post right above yours.

He asked me in a conversation to post the .ork file. I'm not sure what he can glean from that that he couldn't get from running any file in v22—run a sim, make a change, run the sim again, both sims come out identical to each other. Could it be my .ork file? I guess I'll wait and see what he comes back with.

Anyway, thanks again, and thanks to all you guys for the hard work on these releases. I know enough about coding to know it's extremely detailed work, frustrating at times for sure, but also rewarding.

Keep up the good work. And get well!

 

[H. Craig Miller]

"if you would, please show me precisely what I'm doing wrong. (By precisely, I mean by using my steps. . ."

You are using the OpenRocket application incorrectly.

Using your steps, complete through:

All previous simulations are outdated.

Then, go to the Motors & Configuration tab, select the G80-10 motor configuration, left-click Duplicate Configuration (do not change the motor settings), and you now have a new duplicate G80-10 motor configuration. Now, go to the Flight simulations tab, left-click New simulation and create and run the new G80-10 simulation (do not change the simulation settings), and you now have two G80-10 simulations, the old outdated (pre-change) G80-10 simulation and the new updated G80-10 simulation (with the Cd change).



A comparison between the results shows the effects of the change in the nose cone Cd.

A clarification may help. When you add a new simulation, if you use an existing motor configuration, you are simulating the flight of the same rocket configuration, twice. The method you were using is intended to change/compare launch conditions and simulation options (such as launch field coordinates/altutude data).

 

[Dane Ronnow]

You are using the OpenRocket application incorrectly.

When it comes to updating sims, I'd say yes, I see that now. But frankly, I'm sitting here wondering why would the developers make you do all that, when in v15 it was a simple matter of run sim, make change, run sim again. That was it! Instant feedback.

Unless there's a lot more to why motors are updated than I know about, I have to say that was a step backward. At least half my time in OpenRocket is spent optimizing a build as it nears completion—making a change, and seeing what effect it has on the flight. Now it involves another menu, more mouse clicks? It's just not as efficient as v15—unless, and I emphasize this, there are a lot more reasons to having sims update or not, and I'm just using the one: experimenting with the build—a lot of small changes, a lot of simming for comparison.

On the upside for me, v15 is, at least for my rocket, much more accurate in the sims when compared to altimeter data. And, like v22 will become, it's a great piece of software.

Disclaimer: A lot of what I've read in this thread—and I read it all—focuses on 3D rendering, and what v22 can do that 15 couldn't. I get that. But I don't use 3D. So, all that is set aside in my mind when I'm deciding if v22 is right for me.

Frankly, I never found myself wishing OpenRocket would do more when I was using v15. I'm good with it, and it's good to me. Thanks again to the developers for their tireless work. I love this piece of software.

 

[H. Craig Miller]

A lot of what I've read in this thread—and I read it all—focuses on 3D rendering, and what v22 can do that 15 couldn't. I get that. But I don't use 3D. So, all that is set aside in my mind when I'm deciding if v22 is right for me.

You are correct that many posts relating to the 22 beta versions talk about the 3D features. . . primarily because these are discussing problems/issues that are in the process of being resolved. However, the 3D changes/improvements are only a small portion of the improvements that have been made in the beta versions as compared to v15.03.

A review of the release notes may be helpful in indentifying changes/improvements in the functions that you use. The Wiki pages may also provide helpful information on how OpenRocket currently functions.

 

[Dane Ronnow]

A review of the release notes may be helpful in indentifying changes/improvements in the functions that you use. The Wiki pages may also provide helpful information on how OpenRocket currently functions.

I've read those, but thanks. And thanks for the conversation. You and @JoePfeiffer have got me on track. Thanks to both of you for your time. And please understand I'm not dissing v22 in any way. Right now, though, for me, v15 is the ticket.

Before I duck out of here, I need to apologize to everyone on this thread for sucking the air out of the discussion. I'm very sorry. It won't happen again. My best to all—the developers and the users.

 

[Charles_McG]

I think any discussion on how people actually use OR is valuable.

Your use case happens to break OR’s paradigm of ‘fixed design, variable flight configs, variable launch conditions’ - but it’s not the only case that does. There’s at least one request to have a sim-variable mass element (stability ballast) out there that’s similarly paradigm breaking.

V15 immediately updates the summary info in the drawing pane. I hadn’t noticed that V22 propagates that to the sim window. If that’s what’s happening.

 

[neil_w]

Before I duck out of here, I need to apologize to everyone on this thread for sucking the air out of the discussion. I'm very sorry. It won't happen again. My best to all—the developers and the users.

Nonsense. The issue you've raised here is important, and thank you for expending the effort to keep explaining it until we get it. I'm still not 100% certain I've gotten my head around the whole thing, because there are a lot of interrelated parts here, but there's definitely something here we should investigate (at minimum) and/or fix (likely)

Now I want to run a simulation using the G10 motor (simulation 3) to compare the data from that motor before and after the Cd change. But as soon as I select the motor in the Edit simulation window, the previous G10 flight is updated to show the new flight data, before I actually run the simulation:

That seems screwy to me. I'm going to have to play with this and try to reproduce. Sure seems like a bug to me. [edit: I just played with this and confirmed it. Definitely a bug AFAIC.]

On the upside for me, v15 is, at least for my rocket, much more accurate in the sims when compared to altimeter data. And, like v22 will become, it's a great piece of software.

This is something else that we would like to look at; we certainly want v22 to be at least as accurate as v15 if not better. Exactly how much difference are you seeing? Could you provide an ORK file(s) and flight data to go with it? If so we can try to see where the divergence is taking place.

V15 immediately updates the summary info in the drawing pane. I hadn’t noticed that V22 propagates that to the sim window. If that’s what’s happening.

V22 is much more rigorous about updating sim results for the current selected configuration as you make changes to the design. V15 was a bit inconsistent in this regard and not fully reliable.

In fact, v22 *does* propagate the design window results to the simulations tab (for the current selected config). I think that's probably a mistake. Will look into it.

Thanks again to everyone for this discussion. Only by understanding all different use cases can we keep making OR work better for everyone. We may not always be able to respond to all these issues as quickly as we'd like, but everything is considered and fixed whenever possible.

 

[H. Craig Miller]

At least half my time in OpenRocket is spent optimizing a build as it nears completion—making a change, and seeing what effect it has on the flight. Now it involves another menu, more mouse clicks? It's just not as efficient as v15—unless, and I emphasize this, there are a lot more reasons to having sims update or not, and I'm just using the one: experimenting with the build—a lot of small changes, a lot of simming for comparison.

And please understand I'm not dissing v22 in any way. Right now, though, for me, v15 is the ticket.

The resolution of your concern may be followed as Issue #1510.

 

[H. Craig Miller]

Issue #1510 has been fixed and merged, and will be included in the next release. Using the .ork provided by Dane Ronnow, the functionality will be as shown below.

 

[Dane Ronnow]

This is something else that we would like to look at; we certainly want v22 to be at least as accurate as v15 if not better. Exactly how much difference are you seeing? Could you provide an ORK file(s) and flight data to go with it? If so we can try to see where the divergence is taking place.

[Edit] The rocket in the .ork file attached, and used in these sims and actual flight, is the same rocket as in the posts above, but before the fins were modified. This rocket has been launched; the one in the posts above has not, just simmed. [/Edit]

This is the FlightSketch data from a G74-9 launch:

Apogee: 1558.7 ft
Max Speed: 303 mph
Time to Apogee: 10.2 secs
Total Time: 165.4 secs
Avg Descent: 10 fps

Sims shown below use the same launch conditions as those during the actual launch on the lake bed.

v15 sim:



v22 sim:



Link to the FlightSketch log: https://flightsketch.com/flights/3415/

.ork file:

 

[Charles_McG]

[Edit] The rocket in the .ork file attached, and used in these sims and actual flight, is the same rocket as in the posts above, but before the fins were modified. This rocket has been launched; the one in the posts above has not, just simmed. [/Edit]

This is the FlightSketch data from a G74-9 launch:

Apogee: 1558.7 ft
Max Speed: 303 mph
Time to Apogee: 10.2 secs
Total Time: 165.4 secs
Avg Descent: 10 fps

Sims shown below use the same launch conditions as those during the actual launch on the lake bed.

@Dane Ronnow , I'm not somewhere I can try your ORK in both versions handily. But could you humor me and set the wind to 0 with 0 variability in both versions and see what the diff is? I'm thinking that looks like a difference in degree of weathercocking, given the apparent trade off of altitude and velocity at apogee.

 

[Dane Ronnow]

But could you humor me and set the wind to 0 with 0 variability in both versions and see what the diff is? I'm thinking that looks like a difference in degree of weathercocking, given the apparent trade off of altitude and velocity at apogee.

Hey, I'm all about humor

v15, zero wind:



v22, zero wind:

 

[thzero]

[

Why do you keep trying to change the cd of the nose cone? That's got me confused. Do you have like updated data on the nose cone from a test? If so should update the parts database.

Otherwise I guess I'm missing the point.

 

[Dane Ronnow]

Why do you keep trying to change the cd of the nose cone?

@JoePfeiffer mentioned in post #493 that Cd overrides in beta 4 are broken. In post #511, I replied, saying that I was able to change the Cd of the nose cone to bring the apogee in the simulation down to what was recorded in the actual flight. That's where this turn of the thread started—me suggesting that the Cd could be changed to bring sim values closer to what they actually are. Joe responded in #517, kindly educating me in the subtleties of drag coefficients. (Which is to say I know practically nothing about it. )

So, no, this was not about new nose cone data. Just me experimenting.

 

[Charles_McG]

Feature request: Change summary metrics in simulations table and export the summary table.

I can enter this into github if there isn't a related one already. I'm not so good at searching there yet.

So what I'd like to do is be able to edit the columns shown in the simulations overview. I'd like to be able to pick from all the various calculations available - and the time/event. For instance, altitude and vertical velocity of second stage ignition, or stability at end of launch rod, or sustainer landed distances north and east. All things available within the sim.

After that, I'd like to either be able to select rows and cells and copy them in a way that pastable into <spreadheet of choice>, or export the summary table as a delimited file.

This would be really useful for when I plan flights, but I think it would also be useful for people working on exploring design changes. The optimizer might function - but sometimes it's easier to relate to metrics coming out of the end sims. If the table was exportable, a user could set of a series of test case flight condition sims, export it, make a design change, export it, repeat - and use a different platform to visualize the changes.

 

[neil_w]

New poll question!

Does anyone use the sliders in the component editor? If so, what for?

 

[Charles_McG]

New poll question!

Does anyone use the sliders in the component editor? If so, what for?

Positioning components. I use it to get close and vary it a bit. Then I'll enter a direct number if I really need to.

 

[Charles_McG]

@neil_w - do you have any thoughts on my suggestions above?

 

[neil_w]

@neil_w - do you have any thoughts on my suggestions above?

Not many.

I mean, that sort of configurability is always a good thing, but I have no idea either (a) how hard it is to implement, or (b) where it would slot on the priority list.

Would you be willing to enter the feature request on Github, or do you want me to copy it over?

 

[Charles_McG]

I can put it in - tomorrow. The github credentials are cached on my work laptop, which is the only verified email. The verification email sent to my primary account got eaten by my host's spam monster.
I understand that it's a low priority idea - but I thought it would complement some of the recent use cases brought up.

 

[Dane Ronnow]

Does anyone use the sliders in the component editor? If so, what for?

I use the position slider when I add a new component, to quickly move the component where I need it. Then I fine tune the position with the up and down arrows, or by entering a number in the field.

I seldom use dimension sliders (diameter, thickness, etc.).

 

[rocketgeek101]

Would it be possible to have thrust to weight ratio displayed for a flight simulation in the simulations tab? Obviously it's easy enough to calculate on your own (and the PDF printout shows it), but having it displayed right there in the tab would be useful. Actually I think it would be useful to display the average thrust to weight, as well as the initial thrust to weight (just after motor ignition).

I've been finding that the freeform fin editor is not as responsive compared to the previous version in 15.03 (on my Mac at least). I like the new design of the editor UI, but the lack of responsiveness makes it a bit frustrating to use.

(Also, as a dark mode aficionado, what are the odds of a future OR release having a dark mode? )

 

[rharshberger]

Would it be possible to have thrust to weight ratio displayed for a flight simulation in the simulations tab? Obviously it's easy enough to calculate on your own (and the PDF printout shows it), but having it displayed right there in the tab would be useful. Actually I think it would be useful to display the average thrust to weight, as well as the initial thrust to weight (just after motor ignition).

I've been finding that the freeform fin editor is not as responsive compared to the previous version in 15.03 (on my Mac at least). I like the new design of the editor UI, but the lack of responsiveness makes it a bit frustrating to use.

(Also, as a dark mode aficionado, what are the odds of a future OR release having a dark mode? )

Kind of like this idea/feature, for RSO's it would save us a bit of time without having to look up a thrust curve. Usually I am most concerned about the first .5 seconds of the burn after that the rocket should be stable or its probably going to be ugly.