SkillAgentSearch skills...

OpenTurbofanArchitecting

Open-source turbofan architecting benchmark problem

Install / Use

/learn @jbussemaker/OpenTurbofanArchitecting
About this skill

Quality Score

0/100

Supported Platforms

Universal

README

DOI

Open Turbofan Architecting

OTA is an open-source system architecture optimization problem with the purpose of demonstrating the principle of system architecture optimization, and implementing a realistic problem for optimization algorithm benchmarking.

System architectures are defined by assigning components to functions, and by connecting components among each other. A system architecture design space can consist of multiple components able to fulfill a function, which gives architecting decisions and thereby defines the architecture design space. An architecture optimization problem gathers all these decisions (e.g. function assignment, component attributes, component connections) and formulates it as a formal optimization problem: in terms of design variables, objectives, and constraints.

The turbofan architecting problem has the goal of finding the best possible turbofan architecture according to one or more objectives: for example fuel burn, emissions, or weight. It is also possible to use multiple of these objectives at the same time when performing multi-objective optimization, with the result of finding a Pareto front of optimal architectures.

For evaluation of the turbofan architectures thermodynamic cycle, pyCycle is used. PyCycle is a modular engine cycle analysis and sizing framework based on OpenMDAO, a powerful Python-based Multidisciplinary Design Optimization (MDO) framework. For the other disciplines, empirical correlations from literature are used, whose equations can be found in the Python files.

OTA consists of two main packages:

  1. Evaluation: The engine architecture evaluator provides an interface for defining engine architectures and enables the evaluation of a given architecture for specific operating conditions using pyCycle.
  2. Architecting: The engine architecting framework provides a way to describe architectural choices and define an optimization problem, and a way to translate design vectors (as generated by an optimization algorithm) to engine architectures.

Citing

For the accompanying paper, please refer to: System Architecture Optimization: An Open Source Multidisciplinary Aircraft Jet Engine Architecting Problem

Please cite this paper if you are using this code in your work.

Installation

Clone the repository and install dependencies using pip from an environment with at least Python 3.6:

pip install .

Benchmark Problem

Two benchmark problems have been created: a simple architecting problem and a realistic architecting problem.

Design Choices

The implemented architecting choices and their design variable mappings can be found in the list below, in order of execution. The order of execution is important as some architecting choices are dependent on decisions made in previous architecting choices.

  1. The first architecting choice is the inclusion of a fan at the front of the engine. In case a fan is not included, the resulting engine architecture is a turbojet. Otherwise, the architecture is identified as a turbofan. For a turbofan architecture, two additional design variables are activated: the Bypass Ratio (BPR) and the Fan Pressure Ratio (FPR).
  2. If the result of the first architecting choice is to include a fan, the option arises to include a second fan at the front of the engine which rotates at the same speed but the opposite direction as the main fan. This concept is called a Counter-Rotating Turbofan (CRTF).
  3. Next, the number of shafts is decided: the engine architecture will have either one, two or three shafts. These can be referred to as the low-, intermediate- and high-pressure shafts. For each shaft, the RPM is also a design variable. Furthermore, the OPR of the complete engine needs to be specified, as well as the percentage of the Overall Pressure Ratio (OPR) that each compressor generates.
  4. To enable the fan to rotate at an optimal speed, a gearbox can be inserted between the low-pressure shaft and the fan shaft. This architecture is referred to as the Geared Turbofan (GTF). In case a gearbox is included, the gear ratio is a design variable.
  5. It is possible to include a second combustion chamber in the engine architecture, called an Inter-Turbine Burner (ITB). As the name suggest, the ITB is located between two turbines aft of the main combustion chamber. When the ITB is selected, its Fuel-to-Air Ratio (FAR) is a design variable.
  6. In order to cool the turbine or to regulate the axial velocity of the compressor gases, air can be bled from the compressors through bleed valves. This air is referred to as cooling bleed and is a design choice, opposed to the extraction bleed (see choice 9). For the engine architecting problem, the amount of cooling bleed and its targets (i.e. defined turbines) need to be specified for each individual compressor. The implementation of cooling bleed is split up into intra-bleed and inter-bleed: the former defines a situation where air is bled from within a compressor, whereas for the latter it is bled from in between two compressors.
  7. For turbofans, a choice can be made between a separate or mixed flow nozzle. In the mixed flow nozzle, the flow of the core and the bypass is mixed at the end of the engine and leaves the engine through one joint nozzle, whereas this is not the case for a separate flow nozzle.
  8. On stationary and marine gas turbines, a heat rejection method is sometimes implemented called intercooling. During this process, heat is removed from in between two compressors using a heat exchanger. In the architecting problem, an intercooler can be added by specifying its location in the engine and its geometry (radius, length and number of pipes).
  9. Power and extraction bleed offtakes are specified as part of the engine requirements, and are therefore always present in an engine architecture. Power offtakes are satisfied by extracting electrical power from one of the engine shafts in order to power different systems onboard the aircraft. For extraction bleed, air is bled from one of the compressors to support for example the Environment Control System (ECS) or anti-icing systems of the aircraft. The offtake location (both for power and extraction bleed) can be specified with the design variables.

