ANNOUNCEMENT: The OpenRocket 22.02 Beta Period is now finished

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.
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.
I just tried this on my own ork and had the same failure. I then loaded your revised version and also had the failure. Could you confirm the date of the build you are using?

Perhaps I need to create a new ork from scratch.
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.
The purpose was mixed clustering. I had originally planned removable blocks so that it could be flown without all tubes filled, and I had also contemplated a mix of B6-6 and C6-5 motors, which have the same average time to ejection, as well as the possibility of flying it with a central airstart. As it happens, it's not practical to fly the rocket on anything but the C6-7, so I could indeed change to a seven motor cluster, and if I have to create a new ork for it, I will. That isn't the case for another cluster I'm now designing, though in that design I am pairing the motor tubes.
 
I just tried this on my own ork and had the same failure. I then loaded your revised version and also had the failure. Could you confirm the date of the build you are using?

I used Beta 2, but I just tested your design with the current unstable, and it failed. If you know, can you tell me when (the approximate date) you first experienced this problem. An issue will be created, but a date may be helpful in back-tracing what happened.
 
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

What you describe has been reproduced, and Issue #1325 has been opened in connection with your experience. Development will sort it out. Thanks for identifying this issue.
 
I used Beta 2, but I just tested your design with the current unstable, and it failed. If you know, can you tell me when (the approximate date) you first experienced this problem. An issue will be created, but a date may be helpful in back-tracing what happened.
I first encountered the error on the evening of the 28th, after a fresh build from github, when I was running simulations to get altitude estimates for a weekend launch. Of five rockets I simmed, two threw the NaN errors. Of the two, the cluster seemed like the simpler example, so I uploaded it first. I was recently working on two other designs, and I've since verified they do not have the problem.

My shell history is too jumbled to be sure when I had previously built OpenRocket from source, but I tend to check github daily and build if I see major commits. Therefore I'd guess the problem is probably due to one of the commits from the 27th, but possibly the 25th or 26th. I'm nearly certain I had built since the commits on the 20th, and I was working on the second problem ork all week last week without problems until Friday. I'm attaching that one here.

Perhaps notably, both the problem orks have numerous mass overrides and mass elements, and both have had their body tubes extended in the course of mirroring their actual physical rebuilds. The one I'm attaching here has had its motor tube extended too. I havn't had the chance yet to go through and selectively delete mass elements to see if it makes any difference, but moving both motors and fins to the aft tube on the cluster did not fix the problem.

Thanks for looking into this. I can probably work around it by recreating these rockets with simpler tubes and/or masses, but it would be good to understand what's causing it and if it's actually a bug in the software or just something screwy with my orks.
 

Attachments

  • openrocket_crash_2.ork
    67.4 KB · Views: 0
Thanks for looking into this. I can probably work around it by recreating these rockets with simpler tubes and/or masses, but it would be good to understand what's causing it and if it's actually a bug in the software or just something screwy with my orks.
Generally speaking, any appearance of an NaN means that there is something to fix in the software.
 
It appears to be on the development side, but watch Issue #1325 for updates.
Will do. Thanks again. BTW, really impressed that you honed in on the date of the commit that caused it before I had even finished typing up my estimate for the date! 👍 I had thought to try to go back and build without the recent commits to figure that out exactly, but my git-fu is very elementary so it was going to take me some googling to figure out the best way to do that.
Generally speaking, any appearance of an NaN means that there is something to fix in the software.
For better or worse, I seem to turn up all sorts of NaN errors. I have updated my tag line accordingly. 🤣
 
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.
That's exactly what was happening. Thank you for tracking it down. That said, the next beta will have a complete rewrite of the tube fin drag calculations (which will also not have that bug!).
 
