ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

[thzero]

thanks. I will delete those .eng files.
Where did they come from?
Do I need the "C:\Users\waltr\AppData\Roaming\OpenRocket " folder?? Why is that there with nothing in them except bad .eng files??

Its a customization folder; allows the user to put custom thrust curves (engines), plugins and components into the folder which is where OpenRocket will pick them up from when it boots up.

User would have had to put them in the folder.

 

[waltr]

Ok, thanks again for explanation. I probable loaded these from thrust curve when first installed OR 15 since it did not have the newer motors.

I will delete the .eng files from that folder.

 

[Kelly]

Sorry, don't have time to read the whole thread but I don't see this listed in the known bugs list. Saw this on both the beta1 and beta2 versions, on Win10:

I have custom motor files I use. Always worked fine in OR15. If I add some of these to configurations, I notice that the last one added does not simulate - it shows up in the simulation list as "No Motors". But if I add another configuration, and use the same motor (or a different one), then the previous one suddenly works fine, and the one most recently added shows up as 'no motor'. In other words, motors/configurations 1 through N-1 work fine, but motor/configuration N is not seen.

Should I report this on github, or am I missing something?

 

[JoePfeiffer]

Found it in:
C:\Users\waltr\AppData\Roaming\OpenRocket\ThrustCurves
There are also "Aerotech.eng", "Estes.eng" ans Quest.eng" is this folder.
Should I delete them??

Unless those are custom motor files that you added, yes.

The Components & Plugins folders here have nothing in them..
Should the folders be deleted??

Those are for adding things like components to the database, and should do no harm. I actually don't know what would happen if they were deleted; I haven't tried it...

That screenshot contains the actual error message ("Two thrust values for single time point") which is what we have needed to be sure of what's going on. It'll be fixed in the next beta.

 

[JoePfeiffer]

Sorry, don't have time to read the whole thread but I don't see this listed in the known bugs list. Saw this on both the beta1 and beta2 versions, on Win10:

I have custom motor files I use. Always worked fine in OR15. If I add some of these to configurations, I notice that the last one added does not simulate - it shows up in the simulation list as "No Motors". But if I add another configuration, and use the same motor (or a different one), then the previous one suddenly works fine, and the one most recently added shows up as 'no motor'. In other words, motors/configurations 1 through N-1 work fine, but motor/configuration N is not seen.

Should I report this on github, or am I missing something?

Please file the issue on github. Sounds like an off-by-one error has crept in...

 

[waltr]

I deleted the .eng files in that user folder and OR V22 opens without any complaint.
Thanks for the help to determine what was going on.

 

[4regt4]

Not sure if anyone else is having this issue, or if it's been reported elsewhere.....

HP laptop, Windoze 10

In the "Motors and Configurations" tab, in the "Motor configuration" selection window, the window on my display is a very narrow slit. I can barely see half of just one of the configurations, just enough to know what it is. It's workable as-is, but it would be nice to see the entire height of the line, or multiple lines.

Hans.

 

[neil_w]

Not sure if anyone else is having this issue, or if it's been reported elsewhere.....

HP laptop, Windoze 10

In the "Motors and Configurations" tab, in the "Motor configuration" selection window, the window on my display is a very narrow slit. I can barely see half of just one of the configurations, just enough to know what it is. It's workable as-is, but it would be nice to see the entire height of the line, or multiple lines.

Hans.

Screenshot please.

 

[4regt4]

Screenshot please.

OK. Might be a day or two... I'm not near the computer right now.

Hans.

 

[Charles_McG]

