Theory Manual

User Manual:

Open the PDF directly: View PDF .
Page Count: 128

Download
Open PDF In Browser	View PDF

HYDRA: Rotorcraft Conceptual Sizing

Authors
Ananth Sridharan
Bharath Govindarajan
This is the analysis manual for the rotorcraft conceptual sizing analysis HYDRA HYbrid Design and Rotorcraft Analysis, developed and evolved over several years at
the University of Maryland, with inspiration drawn from the AHS Student Design Competition challenges. This manual contains a description of the theory and
various operations performed by the sizing code for both conventional and novel
Vertical-Lift aircraft.

The main advantages of HYDRA over other sizing codes are flexibility, speed
and reliance on only open-source tools. With the majority of the code written in
an interpreted language, i.e., Python, modules can be prototyped and added quickly.
Subsequently select parts of the code can be ported to Fortran or C (i.e., compiled
languages) and wrapped for execution sppeed. Using a combination of OpenMP, MPI
and algorithmic acceleration, up to 2000 designs can be generated per second on a
standard desktop computer with 8 cores.

Another advantage of HYDRA is the ability to set up input decks and call higher
fidelity models (BEMT, FEA for airframe and wings) and the comprehensive analysis PRASADUM, and through the comprehensive analysis, the Maryland Free Wake
(MFW). These higher-fidelity tools are integrated into the sizing loop to provide accurate estimates of rotor performance and component weights, and may be invoked
as required.

Contents
List of Abbreviations

1 VTOL sizing: Overview
1
1.1 The nature of VTOL sizing . . . . . . . . . . . . . . . . . . . . . . . 2
1.1.1 Iterative convergence . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 Constrained optimziation . . . . . . . . . . . . . . . . . . . . . 10
2 Drag models
2.1 Fuselage and empennage drag . . . . .
2.2 Edgewise rotor hub drag . . . . . . . .
2.3 Spinner drag . . . . . . . . . . . . . . .
2.4 Momentum drag for engine air intakes
2.5 Landing gear drag . . . . . . . . . . . .
2.6 Cooling drag . . . . . . . . . . . . . . .
2.7 Mast fairing drag for coaxial rotors . .
2.8 Protrusion drag . . . . . . . . . . . . .

.
.
.
.
.
.
.
.

11
11
12
12
12
13
14
14
14

3 Rotor and Wing Performance Models
3.1 Rotor performance model . . . . . . . . . . . . . .
3.1.1 Momentum Theory . . . . . . . . . . . . . .
3.1.2 Blade Element Momentum Theory (BEMT)
3.2 Wing performance model . . . . . . . . . . . . . . .

.
.
.
.

14
14
15
15
18

4 Weight models
4.1 Engines, fuel and batteries . . . . . . . . . .
4.1.1 Engines . . . . . . . . . . . . . . . .
4.1.2 Fuel, tank and fuel handling systems
4.1.3 Battery models . . . . . . . . . . . .
4.1.4 Electric motor weights . . . . . . . .
4.2 Electric Transmissions . . . . . . . . . . . .
4.3 Wire weights . . . . . . . . . . . . . . . . .
4.4 Physics based model for rotor blades . . . .
4.4.1 Skin sizing . . . . . . . . . . . . . . .
4.4.2 Leading edge weight . . . . . . . . .
4.4.3 Spar caps and shear web sizing . . .
4.4.4 Root fitting sizing . . . . . . . . . . .
4.4.5 Torsion frequency check . . . . . . .
4.5 Flight controls . . . . . . . . . . . . . . . . .
4.5.1 Rotor controls . . . . . . . . . . . . .
4.5.2 Fixed wing controls . . . . . . . . . .
4.5.3 Tilt actuators . . . . . . . . . . . . .
4.6 Motor mount mass . . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

19
19
19
21
23
25
25
27
28
29
29
30
34
34
35
35
36
36
36

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.

4.7

Wing weight model . . . . . . . . . . . .
4.7.1 AFDD wing weight model . . . .
4.7.2 Frequency tuning: bending loads
4.7.3 Hover: shear loads . . . . . . . .
4.8 Airframe Weight Model . . . . . . . . . .
4.8.1 Statistical weight model . . . . .
4.8.2 Physics-based weight model . . .
4.9 Weight margin . . . . . . . . . . . . . .
4.10 Fixed weight groups . . . . . . . . . . .

.
.
.
.
.
.
.
.
.

5 Analysis Organization
5.1 Programming Language and Syntax . . . . . . . . . . . . . .
5.2 Pre-Requisites and Installation Notes . . . . . . . . . . . . .
5.3 Source Code Directories . . . . . . . . . . . . . . . . . . . . .
5.3.1 Python code: src/Python . . . . . . . . . . . . . . . .
5.3.2 NETLIB FILES: Source/fea/Source/mathops/ . . .
5.3.3 Python-integrated routines: Source/pyint_files/ . .
5.3.4 Python-accesible modules: Source/pyint_modules/
5.3.5 Python-invisible files: Source/pyinv_files/ . . . . .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

38
38
38
39
40
40
41
45
45

.
.
.
.
.
.
.
.

46
46
47
48
48
49
49
49
50

6 First-time setup
51
6.1 Installing pre-requisites . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.2 Compiling source code . . . . . . . . . . . . . . . . . . . . . . . . . . 51
6.3 MacOS-specific issues . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
7 Input files
7.1 input.yaml . . . . . . . . . . .
7.1.1 Sizing . . . . . . . . . .
7.1.2 Vehicle configuration
7.1.3 Mission profile . . . .
7.1.4 Aircraft . . . . . . . . .
7.2 defaults.yaml . . . . . . . . .
7.2.1 Sizing dictionary . . . .
7.2.2 Empirical parameters .
7.2.3 Acquisition cost model
7.2.4 Operations . . . . . . .
7.2.5 Redundant systems . .
8 Output files
8.1 log.yaml . . . . .
8.1.1 vehicle summary . .
8.1.2 Rotor . . . . . . . .
8.1.3 Wings . . . . . . . .
8.1.4 Costs . . . . . . . .
8.1.5 Weight breakdown

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

iii

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

55
55
58
61
62
63
65
65
66
71
74
77

.
.
.
.
.
.

78
78
78
79
81
83
86

8.2
8.3

8.1.6 Volumes . . . .
8.1.7 Parasitic drag .
8.1.8 Mission details
8.1.9 Battery details
log.txt . . . .
summary.dat . . . . .

.
.
.
.
.
.

88
89
90
91
92
93

9 Running HYDRA

10 Postprocessing

A Cantilever beam dynamics
A.1 Potential energy . . . . . . . . . . . . . . . . . .
A.2 Kinetic energy . . . . . . . . . . . . . . . . . . .
A.3 Frequency tuning . . . . . . . . . . . . . . . . .
A.4 Validation . . . . . . . . . . . . . . . . . . . . .
A.4.1 Case 1: cantilever beam . . . . . . . . .
A.4.2 Case 2: distributed non-structural mass .
A.4.3 Case 3: half-wing with lumped masses .

.
.
.
.
.
.
.

117
. 119
. 120
. 121
. 122
. 122
. 124
. 124

VTOL sizing: Overview
The objective of rotorcraft sizing is to obtain a consistent combination of

weights and performance for the various components in a VTOL platform. The
interdependent nature of the design of various parts (e.g., engine, rotors, transmission, fuselage) necessitates methods that capture these dependencies to the required
accuracy; otherwise components might be over-designed and heavier/bulkier than
required (performance penalty) or under-designed, requiring a costly sequence of
redesign operations for all parts in the detailed design phase.
Sizing for vertical-lift aircraft is not a new field; the fundamental methods
have been adapted from fixed-wing sizing and augmented with VTOL-specific components, and refined over several decades. A notable example of a VTOL sizing
algorithm is the method of Prof. Marat Tishchenko (MIL design bureau) and Dr.
V.T. Nagaraj; this combination of component sizing laws and the iterative sizing
sequence is one of the cornerstones of HYDRA.
Recent work by Dr. Wayne Johnson at NASA Ames produced several iterations of a continuously updated NASA code called NDARC. This code can size
conventional and unconventional VTOL platforms, as well as a range of fixed-wing
aircraft. Additionally, each major helicopter manufacturer has built up a database
of manufactured part weights and performance, and have developed their respective
in-house sizing tools. These sizing tools were originally developed for single main
rotor helicopters powered by gas turbine engines, and have been gradually adapted

to include eVTOLs (electric Vertical TakeOff and Landing platforms) and configurations with hybrid powerplants featuring Distributed Electric Propulsion (DEP).

1.1

The nature of VTOL sizing

Table 1: Conceptual sizing: drivers for group mass

Group name
Fixed wing
Rotors
Empennage

Mass depends on
Aspect ratio, wing loading → take-off mass
Radius, solidity, RPM, torque, thrust → take-off mass
Tail loading, pitch/yaw stability and control authority

Propeller

Vehicle drag → take-off mass

Fuselage

Dimensions, take-off mass
Take-off mass

Landing gear

Flight controls Blade geometry, wing area, wing loading → take-off mass
Deicing

Wing area, rotor blade area → take-off mass

Battery

C-rating, specific energy, rotor power → take-off mass

Motor

Maximum torque/power → take-off mass

Avionics

Fixed mass group

Power wire

Layout of rotors and motor power limits → take-off mass

Signal wire

Layout of controls and sensors

To illustrate the interdependent nature of sizing laws for various components,
consider the dominant drivers for the weights of various vehicle components in an
eVTOL, shown in Table 1. The list of dependencies is illustrative and not exhaustive, but sufficient to highlight the key point: determination of take-off mass
requires solving for several cyclic dependencies, i.e., the total take-off mass
depends on itself. Two well-known methods have been successfully used to solve
this class of problems with simultaneous nonlinear equations:
1. Iterative convergence
2. Optimization with compatibility constraints
The implementations of both approaches in HYDRA are detailed in the following
sections.

1.1.1

Iterative convergence
Iterative convergence is a popular technique that is used to solve several classes

of problems. It has been successfully applied to nonlinear algebraic equations in
several variables, where analytical solutions are unavailable. The overall approach
is shown in Fig. 1. Four primary types of models are required for conceptual sizing:
1. Weight
2. Performance
3. Sizing and geometry
4. Energy storage
3

Figure 1: Iterative sizing: the classical approach

Typically, low-fidelity models are used to represent each group for conceptual
sizing, because fine-grained resolution of each component is not possible at this
stage due to the unavailability of design details. For VTOL sizing in particular,
sizing operations can be executed in a particular sequence to obtain answers rapidly
with fewer sizing iterations. One such sequence is shown in Fig. 2.
Each block shown in Fig. 2 consists of further sub-modules that are assembled
together in the implementation. The key inputs for sizing are the three green blocks
that feed information to the sizing of the vehicle: aircraft layout, mission profile
and model calibration data.
The aircraft layout is perhaps the most significant assumption required to
initiate sizing. Figure 3 shows a few candidate eVTOL configurations, with different
permutations and combinations of rotor and wing technologies, as shown in Fig. 4.
In HYDRA, the constituent rotor and wing technologies are defined as primitive types.
Based on user inputs, these technology combinations are superimposed in HYDRA to
obtain the appropriate configuration.

Figure 2: Iterative sizing: detailed breakdown of operations

Figure 3: Variety in electric VTOL aircraft

Figure 4: Assumbling eVTOLs from rotor and wing technologies

Figure 5: An example mission profile

The mission profile is specified as a sequence of hover and cruise segments.
Cruise segments are defined through a specified airspeed and distance/time, while
hover segments are defined through duration. Climb and descent segments are
defined as cruise segments with different start and end altitudes. An example mission
profile is shown in Fig. 5.
Finally, the model calibration data refers to calibration constants for parametric models of rotor performance, turboshaft engine performance, electric motors,
fuselage drag vs. weight curve fits, and several other assumptions. Typically, up
to 30 constants are required to calibrate different low-fidelity models accurately,
defined in the defaults.yaml input file. In HYDRA, several parametric models have
been systematically replaced with higher-fidelity counterparts and so lift the specific
assumptions made to arrive at those constants.
Accelerated convergence
The implementation of iterative sizing shown in Fig. 1 requires several iterations (up

Figure 6: Accelerated convergence for iterative sizing

to 30) to converge take-off mass to the required tolerance. An alternate approach
is implemented in HYDRA, resulting in significantly faster convergence for no loss in
accuracy. This accelerated convergence technique is shown in Fig. 6.
In this method, the “inner loop” is executed in fixed take-off mass mode, and
the constituent weight groups are evaluated. Finally, the remaining mass (take-off
mass minus empty weight, minus energy storage) is assigned to payload mass, i.e.,

mpay

M − mempty − mbattery − mfuel

(1)

Here, M represents the take-off mass. Usually, mission profiles are specified
together with the target payload mtarget . However, the “inner loop” described above
runs once to calculate the payload mass mpay for a given take-off mass M . Therefore,
the take-off mass needs to be continuously adjusted to ensure that the “calculated”
payload matches the target payload. One update scheme for the take-off mass (used

in HYDRA) is
Mi+1
The slope

dM
dmpay

Mi −

dM
(mpay − mtarget )
dmpay

(2)

is initially set to 3.0, and subsequently updated based on a finite-

difference approximation as iterations proceed. This method usually converges in 3
– 5 updates for take-off mass (vs. 30 iterations for the baseline technique), resulting
in 5 – 6 times faster convergence for no reduction in accuracy.

1.1.2

Constrained optimziation
The other technique that lends itself to VTOL conceptual sizing is constrained

optimization. The primary advantage of this technique is that it allows for simultaneous minimization of a cost function (e.g. vehicle operating cost) while satisfying
compatibility constraints (e.g., payload matching and landing footprint). If only
sizing is required, the design variables are fed as prescribed inputs and compatibility constraints are specified as nonlinear algebraic constraints. The take-off weight
is provided as a design variable and the payload is calculated as an output. The
condition that the calculated payload (mpay ) be at least the target mission payload
(mtarget ) is enforced as a nonlinear inequality constraint.
In HYDRA, two different optimizers are used for constrained minimization of
the vehicle hourly operating cost: gradient-based optimization, and differential evolution. The constraints are landing footprint (based on wing span and fuselage
length) and payload matching. For concentual sizing, gradient-based optimization requires an accurate initial condition to ensure that global minima (and not
local minima) are identified at the end of optimization. In HYDRA, the gradient10