Last edited:
Thanks for looking into this. I can probably work around it by recreating these rockets with simpler tubes and/or masses, but it would be good to understand what's causing it and if it's actually a bug in the software or just something screwy with my orks.
If your design can cause a NaN, we've got a bug. I haven't looked at your .ork yet so it's entirely possible the fix will be a constraint on your design in which the software says "no" and tells you that you can't do something, but that's different.
 
That's exactly what was happening. Thank you for tracking it down. That said, the next beta will have a complete rewrite of the tube fin drag calculations (which will also not have that bug!).
I'm really glad that this was fixed. I've really enjoyed the 22.02 update, but I also like my tubefins.
 
I first encountered the error on the evening of the 28th, after a fresh build from github, when I was running simulations to get altitude estimates for a weekend launch. Of five rockets I simmed, two threw the NaN errors. Of the two, the cluster seemed like the simpler example, so I uploaded it first. I was recently working on two other designs, and I've since verified they do not have the problem.
<snip>
Thanks for looking into this. I can probably work around it by recreating these rockets with simpler tubes and/or masses, but it would be good to understand what's causing it and if it's actually a bug in the software or just something screwy with my orks.
The problem was that you are using the old "launch lug with 0 inner radius" trick to emulate your rail buttons, and that triggered a bug in my tube drag code. I'll be fixing that later today. You can switch to using actual rail buttons; unfortunately, rail button aerodynamics aren't implemented yet.
 
The problem was that you are using the old "launch lug with 0 inner radius" trick to emulate your rail buttons, and that triggered a bug in my tube drag code. I'll be fixing that later today. You can switch to using actual rail buttons; unfortunately, rail button aerodynamics aren't implemented yet.
Aha! I just checked back in the history of earlier iterations of each of these orks, and they both originated with 15.03, so it makes sense that I hadn't used the rail buttons from the current codebase. Fixed that, and I'm back in business with my latest builds. Many thanks!
 
I found in looking at body tubes that LOC BT-5.38 and FT-5.38 showed as 5,540mm diamater, and Quest 25mm red tint payload tube and Q28700 at an impressive 25m. This appears to be due to typos in the units tags in the (generally excellent) upstream database by dbcook. I opened a bug and pull request in that project to fix these along with a few other cases I only spotted going through the orcs.

I don't know much about interproject dependencies in git, but if you can, you may want to add something on this bug "m" showing as unit in place of "mm" and "in" in several orcs
 
Dbcook committed my pull request to his upstream this afternoon. I'm not sure what has to be done to get the change into OpenRocket though. I thought just a "git submodule update" would do it, but OpenRocket was still showing the 5.5 meter diameter LOC tubing. I then blew away my entire code directory and checked out OpenRocket unstable from scratch. After "git submodule init" and a fresh build, I still see the old tube diameter.

My understanding of submodules is nearly non-existent. Does anyone have tips on how to get the latest database into OR?
 
Development will pull in both the parts library and ThrustCurve databases just prior to Beta 3 release.

The parachute libraries have been expanded as well, including automatically using preset data for Cd and packed dimensions.
Thanks, thought I was doing something wrong. Good to know. I've copied the updated orc in manually for now.

Re. parachutes, I've seen a lot of commits around chutes lately. From reading the commit notes, sounds like tons of improvements in store!
 
Dbcook committed my pull request to his upstream this afternoon. I'm not sure what has to be done to get the change into OpenRocket though. I thought just a "git submodule update" would do it, but OpenRocket was still showing the 5.5 meter diameter LOC tubing. I then blew away my entire code directory and checked out OpenRocket unstable from scratch. After "git submodule init" and a fresh build, I still see the old tube diameter.

My understanding of submodules is nearly non-existent. Does anyone have tips on how to get the latest database into OR?
It looks like
% git submodule update --remote
followed by rebuilding OR does it.
 
It looks like
% git submodule update --remote
followed by rebuilding OR does it.
Confirmed! Thank you. I've updated my build script.

