Designing the propulsion with this tool includes different engineering disciplines. Here is a brief explanation (more information in their respective sections):
-[Engine designer](#enginedesigner): Calculates the performance of one individual engine based on the required thrust.
-[Propulsor integrator](#propulsionintegrator): Places the engine acc. to the user's settings.
-[Nacelle designer](#nacelledesigner): Calculates the nacelle geometry.
-[Pylon designer](#pylondesigner): Calculates the pylon geometry.
-[Mass analyzer](#massanalyzer): Calculates the mass properties (center of gravity, mass, and inertia) of engine, nacelle, and pylon.
Designing the propulsion with this tool includes different steps shown below (with more information in their respective sections):
For these five disciplines, you can choose different methods (or fidelities) of calculating their output. Here is an overview of the currently implemented methods (details in the sections):
*[Engine designer](#enginedesigner): Calculates the performance of one individual engine based on the required thrust.
*[Propulsor integrator](#propulsionintegrator): Places the engine acc. to the user's settings.
*[Nacelle designer](#nacelledesigner): Calculates the nacelle geometry.
*[Pylon designer](#pylondesigner): Calculates the pylon geometry.
*[Mass analyzer](#massanalyzer): Calculates the mass properties (center of gravity, mass, and inertia) of engine, nacelle, and pylon.
For these five disciplines, you can choose different methods of calculating their output. The following methods are integrated (details in the sections):
@@ -20,36 +21,39 @@ For these five disciplines, you can choose different methods (or fidelities) of
If you want to learn more about how to configure methods or generally the settings and outputs, go to the [getting started](getting_started.md).
@important These disciplines are executed sequentially for EACH engine. That means that the engines are not aware of each other within the designing and analyzing. More information, see the [software architecture](software_architecture.md) section.
If you want to learn more about how to configure methods or generally the settings and outputs, go to the [getting started](getting-started.md).
!!! important
These disciplines are executed sequentially for EACH engine. That means that the engines are not aware of each other while designing and analyzing. More information, see the [software architecture](software_architecture.md) section.
## Engine designer {#enginedesigner}
This section describes the principles of the engine designer.
### General principles {#generalprinciples}
The **engine designer** bases its principle on the common modelling practice using
- an _engine dataset_ (operating point **in**dependent)
- an _engine deck_ (operating point dependent)
- a _scale factor_
In the engine design a dataset needs to be written into the projects directory. The following data is needed:
* An engine dataset (operating point independent)
* An engine deck (operating point dependent)
* A scale factor
The _dataset_ (also called _EngineXML_) includes parameter which are independent of the flight condition such as outer engine dimensions or the mass of the unscaled engine.
The three-dimensional \textit{engine deck} contains engine performance data for different values of altitude \( h \), Mach number \( M_a \), and low-pressure engine spool speed \( N_1 \).
The most important performance parameter are thrust and fuel/energy flow. In UNICADO, the deck is split into multiple CSV files. The figure shows an example with values for thrust in kilo newtons. The first block contains data for \( N_1 = 1 \) for \( M_a = 0 \ldots 0.9 \) and \( h = 0 \ldots 14000 \). The second block below is for \( N_1 = 0.95 \).
The _dataset_ (also called _engine_xml_) includes parameter which are independent of the flight condition such as outer engine dimensions or the mass of the unscaled engine.
The three-dimensional \(\text{\textit{engine deck}} \) contains engine performance data for different values of altitude \( h \), Mach number \( M_a \), and low-pressure engine spool speed \( N_1 \).
The most important performance parameter are thrust and fuel/energy flow. In UNICADO, the deck is split into multiple csv files. The figure shows an example with values for thrust in kilo newtons. The first block contains data for \( N_1 = 1 \) for \( M_a = 0 \ldots 0.9 \) and \( h = 0 \ldots 14000 \). The second block below is for \( N_1 = 0.95 \).
@note Detailed information on required dataset and deck data will be updated in near future.
The _scale factor_ is necessary for the rubber method because we use the concept of a so-called _rubber engine_. That means that (depending on the method, see later) we create or assume an engine deck and provide one _scale factor_ to obtain all engine data acc. to the required thrust the engine shall provide. The figure visualized the concept:
@attention →**As mentioned and highlighted in the figure**, there is ONE _scale factor_ **BUT** multiple exponents which differ depending on which property you want to use. E.g., for the diameter, the exponent is \( 0.5 \) and for the mass, its exponent is \( 0.4 \).
**So important to remember** that whenever you want to use engine data, you need to access it via the `engine` library. In the following, a brief explanation of the scaling concept will be given - however details are given in the library documentation.
The _scale factor_ is necessary for the rubber method as it uses the concept of a so-called _rubber engine_. That means that (depending on the method, see later) we create or assume an engine deck and provide a _scale factor_ to scale all engine data acc. to the required thrust the engine shall provide. The figure visualized the concept:
So, the scaling is based on continuity principle assuming that the operating of the inner engine is constant (commonly known station numbering; assuming no extra pressure drop).
!!! attention
**As mentioned and highlighted in the figure**, there is ONE _scale factor_ **BUT** the scaling of the base values is not always linear.
**So important to remember** that whenever you want to use engine data, you need to access it via the `engine` library. In the following, a brief explanation of the scaling concept will be given - however details are given in the library documentation.
The scaling is based on continuity principle assuming that the engine characteristics are constant.
An exemplary simplified calculation (data from the V2527-A5): the current engine provides $127.27~\text{kN}$ as sea level static thrust, but for the design only $100~\text{kN}$ are needed. The scaling factor would be $0.7857$. Assuming an initial diameter $2~\text{m}$, the new diameter would be $1.773~\text{m}$ with the scaling factor of $(0.7857)^{0.5} = 0.8864$.
The general scaling is therefore a linear scaling of the thrust. The fuel flow is scaled in the same way leading to a scaling approach with constant TSFC.
The general scaling is therefore a linear scaling of the thrust. The fuel flow is scaled in the same way leading to a scaling with constant TSFC.
So, again, the engine data is always accessed via the `engine` library to ensure that you have the correctly scaled data for every value. This is valid for both the non operating condition dependent variables and the values that are directly read from the deck values.
The engine data is always accessed via the `engine` library to ensure that you have the correctly scaled data for every value. This is valid for both the non operating condition dependent variables and the values that are directly read from the deck values.
\textbf{Note:} Actually, the sea level static thrust is not at $N1=1$ if you compare the dataset for this engine (for $110.31~\text{kN}$ around $N1=0.95$). So the scaling factor will be slightly lower.
!!! Note
Actually, the sea level static thrust is not at $N1=1$ if you compare the dataset for this engine (for $110.31~\text{kN}$ around $N1=0.95$). So the scaling factor is slightly lower.
### Methods description
The **engine designer** includes different methods which create/use this deck in various ways.
-*empirical*: the initial deck is calculated based on empirical equations.
-*rubber*: (most common approach) based on an existing deck (usually created with GasTurb), the deck is "rubberized".
-*propulsionsystem*: with the help of the library `propulsionsystem`, different architecture can be defined and a deck created (for more information see documentation of the library)
@note *empirical* and *propulsionsystem* is in preparation - not implemented yet!
**empirical*: the initial deck is calculated based on empirical equations.
**rubber*: (most common approach) based on an existing deck (usually created with GasTurb), the deck is "rubberized".
**propulsionsystem*: with the help of the library `propulsionsystem`, different architecture can be defined and a deck created (for more information see documentation of the library)
!!! note
*empirical* and *propulsionsystem* is in preparation - not implemented yet!
For these methods, the approach of using the _scale factor_ is the same (see explanation [here](#generalprinciples)). A deck is either first created or assumed and then data is drawn with the `engine` library with the scaling approach.
For these methods, the approach of using the _scale factor_ is the same (see explanation [here](#generalprinciples)). A deck is either first created or an existing dataset is taken and then data is provided using the `engine` library with the scaling approach.
## Propulsion integrator {#propulsionintegrator}
Additionally to calculating the engine performance parameter, the engine has to be placed on the aircraft. The **propulsion integrator** uses the user settings from the aircraft exchange file - the following needs to be defined:
- parent component: wing, fuselage, empennage
- x-position (aircraft coordinate system): front or rear
- y position (aircraft coordinate system): left or right
...
...
@@ -95,6 +103,7 @@ Additionally to calculating the engine performance parameter, the engine has to
### Methods description
Here, currently only one method is implemented:
-*default* is based on a thesis of RWTH Aachen \cite{Ata10}
This method includes multiple empirical functions for different propulsion integration. These are the options that are currently implemented:
...
...
@@ -112,23 +121,26 @@ This method includes multiple empirical functions for different propulsion integ
For detailed information, it is referred to the thesis.
@note the implementation include currently Turbofan Kerosene only
!!! note
The implementation include currently Turbofan Kerosene only
## Nacelle designer {#nacelledesigner}
After the integration, the nacelle geometry is defined (however its actually independent of the position, so the order could be changed).
After the integration, the nacelle geometry is defined.
### Methods description
For the **nacelle designer**, only one method is implemented:
-*default* uses the `aircraftGeometry2` library
-*default* uses the `aircraftGeometry2` library.
The library uses the `.dat` file defined in the _configXML_ to extrude a polygon in different sections. These sections including the origin, width, height and its profile are saved in the _acXML_. With that, every other tool can "rebuild" the geometry using the same library.
In the current implemented method, there is no differentiation between short and long ducted nacelle. It is a polygon with 3 segments (1. and 3. segments is 25% of engine length). The diameter for the 1. and 3. segment is chosen as the maximum between fan diameter, engine width or height. The 2. segments is 25% larger.
There is no differentiation between short and long ducted nacelle. It is a polygon with 3 segments (1. and 3. segments is 25% of engine length). The diameter for the 1. and 3. segment is chosen as the maximum between fan diameter, engine width or height. The 2. segments is 25% larger.
Keep in mind that the library defines a surface without a thickness. For more information, it is referred to the library.
@note the implementation include currently Turbofan Kerosene only
!!! note
Currently, only a kerosene turbofan engine is included.
## Pylon designer {#pylondesigner}
The pylon is the structural component to connect the engine to the aircraft.
...
...
@@ -136,14 +148,11 @@ The pylon is the structural component to connect the engine to the aircraft.
### Methods description
For the **pylon designer**, only one method is implemented:
-*default* uses the `aircraftGeometry2` library
-*default* uses the `aircraftGeometry2` library.
In the current method, the mounting is attached to the beginning to the nacelle to the leading edge of the wing. The length is the engine length which is extruded to the wing. The profile is, likewise for the nacelle, defined in the _configXML_.
@note the implementation include currently Turbofan Kerosene only
## Mass analyzer {#massanalyzer}
Lastly, the mass properties for engine, nacelle and pylon are calculated separately for center of gravity, mass and inertia.
...
...
@@ -151,6 +160,7 @@ Lastly, the mass properties for engine, nacelle and pylon are calculated separat
### Methods description
Here, only one method is implemented:
-*default* using:
- for engine
- CG: calculating local CG assuming a circular cylinder
...
...
@@ -161,5 +171,6 @@ Here, only one method is implemented:
- mass: empirical estimation
- inertia: wrt. CG with `aircraftGeometry2`lib
@note the implementation include currently Turbofan Kerosene only
!!! note
Currently, only a kerosene turbofan engine is included.