based optimizer is initialized from several starting conditions, each of which are
obtained from a parametric sweep over the available high-level design variables. For
differential evolution, compatibility constraints are implemented indirectly as a
“death penalty” - an analog of exterior penalty functions. The cost function is increased by a large number (1e6) for designs that violate any of the user-specified
constraints. Additionally, HYDRA is programmed to automatically add and remove
design variables based on the number of rotor and wing groups in the vehicle.
The optimizer in HYDRA is invoked after basic sizing over a limited parametric
sweep is carried out. Both optimization techniques - gradient based and differential evolution - are used to minimize vehicle operating costs, and the resulting
optimized designs are checked for uniqueness. These unique designs (obtained from
optimization with different starting conditions) are ranked by operating cost, weight,
battery/fuel or rated power based on a user-selected criterion. Further details are
provided in the appropriate section later on in the documentation.

2
2.1

Drag models
Fuselage and empennage drag
The fuselage is modeled as a slender body of revolution with its length set by

user inputs, and an equivalent diameter based on body width and height (also set by
the user). The procedure to calculate skin friction drag and base drag are identical
to those documented in NASA CR-3083:

Rotary-Wing Aerodynamics: Volume II

by C.N. Keys. Similiarly, the approach for estimating the drag of horizontal and
vertical tail surfaces, as documented in NASA CR-3083, is implemented in HYDRA.

2.2

Edgewise rotor hub drag
The flat-plate area of each edgewise rotor hub is estimated based on a modified

procedure outlined in NASA CR-3083, as follows:
fhub

2.3

1.2R2 (0.0006 + 0.00222Nb )

(3)

Spinner drag
The spinner is assumed to be a rotating body with a hemispherical nose and

blunt base. As shown in Fig. 7, the drag coefficient of such a shape is 0.2 (referenced to cross-sectional area πd2 /4), for a length-to-diameter ratio of 2.5. For the
calculations presented in this paper, a drag coefficient of 0.36 is assumed, to account
for additional blockage from the airframe, vertical fins and interference effects. The
radius of the spinner is 15% of the rotor radius.

2.4

Momentum drag for engine air intakes
For turboshaft engines operating at cruise speeds above 160 knots, the addi-

tional momentum drag is 0.3 ft2 per intake.

Figure 7: Spinner nose cone:drag coefficient, from Fluid Dynamic Drag, Hoerner

2.5

Landing gear drag
The drag of landing gear is modeled with a parametric representation (obtained

from NASA CR-3083) as follows:
loge fLG

y0 + m loge (0.001W )

(4)

Here, fLG is in square feet, and W is in lbs. The constants y0 and m are set
based on the type of landing gear.
1. Retracted gear: fLG = 0
2. Wheeled gear: y0 = 0.5755. The slope m = 0.443 for W ≥ 1000 lb, and zero
for W ≤ 1000 lb.
3. Skid gear: y0 =-0.11626. The slope m = 0.4979 for W ≥ 1000 lb, and zero
for W ≤ 1000 lb.
13

2.6

Cooling drag
The cooling systems required to regulate engine temperatures creates addi-

tional drag, which is estimated using a parametric model given in NASA CR-3083.
fcool (ft2 )

2.7

10−4 Pins (hp)

(5)

Mast fairing drag for coaxial rotors
The fairing for the exposed length of the rotor shaft between the upper and

lower rotors of a coaxial system incurs an additional drag penalty, given by
fmast (ft2 )

2.8

0.0322R2

(6)

Protrusion drag
The drag of protrusions is modeled as an additional 10% of the accumulated

parasitic drag of all wetted surfaces.

3
3.1

Rotor and Wing Performance Models
Rotor performance model
Two performance models are used to calculate rotor power required in hover

and axial flight. The first model is based on momentum theory, and the second
model is based on blade element momentum theory.

3.1.1

Momentum Theory
For momentum theory-based predictions, rotor power is calculated based on

assumed aerodynamic efficiency factors in hover and cruise. Imperial units (foot,
pounds of force and horsepower) are assumed for these expressions. In hover, rotor
power is given by
Phover (hp)

T 1.5
√R
550 2ρA FM

(7)

Here, T is the thrust required in hover from each rotor, and is calculated assuming
the segment weight is equally divided between all rotors. A vertical download factor
(configuration-dependent) is included in the estimation of rotor thrust. The rotor
disk area is A (ft2 ), ρ is the ambient air density (slug/ft3 ) and FM is the rotor figure
of merit in hover.
In cruise, the power required by each rotor when operating in axial flight is
Pcruise (hp)

D V∞
NR 550ηp

(8)

Here, D is the total vehicle drag in lbs when operating at a forward flight
speed of V∞ ft/s, which is overcome by each of the NR rotors operating at a propeller
efficiency of ηp .

3.1.2

Blade Element Momentum Theory (BEMT)
Certain configurations like the tilt-rotor or tilt-wing fly such that the rotors

operate predominantly in axial flight. Therefore, the Blade Element Momentum
Theory (BEMT) is used as a higher-fidelity replacement for momentum theory-based
predictions. Though BEMT can resolve finer details like angle of attack variations
15

along the span, it requires detailed inputs, namely airfoil tables and distribution
of blade chord and twist along the span. These details are populated as described
below.
The rotor is assumed to be constructed from multiple user-specified airfoils.
The lift and drag characteristics for each airfoil may be Reynolds-tabulated or machtabulated. Several combinations of blade chord and twist distribution are generated
assuming linear taper and bilinear twist. The design variables for blade geometry
are:
1. Blade taper ratio (1:1, 2:1 and 3:1)
2. Blade bilinear twist junction (30% – 70% span)
3. Twist at bilinear junction (-5 deg to -20 deg)
4. Twist at tip (-5 deg to -35 deg)
The rotor RPM in cruise (specified as a fraction of hover RPM) is added as a sizing variable. The BEMT analysis calculates the rotor power required for a given
thrust, for all mission segments, exploring a parameter space of 360 designs (combinations of blade twist and taper distribution). The rotor geometry for minimum
energy consumption over the mission is identified from the parametric sweep, and
the aerodynamic efficiencies (figure of merit F M in hover and propeller efficiency
ηp in cruise) are calculated for each mission segment.
Minimizing the energy required at the rotor ensures reduced fuel consumption,
but not necessarily a good overall design. A cruise-dominated mission results in a
16

prop-rotor with a potentially degraded hover figure of merit while achieving good
aerodynamic cruise efficiency. Therefore, installed power (and therefore, engine and
transmission weights) may increase, resulting in a lower payload fraction. To prevent
unchecked increases in powerplant weights, another condition is introduced in the
BEMT analysis: designs are considered “valid" if the hover figure of merit is greater
than a user-specified threshold (e.g., 0.72), and only these valid designs are ranked
to determine the “best” rotor efficiencies.
When BEMT is included in the sizing iterations, sizing proceeds in 3 steps:
1. Perform sizing with momentum theory and assumed efficiency factors in hover
and cruise (F M =0.75, ηp =0.82)
2. If the design satisfies all constraints, perform BEMT analysis to calculate aerodynamic efficiencies for each segment based on thrust requirements; extract
hover or cruise efficiencies (FM, ηp ).
3. Perform sizing with momentum theory, using the calculated rotor aerodynamic
efficiencies obtained in Step 2.
Figure 8 shows the comparison of thrust and power obtained from BEMT
predictions with airfoil tables vs. sub-scale experiments for a variable-pitch and
variable-RPM sub-scale prop-rotor. Good predictions were obtained at various
cruise speeds ranging from 3 m/s to 15 m/s. For these cases, BEMT was found
to be sufficient for accurate performance predictions.

Figure 8: Comparison of BEMT predictions to experiments

3.2

Wing performance model
The drag coefficient of a fixed wing is given by
CD

CDo +

1
CL2
πARe

(9)

The lift coefficient CL and aspect ratio AR are sizing design variables. The profile
drag coefficient CDo is an assumed value, usually 0.014 (including protrusions and
interference). The Oswald efficiency e is calculated as
e

(Q + P πAR)−1

0.38 × 0.02

1.01
s

1 − 2

dfus
bwing

The parameters are dfus = equivalent fuselage diameter, and bwing = wing span.
18

Weight models
There are three main contributors to vehicle take-off mass:
1. Energy storage - battery and/or fuel weight. This component may be
traded-off against payload for mission flexibility, depending on available volume.
2. Empty weight - this weight group represents the airframe, wings, rotors, engines, transmission, motors, seats, avionics and other non-removable systems.
3. Payload - usually specified with the mission definition.

4.1

Engines, fuel and batteries
Though engines strictly belong in the empty weight category, the calculation

of fuel weights are inextricably linked to the evaluation of engine performance and
engine weights. Therefore, engine models are described in this section.

4.1.1

Engines
HYDRA has built-in models for fuel-burning engines of two types: gas turbine

engines, and reciprocating engines (piston engines and aero-diesel engines).
Turboshaft engines
Based on statistical data for various production engines, a trend line was fitted
with good accuracy (R2 = 0.92) for the variation of engine weight Wengine (lb) with

installed power Pins (hp). The fitted engine weight model is given by
Wengine (lb)

0.552
7.3874 Pins

(10)

Another fit is shown in Fig. 9, in SI units with engines manufactured over the last
fifty years.
The variation of engine Specific Fuel Consumption (SFC) at peak efficiency
with installed power is
sfcbase (lb/hp-hr)

1.549 P−0.161
ins

(11)

Engines operating at sub-optimal conditions (i.e. at power settings lower than design
power output) suffer from higher specific fuel consumption. This effect is modeled
using a power law as

sfc

sfcbase

Preq
Pins

−0.256
(12)

Here, Preq is the power output required from the engine to produce a thrust T
during a mission segment. Finally, the variation of available power (relative to
installed power) with ambient temperature and pressure is given by
Pavail

Pins [1 − KT (θ − 1)] [1 + KD (δ − 1)]

(13)

The terms θ and δ are ratios of ambient temperature and ambient pressure to their
corresponding values at mean sea level (ISA). The constants KT and KD are obtained from curve fits of detailed engine performance curves.
Piston engines
The treatment of piston engine weights is similar to that followed for turboshaft
engines. The variation of engine weight with installed power is given by
20

Figure 9: Statistics: turboshaft engine mass vs. installed power

Wengine (lb) = 2.367 Pins (hp)0.916

35 ≤ Pins (hp) ≤ 1000

(14)

Another fit is shown in Fig. 10, in SI units with a larger sample size, including less
efficient engines. The variation of engine SFC at its peak efficiency is
sfcbase (lb/hp-hr) = 0.42, Pins (hp) ≤ 4
= 0.594 − 0.0046 Pins (hp), 4 ≤ Pins ≤ 56
= 0.52 Pins (hp)−0.0972 , 56 ≤ Pins ≤ 1000

4.1.2

Fuel, tank and fuel handling systems
After calculating the engine power required, the mission profile (flight segment

duration) is used with engine power requirement and SFC estimates to calculate the
fuel weight as
mfuel

SEG
ΣNi=1
sf c(i) Peng (i)

+ munusable

(15)

Figure 10: Statistics: reciprocating engine mass vs. installed power

An average density of 6.7 lb/gal is used for both turbine engine fuel and aviation
gasoline. The fuel tank and plumbing mass is estimated from fuel volume using
AFDD models as
Wtank

0.7717
0.5897
1.9491
0.4341 Vtank
Ntank
fcw fbt

(16)

The terms used in the equations are
Vtank is the tank volume in U.S. gallons (1 gal = 3.7.8 liters)
Ntank is the number of internal tanks
fcw is the crashworthiness mark-up factor, usually 1.31
fbt is the ballistic survivability mark-up factor (1.2 for military, 1.0 for civilian)
The weight of plumbing systems used for regulating fuel flow from tanks to
engines is modeled as follows:
k0plumb

max(0.022M, 120)
22

k1plumb

0.025k0

Wplumb

k0plumb + k1plumb (0.01 ∗ Ntank + 0.06 ∗ Nengine ) V̇ 0.866

V̇ is the peak fuel flow rate to the powerplant in lb/hr and the plumbing system
weight is in pounds. M is the take-off mass in kg - the mixing of units and conventions is a result of AFDD models being specified in FPS units, while HYDRA is
implemented in SI units.
For small-scale powerplants, the trendlines predict an over-estimate of fuel
handling system weight. To handle these special cases, a maximum limiter is placed
on the fuel system weights, with the limit set to 50% of fuel weight.

4.1.3

Battery models
Battery weights are accurately represented using a very simple statistical

model. Figure 11 shows the variation of battery weight with rated energy capacity
for commercially available small-scale batteries, where each data point represents a
manufactured unit. Arguably, a battery density of 158 W-hr/kg is quite low and
improvements can be made; this “conservative” design is typical of commercially
available battery packs including the safety casing.
For full-scale platforms used in commercial operations, several conservative
assumptions are used to incorporate various margins in sizing the battery.
1. The minimum depth of discharge is 7.5% of total energy capacity
2. The maximum state of charge near end of life for the battery is 80%, i.e., after
cycling, the usable battery capacity is at most 80% of the rated energy. Thus,
23

Figure 11: Small-scale batteries: weight statistics

the effective usable energy for battery sizing is 72.5% of the rated capacity.
3. The average discharge efficiency of the battery reduces by 4% for every unit
increase in average C-rating.
4. A specific energy of 240 Wh/kg is used to estimate the mass of the cells.
5. A pack integration factor of 0.75 (defined as battery mass to cell mass) is used
to estimate the weight of battery management systems and casing.
6. A curve fit of temperature rise vs. C-rating (obtained from experimental
data) is used to track the rise of cell temperature over the mission duration. A
maximum limit of of 70o C is used to iteratively add cells until thermal limits
are satisfied.

4.1.4

Electric motor weights
Though electric motor weights are strictly driven by peak torque requirements,

the data correlation between weight and peak rated power is also very good as shown
in Fig. 12. For small-scale motors, the speed controller is sized based on the current
drawn by the system assuming a 12 Volt source. The masses of several large-scale
motors with controllers are plotted against rated power in Fig. 13. Motor + speed
controller efficiencies range from 85% to 92% depending on the design point and
operating RPM range. Motor and speed controller weights are estimated as
Wmotor (lb) = 0.74 P

P ≤ 13.4 hp

WESC (lb) = 1.047 P
Wmotor + WESC (lb) = 1.489 P0.783

4.2

P ≤ 13.4 hp
13.4 hp < P ≤ 350 hp

Electric Transmissions
Generators for electric transmissions are sized in a manner identical to electric

