ANNOUNCEMENT: OpenRocket 24.12 beta 1 is now available for download

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
I am getting a warning that appears unrelated. It is saying the non-CHAD booster airframe is open at the forward end. I've verified the OD and ID match the sustainer airframe, and the stages are butted up against each other, so I don't know why it's seeing anything as open.

View attachment 684714
Hard to say for sure without seeing a .ork file. What does your non-CHAD booster look like -- in particular, is it aerodynamically stable? After separation, most boosters have open forward ends. Because some users (especially with high power rockets whose boosters may have recovery systems) are concerned about the behavior of the booster after separation, we give the information that the sim results may be inaccurate for it. We suppress the warning if we can deduce that it's about to tumble (and in a few other cases).
 
I believe that is a know issue with boosters. The booster airframe is open after staging, but there’s no context to the warning to let you know that it’s referring to that part of the sim.
Hard to say for sure without seeing a .ork file. What does your non-CHAD booster look like -- in particular, is it aerodynamically stable? After separation, most boosters have open forward ends. Because some users (especially with high power rockets whose boosters may have recovery systems) are concerned about the behavior of the booster after separation, we give the information that the sim results may be inaccurate for it. We suppress the warning if we can deduce that it's about to tumble (and in a few other cases).

That makes sense.

I had previously tuned the booster fin position so the stage by itself had almost zero stability factor. It was 0.051 calibers. Just because OCD, I tweaked the fin position forward and the new stability factor is 0.001 caliber. In the design panel, it gave me a warning about the booster stage tumbling under thrust. But when I look at the sim results for the full rocket, the warning about the airframe open on the forward end goes away. It looks like OR is suppressing the warning when it sees the stage tumbling, as you say.

I tweaked the fin position a little further by taking the booster stage by itself, making it not a motor mount, and replacing the motor with a cardboard tube approximating a spent motor. This led to moving the fins rearward slightly from where they were with SF zeroed with an unused motor, causing the stage to be on the positive side of stable with the unused motor loaded, and the warning came back.
 
This can be done using a Python script with https://github.com/openrocket/orhelper acting to drive OpenRocket itself. Warning -- it's not for the faint of heart.
Yes, I’m already using Python for this with RocketPy.
Additionally, the Cambridge Rocketry simulator does this.
Of course, one could always get RockSim Pro, if you have the shekels!

Not nearly as good as having a native facility for it, of course.

This has been on my personal to-do list for a while now. Won't make the official release of this version, however.
Excellent! I look forward to its release in the future.

Keep up the great work! You guys have many fans here.
 
I believe that is a know issue with boosters. The booster airframe is open after staging, but there’s no context to the warning to let you know that it’s referring to that part of the sim.
We will be adding that context, if not in the final 24.12 release then in the next one, for sure. Generally improving the clarity and specificity of the warnings will be a high priority going forward.
 
No need to apologize about anything. This is a huge project.

Hans.
why not a screenshot of your desktop?

I find it odd that you are using Debian, its not exactly a general go to, but looks like the default desktop is Gnome. Usually its Ubuntu, or such (which is Debian based).
 
why not a screenshot of your desktop?

I find it odd that you are using Debian, its not exactly a general go to, but looks like the default desktop is Gnome. Usually its Ubuntu, or such (which is Debian based).
At this point, there is little need for a screen shot. The new release seems to have fixed my issues, except for the problem that I have opening files. It's hard to do a screen shot of something that instantly disappears!

Hans.
 
Whee !

I backed up 2309 and the models I am working on.

Then I installed 2412 on Slackware64-15 with openjdk17-17.0.12_7

Then I spent the evening playing with my existing models.

So far everything works as expected.

Woo Hoo !

The only thing I see out of the ordinary is one WARN string.

I start `/opt/OpenRocket-2412-b1/OpenRocket` from the command line so I can see errors and warnings from my bash terminal.

I see an immediate WARN:

Code:
[konrad@kjhlt7 ~]$ or MAUDE-34mm-4-x-1.64-span-m2.50-fins.ork &
[1] 28800
[konrad@kjhlt7 ~]$ 16:22:01.119 [main] WARN info.openrocket.swing.startup.OSXSetup -- Attempting to set up OSX properties on non-MAC_OS
[1]+  Done                    or MAUDE-34mm-4-x-1.64-span-m2.50-fins.ork

But then everything seems to work fine.

Now I can't wait to learn and apply winds aloft !

THANK YOU OR TEAM !

-- kjh
 
OR Team --

I have a question ... mostly just curiosity ...

This is a 'zoomed in' plot of Angle of Attack and Orientation -vs- Time where I added Mach Number to the plot:
TP-no-nose-wt.png

There is a new 'Warning' Marker at t=0.81 sec / Mach Number 1.11

I like it !

I imagine that corresponds to the 'sim summary' warning:

Body calculations may not be entirely accurate at supersonic speeds.

This is simply a 'being nosey' Q ... why does the warning marker line appear at Mach 1.11 ?

I do have two suggestions ... both are 'small potatoes ...

One is that the new Warnings Column Header is pretty wide.
Screenshot_20241222_081829.png
Would it be possible to abbreviate it ?

