Happy to do a Skype at some time that I'm awake in Australia and run you through the process loop...... PM me.
PRIME EXAMPLE !!!!!
- Thread starter rsbhunter
- Start date
Help Support The Rocketry Forum:
- Joined
- Sep 5, 2009
- Messages
- 3,545
- Reaction score
- 1,689
Crap? LOL. The virtual build is the most powerful feature of the simulation design software. If the material databases and/or component overrides are correct (the user has full control of these), then the CG is right on the money.
I confess I am curious about this comment. I know there are a few areas where it's easy to get tripped up but "gotten nowhere" seems a bit extreme. More detail on where you hit the wall would be very useful to us. It seems to me that if you start with one of the example designs you should be about 80% of the way towards having a functional model of your own rocket, although I know you do some unconventional designs and some of those might not simulate well.
We've had a bit of debate about this within the OR team. Let me try to shed some light on the theory of operation, which I acknowledge is a bit murky here.
First of all: as correctly stated above, "subcomponents" refers to those in the design tree. Motors are not included; they exist outside the design.
Next: leaving the "Include subcomponents" box unchecked means that you're only overriding the selected component. This is the default option and in most cases it makes sense.
For "Assembly components" (Stage, Boosters, Pod) which don't correspond to a single physical entity (I think of them as "virtual" components), it's less clear what's going on. The way it works is that when you override a stage without subcomponents, an additional mass bias is applied, without changing CG. To illustrate, here's the Simple Model Rocket example, "stock". It's shown with no motor for clarity:
Dry mass is 1.7 oz, CG at 8.091".
Now let's override the sustainer *without* subcomponents:
I put a 1 oz override on the sustainer, and now we see that the total dry mass of the rocket has increased by 1 oz to 2.7, and the CG is unmoved. If you override the CG without the subcomponents, you are moving the position of this 1 oz invisible mass.
It turns out that this behavior can be useful (I can describe separately if folks want). However, the most common way to use these overrides is to override all subcomponents, and my own preference would be for that to be default on virtual components, but the decision was made to maintain consistent behavior across all component types. In the future we can probably improve the situation a bit by putting a warning in so we can remind the user if they seem to have made the wrong selection.
To conclude: for the standard "weigh the whole built rocket and override" methodology, you want to check the subcomponents box.
This seems like yet another good tutorial topic.
Last edited:
rsbhunter
Well-Known Member
Neil_w, not looking for private classes, but if I add weight to the nosecone to move CG, in OR do I check override all subcomponets ? If I only want to check how overriding a single componet changes the CG, do I need to check the override all componets? This is foe a ork. file rocket, Madcow DX3 2.6". Thanks, rsbhunter
You shouldn't need to over ride anything when adding weight to the nosecone.
You wouldn't be the first!
To add weight to a nose cone you would typically add a "Mass Component", with the chosen mass and location. There are no overrides at all used in this case. Nowhere are you attempting to substitute your own measured value for something calculated by the program, which is expressly what overrides are for. You're adding a new component to the design, and then want to let OR do it's normal calculations.
I typically model simple 3FNC designs so I find it easiest for me to search for a sim file for a kit that is somewhat similar and then modify the components to achieve my new design.
rcktnut
Well-Known Member
Ok, I build (for scratch builds) the rocket using the data base of components, which lists the components mass. I don't weight each component and then override the mass that was derived from the data base for that component. That is what I meant. For kits just use available sims. For all builds to determine CG after built, I weigh, and then determine CG flight ready w/o motor. Then I override mass and CG. Just saying I don't go by what the sim has given me for the CG.
rsbhunter
Well-Known Member
Neil, thank you VERY much. Your explanation tells me more than watching a video. I honestly believe there should be a "sticky" with your explanation of the need, or lack of checking those boxes. It seems the major confusion centers around the "override all componets" function....Thank you, for taking the time to reply...rsbhunter
I will be creating a tutorial for the OpenRocket.info website that will cover all this.
This is the recommended methodology. App-calculated CG is a useful tool for planning, but measuring the mass and CG of the assembled rocket should *always* be done.
Sim files downloaded from the Internet are often distressingly inaccurate. Always double check!
NTP2
Well-Known Member
I like to imagine a dojo where you make your students sim @lakeroadster builds in 30 minutes….You wouldn't be the first!
- Joined
- Feb 26, 2012
- Messages
- 2,120
- Reaction score
- 901
Why start another thread with the same question? Why not question the person on the first thread?
Oh Prime Example meaning prime numbers right so at least 2 maybe 3 or stretched to 5 threads lol. Just teasing
If you have something like a body tube, you can weigh it and override its mass without overriding fins that are attached to it.
The motor is not in the component tree, so it is not a subcomponent.
There has been discussion of making component assemblies like stages and pods always override all subcomponents. We don't do it that way because it would make the interface inconsistent.
rfjustin
Well-Known Member
I understand that part of it but the analogy doesn't follow through to the override for the entire stage. The stage is not an individual component, it is only the assembly of components, so to override the mass of the stage is by definition overriding the assembly of components. I understand the desire to keep the interface the same but in the case of the stage I think it should have a different dialog box or the second checkbox should be grayed out.
As I explained above there *is* a function and value to overriding the mass of virtual components such as stages without the subcomponents. There's no reason to remove that capability (unless we were to render it unnecessary due to changes elsewhere).
I do tend to agree that it would make sense for the override dialog to work differently for assembly components. But once you understand how it works in its current form it shouldn't be something that causes ongoing difficulties.
rcktnut
Well-Known Member
That is the Silica launch site, just NE of Fond du Lac. 10,000 ft waiver. The problem is a schedule can't be made.. There is no access to any of the fields other than driving on them, so if wet no go. If the upcoming weekend looks favorable e-mail sent out on the Monday before and no go or go issued on Thursday, so hard for fliers to schedule. There are a few of us retired guys that fly weekdays. Also only Fall launches after crops are off, sometimes as soon as early August which looks like it this year, big field with winter wheat.
Launches are informal, no membership or launch fees. Just come and fly. There are guys that fly at Bong that show up once and awhile, Eric C., Kenny B., Randy L, Dave M. etc. Anybody is welcome to fly here. Hard to get guys that regularly fly at Bong to show up. Hard to compete with a place you can fly year-round and with a set schedule. If interested can PM me and can put you on e-mail list.