drive motors. The components of an electric transmission are shown in Fig. 14.
The advantage of this hybrid system is that a mechanical transmission is not
required for power transmission to the rotors; further the hybrid system can serve
as a long-range drop-in upgrade for short-range battery-powered variants. The disadvantage of a turboshaft-electric hybrid system is that each additional component
introduces additional points of failure. Adding redundancy and fail-safe architectures can incur a significant empty weight penalty.
25

Figure 12: Statistics: weight of small BLDC motors

Figure 13: Statistics: large-scale DC motor + controller mass vs. installed power.
Manufacturing technology in 2018 can achieve 3.75 kW/kg of power density.

Figure 14: Turbine-generator hybrid powerplant for electric motor. 98% wire transmission efficiency, 92% generator efficiency

4.3

Wire weights
Two types of wires are considered in the sizing analysis: power cables and signal

wires. The weights of electrical power cables are estimated from the vehicle rotor
layout using a wire mass per unit length per unit power of 0.0057 kg/kW/m. Signal
wires are calculated using a linear mass density of 0.17 kg/m and a knowledge of
the rotor layout, together with an estimate of channel counts. Based on user inputs,
doubly/triply redundant power cables and signal wires are automatically added to
the appropriate weight groups for estimating vehicle empty mass.
At full-scale, a key driver of vehicle weight is the rotor design parameter set
(tip speed, solidity, disk loading/radius, first rotating flap frequency). One such em-

Figure 15: Blade cross-section

pirical parameter is the flap natural frequency. In the legacy approach for estimating
rotor blade weight, the designer had to prescribe this parameter to perform sizing.
However, underlying data for the flap frequency is restricted to articulated and hingeless rotors, and plentiful data is not available for stiffer rotors (νβ ≥ 1.08/rev). For
small-scale VTOL with very stiff rotor systems (νβ ≥ 1.4/rev), extrapolation of the
trend line beyond the range of available data for νβ may yield erroneous estimates
for rotor blade weight. For eVTOLs, a physics-based approach is implemented and
used in HYDRA.

4.4

Physics based model for rotor blades
A schematic of the rotor airfoil is shown in Fig. 15. The cross-section consists

of two categories of materials: non-structural masses, and load-bearing components.
The non-structural masses are:
1. Paint: 0.15 mm thickness, density 1800 kg/cu.m, applied on surface
2. Glue: 0.25 mm thickness, density 1800 kg/cu.m, applied on skin, shear webs
3. Core: density of 52 kg/cu.m, encompasses cross-section area of 0.49

t
c

4. Leading edge protection: 1.14mm thickness, density 8900 kg/cu.m, from lead28

ing edge to 25% chord on upper and lower surfaces.
Here,

t
c

is the airfoil thickness-to-chord ratio, usually 0.1 to 0.12 and c is the blade

airfoil chord. For the paint and glue, the chordwise location of the component center
of gravity is 0.5c. For the leading edge protection strip and core, the component
chordwise center of gravity locations are 12.5% chord and 57% chord, respectively.

4.4.1

Skin sizing
The skin is sized to withstand a total torsion moment equivalent to an airfoil

cm =0.2 at the maximum rated rotor speed. The total root pitching moment in hover
is
Mx

1 2 2
ρV c cm R
6 TIP

The skin thickness is given by
tskin

nMx
2Acs τskin

Here, Acs is the cross-section area of the airfoil, and τskin is the maximum allowable
shear stress in the skin. The factor n accounts for additional overload and safety
factors to account for for contingency conditions and fatigue margins.

4.4.2

Leading edge weight
The section chordwise center of gravity for the non-structural components

(paint, leading edge protection and core) along with the skin is obtained from the
respective weights and component centroid locations. If this center of gravity is

behind the blade quarter-chord, a leading edge weight is added to avoid torsional
divergence and flutter for the blade.
The CG of the non-structural components and skin is given by
x1
c
If

x1
c

mLE

4.4.3

mLEP 0.125 + mskin 0.5 + mcore 0.57 + mpaint 0.5 + mglue 0.5
mLEP + mskin + mcore + mpaint + mglue

is greater than 0.25, then a leading edge mass is added, equal to
=

(mLEP + mskin + mcore + mpaint

1
+ mglue ) 4
− 1
c

Spar caps and shear web sizing
The spar is placed so that the neutral axis and CG both lie at quarter-chord.

A NACA-0012 section is used to estimate The elements that support shear and
bending moment due to lift and drag and bending loads are the spar webs (shear
and lag bending moment) and spar caps (flap bending moment and tension due to
the centrifugal load).
The limit load for eVTOL rotor blades is determined from the trim thrust
required under OMI (One Motor Inoperative) conditions. For the “conventional”
tilt-wing configuration (6 rotors on main wing, 2 rotors on horizontal tail) and the
tandem tilt-wing configuration (4 rotors each on canard and wing), the maximum
thrust scaling factor is approximately 150% the hover thrust. With rotor radius
R, rotor speed Ω and peak torque at the blade root Qb determined from the rotor
geometry, the vertical force on the blade is obtained by dividing the maximum
expected thrust level by the total number of blades as
Fz

W
nz
NR Nb

(17)

Figure 16: Blade spanwise segment

The terms nz is a load factor that can incorporate safety margins, dynamic overshoot/landing and fatigue factors for blade loads. The lift distribution along the
span is assumed to be quadratic (a structurally conservative loading profile - the
optimum hovering rotor features a linear spanwise lift distribution, discounting tip
loss effects). The blade is assumed to constructed with a pre-cone angle βp to alleviate root bending moments, and then subdivided into N = 5 equal span segments.
One such segment is shown in Fig. 16.
The dominant loads on the outboard end of the segment, that are carried by
the spar caps, are the centrifugal force (from all segments outboard of the present
one) and a flap bending moment due to (i) distributed lift on segments outboard of
the present one, and (ii) a combination of pre-cone and centrifugal load on segments
outboard of the present one. The blade spanwise segments are successively sized
starting from the tip segment and ending in the root segment. A schematic of the
rotor blade segment and cross-section is shown in Fig. 17.
The total centrifugal load and flap bending moment at the inboard end of the

Figure 17: Rotor blade segment sizing: schematic
segment is
CF (xin )

CF (xout ) + ∆CF

(18)

M (xin )

M (xout ) + ∆M

(19)

The flap bending moment distribution due to lift, along the non-dimensional span
coordinate x (0 at root, 1 at tip) is
Mlift (x)

1
Fz R(x4 − 4x + 3)
4

(20)

The additional centrifugal load and flap bending moment due to loads on the present
segment are
∆CF

∆M

1
2
(ms + mns )VTIP
(x)out2 − x2in )
2
1
−(CFout + ∆CF )∆Rβp + Mlift (xin ) − Mlift (xout )
2

The spar mass per unit span is ms ) and the non-structural mass per unit span is
32

mns . The maximum axial stress in the spar caps at the inboard end of the present
segment is
σxx (xin )

M (xin ) h2
CF
+
2
Aspar
2bt h2

The term Aspar is the area of the spar, given by 2(b + h)t. The individual
expressions can be rearranged to solve for the spar cap thickness t, as
t

LHS

RHS

RHS
LHS

1
1 2
b+h
2
2
σmax + VTIP (xout − xin )ρspar ∆Rβp
−1
n
2
bh

1
1
2
2
2
CF (xout ) + mns VTIP (xout − xin ) + Mlift (xin )
2(b + h)
2

1
1
+
M (xout ) − ∆Rβp CF (xout ) + ∆CF
bh
2

This formulation avoids iterative convergence inner loops for the rotor blade
structure during sizing, improving computational efficiency.
After sizing the spar, the shear webs thickness is determined from the vertical
bending load at the inboard end, given by

tweb

max

1.5nVz
, tweb
hσskin

Here, Vz is the vertical shear due to blade lift integrated from the inboard end of
the segment (x=xin ) to the blade tip (x=1). After sizing one spanwise segment,
the total axial load and flap bending moment at the inboard end of the segment
are calculated using Eqns. 18,19 respectively. The loads at the inboard end of the
present segment are then assigned as tip loads for the next segment, and the process
is repeated for all segments in succession.

4.4.4

Root fitting sizing
The root fitting for the blade is assumed to extend from the shaft (x=0) to

10% of the blade span (x=0.1), and is made of 7075 Aluminum. The density is 2800
kg/cu.m, and a limiting axial stress of 20 MPa is used based on a fatigue life of 108
cycles. The construction of the root fitting is shown in Fig. 18.
The tube radius is assumed to be equal to 4× the airfoil thickness, and the
thickness tRoot is evaluated to ensure that the maximum tensile stress in the material does not exceed the limiting stress (20 MPa). The tube thickness is solved
analytically, using a formulation similar to the approach used for spar sizing. The
expression for tube thickness is
RHS
LHS
Mlift (x = 0.1) − MCF (x = 0.1)
CF (x = 0.1)
+
2
2πrRoot σlimit
3πrRoot
σlimit

tRoot

RHS

LHS

= 1 −

ρ
Ω2 (0.1R)
2σlimit

The root fitting thickness is set to the larger of minimum gauge tmin or the calculated
thickness above, whichever is larger.

4.4.5

Torsion frequency check
The skin thickness is used to calculate the first elastic torsion frequency for the

rotating blade and ensure that it is above 3.3/rev at the hover RPM. If the torsion
frequency is too low, then additional skin thickness is added until this requirement
is satisfied, preserving the same spar design.

Figure 18: Blade root fitting

4.5

Flight controls

Two categories of actuators are modeled: fixed-wing, and rotary-wing.

4.5.1

Rotor controls
Unlike large rotorcraft, some eVTOLs feature low-bandwidth collective actu-

ators and no cyclic or swashplate. In such designs, the collective pitch (e.g., for
prop-rotors) is usually scheduled with airspeed, and RPM is used for feedback control. Sizing laws for these collective actuators are therefore markedly different from
those used for full-scale helicopter controls. The rotor hub mass and collective pitch
actuator masses scale with tip speed VTIP (and blade chord c for the actuator) as

Mhub (kg)

4.84

Mact (kg)

1.47

VTIP
171
VTIP
171

c
0.82
2
c
0.82

The tip speed VTIP is in m/s and mean blade chord c is in meters.

(21)
(22)

4.5.2

Fixed wing controls
Fixed wing flap and actuator weights are obtained from the AFDD model as
Wflaps (lb)

0.41
0.01735W 0.644 Swing

(23)

For this model, the weights are in lbs, including the take-off weight W . The term
Swing is the total plan-form area of all fixed wings, and the actuator weights Wflaps
includes all actuators on all fixed wings.

4.5.3

Tilt actuators
For tilt-rotors and tilt-wing configurations, the masses of tilt actuators are

estimated as the larger of 15.5% of wing mass, and 3.61% of the total mass being
tilted by that actuator. For tilt-wings, both metrics are applicable; for tilt-rotors,
the tilt actuator weight is set to 10% of the masses being tilted.

4.6

Mtilt−wing

max(0.155Mwing , 0.0361Mtilt )

(24)

Mtilt−rotor

0.10(Mhub + Mact + Mblades + Mmotor )

(25)

Motor mount mass
The motor mount structure refers to the overhang beam connecting the motor

and rotor hub, to a wing (or fuselage). For the Vahana tilt-wing configuration, the
motor mount structure is the overhang beam used to offset the rotor hub ahead of the
wing leading edge, as shown in Fig. 19. The motor mount is modeled as a cantilever
beam of length L with a tip mass equal to the mass of the rotor hub, blades and
36

Figure 19: Motor mount model

motor. This structure is sized by a natural frequency requirement, i.e., the first
cantilever bending mode for this beam with a tip mass must be sufficiently
large so that the structural dynamics do not interact with flight dynamics (0 - 4
Hz). For eVTOLs, a target first bending frequency of 8.5 – 10 Hz is used to size the
motor mount beam. The overhang length is set to the sum of wing three-quarter
chord and one rotor radius.
For configurations such as CityAirbus (quad-ducted-coaxial rotors) with no
fixed wings, the rotors are mounted directly on the fuselage using support arms.
The support arms are treated as “motor mounts”, and the beam length is set to
120% rotor radius. Appendix A provides an analytical solution for sizing a cantilever
beam with several lumped non-structural masses, distributed structural and nonstructural masses based on a target frequency.

4.7

Wing weight model
Three models are available to estimate the weight of a fixed wing:

4.7.1

AFDD wing weight model
The weight of a fixed wing is estimated as
Wwing

5.6641

Lw 0.847 0.4 0.21
nz Swing AR0.5
1000

t 0.0936
c

The wing weight is in lbs, Lw is the wing design lift in lbs, nz is the design ultimate
load factor, Swing is the wing plan-form area in sq. ft, AR is the wing aspect ratio
and

4.7.2

t
c

is the wing thickness to chord ratio.

Frequency tuning: bending loads
The wing spar is idealized as a cantilever beam with lumped non-structural

masses (rotor blades, hub and collective actuator assembly and motor), distributed
non-structural masses (skin, ribs) and a hollow circular spar. A schematic of one
half-wing is shown in Fig. 20.
The wing taper ratio λ =

cTIP
cROOT

is a design parameter with a default value of

0.75. A tapered wing shifts the non-structural skin mass inboard while strengthening
the root, resulting in increased first bending frequency for the same mass. The skin
thickness is set to include three layers of carbn fiber (45/0/45), resulting in an areal
mass density of ≈ 4.9 kg/sq.m. During sizing, the rotor assembly mass and motor
mass are used to calculate the wing spar thickness required to achieve a target first
bending frequency using the Rayleigh-Ritz approximation detailed in Appendix A.
38

Figure 20: Wing structure: layout

To decouple wing structural dynamics from vehicle flight dynamics, a target first
bending frequency of at least 4 Hz is desirable (for a take off mass of 2000 kg).
Larger aircraft feature progressively relaxed natural frequency constraints, because
the flight dynamic frequencies are lower for larger vehicles with correspondingly
larger moments inertia.

4.7.3

Hover: shear loads
After determining the spar thickness based on natural frequency requirements,

the wing structure is analyzed with static loads in hover with the tapered beam.
Rotor thrusts are applied at the motor mount locations and the static bending
stresses and shear stresses are calculated at five points between nodes (nodes are
located at the root and motor mount locations). A load factor of 3.8 and safety
margin of 1.5 are applied to ensure that the spar can support the loads in hover.
This hover loading condition is more limiting than cruise flight with the same load