I suppose all the answers I found on Stack Exchange, etc. were geared to local submodules, but never having worked with submodules before, I didn't know the difference. You taught me something useful today!
 
@caveduck , there's a discrepancy between the versions of Centuri ST-20 tube OD.

OR database uses the dimensions published by BMS, which don't add up. OD of 2.024", ID of 2.0", wall thickness of 0.21":

BMS-T204-OD.png

I assume that should be an OD of 2.042", which would agree with their (ID + 2*wall thickness) and the SEM version:

SEM-ST-20-OD.png

BMS is out of town for a few days, so I can't confirm.
 
@tsmith1315
Yes there's a discrepancy for sure; the BMS specs are internally inconsistent. The old OR 15.x BMS file (which I haven't brought forward into my DB yet because it mostly duplicates Estes/Semroc parts and lacks mass information) has ID 2.00 and OD 2.024 for the BMS ST-20, while SEMROC when I retrieved it from the now-vanished original website had specs of ID 2.000 and 2.040. So is the BMS tube wall thickness actually 0.012 or 0.020? Depends on which number in the BMS listing is wrong...hard to say without an actual sample or getting BMS to confirm/deny.

The Centuri original ST-20 - I'm looking at the 1971 catalog just now - was specified as 2.00" ID and 2.04" OD.
 
Beta 3 is available now. Go get it!
https://openrocket.info/downloads.html?vers=22.02.beta.03
First two posts are updated (including release notes), known issues still to be updated for beta 3.

Big new parachute functionality, tube fin drag modeling is fixed, and other stuff. Keep those reports coming!
I just downloaded it, and the tubefin drag seems to have been fixed, along with one or two other niggling issues that I'd seen with beta 1. The Openrocket team has been doing some amazing work the past few months.
 
I don't see this in the GitHub bug list, but it's not really much of a "bug," so...

Saved file sizes are much larger for the "Only primary figures" files with beta 2 and 3. An example: predicted file size is 1k for a simple design created with beta 2 but is actually 104k when saved with beta 2 or beta 3. If I load a file into beta 2 or 3 that was created with the 15.03 version with a file size of 500k because I saved all simulation data and save it as "Only primary figures" it is reduced to 3.3k as it should be.
 
I don't see this in the GitHub bug list, but it's not really much of a "bug," so...

Saved file sizes are much larger for the "Only primary figures" files with beta 2 and 3. An example: predicted file size is 1k for a simple design created with beta 2 but is actually 104k when saved with beta 2 or beta 3. If I load a file into beta 2 or 3 that was created with the 15.03 version with a file size of 500k because I saved all simulation data and save it as "Only primary figures" it is reduced to 3.3k as it should be.
Hm, does this happen for all your designs? I just compared a beta 1 and beta 3 export and both had the same file size (4 kB) for the 'A simple model rocket' design when saving as 'Save Only primary figures'
 
Beta 3 is available now. Go get it!
https://openrocket.info/downloads.html?vers=22.02.beta.03
First two posts are updated (including release notes), known issues still to be updated for beta 3.

Big new parachute functionality, tube fin drag modeling is fixed, and other stuff. Keep those reports coming!
Before installing, be sure to close OR first. I didn't realize that I had a rocket design already open in OR when I installed Beta 3. The installation informed me that I had an open file and should close that file before continuing...but I couldn't close the file during installation. I had to exit the installation, close OR, then restart the installation. Not a big deal, just do it in the right order.
 
Before installing, be sure to close OR first. I didn't realize that I had a rocket design already open in OR when I installed Beta 3. The installation informed me that I had an open file and should close that file before continuing...but I couldn't close the file during installation. I had to exit the installation, close OR, then restart the installation. Not a big deal, just do it in the right order.
Thanks -- we need to add that to the instructions.
 
I have likely overlooked the discussion, but when I run simulations the 'Velocity at Deployment' shows "N/A". Is that a bug or is it something that I have wrong in my drawing?
 
Back
Top