Apologies up front for reporting an issue here, rather than on github - but I'm unfamiliar with the process there - and don't have an account (if that's even needed).

This is related to the configuration error listed above - but goes beyond it. It may have just cost me a successful flight, since I used a faulty sim to set the altitude limits on my eggtimer Proton for my Terrier Sandhawk flight this past weekend. I found this during the data review, and then confirmed in OR 22, beta 2.

First - the configuration list displayed when editing a simulation always lists one more configuration than actually exists, apparent repeating the first config.


And then the bigger problem. There are two CTI H255 motors, and even though I select the 4G WT, the sim uses the 6G BS. I've tried deleting all the configs and sims and rebuilding, but end up in the same place. I found this by comparing the Proton G curve to the OR sim - usually there's a really close match, but this time it was notably different.

Here's the motor selection filtered to the H255s. You can see I've selected the 4G, but the 6G's curve is highlighted. It's also the data that shows up in the simmed flight.


Next, I used the length filter to limit the list to the 4G. Expanding graph - nice feature, BTW - shows both curves , and they have the same label - which is incorrect, since the BS is a 316H255


If I filter to just the 6G, I get one curve - labeled correctly.


And the flight data, for good measure. [Please ignore the issues arising from a sealed av-bay. Look at the acceleration curves on the bottom.]


I really do appreciate all the hard work. Does anyone have an idea how far back this issue goes? I don't really want to go back to 15.03, since the motor selections are incompatible and I have to rebuild the configurations.

 

[JoePfeiffer]

Apologies up front for reporting an issue here, rather than on github - but I'm unfamiliar with the process there - and don't have an account (if that's even needed).

This is related to the configuration error listed above - but goes beyond it. It may have just cost me a successful flight, since I used a faulty sim to set the altitude limits on my eggtimer Proton for my Terrier Sandhawk flight this past weekend. I found this during the data review, and then confirmed in OR 22, beta 2.

First - the configuration list displayed when editing a simulation always lists one more configuration than actually exists, apparent repeating the first config.
View attachment 514851View attachment 514850

And then the bigger problem. There are two CTI H255 motors, and even though I select the 4G WT, the sim uses the 6G BS. I've tried deleting all the configs and sims and rebuilding, but end up in the same place. I found this by comparing the Proton G curve to the OR sim - usually there's a really close match, but this time it was notably different.

Here's the motor selection filtered to the H255s. You can see I've selected the 4G, but the 6G's curve is highlighted. It's also the data that shows up in the simmed flight.
View attachment 514852

Next, I used the length filter to limit the list to the 4G. Expanding graph - nice feature, BTW - shows both curves , and they have the same label - which is incorrect, since the BS is a 316H255
View attachment 514853

If I filter to just the 6G, I get one curve - labeled correctly.
View attachment 514855

And the flight data, for good measure. [Please ignore the issues arising from a sealed av-bay. Look at the acceleration curves on the bottom.]
View attachment 514861

I really do appreciate all the hard work. Does anyone have an idea how far back this issue goes? I don't really want to go back to 15.03, since the motor selections are incompatible and I have to rebuild the configurations.

Screenshot please.

This is something that's been reported before -- the issue is the screen isn't tall enough to accommodate our layout (I see it on my 13" Dell too). We may need to start eliminating some of the frames we have around windows when the screen is too short... which would be ugly, but would make those lilliputian laptops viable.

 

[JoePfeiffer]

First - the configuration list displayed when editing a simulation always lists one more configuration than actually exists, apparent repeating the first config.
View attachment 514851View attachment 514850

This actually isn't a problem. What's happening is that OR always gives you the option of showing the rocket with no motors selected, as the first entry in the dropdown. You've created a configuration that also has no motors, and OR is showing both of them to you.

And then the bigger problem. There are two CTI H255 motors, and even though I select the 4G WT, the sim uses the 6G BS. I've tried deleting all the configs and sims and rebuilding, but end up in the same place. I found this by comparing the Proton G curve to the OR sim - usually there's a really close match, but this time it was notably different.

Here's the motor selection filtered to the H255s. You can see I've selected the 4G, but the 6G's curve is highlighted. It's also the data that shows up in the simmed flight.

This appears to be a combination of a database problem upstream and a poor user interface issue in OR.

thrustcurve.org shows both of these motors, and also has two curves for the 4G motor -- one of which, at first glance, appears to be identical to the 6G (I haven't reviewed the data carefully enough to see whether it's really identical -- but looking at things like case length it's sure not a 4G motor!).

In OR, once you've picked a motor, you can use the dropdown at top left to select a thrustcurve for the motor. You can use that to get the correct curve for the 4G H255, after which you should get a better simulation. We're aware that the ability to select a curve isn't obvious to a user who doesn't already know about it, but we're not sure how to fix it... moving the dropdown to the "show details" pane would probably make it easier to see there's something to do when that pane is open, but it would make it even less obvious than it is now when the "filter motors" pane is open.

 

[neil_w]

OK. Might be a day or two... I'm not near the computer right now.

Thanks. Still would like to see it, just to confirm that it is the same as our known issue and also to glean a few extra useful details.

 

[JoePfeiffer]

Apologies up front for reporting an issue here, rather than on github - but I'm unfamiliar with the process there - and don't have an account (if that's even needed).

I should mention -- thank you for the clear, complete report. You gave us enough information to be able to replicate what you were seeing, figure out the cause, and get an answer back to you without multiple iterations fishing for details.

It was really sort of a model for how to write a bug report to get a resolution as quickly as possible.

 

[Charles_McG]

I should mention -- thank you for the clear, complete report. You gave us enough information to be able to replicate what you were seeing, figure out the cause, and get an answer back to you without multiple iterations fishing for details.

It was really sort of a model for how to write a bug report to get a resolution as quickly as possible.

Thanks. I'm not a professional programmer - but I am a 'Chemist Who Codes' for my group, and adjacent groups. I have practice with receiving bug reports

I didn't realize that was a control, rather than an indicator - or that OR supported multiple thrust curves for one motor.

The updated sim is much closer to reality.

 

[Jimmy D. Jones]

A question on Velocity at Deployment with the new rev of the program - had a simulation running under the old version of the program and the velocity at deployment was maybe 15 ft/sec. I installed the new beta version and reran that same rocket, motor, and delay and get 23 ft/sec.

The Optimum Delay has not changed and in both cases its spot on to the delay selected for the motor. I didn't notice any big change in the calculated results other than that Velocity at Deployment change.

Is a change like that to be expected? Does the new code use the same thrust vs time curve as the old code for the same motor? I assume the new code is considered more accurate.

Not complaining just asking the question.

 

[H. Craig Miller]

A question on Velocity at Deployment with the new rev of the program - had a simulation running under the old version of the program and the velocity at deployment was maybe 15 ft/sec. I installed the new beta version and reran that same rocket, motor, and delay and get 23 ft/sec.

Please post the design file for review.

 

[thzero]

This is something that's been reported before -- the issue is the screen isn't tall enough to accommodate our layout (I see it on my 13" Dell too). We may need to start eliminating some of the frames we have around windows when the screen is too short... which would be ugly, but would make those lilliputian laptops viable.

May also be due to people adjusting the view by 125%, etc. There is option in windows under the graphics settings for it. Accessibility

 

[JoePfeiffer]

I have not had time to look too much thru the thread, or current issue list. But I do a lot of tubefins, and the 15.03 while "experimental tubefin support" did give "close" results for my 1" thru 3" designs (Maybe a little low, but close to FlightSketch altimeter data...) The new version is WAY too low in altitude. It seems the Pressure Drag Coefficient is being calculated at a MUCH higher value. (~0.825 vs ~3.015) Attached is screen shot from both versions, and the design file.
View attachment 513888View attachment 513889

Would you be able to share the FlightSketch data for this rocket, with as many motors as possible? I've been working on improving tube fin support, and my current sim for it has an apogee at about 960 feet.

 

[Neutronium95]

Would you be able to share the FlightSketch data for this rocket, with as many motors as possible? I've been working on improving tube fin support, and my current sim for it has an apogee at about 960 feet.

I have data from several flights on a 3" tubefin, some of which even went supersonic. I will get you data and a rocket file that's as accurate as I can make it this weekend.

In general, I've found that the 15.03 tubefin model has been a pretty decent predictor of performance, especially for subsonic flights, whereas 22.02 gives results that are about half the altitude predicted by 15.03.

 

[Neutronium95]

@neil_w @JoePfeiffer

Here is the sim file. I have good altitude data for two subsonic flights and two supersonic flights in the current configuration of this rocket.

Motor	Actual Flown altitude	15.03 Sim result	22.02 Sim result
J275	3217 (Windy day)	3875	1755
J360	4065	4269	1886
K1103	5009	5548	2250
K2050	4263	4675	1789

As I've said before, 15.03 has provided pretty good sims for subsonic flights, and is a bit optimistic for supersonic flying, whereas 22.02 has completely screwy results.

 

[neil_w]

Thank you!

 

[waltr]

I just looked at Neutron's .ork file.
The total Cd is much higher than any rocket I've seen at 3.89. The Tube fin set in 0.58 and all the components are only 27% of the total drag. Something there doesn't look correct.

 

[Neutronium95]

I just looked at Neutron's .ork file.
The total Cd is much higher than any rocket I've seen at 3.89. The Tube fin set in 0.58 and tall the components are only 27% of the total drag. Something there doesn't look correct.

Thanks for pointing that out. Something is clearly not adding up, I checked one of my other tubefin designs, and it seems to be having the same problem as well. Here are some screenshots to compare.

15.03 component analysis on original file:

22.02 component analysis on original file:


15.03 component analysis on a rough 4" diameter tubefin design:

22.02 component analysis on the same design:


15.03 component analysis on a normal 4" diameter flat fin rocket:

22.02 component analysis of the same design:



Edit: A friend of mine just pointed out that the drag of the tubefin set might be getting multiplied by the number of fins. I've played around with changing the number of fins and that seems to check out.

Edit the second: I checked out the component analysis on a very simple tubefin, and I'm pretty sure that this is what's going on. I'm pretty sure that the drag of a single tubefin is multiplied by the number of fins to get the drag of the finset. Somehow this number is then multiplied by the number of fins again, leading to 6 times the expected drag on a normal tubefin rocket.

Number of tubefins	Finset Pressure CD	Total Pressure CD
1	0.03	0.03
2	0.07	0.13
3	0.10	0.30
4	0.13	0.52
5	0.23	1.17
6	0.2	1.18

 

[JoePfeiffer]

Thank you, that's going to help a lot (having more than one rocket providing data has got to make it better!). The tube fin simulation in the development branch is looking better than this, but still pretty bad...

 

[bad_idea]

Not the beta, but in my own builds since the commits of 27 April, some (though not all) of my rockets are having simulations fail with a not-a-number error:

BUG: Simulation resulted in not-a-number (NaN) value, please report a bug, c=(NaN,NaN,NaN,w=NaN)

Would someone try the attached ork in a copy of OpenRocket built after those commits and see if you get the errors too? I'm enclosing the crash report too in case anyone recognizes a known issue. If the crash is reproduced, and if it doesn't look like a known bug, I'll open an issue on github.

 

[H. Craig Miller]

The problem that you are experiencing is the result of failing to follow generally accepted design concepts -- you cannot put motors tubes in the middle of a rocket and pretend that the motors are at the bottom of the airframe. Yes, OpenRocket allows you to express your creativity in an abundance of ways, but that creativity must be bounded by what can actually be done in real life.

If two components cannot be attached to one another during the actual construction of the model, probably best not to design the rocket using that approach.

Move the motor tubes to the aft most body tube, and all is well. Here is a revised design file. Looks like an interesting design. . . good luck.

 

[bad_idea]

The problem that you are experiencing is the result of failing to follow generally accepted design concepts -- you cannot put motors tubes in the middle of a rocket and pretend that the motors are at the bottom of the airframe. Yes, OpenRocket allows you to express your creativity in an abundance of ways, but that creativity must be bounded by what can actually be done in real life.

If two components cannot be attached to one another during the actual construction of the model, probably best not to design the rocket using that approach.

Move the motor tubes to the aft most body tube, and all is well. Here is a revised design file. Looks like an interesting design. . . good luck.

Thank you for the explanation and workaround.

I will point out that rockets sometimes evolve, and this is exactly how the rocket (the one in my avatar) was constructed. I inherited this rocket partially built with exposed motor tubes, and the ork file originated with the rocket in its original form. To keep the masses correct when I shrouded the motor tubes, I kept track of the what was being added both in tube mass and in epoxy and added that as a new tube, which it was. Simulations worked using the unstable branch with no issue from last September or October or so until the big round of commits last week.

Since it seems OpenRocket is working as designed, I will update my ork to rebase the motor tubes in the bottom tube. I have another, more complex ork for a different rocket that's having the same problem so will try the same fix for that one.

Thank you again for the workaround.

 

[H. Craig Miller]

Post it and I'll take a look, if you want.

 

[neil_w]

The problem that you are experiencing is the result of failing to follow generally accepted design concepts -- you cannot put motors tubes in the middle of a rocket and pretend that the motors are at the bottom of the airframe. Yes, OpenRocket allows you to express your creativity in an abundance of ways, but that creativity must be bounded by what can actually be done in real life.

Hmm, I am not sure I agree. The original file should work IMHO. I would file the bug and let some devs look at it.

A bigger comment I would make is that you should use the built-in cluster mount capabilities rather than specifying a zillion separate motor mounts.