factors and safety factors, because the bending moments due to distributed lift are
lower than the corresponding bending moments in hover. The shear loading is used
to estimate the number of ± 45 deg layers of carbon fiber, while the bending loads
are supported by layers of uniaxial carbon fiber.

4.8
4.8.1

Airframe Weight Model
Statistical weight model
The AFDD82 fuselage weight model for helicopter is given by
wfuselage = wbasic + wpress + wcw

(26)

where wbasic is the basic weight of the fuselage, wpress is the weight from any pressurization constraints (set to none for the sample mission in this work) and wcw is the
weight addition for crashworthiness, which is assumed to be 6% of the basic weight
as per AFDD standards. The basic weight is given by

wbasic = 5.896framp

WGTOW
1000

0.4908

0.2544 0.61
nz0.1323 Sbody
l

(27)

where framp is the factor for a retractable ramp, nz is the load factor, Sbody is the wetted area of the fuselage (sq. ft) and l is the length of the fuselage (feet). While these
terms can be defined for full-scale helicopters/tiltrotor, their definitions become increasingly challenging to interpret in the context of unconventional configurations
such as an eVTOL, with very different load paths compared to helicopters.

4.8.2

Physics-based weight model
A physics-based model is used to estimate the weights of load-bearing compo-

nents that transmit rotor hub forces and wing lift and drag to the vehicle center of
mass. The airframe is subdivided into 3-D beam elements, each with bending, axial
and torsion degrees of freedom. Rotor hub loads and wing lift/drag are modeled
as point loads at the motor points, and distributed uniformly over the wing span,
respectively. The external loads corresponding to each mission phase are applied
on the structure, (rotor thrust, torque, wing lift and wing drag) and the resulting
stresses and deflections are calculated and stored at all the nodes. Subsequently,
the cross-section dimensions of the beams are iteratively resized to ensure; (i) Minimum factor of safety of 1.5 (based on Von-Mises stress) at a load factor of 3.5,
(ii) A maximum deflection of 10% for any node (relative to its distance from the
vehicle center). The cross-sections of all beam elements are assumed to be hollow
circles with wall thickness equal to 15% outer radius. The only design parameter
for a beam element is the outer radius of the cross-section. Beam cross-section radii
for all elements are updated iteratively until the 3 design criteria are satisfied, and
the weight of the airframe members is calculated using material density and final
dimensions. The finite element analysis iterations are performed within the sizing
loop. The parameterization for a quad-rotor layout is shown in Fig. 21.
Integration of FEA into sizing: workflow
The overall process is depicted in a flowchart shown in Fig. 22 and proceeds as
follows

Figure 21: Quad-rotor biplane tail-sitter: layout to finite element representation

Figure 22: Workflow for including physics-based airframe weight model in sizing

1. Initialize: A geometric layout of the airframe is chosen, and beam elements
are defined. The present work assumes the beam cross section to be simple
shapes such as a hollow cylinder or a solid square.
2. Inner FEA loop:

Point forces and moments are applied to the structure

based on rotor and wing loads, such as rotor thrust, rotor torque and wing lift.
The von-Mises stress (σVM ), the corresponding factor of safety and deflection
of the various nodes are computed as
σVM = [(σxx − σyy )2 + (σyy − σzz )2

(28)

2
2
2
+ (σzz − σxx )2 + 6(σyz
+ σxy
+ σxz
)]1/2

where σij are components of the stress tensor and the factor-of-safety (FOS)
is
FOS = min(σV M )i /σyield

∀ i ∈N

(29)

where N is the total number of beam elements.
3. Update cross-section dimensions:

The mathematical constraints im-

posed for convergence are
|FOStar − ∆FOS| ≤ min(FOS)

(30)

where FOStar is the target FOS, set to 1.5 and ∆FOS is the allowable band,
set to 0.1. The axial and bending deflections of each node are normalized by
the distance of the node from the vehicle center of gravity. These normalized
deflections must not exceed a pre-determined fraction (0.08) to ensure struc43

tural rigidity. Depending on the type of condition encountered, two types of
cross-section updates are calculated:
(a) The beam cross-section is scaled up by the term (FOS/FOStar )1/3 ) if the
factor of safety is not sufficiently large. The cube root in the expression
stems from the fact that stress is inversely proportional to cross-section
dimension under static load.
(b) If the deflection of any one node is too large, the dimensions of all crosssections are increased by 10%. Increasing the sizes of all the member
cross-sections is required because adding stiffness to the root end of a
longer beam may be more effective than stiffening an outboard member
(in the present workflow, no apriori assumptions are made about the
load path, and so to guarantee deflections are restricted, all members are
stiffened).
The larger of the two calculated dimensions for each structural member is
provided to the FEA for the next iteration. The stresses and deflections are
recalculated, and members resized until the structure achieves the required
factor of safety and deflection limits.
The airframe weight is computed by multiplying the total volume of all the
beam elements with the material density (Aluminum, 2,700 kg/m3 or carbon,
1650 kg/m3 ). This converged airframe weight from static finite element analysis replaces the fuselage weight from the AFDD empty weight formulae in the
iterative sizing process.
44

The structural analysis used in in sizing the airframe structure also provides estimates of the natural frequencies and the mode-shapes. This information can be used
in advanced stages of design to ensure sufficient separation between the airframe,
blade natural frequencies and operating RPM range of the rotor(s).

4.9

Weight margin
A weight margin is included in the analysis to admit additional expansion of

component performance (and therefore weight) at later stages of design. Therefore,
10% of the vehicle empty weight is allocated for a weight margin.

4.10

Fixed weight groups
Fixed empty weight groups consist of mission-specific components and do not

scale with vehicle dimensions or system performance during sizing. These fixed
weight groups are
1. Carpets, cabin trim and noise insulation
2. Avionics, sensors and flight computers
3. Airconditioning and heaters
4. Seats
5. Low voltage battery, anti-collision lights, air data systems
6. High voltage bus and power distributors

Analysis Organization
HYDRA is a rotorcraft sizing code with the following features:
1. Sizing: obtain consistent vehicle weights and performance for a given payload
and mission profile.
2. Optimization Optimize a given design (e.g., for annual operating cost)
3. Sensitivity Analysis For a given design, identify sensitivity of weights and
performance metrics to (i) underlying assumptions (e.g., engine efficiency),
and (ii) changing design variables (e.g., rotor tip speed)
The main focus of this document is to explain the usage of the analysis, and

implementation of the various performance, weight and cost models used to size the
rotorcraft. The theory, if any, will be explained side-by-side with the corresponding
code segment.

5.1

Programming Language and Syntax
HYDRA is written in Python3, with heavy emphasis on classes to contain and

compartmentalize information. Because Python2 support expires in 2019, it is recommended to use Python3 specifically.
Some parts of the code are written in Fortran. Three fortran compilers have
been tested and verified to work with the compiled parts of the code: GNU fortran, intel fortran and PGI fortran. Among these three compilers, gfortran and

pgfortran are free, while ifort requires academic or commercial licenses. The
main advantage of pgfortran is the availability of support for CUDA-Fortran, while
executables generated with ifort consistently run faster than those generated with
gfortran or pgfortran for the target applications.
HYDRA also features a built-in Blade Element Momentum Theory (BEMT)
solver, also implemented in Fortran90. The BEMT solver is parallelized with
OpenMP. Additionally, the sizing and optimization stages of HYDRA are parallelized
with MPI, and can be executed in parallel.

5.2

Pre-Requisites and Installation Notes
A Fortran90 compiler is required. Due to the use of free-format coding,

derived types and modules, a Fortran77 compiler is not sufficient.
If you want to try running the code on Windows, there are some manual steps
required to help certain Python modules recognize the OpenMP libraries. For the
time being, consult Ananth for installation details on Windows.
Additional Python3 and its modules (freely available) are required to run
HYDRA and its various postprocessors:
1. matplotlib, numpy, scipy, pyyaml, python3-tk, f90wrap
2. Optional: mpi4py
Finally, CMake version 3.0 or higher is required to create Platform-independent
Makefiles that compile the Fortran90 routines. To use integrated LATEXrendering for
fonts in plots, you may also need the texlive-fonts-extra package.
47

5.3

Source Code Directories
All source code to be compiled is located in src/, under various subfolders.

Each subfolder contains a collection of subroutines or functions that pertain to
specific types of operations.

5.3.1

Python code: src/Python
This subfolder contains various classes and functions written in Python that

pertain to sizing a vehicle, in four sub-folders.
1. Stage_0/: This folder contains the “main” class that defines the vehicle in
hydraInterface.py. It contains the various high-level driver functions pertaining to sizing and optimization. The folder also contains two other files,
dict2obj.py (convert dictionary to class) and footprint.py (calculates vehicle footprint).
2. Stage_1/: This folder contains the workhorse routines that perform sizing
with weight, performance and cost estimation.
3. Stage_3/: This folder contains Python-wrapped routines for higher-fidelity
fuselage and wing weight models, BEMT rotor performance models and the
associated interfaces to setup the inputs and extract outputs for the sizing
analysis.
4. Postprocessing/: This folder contains functions that perform postprocessing
analysis, including optimization, design perturbation and sensitivity studies,
48

noise estimation, battery status, profile, power curve, and pie charts for the
breakdown of vehicle weight, operating cost and parasitic drag.

5.3.2

NETLIB FILES: Source/fea/Source/mathops/
This subfolder contains the ODE Solver dassl, algebraic equation solver hybrd

and various dependencies needed for linear algebra and matrix operations. These
files have not be modified, except the algebraic equation solver hybrd.f. This file
alone has been changed to obtain the Jacobian in parallel using OpenMP.
Parts of the sizing analyis, FEA-based fuselage/wing weight estimation and
BEMT-based rotor performance estimation are written in Fortran90 to improve
execution speed. The source code for these operations are contained in src/bemt/Source/, src/fea/Source/ and src/sizing/Source/. Within each of these
folders, there are three sub-folders:

5.3.3

Python-integrated routines: Source/pyint_files/
This subfolder contains routines that can be invoked from Python, using f2py

and James Kermode’s f90wrap adaptation for derived types.

5.3.4

Python-accesible modules: Source/pyint_modules/
The files in this folder contain module definitions used to define universal con-

stants (e.g., 1, 0, π) to the required precision. Using James Kermode’s f2py-f90wrap
interface generator, Python can access and modify these module variables directly
without having to painstakingly break down derived types into its primitive con-

stituents (arrays, integers, real numbers and logicals). The advantage of this automation and abstraction helps avoid programming errors, reduces the number of
arguments passed between Python and Fortran and allows for code feature expansion without significant additional effort.

5.3.5

Python-invisible files: Source/pyinv_files/
The files in this folder are work-horse routines that can be called only by the

routines in Source/pyint_files/, but not directly by Python. These routines,
together with those in Source/pyint_files/, are compiled into shared object files.
Specific routines (present in Source/pyint_files/) in these shared objects can be
called by the Python interface.

6
6.1

First-time setup
Installing pre-requisites
For Debian-based Linux distributions, you can get Python3, CMake and gfor-

tran using the command
sudo apt-get install python3 cmake gfortran texlive-fonts-extra
For MacOS, similar commands can be executed with brew.
After installing Python3, install various modules using pip
sudo python3 -m pip install numpy
sudo python3 -m pip install scipy
In a similar manner, install the other modules with a terminal.

6.2

Compiling source code
After installing the pre-requisites, create the directory cmake/build/ as fol-

lows
cd cmake/
mkdir build/
cd build/
Then, execute the cmake command and compile the code
FC=gfortran cmake ../../
make -j
51

6.3

MacOS-specific issues
Hopefully, there are no issues and the build process executes successfully. How-

ever, if it does not, and you are reading this, chances are that you are using Windows,
or Mac. For Windows, there is a long and complicated series of steps documented
here: https://github.com/jameskermode/f90wrap/issues/73
For MacOS, the system may not recognize the f90wrap and f2py-f90wrap
commands even if the f90wrap module is installed - this issue was noticed for OSX
High Sierra and v3.7 of Python. In case this situation arises, you may have to create
symbolic links to these two commands in /usr/local/bin/. For example, Ananth
had to create a symlink as follows:

1. Identify where f90wrap is installed: use the following command in terminal

python3 -m site

If Python3 is installed correctly, you will see an output that looks like this:

sys.path = [
’/usr/local/bin’,
’/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/
Versions/3.7/lib/python37.zip’,
’/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/
Versions/3.7/lib/python3.7’,

’/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/
Versions/3.7/lib/python3.7/lib-dynload’,
’/usr/local/lib/python3.7/site-packages’,
’/usr/local/lib/python3.7/site-packages/RBF-2018.10.31-py3.7macosx-10.13-x86_64.egg’,
’/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/
Versions/3.7/lib/python3.7/site-packages’,
’/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/
Versions/3.7/lib/python3.7/site-packages/RBF-2018.10.31-py3.7macosx-10.13-x86_64.egg’,
]
USER_BASE: ’/Users/ananthsridharan/Library/Python/3.7’ (doesn’t exist)
USER_SITE: ’/Users/ananthsridharan/Library/Python/3.7/lib/python/sitepackages’ (doesn’t exist)
ENABLE_USER_SITE: True

The results of this command show that f90wrap may be found in
/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions
/3.7/bin/

To verify that the f90wrap and f2py-f90wrap commands can indeed be
located in that folder, use the ls command as follows: (without the linebreak)

