aviary_group.py

class aviary.core.aviary_group.AviaryGroup(verbosity=None, **kwargs)

Bases: Group

A standard OpenMDAO group where all elements of a given aviary aircraft design and mission are defined.

This includes pre_mission, mission, and post_mission analysis. This group also contains methods for loading data from .csv and phase_info files, setting initial values on the group, and connecting all the phases inside the mission analysis to each other.

Instantiating multiple AviaryGroups allows for analysis and optimization of multiple aircraft or one aircraft in multiple missions simultaneously.

__init__(verbosity=None, **kwargs)

Set the solvers to nonlinear and linear block Gauss–Seidel by default.

add_design_variables(problem_type: ProblemType = None, verbosity=None)

Adds design variables to the Aviary problem.

Depending on the mission model and problem type, different design variables and constraints are added.

If using the FLOPS model, a design variable is added for the gross mass of the aircraft, with a lower bound of 10 lbm and an upper bound of 900,000 lbm.

If using the GASP model, the following design variables are added depending on the mission type: - the initial thrust-to-weight ratio of the aircraft during ascent - the duration of the ascent phase - the time constant for the landing gear actuation - the time constant for the flaps actuation

In addition, two constraints are added for the GASP model: - the initial altitude of the aircraft with gear extended is constrained to be 50 ft - the initial altitude of the aircraft with flaps extended is constrained to be 400 ft

If solving a sizing problem, a design variable is added for the gross mass of the aircraft, and another for the gross mass of the aircraft computed during the mission. A constraint is also added to ensure that the residual range is zero.

If solving an OFF_DESIGN_MIN_FUEL problem, only a design variable for the gross mass of the aircraft computed during the mission is added. A constraint is also added to ensure that the residual range is zero.

In all cases, a design variable is added for the final cruise mass of the aircraft, with no upper bound, and a residual mass constraint is added to ensure that the mass balances.

add_fuel_reserve_component(post_mission=True, reserves_name='mission:total_reserve_fuel')

add_phases(parallel_phases=True, verbosity=None, comm=None)

Add the mission phases to the problem trajectory based on the user-specified phase_info dictionary.

Parameters:

• (bool (parallel_phases) – will be a ParallelGroup, otherwise it will be a standard OpenMDAO Group. Defaults to True.

• optional) (If True, the top-level container of all phases) – will be a ParallelGroup, otherwise it will be a standard OpenMDAO Group. Defaults to True.

Returns:

traj

Return type:

The Dymos Trajectory object containing the added mission phases.

add_post_mission_systems(verbosity=None)

Add post-mission systems to the aircraft model. This is akin to the pre-mission group or the “premission_systems”, but occurs after the mission in the execution order.

Depending on the mission model specified (FLOPS or GASP), this method adds various subsystems to the aircraft model. For the FLOPS mission model, a landing phase is added using the Landing class with the wing area and lift coefficient specified, and a takeoff constraints ExecComp is added to enforce mass, range, velocity, and altitude continuity between the takeoff and climb phases. The landing subsystem is promoted with aircraft and mission inputs and outputs as appropriate, while the takeoff constraints ExecComp is only promoted with mission inputs and outputs.

For the GASP mission model, four subsystems are added: a LandingSegment subsystem, an ExecComp to calculate the reserve fuel required, an ExecComp to calculate the overall fuel burn, and three ExecComps to calculate various mission objectives and constraints. All subsystems are promoted with aircraft and mission inputs and outputs as appropriate.

A user can override this with their own postmission systems.

add_pre_mission_systems(verbosity=None)

Add pre-mission systems to the Aviary group. These systems are executed before the mission.

Depending on the mission model specified (FLOPS or GASP), this method adds various subsystems to the aircraft model. For the FLOPS mission model, a takeoff phase is added using the Takeoff class with the number of engines and airport altitude specified. For the GASP mission model, three subsystems are added: a TaxiSegment subsystem, an ExecComp to calculate the time to initiate gear and flaps, and an ExecComp to calculate the speed at which to initiate rotation. All subsystems are promoted with aircraft and mission inputs and outputs as appropriate.

A user can override this method with their own pre-mission systems as desired.

check_and_preprocess_inputs(verbosity=None)

This method checks the user-supplied input values for any potential problems and preprocesses the inputs to prepare them for use in the Aviary problem.

configure()

Configure the Aviary group.

link_phases(verbosity=None, comm=None)

Link phases together after they’ve been added.

Based on which phases the user has selected, we might need special logic to do the Dymos linkages correctly. Some of those connections for the simple GASP and FLOPS mission are shown here.

load_external_subsystems(external_subsystems: list = [], verbosity=None)

Add external subsystems to the AviaryGroup.

Parameters:

• external_subsystems (list of SubsystemBuilders) – List of all external subsystems to be added.

• verbosity (int, Verbosity (optional)) – Sets the printout level for the entire off-design problem that is ran.

load_inputs(aircraft_data, phase_info=None, problem_configurator=None, phase_info_modifier=None, verbosity=None)

This method loads the aviary_values inputs and options that the user specifies. They could specify files to load and values to replace here as well. Phase info is also loaded if provided by the user. If phase_info is None, the appropriate default phase_info based on mission analysis method is used.

This method is not strictly necessary; a user could also supply an AviaryValues object and/or phase_info dict of their own.

set_initial_guesses(parent_prob=None, parent_prefix='', verbosity=None)

Call set_val on the trajectory for states and controls to seed the problem with reasonable initial guesses. This is especially important for collocation methods.

This method first identifies all phases in the trajectory then loops over each phase. Specific initial guesses are added depending on the phase and mission method. Cruise is treated as a special phase for GASP-based missions because it is an AnalyticPhase in Dymos. For this phase, we handle the initial guesses first separately and continue to the next phase after that. For other phases, we set the initial guesses for states and controls according to the information available in the ‘initial_guesses’ attribute of the phase.