The other is that I fly dual deployment on almost every rocket and I like to set my drogue size so the rocket descends at about 75 ft/sec or so from apogee to main deployment. For example:
Screenshot_20241222_082241.png
I don't know if I want to eliminate the 'High Speed Deployment' warning but would it be possible to add the upper limit to preferences ?

Like I said ... small potatoes !

Thanks All'y'All !

-- kjh
 
This is a real one ( maybe ).

This is "Drag Coefficients -vs- Mach Number" in 2309:
Drag-vs-Mach-2309.png

I believe TLAR ...

This is the same plot in 2412:

drag-vs-mach-2412.png

There is something odd about the 'Drag Coefficient' plot near M=0

If I zoom in on the horizontalish lines down near CD = 0, I see something similar to the 2309 plot:
drag-vs-mach-2412-zoomed.png

Maybe it just needs a sanity check for the Y-values down near M = 0 ?

HTH.

-- kjh
 
One is that the new Warnings Column Header is pretty wide.
Screenshot_20241222_081829.png
Would it be possible to abbreviate it ?
We made it so wide because you can have different types of warnings (critical, normal warning & informational). If we were to decrease the column width, the other types would clip out of the column. Ideally, we want the width to change dynamically, but we haven't found a way to do that yet.
 
We made it so wide because you can have different types of warnings (critical, normal warning & informational). If we were to decrease the column width, the other types would clip out of the column. Ideally, we want the width to change dynamically, but we haven't found a way to do that yet.
That Makes Sense !

Thanks for the explanation :)

-- kjh
 
More on the UI

Here is the simulation view, looks normal sized
1734881650019.png

Then we go to motor configuration, and like a lot of the desktop space is empty and the list of motors is only two lines in 1920x1200. Notice the space between select ignition and flight configuration

1734881756375.png

OR 23, look at all the motors you can list in the same size for the rocket drawing
1734881833588.png

The work around is to pull those three dots ... down but to get the same number of motors listed look how small the drawing is now ? I don't think we need just as many, but we need more then 2 or 3.

Frankly I think the [...] control is making it loose so much space?

1734881954188.png
 
If you chose 'New configruation' and then exit out of it, you can't delete the 'None'

1734883241928.png

Exit with out saving bails you out of the issue. Happened a few times this morning, I tend to bail out of the new configuration screen alot

I am still looking for how to reproduce the random getting Stuck on re-simming a certain line item when you select all sims and re-run them due to a change. I thought it was getting stuck on the one selected in the drawing but that was not always true.
 
OR Devs --

RE: New Feature User Interface / Allow components to be hidden from view

Should Hidden Components still contribute to the Mass of the Rocket ?

They do appear to add mass, even when hidden.

Is this just the way it works ?

Thanks

-- kjh

Example:

EDIT: See below ... I figured out a work-around using override mass and CG !

I've got two versions of an Oatey Min Diameter Motor Retention Gadget for a Rocket design in OR:

A long one an a short one:

The long one has an additional 2.5 inch length of Aluminum all-thread and an aluminum threaded Spacer.

OTOH with the short one, the Oatey carriage bolt threads directly into the AT 38mm Plugged, Threaded Forward Closure

The long one weighs 51 grams.

The short one weighs 37 grams.

The rocket mass does not change when I hide one -or- the other Oatey gizmos:

This is MAUDE 38/1080 with a 'short' RMS 38/720 J350W motor using the long Oatey ( the short Oatey is hidden ).

Note the Dry Mass is 561 grams:
Screenshot_20241222_111510.png

This is MAUDE 38/1080 with a full length J570W using the short Oatey ( the long Oatey is hidden ):
Screenshot_20241222_111709.png

Note that in both cases, the Rocket Mass with no Motors is 561 grams.

According to my calcs, it should be 510 grams with the short Oatey and 524 grams with the long Oatey.

If that's how it works that's OK but I was surprised :)

Another question about hiding component assemblies like the Oatey.

I had to select ALL the Oatey sub-components to hide the gizmo.

Is that the way it should work ?

I kinda-sorta expected that if I selected the parent component and then Hide, that all the children would be hidden too ...

THANKS Everybody !

EDIT: p.s. HIDE / SHOW is a great feature, especially for things like motor adapters.

I also just realized that when I HIDE a component, I can Override Mass and CG to zero and check the override for all sub-components !
Screenshot_20241222_113942.png

TLAR -- I got back 10% of my dry mass :)
 
Last edited:
Thanks @neil_w

I edited my post after I figured out how to do what I wanted with override mass and CG -plus- subcomponents !

Are all my Qs in the new docs ?

If so, where can I find them ?

-- kjh
Latest docs are here: https://openrocket.readthedocs.io/en/latest/. You're probably not going to find the sort of detail that you're looking for, though.

As for what you're trying to do: it seems you're looking for a disable function, which would effectively remove the components from the simulation. That's been discussed (there's a github issue for it somewhere) but it's not possible right now. You can fake it for *internal* (i.e. non-aerodynamic) components, as you have been doing, by hiding the components and overriding mass to zero.