ls /usr/local/Cellar/python/3.7.0/Frameworks/
Python.framework/Versions/3.7/bin/*f90wrap
53

You should see an output that looks like this:
/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions
/3.7/bin/f2py-f90wrap
/usr/local/Cellar/python/3.7.0/Frameworks/Python.framework/Versions
/3.7/bin/f90wrap

Now, we’re ready to use the ln command to create symlinks.
2. First, create a link for f90wrap:

ln -s /usr/local/Cellar/python/3.7.0/Frameworks/
Python.framework/Versions/3.7/bin/f90wrap /usr/local/bin

3. Next, create a link for f2py-f90wrap:

ln -s /usr/local/Cellar/python/3.7.0/Frameworks/
Python.framework/Versions/3.7/bin/f2py-f90wrap /usr/local/bin

Then, try deleting the build directory and redo all the compilation steps.

Input files
This section of the documentation details the inputs files and conventions that

that are necessary to perform sizing. The two main input files are input.yaml and
defaults.yaml.

7.1

input.yaml
This input file specifies the mission profile, vehicle configuration, propulsion

type and masses of fixed weight groups (e.g., crew, payload, mission equipment).
An example input.yaml file is shown below in various segments, and each input and
its units are explained.
HYDRA inputs and outputs are handled using yaml files through the pyyaml
package. The yaml input files are converted to Python dictionaries when read, allowing the inputs to be specified in any order. The main dictionaries in input.yaml
are Sizing, Configuration, Mission and Aircraft. All four dictionaries must be
present in input.yaml. An example file is shown below with the main dictionary
names and sub-dictionary names highlighted.
Sizing:
Rotors:
All_rotors:
Nb:

[3]

# per rotor

Vtip:

[170]

# hover tip speed, m/s

ctsigma:

[0.139]

Wings:
Main_wing:
nwing:

[1]

aspectratio:

[5,6,7,8]

cl:

[0.4,0.5,0.6]

liftfraction:

[0.9]

nrotors:

[6]

Tail:
nwing:

[1]

aspectratio:

[6]

cl:

[0.3]

nrotors:

[2]

Fuselage:
nrotors:

# fidelity options for weight and performance models
ifea:

False

use_bemt:

False

Configuration:
Rotors:
All_rotors:

‘All_motors’ # motor group to drive this rotor group

Wings:
Main_wing:

‘All_rotors’ # what rotor group to use on this wing

Tail:

‘All_rotors’ #

# note: 4k95 = 1219.2 m, ISA + 27.92 C, 6k95 = 1828.8 m, ISA + 11.88 C
# flight mode: 0-idle, 1-hover, 3-cruise
Mission:
nsegments:

flight_mode:

[’hover’,’cruise’, ’cruise’,’hover’ ]

time_seg:

[

1.5,

1.5

start_altitude:

[

0.0,

00.0,

] # m

end_altitude:

[

0.0,

] # m

delta_temp_isa:

[

0.0,

] # centrigrade

cruise_speed:

[

98,

] # knots

distance:

[

50,

15,

] # in km

add_payload:

[

] #

segment_type:

[ ‘all’,

sizing_order:

[

# fixed_GTOW:

]

‘all’,‘reserve’, ‘all’ ] #
2,

] #

1400.0

Aircraft:
aircraftID: 2
# 1: SMR, 3: Coax, 4: Quadrotor (needs to be improved), 5: custom

# payload, crew (kg)
mass_payload:
mass_crew:
avionics:

320.0

# 250 kg payload + 70 kg margin

0
79.2

common_equipment: 24.0

# HVAC systems - common for all PAX

common_per_pax: 00.0
pax_count:

nrotor:

# total number of rotors

npropeller:

# Cruise propeller count

engineType:

# passengers (uses pax -> baggage map)

‘electric_motor’

# engine parameters

Each main dictionary and its relevant inputs are discussed below.

7.1.1

Sizing
This dictionary specifies the values of high-level design variables to use for

sizing the vehicle. Up to three sub-dictionaries (Rotor, Wings and Fuselage) and
two logical inputs for using higher-fidelity models constitute the sizing dictionary.

7.1.1.1

Rotors

The Rotors dictionary consists of sub-dictionaries, with each sub-dictionary
corresponding to a rotor. Several instances of this rotor unit may exist on the vehicle;
this detail is provided in the Configuration dictionary, detailed in the following
sub-section.
Each Rotor group is determined by several sizing design variables. In the
present example, the Rotor sub-dictionary is
Rotors:
All_rotors:

Nb:

[3]

Vtip:

[170, 180, 190]

ctsigma:

[0.13, 0.139]

# per rotor
# hover tip speed, m/s

This definition shows that there is one rotor group used in the vehicle called ‘All_rotors’,
with three design variables to size rotors in this group:
1. Number of blades Nb - single or multiple integers
2. Tip speed VTIP in m/s - list of floats
2
) - list of floats
3. Hover blade loading CT /σ = T/(ρNb cRVTIP

Rotor radius: If the rotor radius is specified, then it is set to the input value. If
the disk loading is specified, rotor radius is calculated based on the vehicle weight,
rotor thrust share and hover down-load (specified in defaults.yaml).
If the rotor disk loading in hover is not specified (keyword DL, lb/sq.ft) and
the rotor radius (keyword radius, meters) is also not specified, the rotor is assumed
to be mounted on a wing, and the size is set based on wing span (calculated in fixed
wing sizing) and rotor tip clearance (specified in defaults.yaml). After calculating
rotor radius, the tip speed is used to identify the mean rotor blade chord. If the
rotor geometric solidity (keyword solidity) is specified, then the hover blade loading
is calculated. Otherwise, the the hover blade loading (keyword ctsigma) must be
specified, and the geometric solidity is calculated. Some additional inputs are rotor
cruise RPM to hover RPM ratio (keyword RPM_ratio), and first flap frequency
in hover (keyword fl_freq). If these inputs are not specified, then default values of
59

ΩC /ΩH = 0.5 and νβ =1.1/rev are assumed.

7.1.1.2

Wings

The Wings dictionary consists of sub-dictionaries, with each sub-dictionary
corresponding to a fixed wing type. Several instances of this fixed wing unit may
exist on the vehicle; this detail is specified by the parameter nwing. In the example
shown above, the Wings dictionary is
Wings:
Main_wing:
nwing:

[1]

aspectratio:

[5,6,7,8]

cl:

[0.4,0.5,0.6]

liftfraction:

[0.9]

nrotors:

[6]

Tail:
nwing:

[1]

aspectratio:

[6]

cl:

[0.3]

nrotors:

[2]

This input specifies one fixed wing called “Main_wing”, and another called “Tail”.
The number of wings is specified using the parameter nwing, which is usually 1. The
input nwing =[2] is used for tandem-wing designs, where both the canard and main
wing are of identical construction. The parameter aspectratio is the wing aspect

ratio b2 /Swing , cl is the wing cruise lift coefficient and liftfraction is the fraction of
vehicle weight carried by the wing group in cruise. Finally, the parameter nrotors
specifies the number of rotors mounted on a wing of this group. Here, 6 rotors
are mounted on the main wing, and 2 rotors are mounted on the tail. Each input
parameter can be specified as a list of values to investigate.

7.1.1.3

High-fidelity model switches

The parameter ifea is a logical input, used to specify if the FEA-based weight
model is to be used in the sizing loop to estimate the airframe structural weight.
The other parameter use_bemt indicates whether the Blade Element Momentum
Theory (BEMT) should be used to refine rotor performance estimates in hover (and
cruise for prop-rotors). In this example, both options are not enabled.

7.1.2

Vehicle configuration

Configuration:
Rotors:
All_rotors:

‘All_motors’ # motor group to use to drive this rotor

Wings:
Main_wing:

‘All_rotors’ # what rotor group to use on the main wing

Tail:

‘All_rotors’ # what rotor group to use on the tail

This dictionary specifies the vehicle configuration, and associations between wings/fuselage and rotors, and drive motors for each rotor group. In the example given
above, the configuration dictionary is repeated below. The first sub-dictionary for
61

the configuration specifies that rotors belonging to the group “All_rotors” are driven
by motors specified by a group called “All_motors”. The rotor group name corresponds to the string used to specify the rotor design variables in the Sizing section.
The second sub-dictionary for the vehicle configuration specifies that on the fixed
wing called ‘Main_wing’, the rotors mounted on this structure are of the type
“All_rotors”. Similarly, the “Tail” fixed wing features rotors of type “All_rotors”.
7.1.3

Mission profile
The mission profile from input.yaml is repeated below for convenience:

Mission:
nsegments:

flight_mode:

[’hover’,’cruise’, ’cruise’,’hover’ ]

time_seg:

[

1.5,

1.5

start_altitude:

[

0.0,

00.0,

] # m

end_altitude:

[

0.0,

] # m

delta_temp_isa:

[

0.0,

] # centrigrade

cruise_speed:

[

98,

] # knots

distance:

[

50,

15,

] # in km

add_payload:

[

] # extra payload

segment_type:

[ ‘all’,

sizing_order:

[

# fixed_GTOW:

]

‘all’,‘reserve’, ‘all’ ]
2,

] #

1400.0

The parameter nsegments specifies the number of mission segments. Each segment type can be ‘hover’ or ‘cruise’, specified by the parameter flight_mode. For
62

hover segments, the duration is specified by the parameter time_seg. For cruise
segments, either the segment duration can be specified, or the distance can be
provided as an input and the segment velocity cruise_speed will be calculated.
If the distance is provided as a non-zero input value, the cruise segment duration
input is ignored. For climb segments, the start and end altitudes start_altitude,
end_altitude are specified in meters.
The parameter add_payload is used to inform the analysis that the payload
has changed at the end of a mission segment (e.g., cargo picked up/dropped off or
passenger disembarked/entered the vehicle). The input parameter segment_type
specifies the type of mission segment - ‘all’ indicates the segment is used in dayto-day operations, while ‘reserve’ indicates that the segment is used for sizing, nut
not operating cost calculations. The parameter sizing_order is a list of integers,
with zero specifying that the segment is not used for sizing, and a non-zero integer
specifying that the segment is used to size a particular component. Usually, the first
hover segment and first cruise segment are used for sizing various components. The
final line is an optional input specifying the parameter fixed_GTOW. If this line
is present, it instructs the analysis to run sizing in fixed take-off weight mode, and
estimate the payload based on the remaining mass.

7.1.4

Aircraft
The aircraft specification dictionary is repeated below for convenience. The

payload mass, crew mass, common equipment and avionics mass are fixed mass
groups, specified in kg. The parameter common_per_pax is the mass of equip63

ment that is multiplied by the number of passengers, specified by pax_count.
Based on the number of passengers, additional payload is added internally with the
following map: 150 kg for first passenger, 125 kg for next two passengers and 120
kg for the fourth and fifth passengers.
The parameters nrotor and npropeller are outdated inputs. Finally, engineType specifies the powerplant that is used to store and produce mechanical energy.
Valid entries are ‘electric_motor’ (with Lithium ion battery), ‘turboshaft’ (with mechanical transmission), piston (with mechanical transmission), turbo_electric (turboshaft with generator and electric motors) and piston_electric (piston engine with
generator and electric motors).
Aircraft:
aircraftID: 2
mass_payload:
mass_crew:
avionics:

# 1: SMR, 3: Coax, 4: Quadrotor, 5: custom
320.0

# 250 kg payload + 70 kg margin

0
79.2

common_equipment: 24.0

# HVAC systems - common for all PAX

common_per_pax: 00.0
pax_count:

# passengers (uses pax -> baggage map)

nrotor:

# total number of rotors

npropeller:

# Cruise propeller count

engineType:

‘electric_motor’

# engine parameters

7.2

defaults.yaml
This input file contains the sizing constraints, motor efficiencies, powerplant

details, calibration factors for empirical/reduced-order weight and peformance models and cost models. Also included are “technology factors”, i.e., multipliers applied
to weight predictions for each component. The file is too large to be printed verbatim as a whole unit; instead the text is subdivided into dictionary-sized segments,
and each dictionary in this input file is detailed below.

7.2.1

Sizing dictionary

Sizing:
Constraints:
max_rotor_radius: 12.0 # m
max_ct_sigma

0.14

max_gtow

: 5000.0 # kg

Constraints used to size the vehicle are specified in this dictionary. The
first parameter max_rotor_radius is the maximum rotor radius (for single main
rotor helicopters) or the maximum vehicle footprint (for eVTOL). The parameter max_ct_sigma is the upper limit on rotor blade loading in hover. Finally,
max_gtow is the upper limit on take-off mass imposed for the vehicle. These
constraints are imposed during optimization as well as iterative sizing. If any of
these three constraints are violated during fixed-point iterations, the sizing loop is

terminated and the design is marked “invalid”.
7.2.2

Empirical parameters
This dictionary contains several sub-dictionaries, each of which are detailed

below. A sample dictionary is broken into sub-dictionaries and explained below.

7.2.2.1

Transmission

Empirical:

# Empirical modeling parameters

Transmission:
eta:

1.00

# transmission efficiency

The parameter eta is a fraction between 0 and 1, quantifying the efficiency of
the electrical/mechanical transmission. Both wires and driveshafts/gears feature
upwards of 98% efficiency.
7.2.2.2

Electric motors

Motors:

#motor efficiencies

All_motors:
hover_efficiency: 0.90
cruise_efficiency: 0.85

Presently, the empirical parameters used for motor sizing are hover_efficiency
and cruise_efficiency. In reality, prop-rotors may operate at significantly lower
cruise RPMs, resulting in different electrical-to-mechanical energy conversion effi-

ciencies for the electric motors and speed controllers.
7.2.2.3

Battery

Battery:
Cell:
sp_energy: 240.0

# measured in W-hr/kg

Tmax:

# max cell temperature, deg C

70.0

energy_vol: 632.0
volume:

# energy density, Watt-hours/liter

0.01708 # volume of a cell unit, liters

Pack:
SOH:

0.8

# state of health; 0 = gone; 1 = brand new

DOD_min:

0.075

# minimum depth of discharge;

integ_fac:

0.75

# battery pack integration factor for mass

vol_fac:

0.3

# battery volume integration factor

Force_sizing:

‘energy’ # ignore cell count or temperature effects

The battery sub-dictionary features parameters to model individual cells, as well
as the battery pack. The cell parameters are sp_energy (maximum rated energy
stored per unit cell mass), Tmax (maximum rated cell temperature), energy_vol
(rated energy per unit cell volume) and volume (unit cell volume in liters).
The battery pack is quantified by the following parameters
1. State of health SOH - the maximum energy that can be stored in the pack, as
a fraction of its rated energy. This parameter is usually less than unity because
charge/discharge cycling of cells results in reduced energy storage capacity.

2. Minimum depth of discharge DOD_min - the minimum energy capacity that
the pack must retain to avoid permanent set and reduced energy capacity in
individual cells.
3. Pack mass integration factor integ_fac - the ratio of battery cell mass to
pack mass, to account for the battery casing and power management systems.
4. Pack volume factor vol_fac - the ratio of cell mass to battery pack mass, to
account for additional components introduced by the mass integration factor,
as well as clearances for cell cooling.
Finally, the battery sizing option Force_sizing is character input that directs
the battery sizing module to ignores thermal effects and pack voltage constraints; if
this input is present, only energy-based sizing is performed.

7.2.2.4

Aerodynamics

The aerodynamics dictionary is used to specify rotor hover and cruise efficiencies, interference losses, wing efficiencies and body drag. A sample dictionary is
shown below.
Aerodynamics:
Rotors:
hover_dwld_factor: 0.015
cd0:

0.012

induced_power_factor: 1.18
FM:

0.75

kint:

1.02

hover_thrust:

‘equal’

Wings:
oswald:

0.8

cd0:

0.014

Propellers:
eta:

0.85

Body:
flat_plate_factor: 0.88

# means use drag build-up model

The Rotors sub-dictionary contains modeling constants to quantify hover efficiency
1. hover_dwld_factor is the additional fraction of nominal rotor lift share
that the rotor has to produce in hover to overcome vertical down-load due to
the rotor wake impinging on the structure of the vehicle
2. cd0 is the average profile drag coefficient of the rotor blade airfoil section
3. induced_power_factor is the multiplier for ideal rotor power to account
for non-ideal losses
4. FM is the rotor hover figure of merit. If the hover figure of merit is given as
non-zero, then FM is used to estimate rotor shaft power in hover. If the value
of figure of merit is given as zero, then the profile drag coefficient and induced
power factor are used to estimate rotor hover power.

5. kint is the rotor power scaling factor to account for interference losses.
6. hover_thrust is a character input that ignores the calculated rotor lift share,
and distributes the hover thrust equally across all rotors in the system. This
input is primarily present for backward-compatibility, and should not be used
extensively except for debugging.
The empirical parameters used to model wing performance are the Oswald efficiency
factor oswald (quantifies additional induced drag for non-elliptical span loading)
and the mean profile drag coefficient cd0. The efficiencies of dedicated cruise propellers and prop-rotors in cruise is quantified by the Propeller parameter eta.
Finally, the scaling factor to estimate body drag from weight using a weight-drag
trendline is the parameter flat_plate_factor. If this input is zero, then the analysis uses a component drag build-up to estimate parasitic drag.

7.2.2.5

Geometry

Geometry:
fuselage_width:

1.00

# fuselage width in meters

fuselage_length: 7.00

# fuselage length in meters

clearance:

# rotor tip clearance / radius ratio

0.15

The three geometry parameters used for sizing are the fuselage width at the widest
point fuselage_width (meters), airframe length fuselage_length (meters) and
the rotor clearance parameters clearance. This final parameter is the in-plane

clearance between a rotor plane and other rotor planes/vehicle fuselage.
7.2.2.6

Technology factors

The term technology factor refers to scaling factors (“multipliers”) used to
increase or decrease component empty weights to account for improvements in
lightweight manufacturing. A sample dictionary is shown below.
Tech_factors:
Weight_scaling:

7.2.3

rotor:

1.0

# rotor blades and hub

wing:

0.9

empennage:

1.0

# tail surfaces/winglets

fuselage:

1.0

# airframe structure

landing_gear:

0.4

fuel_system:

1.0

# fuel pumps for engines

drive_system:

1.0

# transmission

# wings

flight_control: 1.0

anti_icing:

0.0

powerplant:

0.76

# motors and engines

fuel:

1.0

# fuel

battery:

1.0

# battery

Acquisition cost model
There are two types of costs associated with the rotorcraft that are modeled

in HYDRA: acquisition cost (component purchase) and operating cost. The dictio71

nary Acquisition contains three sub-dictionaries: Fixed_cost, Scaling_cost
and Beta_acq_factors. Each of these dictionaries is detailed below with examples.

7.2.3.1

Fixed acquisition cost

Acquisition:
Fixed_cost:
sense_avoid:

189817.0

# USD

avionics:

145807.0

# USD

interiors:

45152.0

testing:

6400.0

# USD, air conditioning/heater/HUD
# USD

This sub-dictionary contains inputs for the cost of vehicle components that do not
vary with vehicle size. These groups include the sense and avoid system, avionics,
interiors and component testing.
7.2.3.2

Scaling_cost

This sub-dictionary contains inputs for the cost of vehicle components that
scale with the mass of each component. Several components fall under this category,
particularly airframe, wings, landing gear, rotor blade structures, transmission lines
and motors. A sample dictionary is shown below.
Scaling_cost:
final_assem_line: 90.07

# USD/kg of take-off mass

BRS:

# USD/kg of take-off mass

fuselage:

10.885
2807.0

# USD/kg of fuselage weight

landing_gear:

1725.0

# USD/kg of landing gear strl. weight

wing_structure:

3779.1

# USD/kg of wing

motors:

2669.0

# USD/kg of drive motor mass

power_dist:

31.0

structural weight

# USD/kW of installed power

rotor_blade:

77605.0

# USD/sq.m of plan-form area

rotor_hub:

14133.0

# USD/kg: hub+collective actuator

wires:

20.3

# USD/kg of wire weight

tilt_actuator:

2868.0

# USD/kg of tilt actuator weight

wing_flap:

2619.0

# USD/kg of wing flap/aileron

7.2.3.3

Acquisition cost scaling factors

This dictionary deals with cost multipliers that account for reduction of component prices associated with mass-production. A value less than one indicates that
the component is less expensive when manufactured in bulk.
Beta_acq_factors:

# acquisition cost multipliers

sense_avoid:

0.5

avionics:

0.75

interiors:

1.0

testing:

1.0

# air conditioning/heater/HUD

final_assem_line: 0.5
BRS:

0.75

fuselage:

0.2

landing_gear:

0.2

wing_structure:

0.2

motors:

0.2

power_dist:

1.0

rotor_blade:

0.2

rotor_hub:

0.2

wires:

1.0

tilt_actuators:

0.75

wing_flaps:

0.75

7.2.4

Operations
Operating costs are of two types: annual and hourly operating costs. These

two components of the operating cost model are specified as sub-dictionaries under
Operations. Additionally, the constants required to obtain battery life cycle costs
are also specified. Finally, vertiport details are also specified and the cost of an
eVTOL trip is compared to the cost of using a taxi for traveling the same distance.
Each of these sub-dictionaries are detailed below.

7.2.4.1

Annual costs

Operations:
Annual:
Flight_hours:

1500

# flight hours per year

Liability:

22000

# USD liability insurance per year

Inspection:

7700

# USD, per year

Insurance_percent: 4.5

# insurance, % of acquisition

Depreciation_percent: 10

# % of acquisition cost depr./year

Pilot:

280500

# USD, pilot cost to company/year

Training:

9900

# USD, pilot training/year

The number of flight hours per year (Flight_hours) is used to calculate the
equivalent cost per flight hour from the annual fixed costs incurred in ensuring vehicle airworthiness. The annual costs incurred are Liability, Inspection, insurance
and depreciation (specified as a percentage of acquisition cost, Insurance_percent
and Depreciation_percent respectively). For a piloted vehicle, additional costs
are incurred for pilot salary and overhead (Pilot) as well as continuous training
(Training).
7.2.4.2

Hourly costs

This dictionary specifies the maintenance and inspection costs associated with
operating an air vehicle. The three elements in this dictionary are
1. Frame inspection (Frame_maintenance): specified as a cost in currency per
flight hour
2. Rotor blades, collective actuator and hub inspection (Rotor_inspection):
specified as a cost in currency per flight hour per unit assembly
3. Electric motor inspection (Motor_inspection): specified as a cost in currency per flight hour per motor unit.

Hourly:

Frame_maintenance:

37.35

Rotor_inspection:

1.0

# $/flight hr/rotor

Motor_inspection:

0.625

# $/flight hr/rotor

7.2.4.3

# $/flight hr

Battery costs

This dictionary specifies the number of charge/discharge Cycles that a battery can withstand before its energy reduces to the design state of health specified
in Sizing → Battery → Pack → SOH. Additionally, the purchase price of a battery pack as well as the battery recharge cost are specified as cost per unit rated
energy/cost per unit of energy (Cost_per_kwh, Electricity respectively).
Battery:
Cycles:

900

Cost_per_kwh:

180.0

Electricity:

7.2.4.4

# battery cost/rated energy, $/kWh

0.20

# electricity/unit energy, $/kWh

Vertiport

The relevant operational details at the vertiport are the landing tariffs (Landing_fees)
per touchdown, the distance from the vertiport to the final passenger destination
(Ground_distance in km) and the additional time spent in commuting to and
from the vertiport changing modes of transport (Padding_time).
Vertiport:
Landing_fees:

20.0

# landing fee per flight, USD

Padding_time:

26.0

# min, curb -> UAM + UAM -> curb

Ground_distance:

7.2.4.5

2.0

# last leg distance in km

Taxi details

The details of a taxi that can compete with a short-range aircraft are the
tariff per unit distance traveled (Distance_rate in currency per km), a time tariff
(Time_rate in currency per minute) and the additional time required to change
from another mode of transport to the taxi (Padding_time, minutes).
Taxi:
Distance_rate:

0.55

# Taxi price in USD per km

Time_rate:

0.36

# USD/minute of taxi ride

Padding_time:

7.2.5

15.0

# airport gate to curb, minutes

Redundant systems
The dictionary Redundancies specifies components that feature doubly or

triply redundant backups for flight controls, power cables and avionics. The redundancy factors are used to proportionally increase the component empty weights and
associated group costs.
Redundancies:
wing_flap:

1.0

tilt_actuator:

2.0

wires:

1.0

avionics:

1.0

Output files
This section of the documentation details the output file generated at the

end of sizing. The file pattern is log.yaml, where is an integer
representing a unique design ID number. The output is in plain text formatted as
a YAML file, similar to the input files. These files can be read an automatically
converted to Python dictionaries using the pyyaml package. All outputs are stored
under the outputs/log/ subdirectory in the run folder.

8.1

log.yaml
An example output log file is detailed dictionary-by-dictionary below, and the

relevant outputs are explained.

8.1.1

vehicle summary

# --------------------------------------------------# Mission and Vehicle Log
# --------------------------------------------------vehicle:
aircraftID:

take_off_mass:

1734.67 # [kg]

power_installed:

963.0 # [kW]

Cruise_LbyD:

11.80 #

The vehicle dictionary contains four high-level vehicle metrics. The aircraftID is
78

an outdated output, that is a copy of the input value given in input.yaml. The
other metrics given in this dictionary are the take-off mass in kg, sum of maximum
rated motor power values in kiloWatts and the vehicle lift-to-drag ratio in the cruise
sizing segment.
8.1.2

Rotor
The Rotor dictionary provides details of the rotor geometry and performance

in the hover sizing segment. Each sub-dictionary under the rotor dictionary corresponds to a unique rotor group. For each rotor group, the following outputs are
specified:
1. nrotor: number of rotors of this type in the vehicle
2. nblade: number of blades per rotor in this rotor type
3. disk_loading: rotor hover disk loading in pounds per square foot
4. aspect_ratio: blade aspect ratio (radius to chord ratio)
5. radius: rotor radius in meters
6. chord: mean rotor blade chord in meters
7. tip_speed: rotor hover tip speed in m/s
8. hover_FM: rotor figure of merit in the hover sizing segment
9. cruise_rpm_ratio: rotor cruise RPM divided by rotor hover RPM
10. eta_xmsn: transmission efficiency, 0 to 1
79

11. solidity: rotor geometric solidity
12. cd0: rotor blade airfoil drag coefficient at zero lift
13. ipf : rotor induced power factor in hover (non-ideal losses)
14. hvr_dwld: hover download divided by rotor lift share
15. hvr_ct_sigma: rotor blade loading in hover sizing segment
16. prop_eta: prop-rotor efficiency in cruise sizing segment
Rotor:
set0:
nrotor:

nblade:

disk_loading:

16.76 # [lb/ft2]

aspect_ratio:

5.86

radius:

0.93 # [m]

chord:

0.158 # [m]

tip_speed:

170.0 # [m/s]

hover_FM:

0.750

cruise_rpm_ratio: 0.500
eta_xmsn:

1.000

solidity:

0.16299

cd0:

0.012

ipf:

1.234

hvr_dwld:

0.015

8.1.3

hvr_ct_sigma:

0.139

prop_eta:

0.850

Wings
This dictionary contains details of the wing geometry and operating condition

in the cruise sizing segment. If multiple wing groups are present in the system, then
details of each wing group are listed as sub-dictionaries. For each wing group, the
following details are written:
1. nwing: the number of fixed wings of this type present in the vehicle.
2. span: the tip-to-tip dimension in meters
3. chord: the average wing chord in meters
4. structure_wt: the weight of the structure for one wing
5. wires_wt: the weight of wires running along one wing
6. aspect_ratio: the wing aspect ratio
7. oswald: the wing Oswald efficiency
8. cd0: the wing profile drag coefficient
9. cl: the operating lift coefficient for the cruise sizing segment
10. lift_fraction: lift fraction for this wing group in the cruise sizing segment
11. rotors_per_wing: the number of rotors mounted along a wing of this group
81

12. rotor_group_id: the group identifier for rotors mounted on this wing

Wings:
set0:
nwing:

span:

11.086 # [m]

chord:

2.217 # [m]

structure_wt:

117.303 # [kg, each]

wires_wt:

66.506 # [kg, each]

aspect_ratio:

5.000

oswald:

0.800

cd0:

0.014

cl:

0.400

lift_fraction:

0.900

rotors_per_wing:

rotor_group_id:

set1:
nwing:

span:

4.674 # [m]

... (pattern repeats)
...

8.1.4

Costs
The costs dictionary contains a breakdown of the vehicle acquisition cost and

operating cost per flight hour, as well as the results of comparisons with a ground
taxi. The individual sub-dictionaries are detailed below.

8.1.4.1

Acquisition cost breakdown

The first row Frame_acquisition is the acquisition cost of the aircraft in
millions of currency. The following dictionary shows two values per line: the first
value is the cost of the component in currency, and the second column shows the
fraction of the component’s acquisition cost as a percentage of the total acquisition
cost.
Costs:
Frame_acquisition: [0.779632] # [Millions of USD]
acquisition_cost_breakdown:
BRS

: [

14161.395 , 1.816] # [USD, % acquisition cost]

avionics

: [

109355.250 , 14.027] # [USD, % acquisition cost]

final_assem_line: [

42876.657 , 5.500] # [USD, % acquisition cost]

fuselage

: [

47190.123 , 6.053] # [USD, % acquisition cost]

interiors

: [

45152.000 , 5.791] # [USD, % acquisition cost]

landing_gear

: [

20874.300 , 2.677] # [USD, % acquisition cost]

motors

: [

117455.191 , 15.065] # [USD, % acquisition cost]

power_dist

: [

29854.461 , 3.829] # [USD, % acquisition cost]

rotor_blade

: [

54432.887 , 6.982] # [USD, % acquisition cost]

rotor_hub

: [

20923.226 , 2.684] # [USD, % acquisition cost]

sense_avoid

: [

94908.500 , 12.174] # [USD, % acquisition cost]

testing

: [

6400.000 , 0.821] # [USD, % acquisition cost]

tilt_actuators : [

37893.206 , 4.860] # [USD, % acquisition cost]

wing_flaps

29202.352 , 3.746] # [USD, % acquisition cost]

: [

wing_structure : [
wires

8.1.4.2

: [

106832.064 , 13.703] # [USD, % acquisition cost]
2120.209 , 0.272] # [USD, % acquisition cost]

Annual operating costs

This dictionary details the breakdown of annual operating costs for maintaining airworthiness. The field Fixed_operating_costs shows the aggregated
annual costs in currency. The fixed cost breakdown dictionary is organized in a
manner similar to the previous section: the first column shows the cost in currency,
and the second column shows the cost as a percentage of the annual cost.
Fixed_operating_costs: [142746.614190] # [USD]
fixed_cost_breakdown:
depreciation

: [

77963.182

, 54.616] # [USD, % fixed cost]

inspection

: [

7700.000

, 5.394] # [USD, % fixed cost]

insurance

: [

35083.432

, 24.577] # [USD, % fixed cost]

liability

: [

22000.000

, 15.412] # [USD, % fixed cost]

8.1.4.3

Variable operating costs

This section details the costs that depend on the number of flight hours that
the vehicle is operated for. The field Variable_operating_costs details the currency spent per flight hour in operating costs due to maintenance, energy usage
and inspections/cleaning. The variable operating costs are broken down into the
individual cost elements in the variable_cost_breakdown dictionary. The first
number in the two-column rows is the cost in currency per flight hour, and the
second number is the cost of that contributing element expressed as a percentage of
the Variable_operating_costs field.
Variable_operating_costs: [290.210] # [USD/hr]
variable_cost_breakdown:
battery_use

: [

51.327 , 17.686] # [USD/hr, % variable cost]

electricity

: [

31.895 , 10.990] # [USD/hr, % variable cost]

fixed_annual

: [

95.164 , 32.792] # [USD/hr, % variable cost]

frame_overhaul : [

37.350 , 12.870] # [USD/hr, % variable cost]

landing_fees

: [

61.474 , 21.183] # [USD/hr, % variable cost]

vpf_overhaul

: [

13.000 , 4.480] # [USD/hr, % variable cost]

UAM_time:

[

62.589] # [minutes ]

Taxi_time:

[

80.261] # [minutes ]

UAM_trip_cost:

[

101.662] # [USD

]

Taxi_trip_cost:

[

50.994] # [USD

]

Time_value:

[

2.867] # [$/min saved]

The last five fields are miscellaneous data that compare the performance and
cost of an eVTOL with a ground taxi. UAM_time is the time taken to travel
from an airport gate to a vertiport, fly to another vertiport and finally travel the
last leg by ground taxi (i.e., door-to-door time from airport to final destination
through an “air taxi”). The field Taxi_time is the door-to-door time from airport
to final destination using ground transport only. UAM_trip_cost is the total
cost of operating a combined air taxi and ground taxi for the final leg, and the
corresponding cost for the ground taxi-only option is Taxi_time_cost. The time
value is defined as the price difference between the two transport options, divided
by the time difference, or time value.

8.1.5

Weight breakdown
This dictionary details the breakdown of vehicle weights. Three main weight

categories are listed: battery (and/or fuel), payload and empty mass. For rows
with two columns, the first column is the component mass in kg, and the second
column is the mass of the component expressed as a percentage of take-off mass.
For rows with a single column, the number corresponds to a component’s mass in
kg.
For the empty weight dictionary, each components is listed under subdictionaries. If the empty weight group is a dictionary with additional breakdowns
within the component, those details are also printed, along with a field called total
- the accumulated mass of components within that group. These breakdowns are
plotted in pie charts by the postprocessing script piethon.py.
86

Weights:
empty_weight:
total:

[ 952.1

, 54.9] # [kg, %GTOW]

alighting_gear :
total

: [ 60.5

fairing

: [ 26.0] # [kg]

structure

: [ 34.5] # [kg]

3.5] # [kg, % GTOW]

avionics

: [ 79.2

4.6] # [kg, %GTOW]

common_equip

: [ 24.0

1.4] # [kg, %GTOW]

emergency_sys : [ 40.4

2.3] # [kg, %GTOW]

1.4] # [kg, % GTOW]

empennage

total

: [ 23.9

vtail

: [ 23.9] # [kg]

fuselage

total

: [ 84.1

bulkhead

: [ 12.4] # [kg]

canopy

: [ 12.2] # [kg]

keel

: [ 14.9] # [kg]

skin

: [ 44.6] # [kg]

powerplant
total

4.8] # [kg, % GTOW]

:
: [ 220.0

, 12.7] # [kg, % GTOW]

motor_group0 : [ 220.0] # [kg]
rotor
total

:
: [ 143.6

8.3] # [kg, % GTOW]

group0actuatr: [ 26.9] # [kg]
group0blades : [ 73.7] # [kg]
group0hub
wing

: [ 43.0] # [kg]
:

total

: [ 171.9

actuators

: [ 14.9] # [kg]

mounts

: [ 22.0] # [kg]

structure

: [ 117.4] # [kg]

tilters

: [ 17.6] # [kg]

wires
total

9.9] # [kg, % GTOW]

:
: [ 104.4

6.0] # [kg, % GTOW]

power_wire : [ 74.3] # [kg]
signal_wire : [ 30.1] # [kg]
battery:

[462.58

, 26.7] # [kg]

payload:

[320.02

, 18.4] # [kg]

8.1.6

Volumes
The volume output section is under development, and additional fields will be

introduced in future versions of HYDRA. At present, the dictionary contains:
Volumes:
fuselage_width:
passenger_count:
battery_volume:

1.00 # [m]
0 # [people]
0.439 # [cu.m]

This dictionary outputs the fuselage width (specified in defaults.yaml) in meters,
number of passengers (specified in input.yaml) and the calculated battery volume
in cubic meters.

8.1.7

Parasitic drag
This dictionary details the vehicle flat plate area (flat_plate_area) in square

meters. If the (Empirical → Aerodynamics → Body → flat_plate_factor input in defaults.yaml is set to zero, the component drag build-up for the vehicle
parasitic drag is also printed in a sub-dictionary, flat_plate_breakdown. The
entries in this sub-dictionary are the parasitic drag of each component expressed as
a percentage of the total flat plate area.
Parasitic_drag:
flat_plate_area:

0.422 # [sq.m]

flat_plate_breakdown:
LG

: [ 41.0] # [%]

base

: [ 7.0] # [%]

fus

: [ 18.9] # [%]

prot

: [ 9.1] # [%]

spin

: [ 20.1] # [%]

: [ 3.8] # [%]

8.1.8

Mission details
This dictionary provides relevant details for the vehicle performance during

various mission segments. The field total_energy is the energy in kWh required
to complete the mission, which has nsegments segments. The segment types are
given in the list flight_mode, with the segment altitudes given in meters by the
fields start_alt and end_alt. The variable delta_temp_ISA is the temperature offset at sea level for the sizing mission relative to the temperature in the
International Standard Atmosphere model. The segment rate of climb is specified
in feet per minute, while cruise speed is specified in knots. Segment duration is
specified by the field time, and rotor power required for each segment is listed
in kilowatts. The corresponding battery power draw is also listed in kW, and
the battery C-rating is listed in 1/hr. The cell temperature (if the model is
used in sizing) is shown at the end of each segment in deg C. Ambient density is
specified in kg/cu.m. The vehicle mass at the beginning of each segment is listed in
segment_mass. The variable segment_type is a character string; ‘all’ indicates
the segment is used for sizing and regular operations for operating cost evaluation;
‘reserve’ indicates the segment is used for sizing only, but not for regular mission
operating cost. The ground distance covered by the vehicle in kilometers is output
in the field segment_distance.
Mission:
total_energy:

67.07 # [kW-hr]

nsegments:

flight_mode:

[’hover

’,’cruise ’,’cruise ’,’hover ’]

start_alt:

[

0 ,

0 ] #[m]

end_alt:

[

0 ,

0 ] #[m]

delta_temp_ISA:

[

0.00 ,

0.00 ] #[C]

rate_of_climb:

[

0 ,

0] #[ft/min]

cruise_speed:

[

0.00 ,

98.00 ,

0.00 ] #[knots]

time:

[

1.50 ,

16.53 ,

4.96 ,

rotor_power_reqd: [

486.76 ,

123.49 ,

486.76 ] #[kW]

battery_power_draw: [

540.84 ,

145.28 ,

540.84 ] #[kW]

[

4.96 ,

1.33 ,

4.96 ] #[1/hr]

cell temperature: [

0.00 ,

0.00 ] #[deg C]

C-rating:

density:

[

segment_mass:

[

segment_type:

[’all

segment_distance: [

8.1.9

1.226 ,
2000.9 ,

’,’all
0.00,

1.226 ,
2000.9 ,

1.50 ] #[min]

1.226] #[kg/cu.m]
2000.9 ] #[kg]

’,’reserve ’,’all
50.00,

15.00,

’]
0.00]

Battery details
This dictionary is used to output the details pertaining to the battery. The

rated_capacity is the rated energy in kWh of all vehicle battery packs. The
state_of_health is the multiplier for the battery pack rated energy; the product
of these two numbers is the maximum energy that the pack can store at the pack’s
end-of-life after several charge/discharge cycles. The parameter depth_discharge
is a fraction ranging from 0 to 1, which indicates the smallest energy fraction that

the battery can be discharged to, without damaging the cells. In this example, the
battery rated capacity before cycling is 109.07 kWh, and the design state of health
is 0.8, i.e., at end of life, the maximum energy that can be stored in the battery
is 0.8 × 109.07 = 87.25 kWh. The minimum depth of discharge is 0.075, i.e., the
battery can be discharged until 0.075 × 109.07 = 8.18 kWh of energy is remaining,
without permanently damaging the cells.
Battery:
rated_capacity:

109.07

state_of_health:

0.800

depth_discharge:

0.075

8.2

log.txt
The other output generated by HYDRA is the final converged design and its

details stored as a pickle module. The various postprocessing scripts in HYDRA load
the vehicle class in its converged state for various sensitivity studies and to extract
details. To load the file corresponding to design ID = 0, use this template:
import pickle
fname = ‘outputs/log/log0.yaml’
with open(fname,‘rb’) as f:
design = pickle.load(f )
The variable design is an instance of the hydraInterface class with all methods
and variables required to perform sizing.

A high-level summary of all designs is provided in summary.dat. The first column is the unique design identifier; the

summary.dat

...

1734.67

1872.70

2049.93

1607.40

1702.75

1826.42

Weight (kg)

Design ID #

1143.83

967.71

810.49

1411.57

1171.23

963.05

497.869

441.230

399.572

609.178

525.369

462.579

1008.55

941.50

887.79

1120.75

1027.33

952.07

Power (kW) Fuel/Batt (kg) Empty Wt (kg)

is invalid, while 1 indicates the design satisfies all the constraints.

320.00

320.02

320.04

320.00

320.02

299.42785

285.65621

275.44891

325.62067

305.44722

290.21050

Payload (kg) Op Cost ($/hr) Valid design

seventh column is the vehicle operating cost in currency per flight hour; the final column is an integer - 0 indicates the design

configuration fuel and battery (kg); the fifth column is the empty mass in kg; the sixth column is the payload mass in kg; the

second column is the take-off mass in kg, the third column is the installed power in kW, the fourth column is the mass sum of

8.3

Running HYDRA
1. Create a run directory under cases/
2. Create input files input.yaml, defaults.yaml. If multiple input values of
each design parameter are specified, the analysis generates all possible combinations of all specified design parameters, and launches multiple sizing operations.
3. Run sizing on a parametric sweep: copy xrun.py from a sample run directory
to the current run folder, then use the following command:

python3 xrun.py (serial mode)
mpirun -n 8 python3 xrun.py (parallel mode, 8 threads)

The various cases are automatically subdivided by HYDRA , analyzed and the
summaries are collated in the summary.dat output file.
4. Sort valid designs: use the routine process_data.py routine:

python3 process_data.py

This command will generate a file called best_design.dat in the same format
as summary.dat, with valid designs ranked in order of ascending cost, takeoff weight, installed power, or empty weight depending on the user-specified
choice in process_data.py.

Postprocessing
Several postprocessing scripts are provided in the Postprocessing/ folder in

the sample run directories. Copy these scripts to the run directory with results to
postprocess. Examples of these commands and sample outputs are shown below:
1. Pie chart generator: the script piethon.py generates pie charts for the
breakdown of empty weight, annual operating costs, hourly operating costs
and parasitic drag. Invoke it using the command
python3 Postprocessing/piethon.py
Here, is the integer unique identifier for a design. For example, the
command python3 Postprocessing/piethon.py 10 generates pie charts for
a vehicle with the design ID 10. The relevant images are compiled into a PDF
called costs_design_10.pdf for the sample input. The individual pie charts
are shown in Fig. 23
2. Battery charge profile: HYDRA features the ability to visualize the battery
state of charge as a function of time along the mission profile. This postprocessor can be invoked with the command

python3 Postprocessing/battery_draw.py 10

Here, 10 is the unique design ID for the sized vehicle that needs to be postprocessed. The resulting plot is stored in a PDF called battery_design_10.pdf,
and shown in Fig. 24. The first subplot shows the estimated vehicle range for
95

(a) Acquisition cost

(b) Annual cost

(d) Parasitic drag breakdown

(e) Vehicle weight

(f) Empty weight

Figure 23: Pie charts generated by piethon.py postprocessor for a single design

a “perfect battery” starting the mission at its theoretical maximum state of
charge. The second subplot shows the same “ideal battery” charge, along with
the estimated battery state of charge used in HYDRA for sizing the vehicle.
3. Vehicle performance: To automatically generate the (approximate) power
curve, payload-range and payload-endurance trade offs, HYDRA features a performance postprocessor that can be invoked as follows:

python3 Postprocessing/performance.py 28

Here, 28 is the unique design identifier that will be analyzed at various airspeeds and longitudinal trim will be performed. The outputs from the postprocessor are shown in the following pages.

Battery power required (kW)

500

400
with payload
no payload
6C

300

200

100

20
30
40
Cruise speed (m/s)

100
with payload
no payload

Wing tilt (deg)

20
30
40
Cruise speed (m/s)

Lift to Drag ratio WV/Protor

10
with payload
no payload
8

20
30
40
Cruise speed (m/s)

500

Payload-Endurance in hover, fixed cruise distance
Ideal battery
Vahana assumptions

Payload (kg)

400

300

200

100

6
8
Time in hover (min)

Payload-Endurance in Cruise

500

50 m/s
43 m/s
400

58 m/s

Payload (kg)

50 m/s, ideal battery
300

200

100

30
40
Time in cruise (min)

Payload-Range [3 min hover]

500

Payload (kg)

400

300

200
50 m/s
43 m/s

100

58 m/s
50 m/s, ideal battery
0

60
80
100
120
Cruise range (km)

140

160

Battery charge (%)
Battery charge (%)

Perfect battery assumptions

100
75

range

= 97.
4 km

25
0

15
20
25
Mission time (min)

Vahana battery assumptions

100
75

range

= 50.
0 km

= 97.
4 km
15.0 k
m res
erve

25
0

15
20
25
Mission time (min)

Figure 24: Battery state of charge along mission profile

104

4. Sensitivity analysis: single and two-perturbation sensitivity studies can be
launched using the following script:

python3 Postprocessing/sensitivity_wrapper.py 32

Here, 32 is the unique identifier for a converged vehicle design. The resulting
plots from the sensitivity of the converged design to perturbations in target
airspeed (for the same mission range) are shown in the first two plots. The next
four plots show the effect of changing the cruise wing loading and aspect ratio
on vehicle take-off mass, installed power, battery power and operating cost as
contour plots, with carpet axes. The baseline design point is marked as a circle,
and invalid designs are marked with a red cross (×) inside a gray circle ◦. The
final two plots show the effect of changing the rotor hover blade loading and
hover tip speed on take-off mass, installed power, battery mass and operating
cost. These results are stored in a PDF named sensitivities_design_32.pdf.

105

Effect of cruise airspeed
design point
1850

800

1800
1750
1700

600

1650
500

1600
1550

400
70

90
100
110
Airspeed (knots)

120

Power (kW)

Mass (kg)

700

Effect of cruise airspeed
design point
550

235

525
Battery (kg)

500

225

475

220

450
215
425
210
400
205
375
200
70

90
100
110
Airspeed (knots)

120

Cost (USD/hr)

230

wing (group 0) design variables
1600

Wing loading (N/m2 )

2175.0
2101.2

1400
CL =0.8

2027.5

1200
1000

Mass (kg)

1953.8
CL =0.6

1880.0
800
1806.2

CL =0.4

600

1732.5
400
AR

200
10

1658.8

CL =0.2
AR
=1
=1
0
2

15
20
Wing span (m)

1585.0

wing (group 0) design variables
1600

Wing loading (N/m2 )

752
709

1400
CL =0.8

666

1200
1000

Power (kW)

623
CL =0.6

580
800
537

CL =0.4

600

494
400
AR

200
10

451

CL =0.2
A
=1 R=1
0
2

15
20
Wing span (m)

408

wing (group 0) design variables
1600

Wing loading (N/m2 )

573.0
551.9

1400
CL =0.8

530.8

1200
1000

Battery (kg)

509.6
CL =0.6

488.5
800
467.4

CL =0.4

600

446.2
400
AR

200
10

425.1

CL =0.2
A
=1 R=1
0
2

15
20
Wing span (m)

404.0

wing (group 0) design variables
1600

Wing loading (N/m2 )

284.00
274.38

1400
CL =0.8

264.75

1200
1000

(USD/hr)

255.12
CL =0.6

245.50
800
235.88

CL =0.4

600

226.25
400
AR

200
10

216.62

CL =0.2
AR
AR
=8
=1
=1
0
2

15
20
Wing span (m)

207.00

rotor (group 0) design variables
0.225

Mass (kg)
1972.0

CT /σ=0.08

1925.6
0.200

140 m/s

CT /σ=0.09

1879.2

CT /σ=0.1

Solidity

0.175

1832.9

CT /σ=0.11
160 m/s

0.150

CT /σ=0.12

1786.5

CT /σ=0.13

0.125

1740.1

180 m/s

0.100

1693.8

0.075

1647.4
7.70

7.75 7.80 7.85 7.90 7.95
Disk loading (lb/sq.ft)

8.00

1601.0

rotor (group 0) design variables
0.225

Power (kW)
670.0

CT /σ=0.08

655.5
0.200

140 m/s

CT /σ=0.09

641.0

CT /σ=0.1

Solidity

0.175

626.5

CT /σ=0.11
160 m/s

0.150

CT /σ=0.12

612.0

CT /σ=0.13

0.125

597.5

180 m/s

0.100

583.0

0.075

568.5
7.7

7.8
7.9
Disk loading (lb/sq.ft)

8.0

554.0

rotor (group 0) design variables
0.225

Battery (kg)
496.00

CT /σ=0.08

486.88
0.200

140 m/s

CT /σ=0.09

477.75

CT /σ=0.1

Solidity

0.175

468.62

CT /σ=0.11
160 m/s

0.150

CT /σ=0.12

459.50

CT /σ=0.13

0.125

450.38

180 m/s

0.100

441.25

0.075

432.12
7.7

7.8
7.9
Disk loading (lb/sq.ft)

8.0

423.00

rotor (group 0) design variables
0.225

(USD/hr)
243.00

CT /σ=0.08

238.75
0.200

140 m/s

CT /σ=0.09

234.50

CT /σ=0.1

Solidity

0.175

230.25

CT /σ=0.11
160 m/s

0.150

CT /σ=0.12

226.00

CT /σ=0.13

0.125

221.75

180 m/s

0.100

217.50

0.075

213.25
7.70

7.75 7.80 7.85 7.90 7.95
Disk loading (lb/sq.ft)

8.00

209.00

5. Optimization: After running xrun.py, use the following commands to invoke sizing optimization:

python3 process_data.py

#⇒ filter out invalid designs, rank

python3 Postprocessing/optimize_driver.py

# serial mode

mpirun -n 8 python3 Postprocessing/optimize_driver.py # parallel

This command launches two types of optimization: (a) gradient-based optimization (several threads), with several initial conditions based on valid
designs identified by the process_data.py command, and (b) differential
evolution (first thread), with a latin-hypercube initial sampling. The optimized designs (generated by both methods) are aggregated and checked for
uniqueness and validity. These unique designs are written to the file optim_summary.dat, with the syntax identical to summary.dat and best_design.dat.
Additionally, the file optim_dvars_summary.dat shows the values of the
design variables that yield the optimum design. After optimization is complete,
the outputs/log/ folder will feature files with the pattern optim_log_.yaml
and optim_log_.txt, with patterns similar to the regular output
files of the same format. The process_data.py command can be called with
an additional argument ‘optim’ as follows:

python3 process_data.py optim

This command sorts the various optimized unique designs in optim_summary.dat
from best to worst and writes the results in a file called optim_ranked.dat.
116

Cantilever beam dynamics
Consider an eVTOL wing with multiple electric motors and rotors mounted

along the spar, shown in Fig. 25. The wing structure is idealized as a cantilever
beam with non-structural lumped masses placed along the span, shown in Fig. 26.

Figure 25: Rotor layout for an example eVTOL wing

Figure 26: Idealization of eVTOL wing structure

To expand the generality of the analysis, consider a tapered circular spar
running along the length of the wing. The cross-section of the spar is shown in
117

Figure 27: Linearly tapered circular spar

Fig. 27. The tube thickness is equal to t, and is uniform along the spar length. The
radius of the circular cross-section varies from r1 at the root of the beam to r2 at
the tip. The mass per unit span and bending stiffness of the spar is given by
m(x)

2πρr(x)t

EIyy (x)

Eπr(x)3 t

The first bending natural frequency is estimated using a Rayleigh-Ritz approximation, with a mode shape set by the static deflection of the cantilever due to a
tip-load, i.e.,
w00 (x)

P (L − x)

(31)

Integrate twice along the span and apply the cantilever boundary condition to obtain
the deflected bending slope as
0

w (x)

P
a2
a1
+
+ a0
Eπt r(x)2
r(x)
118

(32)

The constants are
a2

L
r1
−
0
2r
2r0 2
1
− 02
r
L
1
−
2
0
0
2r r1
2r 2 r1
−

Integrate the bending slope along the span to obtain the deflected mode shape as
w(x)

bm
P
b0 + b1 x +
+ bl loge r(x)
Eπt
r(x)

(33)

The constants are

A.1

−

= a0

−

a1
r0

a2
a1
−
loge (r1 )
r1 r 0
r0

a2
r0

Potential energy
The maximum potential energy is given by
U

1
2

Z
0

P 2 (L − x)2
dx
EIyy (x)

Substitute for the bending stiffness to obtain
U

1 P2
[A + B + C](λ)
2 Eπt

The term λ is the spar taper ratio, given by
λ

=
119

r2
r1

(34)

The sum A + B + C is well-represented by a cubic polynomial in λ as
A+B+C

(1.6261 − 0.4826λ + 2.1197λ2 − 0.5957λ3 )

≈

1
K3

The constant K is the inverse of the spar aspect ratio, given by
K
Here,

A.2

t
c

2( ct )
ARwing

(35)

is the wing thickness to chord ratio, and ARwing is the wing aspect ratio.

Kinetic energy
The maximum kinetic energy of the beam has contributions from three types

of masses:
1. Structural masses: This term deals with the kinetic energy of the spar
structure. This contribution to kinetic energy is
Z
KEs

=
0

1
2πr(x)tρ w(x)2 ωn2 dx
2

P2
ρω 2 (RHS)
E 2 πt n

The term RHS is a function of the taper ratio λ, length L and spar taper ratio
inverse K only. Further, the dependence on wing taper λ can be approximated
using a cubic polynomial in λ. Thus, the kinetic energy coefficient RHS is
approximated as
RHS

≈

L2
(0.04823 + 0.269λ + 0.15178λ2 + 0.36917λ3 )
K5

2. Non-structural distributed masses: This term deals with the kinetic energy due to the skin and other components (e.g., wires) that do not contribute
120

significantly to bending stiffness. The kinetic energy term is
L

Z
KENS

=
0

1
mNS (x) w(x)2 ωn2 dx
2

The non-structural mass due to wing skin is given by
mNS (x)
The term

MNS
A

2MNS
r(x)
A( ct )

is the non-structural mass per unit plan-form area of the skin.

Define an intermediate quantity β given by
β

MNS
A( ct )

The expression for kinetic energy of non-structural masses simplifies to
KENS

P 2 ωn2
RHS
E 2 π 2 t2

3. Non-structural lumped mass: This term refers to the kinetic energy of
the electric motor/speed controller unit, rotor hubs and rotor blades. These
discrete lumped masses are mounted along the wing spar, and the kinetic
energy of these masses is given by
KElump

ΣNi M

1
Mi w(xi )2
2

P 2 ωn2
∆RHS
E 2 π 2 t2

The coefficient ∆RHS is
∆RHS

A.3

NM Mi
i
2

bm
b0 + b1 xi + bl loge r(xi ) +
r(xi )

Frequency tuning
The goal is to determine the spar mass by setting a target first natural fre-

quency ωn for the cantilever beam with distributed and lumped non-structural
121

masses. Equating the maximum total kinetic energy and maximum potential energy
for the first bending mode, we obtain
1 P2
LHS
2 E 2 πt

ωn2

P2
P2
P2
(RHS)
+
β(RHS)
+
∆RHS
E 2t
E 2 π 2 t2
E 2 π 2 t2

(36)

Solve for spar thickness as

Eπ
LHS − ρπRHS
2ωn2

−1
[β(RHS) + ∆RHS]

The total spar mass is therefore
Mspar

πρ t(1 + λ)r1

(37)

For validation of the Rayleigh-Ritz solution, several cases were evaluated with
and without lumped non-structural masses.

A.4

Validation

A.4.1

Case 1: cantilever beam

Consider a cantilever beam with a hollow circular cross-section of constant wall
thickness, and the cross-section radius is linearly tapered from root to tip, with a
taper ratio of λ varying from 0.5 to 1.2. The beam length is 2.9 m, mean tube radius
is 0.1411 m. The first bending natural frequency predictions from the Rayleigh-Ritz
approximation are compared against a beam Finite Element Method analysis. These
two frequencies are plotted in Fig. 28. The Rayleigh-Ritz approximation exhibits
about 2% over-prediction, but otherwise captures the trends accurately. In this
example, no non-structural masses were considered.
122

(a) Natural frequency vs. taper ratio

(b) Rayleigh-Ritz vs. FEM

Figure 28: Natural frequency: Rayleigh-Ritz vs. FEM predicted natural frequencies
for a tapered cantilever beam

(a) Natural frequency vs. taper ratio

(b) Rayleigh-Ritz vs. FEM

Figure 29: Natural frequency: Rayleigh-Ritz vs. FEM for a tapered cantilever beam
with distributed non-structural masses

123

(a) Layout of eVTOL wing

(b) Rayleigh-Ritz vs. FEM

Figure 30: Natural frequency: Rayleigh-Ritz vs. FEM for an example eVTOL wing

A.4.2

Case 2: distributed non-structural mass

This case is representative of an aircraft half-wing with skin, and no lumped
masses. The non-structural masses are represented as a mass per unit area, i.e.,

M
A

kg/m2 . Three different values of the non-structural mass per unit wing area were
evaluated: 0, 2.0 and 4.9 kg/m2 . The resulting natural frequencies were calculated
from both Rayleigh-Ritz and FEM, and are plotted in Fig. 29. Excellent agreement
is obtained.

A.4.3

Case 3: half-wing with lumped masses

This case is representative of an eVTOL wing. The dimensions of the beam
are the same as in the previous examples, and the distributed skin mass per unit
area is 4.9 kg/m2 . Two lumped masses (21.3 kg, 27 kg) are placed along the beam
at 0.5L and L, respectively. The wing layout and natural frequencies are shown in
Fig. 30.
124

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.5
Linearized                      : No
Page Count                      : 128
Page Mode                       : UseOutlines
Author                          : 
Title                           : 
Subject                         : 
Creator                         : LaTeX with hyperref package
Producer                        : pdfTeX-1.40.19
Create Date                     : 2019:01:13 19:31:33-08:00
Modify Date                     : 2019:01:13 19:31:33-08:00
Trapped                         : False
PTEX Fullbanner                 : This is pdfTeX, Version 3.14159265-2.6-1.40.19 (TeX Live 2018) kpathsea version 6.3.0

EXIF Metadata provided by EXIF.tools

Theory Manual

Navigation menu

Versions of this User Manual:

Views

Navigation