Sizing effect on mass and geometry

Skip to first unread message

Jia Wei Kho

Nov 17, 2021, 1:15:16 PM11/17/21
Hi all,

I would like to use SUAVE to design hydrogen gas-turbine powered aircraft and I am really excited by the capabilities offered by SUAVE. As part of this, I am trying to make small adjustments to the aircraft by increasing or decreasing the fuselage length. In an ideal design, I should expect this to have an effect on the final geometry (centre of gravity, location of wings and tail) and weight breakdown (weight of fuselage). How can I emulate this within SUAVE?

Firstly, changes to the length might affect changes to the rest of the aircraft but I am struggling to understand if these knock-on effects are captured by the sizing function in analyses? Does the un-edited version of SUAVE do anything when it calls sizing? If so, what are the effects on the weight/geometry of the other components?

Additionally, I noticed that in the B737 tutorial, changing fuselage length will result in a change of fuselage mass and hence total empty weight using the analyses weights function. Is this empty weight being used for the performance calculation and mission plots or does performance rely on the vehicle.mass_properties that is initialised with the vehicle? I was under the assumption that vehicle.mass_properties was an initial guess that is then overridden when mass estimates are calculated based on wing geometry.

Finally, do changes in fuselage length affect the placement of wing and tail components? Otherwise, will we need to define the new wing, tail, and energy networks origins? Do these changes get translated to changes in the centre of gravity and stability calculations? Will these parameters have any effect on the final performance? For example, a nose-heavy aircraft will incur greater trim-drag penalties over one that is more balanced about the centre of lift.

Any help regarding these questions would be greatly appreciated.

Thanks in advance!
Jia Wei

Nov 17, 2021, 2:16:00 PM11/17/21
Hi Jia Wei,
I understand this can be confusing. Let me explain some fundamental ideas in SUAVE so it makes sense how to do what you want.

SUAVE was intended for optimization since day one. The analyses try to give an answer whether realistic or not (for example you can burn more fuel than the airplane has mass). This was intended so that an optimizer could try something crazy and through enforcing constraints eventually converge to the correct solution. Many codes break when you connect to an optimizer for this very reason. It becomes the users responsibility to properly constrain the problem and consequently  leads to a learning curve for SUAVE.

Similarly, for weight estimation you've noticed that the component level, and OEW, changes when you change the geometry dimensions. However, the MTOW will stay fixed because that is an input to the weight estimation (it sizes spars etc..). The takeoff weight is also an input, an aircraft operator can choose how much stuff to takeoff with, it's not always going to be MTOW. Thus, MTOW and takeoff weight are functionally independent of dimensions. You'll need to add constraints.

At one point we tried to put together a one size fits all solution for sizing, but we found that every problem had totally different needs. There are some sizing scripts, but they're not all encompassing, here's a folder of useful scripts.

To answer your final questions. No, the wing, tails, and energy network move independently of the fuselage (I suggest putting together a simple sizing rule for this if you want them to move). CG and stability will change (if you call those functions) when you change the geometry. Yes, they will change the performance. However, trim drag is not well accounted for in SUAVE right now. There is a mark up for it, but the assumption is that the static margin is in a reasonable range. 

None of what I mentioned requires changing SUAVE, it's just problem formulation.

Please keep asking questions, there are a lot nuances here. This probably makes no sense to why we do things this way, but from another users perspective your design flow makes no sense for their problem either.

Reply all
Reply to author
0 new messages