Aerodynamics Subsystem

Aerodynamics Subsystem#

The built-in aerodynamics subsystem in Aviary offers multiple options for computing drag. Users can select from methods based on the FLOPS or GASP legacy codes. Choice of which legacy code’s routines to use is determined by the code_origin option provided when initializing a CoreAerodynamicsBuilder. When using Aviary’s Level 1 interface, the code origin for aerodynamics is automatically set to match with the mission method (height-energy is paired with FLOPS, and 2-degree-of-freedom is paired with GASP). Future updates to Aviary will allow for the user to specify aerodynamics code origin directly in the input file.

from aviary.api import CoreAerodynamicsBuilder, LegacyCode

aero_builder = CoreAerodynamicsBuilder(name='aero_example', code_origin=LegacyCode.FLOPS)

/usr/share/miniconda/envs/test/lib/python3.12/site-packages/pyoptsparse/pyOpt_MPI.py:68: UserWarning: mpi4py could not be imported. mpi4py is required to use the parallel gradient analysis and parallel objective analysis for non-gradient based optimizers. Continuing using a dummy MPI module from pyOptSparse.
  warnings.warn(warn)

Both FLOPS and GASP methods have only a single option for pre-mission components, so there are no user-configurable options when calling CoreAerodynamicsBuilder.build_pre_mission().

For mission analysis, a variety of methods are available to both legacy codes, each with unique options. This can be configured per-mission segment in a phase_info file, with relevant aerodynamics configurations placed inside <phase_name>['core_subsystems']. The following example would instruct Aviary to send the defined options to a subsystem named ‘aero_example’ when building the mission, if the dictionary is properly added to phase_info

from aviary.api import AviaryValues

# If you are using Aviary's interface to run analysis, this example dictionary must be
# place in phase_info, under the phase you want the arguments applied, like this:
# (<phase_name>[<subsystem_name>] = aerodynamic_args).

# The aerodynamics subsystem name must match what you provide here
aerodynamic_args = {'aero_example': {'method': 'computed', 'gamma': 1.35}}

# If you are manually building your subsystems, you can instead directly pass the
# arguments to the builder
input_variables = AviaryValues() # include your aircraft inputs here
mission_comp = aero_builder.build_mission(num_nodes=1,
                                          aviary_inputs=input_variables,
                                          kwargs=aerodynamic_args['aero_example'])

FLOPS Based#

The choice of using FLOPS based aerodynamics behavior is user specified per mission. Note, detailed wing weight input variables do not impact aerodynamic calculations.

The FLOPS aerodynamics pre-mission component performs calculations to determine the design Mach and lift coefficient of the aircraft.

The following input variables are required for the pre-mission calculations:

  • Aircraft.Wing.MAX_CAMBER_AT_70_SEMISPAN : Maximum camber at 70 percent semi-span, percent of local chord

  • Aircraft.Design.BASE_AREA : Aircraft base area (total exit cross-section area minus inlet capture areas for internally mounted engines)

  • Aircraft.Wing.AIRFOIL_TECHNOLOGY : Airfoil technology parameter. Limiting values are: 1.0 represents conventional technology wing (Default); 2.0 represents advanced technology wing

For mission analysis, FLOPS-based aerodynamics has several choices of method to determine the total lift and drag on the vehicle, listed below. The default is computed. If another method is desired, it should be specified in phase_info for each individual mission segment.

  • computed: uses regression-based techniques to estimate lift and drag

  • low_speed: for use in detailed takeoff analysis, and includes high-lift devices and considers angle-of-attack

  • tabular: allows the user to substitute the lift and drag coefficient calculations in computed with data tables

Computed Aerodynamics#

The FLOPS based aerodynamics subsystem uses a modified version of algorithms from the EDET (Empirical Drag Estimation Technique) program [1] to internally compute drag polars. FLOPS improvements to EDET as implemented in Aviary include smoothing of drag polars, more accurate Reynolds number calculations, and use of the Sommer and Short T’ method [2] for skin friction calculations.

Low Speed Aerodynamics#

This aerodynamics routine is designed for use with the height-energy detailed takeoff phase, which includes use of high-lift devices. This aerodynamics method uses angle of attack, which is a special case not present in other height-energy phases.

User Specified Tabular Drag Polars#

Third party drag polars can be specified by the user, either via a data file in Aviary data format or a NamedValues object. Two tables are required, one for lift-dependent drag, and another for zero-lift drag.

  • The lift-dependent drag coefficient table must include Mach number and lift coefficient as independent variables.

  • The zero-lift drag coefficient table must include altitude and Mach number as independent variables.

Tabular aerodynamics uses Aviary’s data_interpolator_builder interface. This component is unique as it requires two data tables to be provided. All configuration options, such as the choice to use a structured metamodel or training data, are applied to both tables.

GASP Based#

Using GASP Aerodynamics with the Height-Energy Equations of Motion (FLOPS Mission)#

You can also use GASP-based aero with the height-energy mission by using the solved_alpha method.

Gasp-based drag polars have 3 inputs: altitude, mach number, and angle of attack. Since the height-energy equations of motion do not incorporate angle of attack, solved_alpha creates an computational group with a solver that varies the angle of attack until the interpolated lift matches the weight force on the aircraft. The format for the table in the file is the same as for GASP-based aerodynamics used with the 2-DOF mission.

Externally Computed Polars#

Both FLOPS and GASP methods that use data tables support the use of training data, where the values for interpolation are provided by another openMDAO component via connections. An example problem using this method can be found here.