In total, the design space includes 41 design variables: 6 categorical, 5 integer and 30 continuous. Only the discrete variables already account for approximately 1.3 million engine design points.

Operating Conditions

The operating conditions of the aircraft engine optimized in the benchmark problem are the same as the operating conditions for the LEAP-1C engine:

  • Mach ≈ 0
  • Altitude = 0 ft
  • Thrust = 150 kN
  • Turbine inlet temperature = 1450 degC
  • Extraction bleed = 0.5 kg/s
  • Power offtake = 37.5 kW

Simple Architecting Problem

The simple architecting problem can be accessed via the tests\examples\simple_problem.py file. The file is ready to run. However, the user can specify the location to save results on line 90.

This engine architecting problem features only one objective (TSFC), and only design feasibility constraints. The included design choices are: fan inclusion (1), number of shafts (3), gearbox implementation (4), nozzle type (7), and offtake locations (9). The numbers indicate the specific architecting choices defined before. These design choices result in 15 design variables and the creation of solely conventional engine architectures. In total, 15 distinct engine architectures and 216 engine design points can be generated taking into account the discrete design variables. The popular multi-objective optimization algorithm NSGA-II with a population size of 75 and termination criteria of 1000 evaluations was used to run the optimization in the pymoo framework.

The architectures were analyzed, and their results are presented. All feasibility constraints are satisfied. Approximately 49% of the generated engine architectures converged during the initial DOE, whereas this increased to 92% for the last iteration.

The lowest achieved TSFC is an ultra-high BPR (UHBR) turbofan with a TSFC of 6.7 g/kNs.

image image image image image image

Realistic Architecting Problem

The realistic architecting problem can be accessed via the tests\examples\realistic_problem.py file. The file is ready to run. However, the user can specify the location to save results on line 42.

This engine architecting problem is constructed and solved to provide a target Pareto front for future optimization algorithm research. The realistic architecting problem contains three conflicting objectives (TSFC, weight and noise), and multiple constraints (e.g. geometry and emissions). All available design choices are included in the problem, leading to 41 design variables. This results in the possibility to generate 85 distinct engine architectures and approximately 1.3 million engine design points taking all discrete variables into account. Evaluating one engine design point can take up to two minutes, making for a challenging optimization problem. The same NSGA-II algorithm is used as for the simple architecting problem. The population size was set to 205 and the termination criteria to 4000 evaluations, to account for the increase in number of design variables.

All constraints imposed on the architecture are satisfied. This shows that the benchmark problem achieves feasible results for the engine disciplines. From the generated engi

View on GitHub
GitHub Stars15
CategoryDevelopment
Updated1mo ago
Forks6

Languages

Python

Security Score

90/100

Audited on Mar 6, 2026

No findings