Clicking on a parent doesn't automatically hide the children because sometimes you might want to hide the parent just so you can see the children more easily, or something like that. Note that you can, though, multiselect the parent and all it's children before doing the "Hide" on all of them at once.
 
Latest docs are here: https://openrocket.readthedocs.io/en/latest/. You're probably not going to find the sort of detail that you're looking for, though.

As for what you're trying to do: it seems you're looking for a disable function, which would effectively remove the components from the simulation. That's been discussed (there's a github issue for it somewhere) but it's not possible right now. You can fake it for *internal* (i.e. non-aerodynamic) components, as you have been doing, by hiding the components and overriding mass to zero.

Clicking on a parent doesn't automatically hide the children because sometimes you might want to hide the parent just so you can see the children more easily, or something like that. Note that you can, though, multiselect the parent and all it's children before doing the "Hide" on all of them at once.

Thanks Neil !

Once again, that all makes sense.

Is multi-select the same as [Shift]-[Click] a list of components or is there a better way ?

Thanks again !

-- kjh
 
One problem disappears... One new problem.

Just installed the Beta. On this version, so far all the "Close" and "OK" buttons seem to work, as does mouse navigation. But I haven't checked everywhere yet.

But..

Files -> "Open..." isn't working correctly. When I click on it, the files list window pops open VERY briefly, and then closes. As a workaround, I found that opening it via ctrl-O and then HOLDING the ctrl button keeps the window visible. The other main menu items seem to work.

I know little about Linux, but the version I'm using is listed as Debian 12 (Bookworm).

Hans.
Need to change my comment a little bit....

As mentioned it seems most, if not all, of the UI problems ("Close" and "OK" not clickable and a few others) I was having with 23.09 have been fixed.

The only niggle I'm having is the Files -> "Open" not working via mouse. What I need to amend to the previous is that after I did a program restart, the ctlr-O does work correctly, I don't need to continue to hold the ctrl button as I previously stated.

Thanks for the great program.

Hans.
 
For the people reporting that the 24.12.beta.01 UI was a bit difficult to read: I pushed a PR to hopefully fix that (link). The biggest change is the switch to a new font, Google Inter, which should be more legible, and the addition of more UI customization (UI scale, font style & character spacing). You can read the full details in the PR. Here's a comparison of 24.12.beta.01 and the new UI from the PR:
1734919525163.png

If that's still not clear enough, you can customize the UI settings further. Here's some example settings:
1734919565752.png
 
Last edited:
I imagine that corresponds to the 'sim summary' warning:

Body calculations may not be entirely accurate at supersonic speeds.
Yes, it does.
This is simply a 'being nosey' Q ... why does the warning marker line appear at Mach 1.11 ?
This will not be a good answer, but it's the only one I have: devs on the team before any current devs were involved appear to have thought that was roughly when the rocket was past transonic and into solidly supersonic. There's every chance that some day that warning will move to about .8 Mach and change to "Transonic and supersonic calculations may be inaccurate"...

I do have two suggestions ... both are 'small potatoes ...


The other is that I fly dual deployment on almost every rocket and I like to set my drogue size so the rocket descends at about 75 ft/sec or so from apogee to main deployment. For example:
View attachment 684833
I don't know if I want to eliminate the 'High Speed Deployment' warning but would it be possible to add the upper limit to preferences ?
Yes. Hasn't happened yet, but will at some point. Also let the user set minimum speed off the rail and warn if too small, also max ground hit speed.
 
Thanks for the feedback, Joel !

This is one for everybody out there ...

I've been playing with the new multi-level wind modeling in OR 2412.

I wanted to fly Nocturnal Missions to 8,400 ft last Saturday but it didn't work out.

But to prep for the flight, I took a screenshot of the winds aloft from Windy last Friday evening and now I have entered them into the OR 2412 multi-level wind table.

This is a screen shot of what I did:

nm-k1100t-c41221-503-multi-level-wind-setup.png

You should recognize most of the screen shots except maybe the lower right image which is a shot of the Windy sounding forecast for for our launch site on Saturday, 12-21 at 11:00 am CST.

I love the visualize feature !

Note that the wind direction changes 190 degrees from the pad at our site at 643 ft MSL to 6,000 ft AGL !

What is the best way to plot weathercocking and drift now that I can enter wind speeds and directions other than a single average at 90 degrees ?

I can't find a way to generate a useful plot ...

Or is this a case where I need to come up with something on my own using the export.csv file ?

Thanks !

-- kjh
 
What is the best way to plot weathercocking and drift now that I can enter wind speeds and directions other than a single average at 90 degrees ?

I can't find a way to generate a useful plot ...

This is a good question. I guess you can look at altitude vs. position east of launch AND altitude vs. position north of launch and try to visualize the vector sum of those two. Or, export the data and do your own calculations as you mentioned, but that would be tedious.
 
What is the best way to plot weathercocking and drift now that I can enter wind speeds and directions other than a single average at 90 degrees ?
You could plot lateral distance and lateral direction, but it's not easy to visualize the result. Lateral distance on its own is not bad though.

What you really want, I think, is an overhead view, which you could do with a CSV export but not inside OR at the moment.
 
Back
Top