From e72d8fc55cb606d01cb521a00509cedfe4011cd0 Mon Sep 17 00:00:00 2001
From: Kristina Mazur <kristina.mazur@tum.de>
Date: Tue, 28 Jan 2025 18:42:44 +0100
Subject: [PATCH] Fix note and equations to md native + some links
---
.../cost_estimation/getting-started.md | 7 +-
.../analysis/cost_estimation/index.md | 14 +-
.../cost_estimation/operating_cost_method.md | 244 ++++++++--------
.../run_your_first_cost_estimation.md | 5 +-
.../ecological_assessment/aqi_schaefer.md | 8 +-
.../ecological_assessment/getting-started.md | 3 +-
.../ecological_assessment/lca_schaefer.md | 5 +-
.../mission_emissions.md | 8 +-
.../basic-concepts.md | 98 +++----
.../weight_and_balance_analysis/usage.md | 3 +-
.../libraries/aircraftGeometry2/index.md | 18 +-
.../aircraftGeometry2/tutorial-convert.md | 6 +-
.../aircraftGeometry2/tutorial-factory.md | 44 +--
.../aircraftGeometry2/tutorial-geometry.md | 18 +-
.../sizing/fuselage_design/design_method.md | 143 +++++-----
.../sizing/fuselage_design/getting-started.md | 12 +-
.../sizing/fuselage_design/index.md | 8 +-
.../fuselage_design/run_your_first_design.md | 3 +-
.../fuselage_design/software_architecture.md | 2 +-
.../sizing/initial_sizing/changelog.md | 3 +-
.../sizing/initial_sizing/getting-started.md | 5 +-
.../sizing/initial_sizing/index.md | 2 +-
.../landing_gear_design/design_method.md | 270 +++++++++---------
.../landing_gear_design/getting-started.md | 9 +-
.../sizing/landing_gear_design/index.md | 8 +-
.../run_your_first_design.md | 3 +-
.../software_architecture.md | 2 +-
.../sizing/propulsion_design/changelog.md | 5 +-
.../engineering_principles.md | 43 +--
.../propulsion_design/getting-started.md | 29 +-
.../sizing/propulsion_design/index.md | 3 +-
.../software_architecture.md | 1 +
.../sizing/tank_design/getting-started.md | 14 +-
.../documentation/sizing/tank_design/index.md | 8 +-
.../tank_design/run_your_first_tank_design.md | 3 +-
.../tank_design/software_architecture.md | 2 +-
.../sizing/tank_design/tank_design_method.md | 99 +++----
37 files changed, 615 insertions(+), 543 deletions(-)
diff --git a/docs/documentation/analysis/cost_estimation/getting-started.md b/docs/documentation/analysis/cost_estimation/getting-started.md
index e21104e..ff94edb 100644
--- a/docs/documentation/analysis/cost_estimation/getting-started.md
+++ b/docs/documentation/analysis/cost_estimation/getting-started.md
@@ -5,7 +5,8 @@ This section will guide you through the necessary steps to get the _cost\_estima
- [Additional requirements](#additional-requirements) - Is anything else necessary to get the module running?
- [Next steps](#next-steps) - How to proceed?
-@note It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
+!!! note
+ It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
Generally, we use two files to set or configure modules in UNICADO:
- The aircraft exchange file (or _acXML_) includes
@@ -47,11 +48,13 @@ The following information is needed from the _acXML_:
The _configXML_ is structured into two blocks: the control and program settings.
The control settings are standardized in UNICADO and will not be described in detail here. But to get started, you have to change at least
+
- the `aircraft_exchange_file_name` and `aircraft_exchange_file_directory` to your respective settings,
- the `console_output` at least to `mode_1`, and
- the `plot_output` to false (or define `inkscape_path` and `gnuplot_path`).
-@note If the tool is executed via the workflow, those settings are set by the workflow settings.
+!!! note
+ If the tool is executed via the workflow, those settings are set by the workflow settings.
The program settings are structured like this (descriptions can be found in the `cost_estimation_conf.xml`):
diff --git a/docs/documentation/analysis/cost_estimation/index.md b/docs/documentation/analysis/cost_estimation/index.md
index 4d38f4a..7446bf1 100644
--- a/docs/documentation/analysis/cost_estimation/index.md
+++ b/docs/documentation/analysis/cost_estimation/index.md
@@ -1,16 +1,16 @@
# Introduction {#mainpage}
-Welcome to the _cost\_estimation_ module in UNICADO – where we take your aircraft operating costs from “hmm… probably a lot?” to laser-accurate precision! This tool is like a financial \emoji crystal_ball for your aircraft, crunching numbers on fuel, maintenance, crew costs, and just about (almost) every other expense you can imagine. Think of it as your budgeting co-pilot, always ready to calculate so you can focus on the skies instead of spreadsheets. With _cost\_estimation_, you stay in control, keep the accountants happy, and land at your bottom line without any turbulence. So buckle up, and let’s start calculating!
+Welcome to the _cost\_estimation_ module in UNICADO – where we take your aircraft operating costs from “hmm… probably a lot?” to laser-accurate precision! This tool is like a financial :crystal_ball for your aircraft, crunching numbers on fuel, maintenance, crew costs, and just about (almost) every other expense you can imagine. Think of it as your budgeting co-pilot, always ready to calculate so you can focus on the skies instead of spreadsheets. With _cost\_estimation_, you stay in control, keep the accountants happy, and land at your bottom line without any turbulence. So buckle up, and let’s start calculating!
## Summary of features
Here’s a quick rundown of what the tool currently does, along with a sneak peek at what's planned:
Configuration | Energy carrier |Cost share | Status |
------------------|-----------------|-------------------------|:------------------------------------:|
-Tube-and-wing |Kerosene |Direct operating cost |running \emoji white_check_mark |
-Tube-and-wing |Kerosene |Indirect operating cost |under development \emoji construction |
-Tube-and-wing |Liquid hydrogen |Direct operating cost |running \emoji white_check_mark |
-Tube-and-wing |Liquid hydrogen |Indirect operating cost |under development \emoji construction |
-Blended-wing-body |... |... |under development \emoji construction |
+Tube-and-wing |Kerosene |Direct operating cost |running :white_check_mark: |
+Tube-and-wing |Kerosene |Indirect operating cost |under development :construction:|
+Tube-and-wing |Liquid hydrogen |Direct operating cost |running :white_check_mark: |
+Tube-and-wing |Liquid hydrogen |Indirect operating cost |under development :construction:|
+Blended-wing-body |... |... |under development :construction:|
## A user's guide to cost calculation
The _cost\_estimation_ tool is your key to accurately calculating the operating costs of an aircraft. In this user documentation, you’ll find all the information you need to understand the tool, as well as the necessary inputs and configurations to run a cost analysis from the ground up.
@@ -23,7 +23,7 @@ For a comprehensive understanding of the tool’s functionality, the documentati
- a [software architecture](software_architecture.md)
section.
-Ready to dive in? Let’s get started! \emoji money_with_wings
+Ready to dive in? Let’s get started! :money_with_wings:
<!-- ## You are a Developer?
diff --git a/docs/documentation/analysis/cost_estimation/operating_cost_method.md b/docs/documentation/analysis/cost_estimation/operating_cost_method.md
index 6c9b8ee..c323127 100644
--- a/docs/documentation/analysis/cost_estimation/operating_cost_method.md
+++ b/docs/documentation/analysis/cost_estimation/operating_cost_method.md
@@ -1,55 +1,56 @@
# Calculation method
The total operating costs of an aircraft are split into direct operating costs (DOC) and indirect operating costs (IOC).
-\f[
+$
TOC = DOC + IOC
-\f]
+$
-@note Unless explicitly stated, all values are in SI units and all costs in EUR.
+!!! note
+ Unless explicitly stated, all values are in SI units and all costs in EUR.
## Direct operating costs (calculate_direct_operating_costs function)
The Direct Operating Costs (DOC) are directly influenced by the parameters and the aircraft's performance and are commonly used for aircraft evaluation. Therefore, a simplified method for DOC estimation, based on „From Aircraft Performance to Aircraft Assessment“ by J. Thorbeck <sup>[1]</sup>, is provided. The DOC are determined for one year and the entire depreciation period.
-Two elements are required for the simplified DOC model: The route independent (fixed) costs \f$C_1\f$ and route dependent (variable) costs \f$C_2\f$:
-\f[
+Two elements are required for the simplified DOC model: The route independent (fixed) costs $C_1$ and route dependent (variable) costs $C_2$:
+$
DOC = C_1 + C_2
-\f]
+$
### Route independent costs (calculate_route_independent_costs function)
Route-independent costs include all cost components apart from the operation of the aircraft.
Hence, the route-independent costs are the sum of the capital costs and the crew costs:
-\f[
+$
C_1 = C_{CAP} + C_{crew}
-\f]
+$
Those are calculated both, for one year and for the depreciation period.
#### Capital costs (calculate_capital_costs function)
The capital costs can be assumed to be a linear function of the operating empty mass if the influence of the aircraft market is considered negligible:
-\f[
+$
C_{CAP} = P_{OE} \cdot m_{OE} \cdot (a+f_I)
-\f]
+$
In which
-- \f$P_{OE}\f$ - price per kg operating empty mass
-- \f$m_{OE}\f$ - operating empty mass
-- \f$a\f$ - annuity factor in percent
-- \f$f_I\f$ - insurance rate in percent
+- $P_{OE}$ - price per kg operating empty mass
+- $m_{OE}$ - operating empty mass
+- $a$ - annuity factor in percent
+- $f_I$ - insurance rate in percent
The annuity formula, which is based on a modified mortgage equation, addresses both yearly depreciation and interest:
-\f[
+$
a = f_{IR} \cdot \frac{1-f_{RV} \cdot \left(\frac{1}{1+f_{IR}}\right)^{t_{DEP}}}{1-\left(\frac{1}{1+f_{IR}}\right)^{t_{DEP}}}
-\f]
+$
In which
-- \f$f_{IR}\f$ - interest rate in percent
-- \f$f_{RV}\f$ - residual value factor in percent
-- \f$t_{DEP}\f$ - depreciation period in years
+- $f_{IR}$ - interest rate in percent
+- $f_{RV}$ - residual value factor in percent
+- $t_{DEP}$ - depreciation period in years
The reason for the annuity method modification is to include the residual aircraft value at the end of the depreciation period into the capital costs, which is occasionally relevant. This assumes that an operator is purchasing an aircraft at a constant price per kilogram and spends the corresponding capital cost consistently per year throughout the depreciation period.
#### Crew costs (calculate_crew_costs function)
This method is based on the lecture "J Flugzeugbewertung" by A. Bardenhagen <sup>[2]</sup>.
The annual crew costs are assumed to be the sum of the flight and cabin crew costs:
-\f[
+$
C_{crew} = C_{FC} + C_{CC}
-\f]
+$
both of which are of different levels. There are different approaches here, which must be adapted to the respective cost structure of the airline:
- Some airlines (mainly low-cost carriers) employ and pay pilots and flight attendants on a time basis (block hours).
@@ -58,27 +59,27 @@ both of which are of different levels. There are different approaches here, whic
In the first case, the personnel costs belong to the variable in the second case to the fixed direct operating costs. Here, crew costs are assumed to be fixed (route independent) because an airline must provide enough crews to ensure flight operations over the entire service time and therefore are proportional to the payload. 50 passengers per flight attendant are assumed based on certification requirements. Crew costs are constant per year. To calculate the crew cost for several years, the expected salary increase should be considered by an escalation factor. Accordingly, past price levels can be extrapolated to the current level changed according to inflation, price, or salary increase.
Both cost shares are determined by the same variables:
-- The flight/cabin crew complement (the number of crews per aircraft, dependent on the stage length): \f$n_{FCC}\f$/\f$n_{CCC}\f$,
-- The number of flight/cabin crew members: \f$n_{FC}\f$/\f$n_{CC}\f$,
-- The annual salary of a flight/cabin crew member (dependent on the stage length): \f$S_{FC}\f$/\f$S_{CC}\f$, and
-- The escalation factor in percent: \f$f_{ESC}\f$.
+- The flight/cabin crew complement (the number of crews per aircraft, dependent on the stage length): $n_{FCC}$/$n_{CCC}$,
+- The number of flight/cabin crew members: $n_{FC}$/$n_{CC}$,
+- The annual salary of a flight/cabin crew member (dependent on the stage length): $S_{FC}$/$S_{CC}$, and
+- The escalation factor in percent: $f_{ESC}$.
<!-- NOTE: The values of these drivers depend on the stage length. Two modes are implemented. Mode 1 (salary_variation = False, default): To ensure that the values of the above-mentioned parameters are the same for the design mission and mission study, the stage length of the design mission is used to determine the values for the study mission as well. Mode 2 (salary_variation = True): The above-mentioned values are obtained for different stage lengths for the design mission and mission study. -->
That results in the following calculations:
-\f[
+$
C_{FC} = n_{FCC} \cdot n_{FC} \cdot S_{FC} \cdot f_{ESC}
-\f]
-\f[
+$
+$
C_{CC} = n_{CCC} \cdot n_{CC} \cdot S_{CC} \cdot f_{ESC}
-\f]
+$
The escalation factor
-\f[
+$
f_{ESC} = (1+r_{INF})^{y}
-\f]
+$
-incorporates the inflation rate (\f$r_{INF}\f$), which encompasses both price and salary adjustments, and the number of years elapsed between the calculation year and the base year for salaries (\f$y\f$).
+incorporates the inflation rate ($r_{INF}$), which encompasses both price and salary adjustments, and the number of years elapsed between the calculation year and the base year for salaries ($y$).
If the depreciation period is used as the time difference, resulting costs are related to the whole depreciation period, whereas a time difference of one year solely results in the costs for the base year.
The crew complements as well as the average annual salaries are dependent on the stage length:
@@ -90,7 +91,7 @@ The crew complements as well as the average annual salaries are dependent on the
and can be taken from the following tables:
-Segment | Crew complement | \f$S_{FC}\f$ in EUR/y | \f$S_{CC}\f$ in EUR/y |
+Segment | Crew complement | $S_{FC}$ in EUR/y | $S_{CC}$ in EUR/y |
----------------|:---------------:|:-----------------:|:-----------------:|
Regional | 5 | 70 000 | 30 000 |
Short haul | 5 | 120 000 | 30 000 |
@@ -99,75 +100,75 @@ Long haul | 8 | 200 000 | 45 000 |
Ultra-long haul | 8 | 200 000 | 45 000 |
### Route dependent costs (calculate_route_dependent_costs function)
-Route dependent costs \f$C_2\f$ include all cost components that are directly attributable to flight operations. These include
-- fuel \f$C_F\f$,
-- fees (handling \f$C_H\f$, landing \f$C_L\f$, air traffic control (ATC) \f$C_{ATC}\f$), and
-- maintenance \f$C_{MRO}\f$.
+Route dependent costs $C_2$ include all cost components that are directly attributable to flight operations. These include
+- fuel $C_F$,
+- fees (handling $C_H$, landing $C_L$, air traffic control (ATC) $C_{ATC}$), and
+- maintenance $C_{MRO}$.
Thus, the **annual** route dependent costs can be calculated by
-\f[
+$
C_2 = C_F + C_H + C_{LDG} + C_{ATC} + C_{MRO}
-\f]
+$
#### Flights per year
Knowing the number of annual flights is mandatory to calculate the above-mentioned cost shares.
A reliable approximation of the number of annual flights can be found using the following analytical basis:
-- Potential flight hours per year: \f$365 \cdot 24 = 8760\f$
-- Maintenance lay days per year (C-Check every 15 months for 4 days): \f$4 \cdot 12/15 = 3.2\f$
-- Overhaul lay days per year (D-Check every 5 years for 4 weeks): \f$4 \cdot 7/5 = 5.6\f$
-- Lay days for repairs, technical and operational reserve: \f$2.6\f$
-- Lay hours per year: \f$(3.2+5.6+2.6) \cdot 24 = 273.6\f$
-- Potential operation days per year: \f$365-(3.2+5.6+2.6) = 353.6\f$
-- Daily night curfew hours: \f$7\f$
-- Yearly night curfew hours: \f$354 \cdot 7 = 2475\f$
-- Yearly operation time in hours: \f$OT = 8760-2475-273.6 = 6011.4\f$
-
-Knowing the time for one flight \f$FT\f$ and the block time supplement \f$BT\f$ (turn around time) per flight, the number of flight cycles \f$FC\f$ can be calculated:
-\f[
+- Potential flight hours per year: $365 \cdot 24 = 8760$
+- Maintenance lay days per year (C-Check every 15 months for 4 days): $4 \cdot 12/15 = 3.2$
+- Overhaul lay days per year (D-Check every 5 years for 4 weeks): $4 \cdot 7/5 = 5.6$
+- Lay days for repairs, technical and operational reserve: $2.6$
+- Lay hours per year: $(3.2+5.6+2.6) \cdot 24 = 273.6$
+- Potential operation days per year: $365-(3.2+5.6+2.6) = 353.6$
+- Daily night curfew hours: $7$
+- Yearly night curfew hours: $354 \cdot 7 = 2475$
+- Yearly operation time in hours: $OT = 8760-2475-273.6 = 6011.4$
+
+Knowing the time for one flight $FT$ and the block time supplement $BT$ (turn around time) per flight, the number of flight cycles $FC$ can be calculated:
+$
FC = \frac{OT}{(FT + BT)}
-\f]
+$
It is assumed that one flight cycle consists of an outbound flight, a turnaround time and a return flight. Consequently, the number of annual flights is calculated as follows:
-\f[
+$
n_{flights} = 2 \cdot FC
-\f]
+$
#### Fuel costs (calculate_fuel_costs function)
-The fuel costs depend on the fuel price \f$P_F\f$, the trip fuel mass \f$m_{TF}\f$ (which can be obtained from the payload range diagram (PRD)), and the number of yearly flights \f$n_{flights}\f$:
-\f[
+The fuel costs depend on the fuel price $P_F$, the trip fuel mass $m_{TF}$ (which can be obtained from the payload range diagram (PRD)), and the number of yearly flights $n_{flights}$:
+$
C_F = P_{F} \cdot m_{TF} \cdot n_{flights}
-\f]
+$
#### Handling costs (calculate_handling_costs function)
-Handling charges \f$F_H\f$ include charges for loading and unloading, use of terminals and passenger boarding bridges, security checks, and ground energy supply.
-The annual handling fees are charged based on the payload mass \f$m_{PL}\f$ and the number of flights per year. The resulting handling costs are calculated as follows:
-\f[
+Handling charges $F_H$ include charges for loading and unloading, use of terminals and passenger boarding bridges, security checks, and ground energy supply.
+The annual handling fees are charged based on the payload mass $m_{PL}$ and the number of flights per year. The resulting handling costs are calculated as follows:
+$
C_H = m_{PL} \cdot F_{H} \cdot n_{flights}
-\f]
+$
#### Landing costs (calcutale_landing_costs function)
-The annual landing fees \f$F_{LDG}\f$ are charged based on the maximum (certified) takeoff mass \f$m_{TO}\f$ and number of flights per year. The resulting landing costs are calculated as follows:
-\f[
+The annual landing fees $F_{LDG}$ are charged based on the maximum (certified) takeoff mass $m_{TO}$ and number of flights per year. The resulting landing costs are calculated as follows:
+$
C_{LDG} = m_{TO} \cdot F_L \cdot n_{flights}
-\f]
+$
#### Air traffic control costs (calculate_air_traffic_control_costs function)
The calculation of the ATC costs is based on the EUROCONTROL route charge formula <sup>[3]</sup>, more precisely the aircraft weight factor.
> "The weight factor (expressed to two decimals) is determined by dividing, by fifty (50), the certificated Maximum Take-Off Weight (MTOW) of the aircraft (in metric tonnes, to one decimal) and subsequently taking the square root of the result rounded to the second decimal [...]".
-The ATC price factor \f$f_{ATC}\f$ considers the fact that the price scenarios are varying strongly for each continent (or even region):
-- \f$f_{ATC} = 1.0\f$ for domestic europe
-- \f$f_{ATC} = 0.7\f$ for transatlantic flights
-- \f$f_{ATC} = 0.6\f$ for far east flights (only half of the landings at european airports)
+The ATC price factor $f_{ATC}$ considers the fact that the price scenarios are varying strongly for each continent (or even region):
+- $f_{ATC} = 1.0$ for domestic europe
+- $f_{ATC} = 0.7$ for transatlantic flights
+- $f_{ATC} = 0.6$ for far east flights (only half of the landings at european airports)
The ATC costs are calculated as follows:
-\f[
+$
C_{ATC} = R \cdot f_{ATC} \cdot \sqrt{\frac{m_{TO}[\text t]}{50}} \cdot n_{flights}
-\f]
+$
with
-- \f$R\f$ - range in km
-- \f$m_{TO}\f$ - maximum takeoff mass (in tonnes)
+- $R$ - range in km
+- $m_{TO}$ - maximum takeoff mass (in tonnes)
#### Maintenance costs (calculate_maintenance_costs function)
Maintenance costs are categorized into three components:
@@ -176,36 +177,36 @@ Maintenance costs are categorized into three components:
- Calendar time dependent cost: This component represents a constant share, such as the rectification of corrosion during overhaul.
In the following, only the maintenance costs per flight cycle are considered. Following the JADC method, an approximation for those costs is given by the sum of three parts:
-- Airframe material maintenance cost (repair and replacement): \f$C_{MRO,AF,MAT}\f$
-- Airframe personnel maintenance cost (inspection and repair): \f$C_{MRO,AF,PER}\f$
-- Engine total maintenance cost: \f$C_{MRO,ENG}\f$
+- Airframe material maintenance cost (repair and replacement): $C_{MRO,AF,MAT}$
+- Airframe personnel maintenance cost (inspection and repair): $C_{MRO,AF,PER}$
+- Engine total maintenance cost: $C_{MRO,ENG}$
In which
-\f[
+$
C_{MRO,AF,MAT} = m_{OE}[\text t] \cdot (0.2 \cdot t_{flight} + 13.7) + C_{MRO,AF,REP}
-\f]
-\f[
+$
+$
C_{MRO,AF,PER} = f_{LR} \cdot (1+C_B) \cdot \left[ (0.655 + 0.01 \cdot m_{OE}[\text t]) \cdot t_{flight} + 0.254 + 0.01 \cdot m_{OE}[\text t] \right]
-\f]
-\f[
+$
+$
C_{MRO,ENG} = n_{ENG} \cdot \left( 1.5 \cdot \frac{T_{0} [\text t]}{n_{ENG}} + 30.5 \cdot t_{flight} + 10.6 \cdot f_{MRO,ENG}\right)
-\f]
+$
with
-- \f$C_{MRO,AF,REP}\f$ - airframe repair cost per flight
-- \f$f_{LR}\f$ - labor rate in EUR/h
-- \f$C_B\f$ - cost burden
-- \f$n_{ENG}\f$ - number of engines
-- \f$T_{0}\f$ - sea level static thrust per engine
-- \f$f_{MRO,ENG}\f$ - engine maintenance factor
+- $C_{MRO,AF,REP}$ - airframe repair cost per flight
+- $f_{LR}$ - labor rate in EUR/h
+- $C_B$ - cost burden
+- $n_{ENG}$ - number of engines
+- $T_{0}$ - sea level static thrust per engine
+- $f_{MRO,ENG}$ - engine maintenance factor
-The airframe repair cost per flight \f$C_{MRO,AF,REP}\f$ equal 57.5 for kerosene-powered aircraft. For hydrogen-powered aircraft, this value is multiplied by the operating empty mass factor \f$f_{OEM} = 1.1\f$ to account for an approx. 10% higher operating empty mass.
-The engine maintenance factor is considered \f$f_{ENG} = 1\f$ for kerosene-powered aircraft and \f$f_{ENG} = 0.7\f$ for hydrogen-powered aircraft.
+The airframe repair cost per flight $C_{MRO,AF,REP}$ equal 57.5 for kerosene-powered aircraft. For hydrogen-powered aircraft, this value is multiplied by the operating empty mass factor $f_{OEM} = 1.1$ to account for an approx. 10% higher operating empty mass.
+The engine maintenance factor is considered $f_{ENG} = 1$ for kerosene-powered aircraft and $f_{ENG} = 0.7$ for hydrogen-powered aircraft.
Thus, the annual maintenance costs result in
-\f[
+$
C_{MRO} = (C_{MRO,AF,MAT} + C_{MRO,AF,PER} + C_{MRO,ENG}) \cdot n_{flights}
-\f]
+$
## Related direct operating costs
Absolute DOC are generally unsuitable as an assessment measure because aircraft size and technology strongly influence this figure. They are therefore expressed in differently related quantities, depending on the purpose of the evaluation:
@@ -218,41 +219,42 @@ These are described below.
### Flight kilometer costs (calculate_flight_kilometer_costs function)
The flight kilometer costs are very flexible and suitable for an extended consideration of changed route structures. This parameter allows the range potential of the aircraft to be assessed:
-\f[
+$
FKC = \frac{DOC}{R}.
-\f]
+$
### Seat kilometer costs (calculate_seat_kilometer_costs function)
-The seat kilometer offered (SKO) (or available) is a measure of an aircraft's passenger carrying capacity or, in other words, its potential to generate revenue by providing available seats to passengers. They are calculated by multiplying the number of seats available \f$n_{seats}\f$ by the range:
-\f[
+The seat kilometer offered (SKO) (or available) is a measure of an aircraft's passenger carrying capacity or, in other words, its potential to generate revenue by providing available seats to passengers. They are calculated by multiplying the number of seats available $n_{seats}$ by the range:
+$
SKO = n_{seats} \cdot R.
-\f]
+$
The seat kilometer costs allow the analysis of a change in seat capacity and thus the assessment of the passenger kilometer potential:
-\f[
+$
SKC = \frac{DOC}{SKO}
-\f]
+$
### Corrected seat kilometer costs (calculate_corrected_seat_kilometer_costs function)
-@note The calculation of this cost share is not implemented at the moment and set to `0` instead.
+!!! note
+ The calculation of this cost share is not implemented at the moment and set to `0` instead.
A method of freight equivalent passenger seats is applied.
-Cargo revenue from residual cargo payload at maximum zero fuel mass (\f$m_{PL,max} - m_{PL}\f$) can be calculated using
-\f[
+Cargo revenue from residual cargo payload at maximum zero fuel mass ($m_{PL,max} - m_{PL}$) can be calculated using
+$
I_{cargo} = I_{FR} \cdot (W_{PL,max} - W_{PAX})
-\f]
+$
with
-- \f$I_{FR}\f$ - revenue per freight kilometer
-- \f$W_{PL,max}\f$ - maximum payload weight
-- \f$W_{PAX}\f$ - pax weight
+- $I_{FR}$ - revenue per freight kilometer
+- $W_{PL,max}$ - maximum payload weight
+- $W_{PAX}$ - pax weight
The equivalent seat revenue can be derived using the following formula:
-\f[
+$
n_{PAX,cargo} = \frac{I_{cargo}}{I_{PAX}}
-\f]
-with \f$I_{PAX}\f$ as revenue per seat and flight (see following table).
+$
+with $I_{PAX}$ as revenue per seat and flight (see following table).
-Segment | \f$I_{PAX,multi-class}\f$ in EUR/SO | \f$I_{PAX,all-economy}\f$ in EUR/SO |
+Segment | $I_{PAX,multi-class}$ in EUR/SO | $I_{PAX,all-economy}$ in EUR/SO |
----------------|:-------------------------------:|:-------------------------------:|
Short haul | 400 | 250 |
Medium haul | 450 | 300 |
@@ -260,33 +262,33 @@ Long haul | 550 | 400
Ultra long haul | 700 | 550 |
Finally, the SKC correction can be determined as follows:
-\f[
+$
SKC_{cor} = SKC \cdot \frac{n_{PAX}}{n_{PAX} + n_{PAX,cargo}}
-\f]
+$
### Ton kilometer costs (calculate_ton_kilometer_costs function)
The ton kilometer costs (TKC) allow the analysis of a change in payload capacity and thus the assessment of the payload kilometer potential. The Ton Kilometers Offered (TKO) are the product of the payload and the range:
-\f[
+$
TKO = m_{PL} \cdot R
-\f]
+$
The Ton Kilometer Costs (TKC) are the DOC related to the TKO:
-\f[
+$
TKC = \frac{DOC}{TKO}
-\f]
+$
### Revenue seat kilometer costs (calculate_revenue_seat_kilometer_costs)
-Revenue passenger kilometers (RPK) are a measure of how many kilometers the aircraft has carried paying passengers. It is often referred to as "traffic" as it represents the actual demand for air transport. The RPK are determined by multiplying the range by the number of paying passengers. The revenue passenger kilometers are calculated by multiplying the number of revenue passengers with the maximum number of seats and the seat load factor \f$f_{PL}\f$:
-\f[
+Revenue passenger kilometers (RPK) are a measure of how many kilometers the aircraft has carried paying passengers. It is often referred to as "traffic" as it represents the actual demand for air transport. The RPK are determined by multiplying the range by the number of paying passengers. The revenue passenger kilometers are calculated by multiplying the number of revenue passengers with the maximum number of seats and the seat load factor $f_{PL}$:
+$
RPK = n_{PAX} \cdot f_{SL} \cdot R
-\f]
+$
The DOC per revenue passenger kilometer additionally take into account the overall performance of an airline. Note that revenue is strongly dependent on market situation and therefore varying.
-\f[
+$
RSKC = \frac{DOC}{RPK}
-\f]
+$
## Indirect operating costs (IOC)
-tbd. \emoji construction
+tbd. :construction:
---
<sup>[1]</sup> J. Thorbeck, 2007. *From Aircraft Performance to Aircraft Assessment*. DLR.<br>
diff --git a/docs/documentation/analysis/cost_estimation/run_your_first_cost_estimation.md b/docs/documentation/analysis/cost_estimation/run_your_first_cost_estimation.md
index dfa91ac..a043b4a 100644
--- a/docs/documentation/analysis/cost_estimation/run_your_first_cost_estimation.md
+++ b/docs/documentation/analysis/cost_estimation/run_your_first_cost_estimation.md
@@ -1,5 +1,5 @@
# Run your first cost estimation
-Let's dive into the fun part and crunch some numbers! \emoji moneybag
+Let's dive into the fun part and crunch some numbers! :moneybag:
## Tool single execution
The tool can be executed from the console directly if all paths are set. The following will happen:
@@ -62,7 +62,8 @@ In the following, a short overview is given on the generated reports:
- plots in the `plots` folder
### Write data to the aircraft exchange file {#write-data-to-acxml}
-@note The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
+!!! note
+ The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
Results are saved in the aircraft exchange file at the `aircraft_exchange_file/assessment/cost_estimation/operating_cost` node. The following information is written to the _acXML_:
```
diff --git a/docs/documentation/analysis/ecological_assessment/aqi_schaefer.md b/docs/documentation/analysis/ecological_assessment/aqi_schaefer.md
index 7746724..9d53720 100644
--- a/docs/documentation/analysis/ecological_assessment/aqi_schaefer.md
+++ b/docs/documentation/analysis/ecological_assessment/aqi_schaefer.md
@@ -4,13 +4,13 @@ This method provides a single indicator (called the Air Quality Index (AQI)) for
## General principles {#aqi-schaefer-generalprinciples}
The calculation method, including all required inputs, is described in Schaefer (2017) \cite Sch17. It is:
-\f$ AQI = 1/n \cdot \sum x_i/x_{i,max}\f$
+$ AQI = 1/n \cdot \sum x_i/x_{i,max}$
where:
-- \f$ x_i \f$: emission mass [g] ( for CO, HC, NOx) or maximum concentration [mg/m^3] ( for soot) during the landing and takeoff cycle,
-- \f$ x_{i,max}\f$: regulatory value defined by ICAO, the ratio of emission mass Dp [g] emitted during LTO and the rated thrust F00 [kN],
-- \f$ n \f$: number of emission species.
+- $ x_i $: emission mass [g] ( for CO, HC, NOx) or maximum concentration [mg/m^3] ( for soot) during the landing and takeoff cycle,
+- $ x_{i,max}$: regulatory value defined by ICAO, the ratio of emission mass Dp [g] emitted during LTO and the rated thrust F00 [kN],
+- $ n $: number of emission species.
## Input-Data {#aqi-schaefer-input}
Only engine and emission data are needed. To construct the engine object, the following is required from acXML:
diff --git a/docs/documentation/analysis/ecological_assessment/getting-started.md b/docs/documentation/analysis/ecological_assessment/getting-started.md
index da59af2..ffa00dd 100644
--- a/docs/documentation/analysis/ecological_assessment/getting-started.md
+++ b/docs/documentation/analysis/ecological_assessment/getting-started.md
@@ -3,7 +3,8 @@
## Tool execution
This guide will show you the basic usage of the _ecological\_assessment_ tool.
-@note It is assumed that you have the `UNICADO Package` installed, including the executables and UNICADO libraries. If you are a developer, you need to build the tool first (see [build instructions on the UNICADO website](https://unicado.pages.rwth-aachen.de/unicado.gitlab.io/developer/build/cpp/)).
+!!! note
+ It is assumed that you have the `UNICADO Package` installed, including the executables and UNICADO libraries. If you are a developer, you need to build the tool first (see [build instructions on the UNICADO website](../../../get-involved/build/cpp/)).
The following steps are necessary:
1. Create a dummy `aircraft_exchange_file` and provide all other required inputs (for submodule-dependent minimal required inputs see [here](#submodules)).
diff --git a/docs/documentation/analysis/ecological_assessment/lca_schaefer.md b/docs/documentation/analysis/ecological_assessment/lca_schaefer.md
index e41ab25..d03f517 100644
--- a/docs/documentation/analysis/ecological_assessment/lca_schaefer.md
+++ b/docs/documentation/analysis/ecological_assessment/lca_schaefer.md
@@ -2,14 +2,15 @@
# LCA_schaefer {#lca-schaefer}
The method is based on the dissertation by Katharina Schäfer (2011) \cite Sch17. It is highly recommended to refer to this work for detailed insights. The method calculates the energy demand and emissions across the aircraft's life cycle phases: development, production, operation, and end-of-life. The following image shows the processes considered.
-
+
## General principles {#lca-schaefer-generalprinciples}
For all processes within the four phases, an inventory analysis is conducted. The function `calculateResources` collects all relevant inputs, such as materials and energy demand. Next, `calculateEmissions` determines the resulting emissions. For background processes, data provided primarily by [GaBi Software](https://ghgprotocol.org/gabi-databases) is used, offering emission data for material extraction, fuel production, energy production, and more.
If recycling is enabled, emissions in the end-of-life phase can be negative, as the emissions saved in the production phase due to recycling are accounted for here.
## Input-Data {#lca-schaefer-input}
-@note The following lists show only the data that is directly read by the module. For data required by the libraries in use, please refer to the respective documentation.
+!!! note
+ The following lists show only the data that is directly read by the module. For data required by the libraries in use, please refer to the respective documentation.
The method reads following data from the acXML file:
```xml
diff --git a/docs/documentation/analysis/ecological_assessment/mission_emissions.md b/docs/documentation/analysis/ecological_assessment/mission_emissions.md
index 08979db..1871d52 100644
--- a/docs/documentation/analysis/ecological_assessment/mission_emissions.md
+++ b/docs/documentation/analysis/ecological_assessment/mission_emissions.md
@@ -6,10 +6,10 @@ The following steps are executed within the mission class:
- `get_mission_data`, `write_emissions_path_csv`, and `get_engine_thermodynamics_LTO`: Data from the `mission.csv` file is imported, engine data for every mission step is determined and saved in a CSV file, and the engine thermodynamics during the landing and takeoff phase according to ICAO definition are calculated.
- Emission calculation: Depending on the defined engine carrier, the emissions will be calculated for every mission step.
- Kerosene:
- - The emissions of CO2, H2O, SO2, and SO4 are considered to be proportional to the fuel flow. Therefore, they are calculated via \f$ m_{emission} = EI * m_{fuel}\f$, with
- - \f$ m_{emission}\f$: emission mass \f$[kg]\f$
- - \f$ EI \f$: emission index \f$[\frac{kg_{emission}}{kg_{fuel}}]\f$
- - \f$ m_{fuel} \f$: fuel mass \f$[kg]\f$
+ - The emissions of CO2, H2O, SO2, and SO4 are considered to be proportional to the fuel flow. Therefore, they are calculated via $ m_{emission} = EI * m_{fuel}$, with
+ - $ m_{emission}$: emission mass $[kg]$
+ - $ EI $: emission index $[\frac{kg_{emission}}{kg_{fuel}}]$
+ - $ m_{fuel} $: fuel mass $[kg]$
- All other emissions are considered to be non-proportional. For NOx emissions, there are a P3T3 Method \cite Nor03, Boeing Fuel Flow Method 2 \cite Sch13, and the calculation based on data generated by GasTurb available. For HC as well as CO emissions, the DLR Omega method and Boeing Fuel Flow Method 2 \cite Sch13 are implemented. Additionally, there is the option to calculate the landing and takeoff cycle emissions based on constants provided by ICAO. Soot emissions can be determined via a DLR correlation based on ICAO smoke numbers or a correlation by R.B. Whyte \cite Kug05. Alternatively, it can be assumed to be proportional to the consumed fuel.
- Hydrogen: Only H2O and NOx emissions are produced.
- H2O is assumed to be proportional to the fuel flow.
diff --git a/docs/documentation/analysis/weight_and_balance_analysis/basic-concepts.md b/docs/documentation/analysis/weight_and_balance_analysis/basic-concepts.md
index a6c77b1..238d4d7 100644
--- a/docs/documentation/analysis/weight_and_balance_analysis/basic-concepts.md
+++ b/docs/documentation/analysis/weight_and_balance_analysis/basic-concepts.md
@@ -18,26 +18,26 @@ Let us start defining the different masses calculated by the tool and how they a
- The **Operating Empty Mass (OEM)** represents the mass of the aircraft which includes the crew, all essential operational fluids and all operator-required items and equipment for flight. It coresponds to the MEM with addition of the operator items mass.
- \f$ OEM = MEM + operator\_items\_mass \f$
+ $ OEM = MEM + operator\_items\_mass $
> [!NOTE]
> The operator items are calculated by both the fueselage design and the systems design module.
- The **Maximum Zero Fuel Mass (MZFM)** is the total mass of the aircraft without any fuel. It is calculated with
- \f$MZFM = OEM + maximum\_payload\_mass \f$
+ $MZFM = OEM + maximum\_payload\_mass $
- The ***maximum payload mass*** is refering to the maximum allowed payload which can be taken on board without violation of the structural limits and capacity constraints. This is defined in the TLARs.
- The **Ferry Range Mass (FRM)** is the mass at which the aircraft can reach the maximum range. For this, no payload is carried and the tanks are filled up with the maximum fuel mass.
- \f$ FRM = OEM + maximum\_fuel\_mass \f$
+ $ FRM = OEM + maximum\_fuel\_mass $
- The ***maximum fuel mass*** is the maximum fuel that can be carried and fits in all tanks up to the maximum capacity, i.e all tanks are full. The tank design module outputs the maximum energy per each designed tank. These are transformed here with the corresponding gravimetric density to a maximum fuel mass per tank and then summed up for all tanks.
- The **Maximum Take-Off Mass (MTOM)** is the mass at which the aircraft takes off. For the design mission this corresponds to the design mass at take-off. Starting with the previously determined OEM, the calculated design fuel at takeoff and the design payload mass are added:
- \f$ MTOM = OEM + design\_fuel\_mass\_takeoff + design\_payload\_mass \f$
+ $ MTOM = OEM + design\_fuel\_mass\_takeoff + design\_payload\_mass $
> [!NOTE]
> The estimated MTOM is an input of the weight and balance analysis tool and is initially written by the _initial\_sizing_ module. Here, it is updated to a mass based on more exact calculation, as the components design and its mass breakdown is now known.
@@ -49,7 +49,7 @@ Let us start defining the different masses calculated by the tool and how they a
- The ***design fuel mass landing*** corresponds to the remaining fuel in the tanks just after the plane touched down. The minimum fuel mass at landing is determined by substracting from the mission fuel mass the trip fuel mass (containing all flight segments) and the taxi fuel mass before the take-off. If no mission information is available, the minimum design fuel mass at landing is calculated by multiplying the design fuel mass at takeoff with factors for the contingency fuel, alternate fuel and the final fuel reserve.
With the knowledge about the OEM, the design payload mass and the design fuel masses at different points during flight, the total design masses of the aircraft at specific times can be calculated:
- - ***design mass mission*** (the mass of the aircraft in the parking position before the start) \f$design\_mass\_mission = OEM + design\_fuel\_mass\_mission + design\_payload\_mass. \f$
+ - ***design mass mission*** (the mass of the aircraft in the parking position before the start) $design\_mass\_mission = OEM + design\_fuel\_mass\_mission + design\_payload\_mass. $
- ***design mass at take-off*** (equal with the MTOM and to the ***design mass*** written in the acxml)
- ***design mass at midflight***
- ***design mass at landing***
@@ -57,12 +57,12 @@ Let us start defining the different masses calculated by the tool and how they a
- The **Maximum Landing Mass (MLM)** is the maximum mass at which the pilot of the aircraft is allowed to attempt to land due to structural or other limits.
Two calculation modes are available:
- based on the mission information and the consumed fuel during flight (`default method`):
- \f$MLM = OEM + design\_fuel\_mass\_landing + design\_payload\_mass \f$
+ $MLM = OEM + design\_fuel\_mass\_landing + design\_payload\_mass $
- via the `RWTH regression method`: This calculation uses different formulas depending on whether the maximum takeoff mass exceeds a threshold value of 15,000 kg.
1. For Aircraft with *MTOM > 15,000 kg* the following empirical formula is used:
- \f$MLM = 1.9689 \times MTOM^{0.9248}\f$
+ $MLM = 1.9689 \times MTOM^{0.9248}$
2. For Aircraft with *MTOM ≤ 15,000 kg* a linear approximation is used:
- \f$MLM = 0.9009 \times MTOM + 410.85 \f$
+ $MLM = 0.9009 \times MTOM + 410.85 $
Additionally, two masses are calculated for the case that the aircraft flies either with maximum payload mass or with maximum fuel mass. In both cases the difference up to MTOM is completed with fuel or payload respectively. Based on the loading diagramm, the masses at the most forward and most aft CG positions are also determined.
@@ -71,16 +71,16 @@ Additionally, two masses are calculated for the case that the aircraft flies eit
The knowledge of the center of gravity (CG) position and movement is necessary to ensure the static stability and controllability of the aircraft on the ground and in the air. Based on the results of the detailed mass breakdown of the components with their _mass properties_ information, the total center of gravity of the aircraft can now be determined. The position of the overall CG can generally be determined from the position of the individual centers of gravity w.r.t. a global reference point.
-The calculation involves determining the weighted average of the CG positions for all components. For each axis (_x, y ,z_), the function sums the scaled masses, which are the product of a component’s mass and its CG coordinate for the respective axis. This sum is then divided by the total mass of all components to yield the final CG coordinate for that axis. The global center of gravity (\f$ \text{CG} \f$) for a specific axis (\f$ \text{ax} \f$) is calculated as:
+The calculation involves determining the weighted average of the CG positions for all components. For each axis (_x, y ,z_), the function sums the scaled masses, which are the product of a component’s mass and its CG coordinate for the respective axis. This sum is then divided by the total mass of all components to yield the final CG coordinate for that axis. The global center of gravity ($ \text{CG} $) for a specific axis ($ \text{ax} $) is calculated as:
-\f$
+$
\text{CG}_{\text{ax}} = \frac{\sum_{i=1}^n (m_i \cdot x_i)}{\sum_{i=1}^n m_i}
-\f$
+$
Where:
-- \f$ m_i \f$ is the mass of the \f$ i \f$-th component.
-- \f$ x_i \f$ is the coordinate of the \f$ i \f$-th component along the \f$ \text{ax} \f$.
-- \f$ n \f$ is the total number of components.
+- $ m_i $ is the mass of the $ i $-th component.
+- $ x_i $ is the coordinate of the $ i $-th component along the $ \text{ax} $.
+- $ n $ is the total number of components.
> [!NOTE]
> It is often common to specify the center of gravity as %MAC.
@@ -129,32 +129,32 @@ Finally, the **most forward and most aft _x_-CG positions** and the correspondin
---
## Mass Moments of Inertia {#inertia}
-Inertia forces arise from the tendency of mass to resist accelerations. For rotational accelerations, these forces are represented by the **mass moment of inertia** terms.These are critical parameters in the analysis and design of aircraft, as they determine the rotational dynamics about the principal axes: roll, pitch, and yaw. These values influence stability, control responsiveness, and handling qualities. The moments of inertia are calculated relative to an axis and depend on the mass distribution of the aircraft. The cross products of inertia (e.g., \f$ I_{xy} \f$) arise when the axes are not aligned with the principal axes of the mass distribution.
+Inertia forces arise from the tendency of mass to resist accelerations. For rotational accelerations, these forces are represented by the **mass moment of inertia** terms.These are critical parameters in the analysis and design of aircraft, as they determine the rotational dynamics about the principal axes: roll, pitch, and yaw. These values influence stability, control responsiveness, and handling qualities. The moments of inertia are calculated relative to an axis and depend on the mass distribution of the aircraft. The cross products of inertia (e.g., $ I_{xy} $) arise when the axes are not aligned with the principal axes of the mass distribution.
In this context the mass moments of inertia about the three principal axes
-- \f$ I_{xx} \f$: About the roll axis
-- \f$ I_{yy} \f$: About the pitch axis
-- \f$ I_{zz} \f$: About the yaw axis
+- $ I_{xx} $: About the roll axis
+- $ I_{yy} $: About the pitch axis
+- $ I_{zz} $: About the yaw axis
> [!NOTE]
> The mass moments of inertia are calculated only for the total masses.
are determined determined by means of the following ***calculation methods:***
#### 1. Using Raymer's Empirical Equations
-*Raymer* provides empirical formulas to estimate the moments of inertia based on the aircraft's geometry and mass distribution. These equations are derived from historical data based on nondimensional radii of gyration (\f$ R_x \f$, \f$ R_y \f$, \f$ R_z \f$) and are suitable for early design phases where detailed component-level data may not be available. The mass moments of inertia are given as follows:
+*Raymer* provides empirical formulas to estimate the moments of inertia based on the aircraft's geometry and mass distribution. These equations are derived from historical data based on nondimensional radii of gyration ($ R_x $, $ R_y $, $ R_z $) and are suitable for early design phases where detailed component-level data may not be available. The mass moments of inertia are given as follows:
-- **Roll**: \f$I_{xx} = \frac{b^2 M R_x^2}{4} \cdot f_{xx}\f$
-- **Pitch**: \f$I_{yy} = \frac{l^2 M R_y^2}{4} \cdot f_{yy} \f$
-- **Yaw:** \f$I_{zz} = \frac{\left( \frac{b + l}{2} \right)^2 M R_z^2}{4}\f$
+- **Roll**: $I_{xx} = \frac{b^2 M R_x^2}{4} \cdot f_{xx}$
+- **Pitch**: $I_{yy} = \frac{l^2 M R_y^2}{4} \cdot f_{yy} $
+- **Yaw:** $I_{zz} = \frac{\left( \frac{b + l}{2} \right)^2 M R_z^2}{4}$
Where:
-- \f$ b \f$: Wingspan
-- \f$ l \f$: Fuselage length
-- \f$ M \f$: Aircraft mass
-- \f$f_{xx}\f$ and \f$f_{yy}\f$: Technology factors set to \f$1.25\f$ respectively \f$1.15\f$
-- \f$ R_x, R_y, R_z \f$: Nondimensional radii of gyration. The following values are implemented:
+- $ b $: Wingspan
+- $ l $: Fuselage length
+- $ M $: Aircraft mass
+- $f_{xx}$ and $f_{yy}$: Technology factors set to $1.25$ respectively $1.15$
+- $ R_x, R_y, R_z $: Nondimensional radii of gyration. The following values are implemented:
-| **Aircraft Configuration** | \f$ R_x \f$ | \f$ R_y \f$ | \f$ R_z \f$ |
+| **Aircraft Configuration** | $ R_x $ | $ R_y $ | $ R_z $ |
|-----------------------------------------|-----------|-----------|-----------|
| Fuselage-mounted engines | 0.24 | 0.34 | 0.42 |
| 2 wing-mounted engines | 0.23 | 0.33 | 0.45 |
@@ -163,50 +163,50 @@ Where:
#### 2. Using the LTH Tables (*Luftfahrttechnisches Handbuch*)
-The LTH provides tabulated values and empirical methods specific to various aircraft configurations. These tables account for typical mass distributions and structural layouts. They are more accurate than Raymer’s approach but require knowledge of the specific aircraft class and design. The `calculate_inertia_by_lth_method` function is tailored specifically for conventional tube-and-wing configurations. This method uses aircraft mass properties like the OEM, the payload mass (\f$m_{payload}\f$) and the fuel mass (\f$m_{fuel}\f$) and geometric dimensions such as wing span \f$b\f$ and fuselage length \f$l\f$. All cross-product terms (\f$I_{xy}\f$, \f$I_{xz}\f$, etc.) are set to \f$0\f$, assuming symmetry.
+The LTH provides tabulated values and empirical methods specific to various aircraft configurations. These tables account for typical mass distributions and structural layouts. They are more accurate than Raymer’s approach but require knowledge of the specific aircraft class and design. The `calculate_inertia_by_lth_method` function is tailored specifically for conventional tube-and-wing configurations. This method uses aircraft mass properties like the OEM, the payload mass ($m_{payload}$) and the fuel mass ($m_{fuel}$) and geometric dimensions such as wing span $b$ and fuselage length $l$. All cross-product terms ($I_{xy}$, $I_{xz}$, etc.) are set to $0$, assuming symmetry.
The mass moments of inertia around the principal axes are given as follows:
- **Roll**:
- \f$
+ $
I_{xx} = f_{xx} \cdot K_x^2 \cdot b^2 \cdot m_m
- \f$
+ $
- **Pitch**:
- \f$
+ $
I_{yy} = f_{yy} \cdot K_y^2 \cdot l^2 \cdot m_m
- \f$
+ $
- **Yaw**:
- \f$
+ $
I_{zz} = 0.96 \cdot (I_{xx} + I_{yy})
- \f$
+ $
-Here, \f$f_{xx}\f$ and \f$f_{yy}\f$ are technology factors set to \f$0.8\f$ respectively \f$0.9\f$. The expected mass \f$M\f$ and the scaling factors \f$K_x\f$ and \f$K_y\f$, derived from empirical LTH tables, are defined as:
+Here, $f_{xx}$ and $f_{yy}$ are technology factors set to $0.8$ respectively $0.9$. The expected mass $M$ and the scaling factors $K_x$ and $K_y$, derived from empirical LTH tables, are defined as:
- \f$ M = OME + m_{payload} + m_{fuel} \f$
+ $ M = OME + m_{payload} + m_{fuel} $
- \f$ K_x = \frac{1}{12} \left( \left[ - \frac{2}{3} \cdot \left(\frac{M}{OME}- 1\right) + \frac{m_{fuel}}{OME} \right] +1 \right) + 0.065 \f$
+ $ K_x = \frac{1}{12} \left( \left[ - \frac{2}{3} \cdot \left(\frac{M}{OME}- 1\right) + \frac{m_{fuel}}{OME} \right] +1 \right) + 0.065 $
- \f$ K_y = -\frac{0.065}{1.72} \left[ 0.2 \cdot \left(\frac{M}{OME}- 1\right) + \frac{m_{fuel}}{OME} \right] + 0.2025 \f$
+ $ K_y = -\frac{0.065}{1.72} \left[ 0.2 \cdot \left(\frac{M}{OME}- 1\right) + \frac{m_{fuel}}{OME} \right] + 0.2025 $
#### 3. Using the Component's Inertia
-This method involves calculating the total inertia tensor of the aircraft based on its components' individual mass properties. For each inertia component (\f$I_{xx}\f$, \f$I_{xy}\f$, etc.), the function adds the component's intrinsic inertia and the inertia due to its offset from the reference CG (using the Steiner theorem). The mass moments of inertia are given exemplary
+This method involves calculating the total inertia tensor of the aircraft based on its components' individual mass properties. For each inertia component ($I_{xx}$, $I_{xy}$, etc.), the function adds the component's intrinsic inertia and the inertia due to its offset from the reference CG (using the Steiner theorem). The mass moments of inertia are given exemplary
-- around the principal axes (\f$I_{xx}\f$, \f$I_{yy}\f$,\f$I_{zz}\f$):
-\f$
+- around the principal axes ($I_{xx}$, $I_{yy}$,$I_{zz}$):
+$
I_{xx} = \sum (I_{xx},{\text{component}} + m_{\text{component}} \cdot (p^2 + q^2))
-\f$
-- around the deviation axes (cross-product terms \f$I_{xy}\f$, \f$I_{xz}\f$, etc.):
-\f$
+$
+- around the deviation axes (cross-product terms $I_{xy}$, $I_{xz}$, etc.):
+$
I_{xy} = \sum (I_{xy},{\text{component}} + m_{\text{component}} \cdot -(p \cdot q))
-\f$
+$
-with \f$p\f$ and \f$q\f$ representing the relative distances between the reference center of gravity (CG) and the current component's CG along the specified axes. Specifically:
-- \f$ p \f$: The distance along the first axis (e.g., x, y, or z).
-- \f$ q \f$: The distance along the second axis (e.g., x, y, or z).
+with $p$ and $q$ representing the relative distances between the reference center of gravity (CG) and the current component's CG along the specified axes. Specifically:
+- $ p $: The distance along the first axis (e.g., x, y, or z).
+- $ q $: The distance along the second axis (e.g., x, y, or z).
> [!NOTE]
> The component's moments of inertia, if available, are calculated in the component's design modules. Otherwise, these are 0.
diff --git a/docs/documentation/analysis/weight_and_balance_analysis/usage.md b/docs/documentation/analysis/weight_and_balance_analysis/usage.md
index 5185edd..117b548 100644
--- a/docs/documentation/analysis/weight_and_balance_analysis/usage.md
+++ b/docs/documentation/analysis/weight_and_balance_analysis/usage.md
@@ -57,7 +57,8 @@ The _weight\_and\_balance\_analysis\_conf.xml_ is structured into two blocks: th
- the `aircraft_exchange_file_name` and `aircraft_exchange_file_directory` to your respective settings,
- the `console_output` at least to `mode_1`, and
-@note If the tool is executed via the workflow, those settings are set by the workflow settings.
+!!! note
+ If the tool is executed via the workflow, those settings are set by the workflow settings.
## Method Selection {#method-selection}
By changing the program settings im the configXML we can manipulate how the w&b analysis tool is running. The program settings are structured like this:
diff --git a/docs/documentation/libraries/aircraftGeometry2/index.md b/docs/documentation/libraries/aircraftGeometry2/index.md
index 5286723..2d692b3 100644
--- a/docs/documentation/libraries/aircraftGeometry2/index.md
+++ b/docs/documentation/libraries/aircraftGeometry2/index.md
@@ -15,7 +15,8 @@ Before we dive into the coordinate systems however, let's get to know how the ac
@attention → This library does only support discrete shapes. Meaning the shapes are **always** polygons where the discrete vertices of the polygon are connected with lines which form the edges of the polygon.
-@note The Python binding of this library does __not__ include a complete implementation of **CGAL**!
+!!! note
+ The Python binding of this library does __not__ include a complete implementation of **CGAL**!
If you want to use the full flexibility of **CGAL** you need to implement your tool in C++.
---
@@ -55,7 +56,8 @@ Note, that the library rather uses sections and not segments and therefore does
The main extrusion direction of the surface is along the local `Z` axis.
The origin points of each section are 3D coordinates and define the location of the section within the surface coordinate space. By moving the origin point, the complete section gets moved as well.
-@note The order how you insert the sections in the surface **does** matter as it defines how the sections are connected.
+!!! note
+ The order how you insert the sections in the surface **does** matter as it defines how the sections are connected.
The surfaces themselves have an origin point which defines their location in the 3D space of some parent entity.
@@ -103,20 +105,21 @@ That is not enough to represent arbitrary geometry. You need a mechanism to orie
The normal direction basically defines the direction where the local `Z` axis should point to within a parent scope.
The direction is defined using the [Direction_3](@ref geom2.Direction_3) class of **CGAL** and is a vector in 3D space. Although, this class is technically not concerned about the length of the vector, it is a good idea to make sure, that the resulting length of the normal direction is equal to **1.0**.
-The definition of this normal direction is not enough to unambiguously define the three Euler angles which are needed for the coordinate transform. The normal direction can only define **two** of the three angles. As a consequence, the third Euler angle \f$\gamma\f$ has to be set manually using the `rotation_z` property of the geom2::Entity3D class.
+The definition of this normal direction is not enough to unambiguously define the three Euler angles which are needed for the coordinate transform. The normal direction can only define **two** of the three angles. As a consequence, the third Euler angle $\gamma$ has to be set manually using the `rotation_z` property of the geom2::Entity3D class.
This angle applies a rotation around the local `Z` axis whenever the coordinates of the geometry are transformed to another coordinate system.
-@note The handling of the third Euler angle can still be subjected to change.
+!!! note
+ The handling of the third Euler angle can still be subjected to change.
The usage of the Euler angles can lead to unintuitive results, but that is unfortunately the nature of those angles. Here are some results of Euler angles with different normal directions:
-|Normal Direction | Euler Angle \f$\alpha\f$ | Euler Angle \f$\beta\f$ | Euler Angle \f$\gamma\f$ |
+|Normal Direction | Euler Angle $\alpha$ | Euler Angle $\beta$ | Euler Angle $\gamma$ |
| --- | :---: | :---: | :---: |
|`[0, 0, 1]` | 0° | 0° | 0° |
|`[0, 1, 1]` | -45° | 0° | 0° |
|`[1, 0, 1]` | 45° | 0° | 90° |
Understanding the relationship of the normal direction and the Euler angles of this table is key to understand the 3D coordinate transformation with rotation.
-**Most importantly,** the last case, where a "simple" rotation around the `Y` axis leads to *two* non-zero angles, especially the third angle \f$\gamma\f$ is not zero any more as opposed to the initial assumption! That is again due to the fact how Euler angles work...
+**Most importantly,** the last case, where a "simple" rotation around the `Y` axis leads to *two* non-zero angles, especially the third angle $\gamma$ is not zero any more as opposed to the initial assumption! That is again due to the fact how Euler angles work...
In the end, you do not need to understand this in great detail to use the library, just be aware, that certain normal directions can lead to a final orientation which was not the one you expected. In such cases, you can use the `rotation_z` parameter to adjust.
@@ -125,4 +128,5 @@ Here is an overview how the library is structured:
{html: width=1000}
-@note This is still work in progress and can change!
+!!! note
+ This is still work in progress and can change!
diff --git a/docs/documentation/libraries/aircraftGeometry2/tutorial-convert.md b/docs/documentation/libraries/aircraftGeometry2/tutorial-convert.md
index 93b1c31..7747cc7 100644
--- a/docs/documentation/libraries/aircraftGeometry2/tutorial-convert.md
+++ b/docs/documentation/libraries/aircraftGeometry2/tutorial-convert.md
@@ -12,14 +12,16 @@ You have the specify how the converter "treats" this surface, since certain form
You can select the surface function base on type by using the surface type variant geom2::io::SurfaceType.
Depending on which type you select for the variant the converter will treat the surface accordingly.
-@note The python bindings do work differently. They use the same underlying functions, but the interface does not enable the polymorphic use (yet)!
+!!! note
+ The python bindings do work differently. They use the same underlying functions, but the interface does not enable the polymorphic use (yet)!
## Convert to aixml::node Object
The following tutorial will show you how you can convert a multi-section surface as a wing surface node to the aircraft XML using the geom2::io::AixmlConverter class.
The *aixml* library will not be discussed in detail in this tutorial.
Refer to its [documentation](https://www.google.de) if you need further information.
-@note The Python examples assume that you imported the following modules:
+!!! note
+ The Python examples assume that you imported the following modules:
```python
import pyaircraftGeometry2 as geom2
import pyaixml as aixml
diff --git a/docs/documentation/libraries/aircraftGeometry2/tutorial-factory.md b/docs/documentation/libraries/aircraftGeometry2/tutorial-factory.md
index 189b70a..1ba48f5 100644
--- a/docs/documentation/libraries/aircraftGeometry2/tutorial-factory.md
+++ b/docs/documentation/libraries/aircraftGeometry2/tutorial-factory.md
@@ -7,10 +7,11 @@ The factory classes follow the *factory design pattern*, hence the name.
The idea is, that you give this "factory" a **build plan** of what you want and the factory produces or creates the **item** for you.
In our case, the build plan is the *aircraft XML file* and the items are the *resulting surfaces*.
-@note The concept how the geometry is encoded in den aircraft XML file **differs** from the concept used in this library!
-The main difference is, that the library uses sections rather than segments!
-The factories translate the data of the aircraft XML to the surface concept of this library.
-Although, this might change in future release if the aircraft XML structure.
+!!! note
+ The concept how the geometry is encoded in den aircraft XML file **differs** from the concept used in this library!
+ The main difference is, that the library uses sections rather than segments!
+ The factories translate the data of the aircraft XML to the surface concept of this library.
+ Although, this might change in future release if the aircraft XML structure.
The library has factories for all major components of the aircraft geometry as they are currently defined in the aircraft XML file:
- @ref hull_factory
@@ -20,7 +21,8 @@ The library has factories for all major components of the aircraft geometry as t
- @ref spar_factory
- @ref control_device_factory
-@note The Python examples assume that you imported the following modules:
+!!! note
+ The Python examples assume that you imported the following modules:
```python
import pyaircraftGeometry2 as geom2
import pyaixml as aixml
@@ -121,7 +123,8 @@ factory = geom2.factory.HullFactory(AcXML, "./geometryData")
</div>
-@note You can omit the path `"./geometryData"` for the *version 2.0.0* aircraft exchange files and just give an empty string. The factories then will search for the directory as explained before.
+!!! note
+ You can omit the path `"./geometryData"` for the *version 2.0.0* aircraft exchange files and just give an empty string. The factories then will search for the directory as explained before.
After creating the factory with the existing aircraft XML data, the factory knows what to do and you can ask it to create the complete surface for you.
The aircraft XML can contain several surfaces of the same type, but with a different id.
@@ -270,8 +273,9 @@ wing = factory.create("LiftingSurface@MainWing")
</div>
-@note The wing factory does **not** produces discontinuous sections!
-It takes the inner length of the first segment as the length for the first section and then continuous by using the outer length of the following segments from the aircraft XML file!
+!!! note
+ The wing factory does **not** produces discontinuous sections!
+ It takes the inner length of the first segment as the length for the first section and then continuous by using the outer length of the following segments from the aircraft XML file!
### Spar Factory {#spar_factory}
> **XML Example:** `aircraftGeometry2/test/stubs/aixml-v2/wing.xml`
@@ -307,10 +311,11 @@ spar = factory.create("LiftingSurface@MainWing")
</div>
-@note This factory returns a multi-section surface which contains geom2::PolygonSection as the section type.
-Be aware, that the spar geometry is **not** considered an airfoil shape in the context of this library.
-The extrusion direction, however, is the **negative** local `Z` direction as for the airfoil surfaces, so that the spar geometry is at the same location as the wing geometry.
-The origin point of the spar is the same as the wing origin as well.
+!!! note
+ This factory returns a multi-section surface which contains geom2::PolygonSection as the section type.
+ Be aware, that the spar geometry is **not** considered an airfoil shape in the context of this library.
+ The extrusion direction, however, is the **negative** local `Z` direction as for the airfoil surfaces, so that the spar geometry is at the same location as the wing geometry.
+ The origin point of the spar is the same as the wing origin as well.
The spar factory just returns the spar surface and **not** the wing surface.
You have to use the wing factory separately to create the wing surface.
@@ -365,7 +370,8 @@ The node defining the geometry file in the aircraft XML simply looks like this:
```
The library will then try to use a `n0012.dat` file from the `data_directory` you have given it.
-@note In the following examples it is assumed, that you have the same directory structure for the *version 3.0.0* XML files as for the *version 2.0.0* files in @ref tutorial_aixml_v2 !
+!!! note
+ In the following examples it is assumed, that you have the same directory structure for the *version 3.0.0* XML files as for the *version 2.0.0* files in @ref tutorial_aixml_v2 !
### Hull Factory
> **XML Example:** `aircraftGeometry2/test/stubs/aixml-v3/hull.xml`
@@ -391,7 +397,8 @@ factory = geom2.factory.HullFactory(AcXML, "./geometryData")
</div>
-@note You **cannot** omit the path `"./geometryData"` for the *version 3.0.0* aircraft exchange files!
+!!! note
+ You **cannot** omit the path `"./geometryData"` for the *version 3.0.0* aircraft exchange files!
- Get **nacelle** with the id `0` from the factory:
@@ -497,10 +504,11 @@ spar = factory.create("wing/specific/geometry/aerodynamic_surface@0/spars/spar@0
</div>
-@note This factory returns a multi-section surface which contains geom2::PolygonSection as the section type.
-Be aware, that the spar geometry is **not** considered an airfoil shape in the context of this library.
-The extrusion direction, however, is the **negative** local `Z` direction as for the airfoil surfaces, so that the spar geometry is at the same location as the wing geometry.
-The origin point of the spar is the same as the wing origin as well.
+!!! note
+ This factory returns a multi-section surface which contains geom2::PolygonSection as the section type.
+ Be aware, that the spar geometry is **not** considered an airfoil shape in the context of this library.
+ The extrusion direction, however, is the **negative** local `Z` direction as for the airfoil surfaces, so that the spar geometry is at the same location as the wing geometry.
+ The origin point of the spar is the same as the wing origin as well.
The spar factory just returns the spar surface and **not** the wing surface.
You have to use the wing factory separately to create the wing surface.
diff --git a/docs/documentation/libraries/aircraftGeometry2/tutorial-geometry.md b/docs/documentation/libraries/aircraftGeometry2/tutorial-geometry.md
index fa4f26c..4424658 100644
--- a/docs/documentation/libraries/aircraftGeometry2/tutorial-geometry.md
+++ b/docs/documentation/libraries/aircraftGeometry2/tutorial-geometry.md
@@ -5,7 +5,8 @@ The resulting images of each step are not part of the library, though.
Those images are rendered with a 3D animation software after the geometry is exported as a `*.ply` file after each step.
The tutorial will show as a last step, how this is done.
-@note The Python examples assume that you imported the module with:
+!!! note
+ The Python examples assume that you imported the module with:
```python
import pyaircraftGeometry2 as geom2
```
@@ -37,7 +38,8 @@ shape = geom2.io.read_dat_file("aircraftGeometry2/test/stubs/dat-files/circle-ta
</div>
-@note Make sure the path to the file is correct according to your current working directory!
+!!! note
+ Make sure the path to the file is correct according to your current working directory!
This will give you the following 2D polygon:
@@ -171,7 +173,8 @@ surface.sections[0].origin = geom2.Point_3(-0.5,0,0);
</div>
-@note **CGAL** does not supply a mechanism to change single components of points or vectors. You always have to assign a complete new set of coordinates. However, you can read the value of single coordinate components.
+!!! note
+ **CGAL** does not supply a mechanism to change single components of points or vectors. You always have to assign a complete new set of coordinates. However, you can read the value of single coordinate components.
As you can see, the bottom section moved in negative X direction:
@@ -210,7 +213,8 @@ The local coordinate system of the surface remains unchanged.
You can also see that the orientation introduced a rotation around the local `Z` axis in this case, again see @ref euler_angles why this is.
For the expected result you need to set the parameter `rotate_z` of the surface.
-@note This behavior is admittedly not the most intuitive result. In further release this might get fixed. In a practical point of view, you are most often interested in properties within the local coordinate system of the surface rather then global properties in between multiple surfaces.
+!!! note
+ This behavior is admittedly not the most intuitive result. In further release this might get fixed. In a practical point of view, you are most often interested in properties within the local coordinate system of the surface rather then global properties in between multiple surfaces.
### Step 7 - Move Surface
As for moving the location of a section, the same principle applies when moving the surface within the global 3D space.
@@ -259,7 +263,8 @@ width = geom2.measure.width(surface, 0.5)
This should result in `width = 0.75`.
-@note There are measurement functions which use additional properties of the geom2::MultisectionSurface as their input, because their result depends on more information than contained in the *sections* vector. See the documentation of each measurement for more information.
+!!! note
+ There are measurement functions which use additional properties of the geom2::MultisectionSurface as their input, because their result depends on more information than contained in the *sections* vector. See the documentation of each measurement for more information.
### Step 9 - Export PLY (optional)
As an optional step, you can export your surface as a triangulated surface mesh in the **PLY** format.
@@ -281,7 +286,8 @@ geom2.io.export_ply(surface, "./mesh.ply")
</div>
-@note This function is rather a debugging tool than a fully tested tool for production use!
+!!! note
+ This function is rather a debugging tool than a fully tested tool for production use!
---
diff --git a/docs/documentation/sizing/fuselage_design/design_method.md b/docs/documentation/sizing/fuselage_design/design_method.md
index 5bba67a..fdd1ec8 100644
--- a/docs/documentation/sizing/fuselage_design/design_method.md
+++ b/docs/documentation/sizing/fuselage_design/design_method.md
@@ -5,82 +5,83 @@
- [Estimation of masses](#mass-estimation)
- [Generation of fuselage shape](#generate-shape)
-@note Currently the tool supports only one fuselage with one payload tube.
+!!! note
+ Currently the tool supports only one fuselage with one payload tube.
## Determine cabin geometry {#cabin-geometry}
### Cabin width
The cabin width is estimated using the given class definition.
#### Determine width of seat row per aircraft side
-The width of one seat row/bench \f$w_{seat\_bench}\f$ (in inch) can be determined for the left and right side of the aircraft using the following equation:
-\f[
+The width of one seat row/bench $w_{seat\_bench}$ (in inch) can be determined for the left and right side of the aircraft using the following equation:
+$
w_{seat\_bench} = n_{seats} \cdot w_{seat} + 2 \cdot w_{armrest}
-\f]
+$
In which
-- \f$n_{seats}\f$ - number of seats per seat bench
-- \f$w_{seat}\f$ - seat width (taken from lowest class seat)
-- \f$w_{armrest}\f$ - armrest width (taken from lowest class seat)
+- $n_{seats}$ - number of seats per seat bench
+- $w_{seat}$ - seat width (taken from lowest class seat)
+- $w_{armrest}$ - armrest width (taken from lowest class seat)
#### Calculate cabin width
-The cabin width \f$w_{cabin}\f$ (in inch) can then be calculated:
-\f[
+The cabin width $w_{cabin}$ (in inch) can then be calculated:
+$
w_{cabin} = w_{aisle} + w_{seat\_bench\_left} + w_{seat\_bench\_right} + 2 \cdot w_{seat\_space}
-\f]
+$
In which
-- \f$w_{aisle}\f$ - passenger aisle width
-- \f$w_{seat\_space}\f$ - lowest class seat space
+- $w_{aisle}$ - passenger aisle width
+- $w_{seat\_space}$ - lowest class seat space
-In case of a **wide-body aircraft configuration** there is an additional row in the middle of the aircraft as well as an additional passenger aisle. The width of the seat bench \f$w_{seat\_bench\_center}\f$ can be calculated using an equation similar to that in the previous section.
-\f[
+In case of a **wide-body aircraft configuration** there is an additional row in the middle of the aircraft as well as an additional passenger aisle. The width of the seat bench $w_{seat\_bench\_center}$ can be calculated using an equation similar to that in the previous section.
+$
w_{seat\_bench\_center} = n_{seats} \cdot w_{seat} + 2 \cdot w_{armrest\_outer} + (n_{seats} - 1) \cdot w_{armrest\_inner}
-\f]
+$
In which
-- \f$w_{seat}\f$ - seat width (from lowest class seat parameters of right side)
-- \f$w_{armrest\_outer}\f$ - width of outer armrest (from lowest class seat parameters of right side)
-- \f$w_{armrest\_inner}\f$ - width of inner armrest (from lowest class seat parameters of right side)
+- $w_{seat}$ - seat width (from lowest class seat parameters of right side)
+- $w_{armrest\_outer}$ - width of outer armrest (from lowest class seat parameters of right side)
+- $w_{armrest\_inner}$ - width of inner armrest (from lowest class seat parameters of right side)
The equation for the cabin width estimation must be adapted accordingly:
-\f[
+$
w_{cabin} = w_{aisle} + w_{seat\_bench\_left} + w_{seat\_bench\_right} + 2 \cdot w_{seat\_space} + w_{aisle} + w_{seat\_bench\_center}
-\f]
+$
### Cabin slenderness ratio <sup>[1]</sup>
-The cabin slenderness ratio describes the ratio of cabin width to cabin length \f$\frac{w_{cabin}}{l_{cabin}}\f$.
+The cabin slenderness ratio describes the ratio of cabin width to cabin length $\frac{w_{cabin}}{l_{cabin}}$.
Whilst the cabin width is already known, the cabin length can be determined using the following equation:
-\f[
+$
l_{cabin} = \frac{n_{PAX\_per\_class}}{ab} \cdot \left[ sp + \frac{a_{service}}{w_{seat}} + \frac{a_{bulk}}{\frac{w_{aisle}}{ab} + w_{seat}} + x \cdot w_{exit} \cdot \left( \frac{ab}{n_{PAX\_per\_class}} + \frac{sp}{d_{exits}} \right) \right]
-\f]
+$
In which
-- \f$x\f$ - factor (1 for single-aisle, 2 for wide-body)
-- \f$n_{PAX\_per\_class}\f$ - number of PAX per class
-- \f$ab\f$ - seat abreast
-- \f$sp\f$ - seat pitch
-- \f$a_{service}\f$ - service area per PAX
-- \f$a_{bulk}\f$ - bulk area per PAX
-- \f$w_{exit}\f$ - exit width
-- \f$d_{exits}\f$ - maximum distance between two exits
+- $x$ - factor (1 for single-aisle, 2 for wide-body)
+- $n_{PAX\_per\_class}$ - number of PAX per class
+- $ab$ - seat abreast
+- $sp$ - seat pitch
+- $a_{service}$ - service area per PAX
+- $a_{bulk}$ - bulk area per PAX
+- $w_{exit}$ - exit width
+- $d_{exits}$ - maximum distance between two exits
### Cabin length
Knowing the cabin width and the cabin slenderness ratio, the cabin length (in inch) can be calculated:
-\f[
+$
l_{cabin} = \frac{w_{cabin}}{\frac{w_{cabin}}{l_{cabin}}}
-\f]
+$
### Cabin wall thickness
The cabin wall thickness can be estimated using the following calculation:
-\f[
+$
t_{wall} = 0.02 \cdot w_{cabin} + 2.5"
-\f]
+$
### Cabin floor thickness
With the use of the cabin wall thickness, the cabin floor thickness can be calculated:
-\f[
+$
t_{floor} = 1.5 \cdot t_{wall}
-\f]
+$
## Determine fuselage geometry {#fuselage-geometry}
With the calculated cabin the fuselage dimensions can be estimated.
@@ -89,14 +90,14 @@ With the calculated cabin the fuselage dimensions can be estimated.
The fuselage length can be determined via regression formulas using the cabin length (in meter).
For single-aisle aircraft:
-\f[
+$
l_{fuselage} = \frac{l_{cabin}}{0.23482756 \cdot \log l_{cabin} - 0.05106017}
-\f]
+$
For wide-body aircraft:
-\f[
+$
l_{fuselage} = \frac{l_{cabin}}{0.1735 \cdot \log l_{cabin} - 0.0966}
-\f]
+$
### Fuselage diameters
The fuselage does not necessarily have a circular cross-section. It is more common to design elliptical cross-sections. Because of that, there are several values that must be determined:
@@ -105,65 +106,66 @@ The fuselage does not necessarily have a circular cross-section. It is more comm
- Fuselage diameter in positive z-direction
#### Fuselage diameter in y-direction
-The fuselage diameter in y-direction \f$d_{fuselage\_y}\f$ can be calculated in the following way:
-\f[
+The fuselage diameter in y-direction $d_{fuselage\_y}$ can be calculated in the following way:
+$
d_{fuselage\_y} = w_{cabin} + 2 \cdot t_{wall}
-\f]
+$
#### Fuselage diameter in negative z-direction
-The fuselage diameter in negative z-direction \f$d_{fuselage\_z\_neg}\f$ is determined by the cargo accommodation. It can be calculated in the following way.
+The fuselage diameter in negative z-direction $d_{fuselage\_z\_neg}$ is determined by the cargo accommodation. It can be calculated in the following way.
At first, the distance to the cargo bottom is calculated:
-\f[
+$
d_{to\_cargo\_bottom} = h_{max} + t_{floor} + d_{container\_to\_ceil} + o_{cabin\_floor}
-\f]
+$
In which
-- \f$h_{max}\f$ - maximum height of unit load device
-- \f$d_{container\_to\_ceil}\f$ - distance from the container to the ceiling
-- \f$o_{cabin\_floor}\f$ - offset cabin floor
+- $h_{max}$ - maximum height of unit load device
+- $d_{container\_to\_ceil}$ - distance from the container to the ceiling
+- $o_{cabin\_floor}$ - offset cabin floor
Afterwards, the distance to the lower compartment edge is estimated:
-\f[
+$
d_{to\_lower\_compartment\_edge} = d_{container\_to\_wall} + 0.5 \cdot w_{max\_at\_base}
-\f]
+$
In which
-- \f$d_{container\_to\_wall}\f$ - distance from container to wall
-- \f$w_{max\_at\_base}\f$ - maximum width at container base
+- $d_{container\_to\_wall}$ - distance from container to wall
+- $w_{max\_at\_base}$ - maximum width at container base
Based on the Pythagorean theorem, the inner fuselage diameter (that equals the hypotenuse) can be calculated:
-\f[
+$
d_{inner\_fuselage\_z\_neg} = \sqrt{(d_{to\_cargo\_bottom})^2 + (d_{to\_lower\_compartment\_edge})^2}
-\f]
+$
Adding the wall thickness results in the fuselage diameter in negative z-direction:
-\f[
+$
d_{fuselage\_z\_neg} = d_{inner\_fuselage\_z\_neg} + t_{wall}
-\f]
+$
#### Fuselage diameter in positive z-direction
-The fuselage diameter in positive z-direction \f$d_{fuselage\_z\_pos}\f$ is determined by the passenger accommodation. It can be calculated in the following way.
+The fuselage diameter in positive z-direction $d_{fuselage\_z\_pos}$ is determined by the passenger accommodation. It can be calculated in the following way.
Firstly, the inner fuselage height (equals outer cabin height) can be determined:
-\f[
+$
d_{inner\_fuselage\_z\_pos} = h_{aisle\_standing} - o_{cabin\_floor} + h_{system\_bay}
-\f]
+$
In which
-- \f$h_{aisle\_standing}\f$ - passenger aisle standing height
-- \f$o_{cabin\_floor}\f$ - cabin floor offset
-- \f$h_{system\_bay}\f$ - system bay height above cabin
+- $h_{aisle\_standing}$ - passenger aisle standing height
+- $o_{cabin\_floor}$ - cabin floor offset
+- $h_{system\_bay}$ - system bay height above cabin
Adding the wall thickness leads to the fuselage diameter in positive z-direction.
-\f[
+$
d_{fuselage\_z\_pos} = d_{inner\_fuselage\_z\_pos} + t_{wall}
-\f]
+$
### Fuselage height
The total height of the fuselage can be determined by summing up the fuselage diameters in positive and negative z-direction:
-\f[
+$
h_{fuselage} = d_{fuselage\_z\_pos} + d_{fuselage\_z\_neg}
-\f]
+$
-@note If the `force_circle_cross_section` mode is selected, fuselage height and width are set to the maximum of both.
+!!! note
+ If the `force_circle_cross_section` mode is selected, fuselage height and width are set to the maximum of both.
## Mass estimation {#mass-estimation}
The following masses are estimated:
@@ -173,7 +175,8 @@ The following masses are estimated:
Please refer to _Synthesis of Subsonic Airplane Design_ by E. Torenbeek<sup>[3]</sup> and the Certification Specifications<sup>[4]</sup> for further information.
-@note All masses are estimated in accordance with the CPACS standard.
+!!! note
+ All masses are estimated in accordance with the CPACS standard.
<!-- ## Estimate positions and COG -->
## Generate fuselage shape {#generate-shape}
diff --git a/docs/documentation/sizing/fuselage_design/getting-started.md b/docs/documentation/sizing/fuselage_design/getting-started.md
index c9af4ab..7973557 100644
--- a/docs/documentation/sizing/fuselage_design/getting-started.md
+++ b/docs/documentation/sizing/fuselage_design/getting-started.md
@@ -7,7 +7,8 @@ This section will guide you through the necessary steps to get the _fuselage\_de
- [Additional requirements](#additional-requirements) - Is anything else necessary to get the module running?
- [Next steps](#next-steps) - How to proceed?
-@note It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
+!!! note
+ It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
Generally, we use two files to set or configure modules in UNICADO:
- The aircraft exchange file (or _acXML_) includes
@@ -74,7 +75,8 @@ The following data should be available in the _acXML_ (2. and 3. are optional):
- Chord length
- Global reference point position
-@note When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
+!!! note
+ When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
## Module configuration file {#module-configuration-file}
The _configXML_ is structured into two blocks: the control and program settings.
@@ -84,7 +86,8 @@ The control settings are standardized in UNICADO and will not be described in de
- the `console_output` at least to `mode_1`, and
- the `plot_output` to false (or define `inkscape_path` and `gnuplot_path`).
-@note If the tool is executed via the workflow, those settings are set by the workflow settings.
+!!! note
+ If the tool is executed via the workflow, those settings are set by the workflow settings.
The program settings are structured like this (descriptions can be found in the `fuselage_design_conf.xml`):
@@ -210,7 +213,8 @@ The `fuselage_design_cs_requirements.xml` file contains necessary design require
- Maximum number of PAX per flight attendant
- Maximum crew duty time
-@note Please do not change any values that are set in accordance with the CS-25. Otherwise compliance of the design with the certification requirements cannot be guaranteed.
+!!! note
+ Please do not change any values that are set in accordance with the CS-25. Otherwise compliance of the design with the certification requirements cannot be guaranteed.
## Next steps {#next-steps}
The next step is to [run the _fuselage\_design_ module](run_your_first_design.md).
\ No newline at end of file
diff --git a/docs/documentation/sizing/fuselage_design/index.md b/docs/documentation/sizing/fuselage_design/index.md
index 89bd2ee..4fee3ec 100644
--- a/docs/documentation/sizing/fuselage_design/index.md
+++ b/docs/documentation/sizing/fuselage_design/index.md
@@ -1,5 +1,5 @@
# Introduction {#mainpage}
-The _fuselage\_design_ module is your go-to tool in the UNICADO sizing loop for all things aircraft fuselage! From sculpting the cockpit section to shaping the constant and tail section, this module handles it all with precision and flexibility. Need parametric ellipses for those fuselage cross-sections? Done. Want to adapt to a unique aircraft configuration? No problem! Ok, you got me... coming soon. \emoji soon
+The _fuselage\_design_ module is your go-to tool in the UNICADO sizing loop for all things aircraft fuselage! From sculpting the cockpit section to shaping the constant and tail section, this module handles it all with precision and flexibility. Need parametric ellipses for those fuselage cross-sections? Done. Want to adapt to a unique aircraft configuration? No problem! Ok, you got me... coming soon. :soon:
Seamlessly integrated into the design workflow, _fuselage\_design_ empowers you to create efficient, certifiable fuselage geometries — all while keeping your design process smooth and adaptable.
@@ -8,9 +8,9 @@ Here’s a quick rundown of what the tool currently does, along with a sneak pee
Configuration | Energy carrier | Fidelity | Methods | Status |
------------------|------------------|-----------|-----------|:------------------------------------:|
-Tube-and-wing |Kerosene |Empirical |TUB |running \emoji white_check_mark |
+Tube-and-wing |Kerosene |Empirical |TUB |running :white_check_mark: |
Tube-and-wing |Liquid hydrogen |Empirical |TUB |? |
-Blended-wing-body |... |... |... |under development \emoji construction |
+Blended-wing-body |... |... |... |under development :construction:|
## A user's guide to fuselage design
The _fuselage\_design_ tool is your key to designing the aircraft's fuselage. In this user documentation, you’ll find all the information you need to understand the tool, as well as the necessary inputs and configurations to run a fuselage design from the ground up.
@@ -23,7 +23,7 @@ For a comprehensive understanding of the tool’s functionality, the documentati
- a [software architecture](software_architecture.md)
section.
-Ready to dive in? Let’s get started! \emoji airplane
+Ready to dive in? Let’s get started! :airplane:
<!-- ## You are a Developer?
diff --git a/docs/documentation/sizing/fuselage_design/run_your_first_design.md b/docs/documentation/sizing/fuselage_design/run_your_first_design.md
index 1196538..4e69db7 100644
--- a/docs/documentation/sizing/fuselage_design/run_your_first_design.md
+++ b/docs/documentation/sizing/fuselage_design/run_your_first_design.md
@@ -58,7 +58,8 @@ In the following, a short overview is given on the generated reports:
- plots in the `plots` folder
### Write data to the aircraft exchange file {#acxml}
-@note The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
+!!! note
+ The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
Results are saved in the aircraft exchange file at the `/aircraft_exchange_file/component_design/fuselage` node. The following information is written to the _acXML_:
```plaintext
diff --git a/docs/documentation/sizing/fuselage_design/software_architecture.md b/docs/documentation/sizing/fuselage_design/software_architecture.md
index 05446b9..4c59c73 100644
--- a/docs/documentation/sizing/fuselage_design/software_architecture.md
+++ b/docs/documentation/sizing/fuselage_design/software_architecture.md
@@ -1,2 +1,2 @@
# Software architecture
-This site is currently under development. \emoji construction
\ No newline at end of file
+This site is currently under development. :construction:
\ No newline at end of file
diff --git a/docs/documentation/sizing/initial_sizing/changelog.md b/docs/documentation/sizing/initial_sizing/changelog.md
index ec0bb9d..2e8daec 100644
--- a/docs/documentation/sizing/initial_sizing/changelog.md
+++ b/docs/documentation/sizing/initial_sizing/changelog.md
@@ -15,6 +15,7 @@ During the development of this release the following bugs were found and fixed:
### Changes in the CSR designs
The implemented changes and bugfixes lead to the following changes in the results of the CSR designs.
-@note Only changes which exceed a 10 % change are listed.
+!!! note
+ Only changes which exceed a 10 % change are listed.
diff --git a/docs/documentation/sizing/initial_sizing/getting-started.md b/docs/documentation/sizing/initial_sizing/getting-started.md
index 61f4b3a..e9c0520 100644
--- a/docs/documentation/sizing/initial_sizing/getting-started.md
+++ b/docs/documentation/sizing/initial_sizing/getting-started.md
@@ -3,7 +3,7 @@ This guide will show you the basic usage of **initial_sizing**. Following steps
## Step-by-step
-It is assumed that you have the `UNICADO Package` installed including the executables and the engine database. In case you are a developer, you need to build the tool first (see [build instructions on UNICADO website](https://unicado.pages.rwth-aachen.de/unicado.gitlab.io/developer/build/cpp/)).
+It is assumed that you have the `UNICADO Package` installed including the executables and the engine database. In case you are a developer, you need to build the tool first (see [build instructions on UNICADO website](../../../get-involved/build/cpp/)).
1. Create a dummy `aircraft_exchange_file` (minimal required input see [here](#acXML))
2. Fill out the configuration file - change at least:
@@ -31,7 +31,8 @@ Generally, we use 2 files to set our configuration in UNICADO:
- program settings (e.g. set parameters to consider for specific technologies or change of methods)
### Aircraft exchange file
-@note _acXML_ is an exchange file - we agreed on that only data will be saved as output which is needed by another tool!
+!!! note
+ _acXML_ is an exchange file - we agreed on that only data will be saved as output which is needed by another tool!
**Inputs**:
The following is needed from the _acXML_:
diff --git a/docs/documentation/sizing/initial_sizing/index.md b/docs/documentation/sizing/initial_sizing/index.md
index e5f09ae..72fdf8f 100644
--- a/docs/documentation/sizing/initial_sizing/index.md
+++ b/docs/documentation/sizing/initial_sizing/index.md
@@ -10,7 +10,7 @@ This tool is exiting because it starts the clean sheet aircraft design and you w
To remind you of the concept of an initial sizing chart and desing window, here is the diagram where each border is derived from a different TLAR - hence every combination of wing loading
and thrust to weight ratio within the borders are possible design points for the aircraft.
-
+
The @subpage getting-started gives you a first insight in how to execute the tool and how it generally works.
diff --git a/docs/documentation/sizing/landing_gear_design/design_method.md b/docs/documentation/sizing/landing_gear_design/design_method.md
index 896cc0b..d117245 100644
--- a/docs/documentation/sizing/landing_gear_design/design_method.md
+++ b/docs/documentation/sizing/landing_gear_design/design_method.md
@@ -11,7 +11,7 @@
## Initial positions {#initial-positions}
-First, initial x axis positions for the nose \f$x_{NLG}\f$ and main landing gear \f$x_{MLG}\f$ are estimated. If any of the required values are missing, default values are used, such as a minimum distance of 2 meters between the main landing gear and the aft-most center of gravity.
+First, initial x axis positions for the nose $x_{NLG}$ and main landing gear $x_{MLG}$ are estimated. If any of the required values are missing, default values are used, such as a minimum distance of 2 meters between the main landing gear and the aft-most center of gravity.
The nose gear position is determined either from module configuration data or input parameters, such as the front reference point of the payload area or existing landing gear positions. If no relevant data is available, a default starting position, such as 5 meters, is applied.
@@ -28,38 +28,38 @@ Default values are assigned if parameters are not explicitly provided.
#### Distance between nose and main landing gear
The distance between the nose and the main landing gear can be estimated using the following equation:
-\f[
+$
d_{NLG\_MLG} = |x_{MLG} - x_{NLG}|
-\f]
+$
In which
-- \f$ x_{MLG}\f$ - x position of main landing gear
-- \f$ x_{NLG}\f$ - x position of nose landing gear
+- $ x_{MLG}$ - x position of main landing gear
+- $ x_{NLG}$ - x position of nose landing gear
#### Distance between nose gear and foremost center of gravity position
If the foremost center of gravity position is already known, the distance to the nose gear can be determined according to the following formula:
-\f[
+$
d_{NLG\_front\_CG} = |x_{front\_CG} - x_{NLG}|
-\f]
+$
In which
-- \f$ x_{front\_CG}\f$ - x position of foremost center of gravity
+- $ x_{front\_CG}$ - x position of foremost center of gravity
-Otherwise, \f$d_{NLG\_front\_CG}\f$ is determined by using a first estimation:
-\f[
+Otherwise, $d_{NLG\_front\_CG}$ is determined by using a first estimation:
+$
d_{NLG\_front\_CG} = |(x_{MLG} - 2) - x_{NLG}|
-\f]
+$
#### Distance between nose gear and rearmost center of gravity
The distance between the nose gear position and the rearmost center of gravity in x direction can be calculated as follows:
-\f[
+$
d_{NLG\_rear\_CG} = |x_{rear\_CG} - x_{NLG}|
-\f]
+$
In which
-- \f$x_{rear\_CG}\f$ - x position of rearmost center of gravity
+- $x_{rear\_CG}$ - x position of rearmost center of gravity
-Otherwise, \f$d_{NLG\_rear\_CG}\f$ is determined by using a first estimation:
-\f[
+Otherwise, $d_{NLG\_rear\_CG}$ is determined by using a first estimation:
+$
d_{NLG\_rear\_CG} = |(x_{MLG} - 1) - x_{NLG}|
-\f]
+$
#### Distance between main landing gear and rearmost center of gravity position
If no distance between the main landing gear and the rearmost center of gravity is available from earlier iterations, it equals `1`.
@@ -68,40 +68,40 @@ If no distance between the main landing gear and the rearmost center of gravity
#### Vertical distance between ground and center of gravity position
-Starting with the second iteration loop, the vertical distance between ground and center of gravity \f$\Delta h_{GND\_CG}\f$ is known.
+Starting with the second iteration loop, the vertical distance between ground and center of gravity $\Delta h_{GND\_CG}$ is known.
In the first loop, however, the vertical distance must be calculated as sum of the following heights:
-1. Vertical distance from fuselage center line to center of gravity \f$\Delta h_{FCL\_CG}\f$
-2. z position of tail tipping point (equals vertical distance between fuselage center line and tail tipping point) \f$z_{TP}\f$
-3. Vertical distance from tail tipping point to ground \f$\Delta h_{TP\_GND}\f$
+1. Vertical distance from fuselage center line to center of gravity $\Delta h_{FCL\_CG}$
+2. z position of tail tipping point (equals vertical distance between fuselage center line and tail tipping point) $z_{TP}$
+3. Vertical distance from tail tipping point to ground $\Delta h_{TP\_GND}$
**1. Vertical distance from fuselage center line to center of gravity**<br>
-The distance between global center of gravity in z-direction and the fuselage center line \f$\Delta h_{FCL\_CG}\f$ is either estimated by subtracting the z position of the fuselage center line \f$z_{FCL}\f$ from the z position of the most aft CG position \f$z_{rear\_CG}\f$
-\f[
+The distance between global center of gravity in z-direction and the fuselage center line $\Delta h_{FCL\_CG}$ is either estimated by subtracting the z position of the fuselage center line $z_{FCL}$ from the z position of the most aft CG position $z_{rear\_CG}$
+$
\Delta h_{FCL\_CG} = |z_{rear\_CG} - z_{FCL}|
-\f]
+$
or, if those values are not given, set to `0.5` for single-aisle and `1.0` for wide-body configurations.
**2. z position of tail tipping point**<br>
-If the position of the tail tipping point in z direction is not known, it is assumed to equal \f$z_{TP} = -0.3 \cdot h_{fuselage}\f$. The fuselage height \f$h_{fuselage}\f$ in meter is known or assumed to be `3.8` for single-aisle and `5.8` for wide-body aircraft.
+If the position of the tail tipping point in z direction is not known, it is assumed to equal $z_{TP} = -0.3 \cdot h_{fuselage}$. The fuselage height $h_{fuselage}$ in meter is known or assumed to be `3.8` for single-aisle and `5.8` for wide-body aircraft.
**3. Vertical distance from tail tipping point to ground**<br>
-The vertical distance from the tail tipping point to the ground \f$\Delta h_{TP\_GND}\f$ is estimated in the following way:
+The vertical distance from the tail tipping point to the ground $\Delta h_{TP\_GND}$ is estimated in the following way:
-\f[
+$
\Delta h_{TP\_GND} = |\tan(\theta_{LDG}) \cdot d_{MLG\_TP}| - h_{susp}
-\f]
+$
-The vertical distance between the main landing gear and the tail tipping point \f$d_{MLG\_TP}\f$ is either known or set to `15` for single-aisle or `25` for wide-body aircraft configurations.
+The vertical distance between the main landing gear and the tail tipping point $d_{MLG\_TP}$ is either known or set to `15` for single-aisle or `25` for wide-body aircraft configurations.
-If a strut suspension system is implemented, the vertical distance between ground and CG decreases by the suspension travel \f$h_{susp}\f$ that equals `0` if no suspension system is implemented.
+If a strut suspension system is implemented, the vertical distance between ground and CG decreases by the suspension travel $h_{susp}$ that equals `0` if no suspension system is implemented.
**Vertical distance between ground and center of gravity position**<br>
Finally, the vertical distance between the ground and the CG position can be calculated by summing up these values:
-\f[
+$
\Delta h_{GND\_CG} = \Delta h_{FCL\_CG} + |z_{TP}| + \Delta h_{TP\_GND}
-\f]
+$
## Load estimation {#loads}
Subsequently, the loads on the nose and main landing gear are calculated based on Norman S. Currey's work<sup>[1]</sup>, unless explicitly stated otherwise. It considers the static and dynamic loads during takeoff, landing, and taxiing, while ensuring the loads conform to the permissible percentages as per aviation regulations.
@@ -116,29 +116,29 @@ If no values are available, initial values are set.
### Nose landing gear loads
**Minimum static nose gear load**
-\f[
+$
L_{NLG,stat,min} = \frac{MRW \cdot (d_{NLG\_MLG} - d_{NLG\_rear\_CG})}{d_{NLG\_MLG}}
-\f]
+$
In which
-- \f$MRW\f$ - maximum ramp weight
-- \f$d_{NLG\_MLG}\f$ - distance between nose and main gear
-- \f$d_{NLG\_rear\_CG}\f$ - distance between nose gear and rearmost center of gravity
+- $MRW$ - maximum ramp weight
+- $d_{NLG\_MLG}$ - distance between nose and main gear
+- $d_{NLG\_rear\_CG}$ - distance between nose gear and rearmost center of gravity
**Maximum static nose gear load**
-\f[
+$
L_{NLG,stat,max} = \frac{MRW \cdot (d_{NLG\_MLG} - d_{NLG\_front\_CG})}{d_{NLG\_MLG}}
-\f]
+$
In which
-- \f$MRW\f$ - maximum ramp weight
-- \f$d_{NLG\_MLG}\f$ - distance between nose and main gear
-- \f$d_{NLG\_front\_CG}\f$ - distance between nose gear and foremost center of gravity
+- $MRW$ - maximum ramp weight
+- $d_{NLG\_MLG}$ - distance between nose and main gear
+- $d_{NLG\_front\_CG}$ - distance between nose gear and foremost center of gravity
**Maximum dynamic nose gear load**
-\f[
+$
L_{NLG,dyn,max} = L_{NLG,stat,max} + \frac{10 \cdot d_{GND\_rear\_CG} \cdot MRW}{32.2 \cdot d_{NLG\_MLG}}
-\f]
+$
In which
-- \f$d_{GND\_rear\_CG}\f$ - vertical distance between ground and aft center of gravity
+- $d_{GND\_rear\_CG}$ - vertical distance between ground and aft center of gravity
The static loads on the nose landing gear should be between 6% and 20% of the maximum ramp weight for all CG positions. These values are absolute limits and must not be exceeded at any time. Ideally, the static loads for the minimum and maximum nose landing gear load should be between 8% and 15%. If the limits are violated, the landing gear positions and/or the empty mass center of gravity must be varied. This leads to a renewed check of the center of gravity movement and the limits to be adhered to (iterative process).
@@ -146,129 +146,130 @@ The static loads on the nose landing gear should be between 6% and 20% of the ma
The calculation of the dynamic nose gear loads for takeoff and landing conditions is in accordance with CS 25.733 (b)(2) and (b)(3)<sup>[2]</sup>.
**Maximum static nose gear landing load**
-In order to calculate the maximum static nose gear load at landing, the maximum static nose gear landing load \f$ L_{NLG,stat,max,LDG}\f$ has to be estimated first.
+In order to calculate the maximum static nose gear load at landing, the maximum static nose gear landing load $ L_{NLG,stat,max,LDG}$ has to be estimated first.
-\f[
+$
L_{NLG,stat,max,LDG} = \frac{MLM \cdot g \cdot (d_{NLG\_MLG} - d_{NLG\_front\_CG})}{d_{NLG\_MLG}}
-\f]
+$
In which
-- \f$MLM\f$ - maximum landing mass
-- \f$ g\f$ - gravitational acceleration
-- \f$d_{NLG\_MLG}\f$ - distance between nose and main gear
-- \f$d_{NLG\_front\_CG}\f$ - distance between nose gear and foremost center of gravity
+- $MLM$ - maximum landing mass
+- $ g$ - gravitational acceleration
+- $d_{NLG\_MLG}$ - distance between nose and main gear
+- $d_{NLG\_front\_CG}$ - distance between nose gear and foremost center of gravity
-@note If no maximum landing mass exists, 90% of the maximum ramp weight are initially assumed for the calculation.
+!!! note
+ If no maximum landing mass exists, 90% of the maximum ramp weight are initially assumed for the calculation.
-Subsequently, the maximum dynamic load at landing \f$ L_{NLG,dyn,max,LDG} \f$ can be calculated based on CS 25.733 (b)(2):
-\f[
+Subsequently, the maximum dynamic load at landing $ L_{NLG,dyn,max,LDG} $ can be calculated based on CS 25.733 (b)(2):
+$
L_{NLG,dyn,max,LDG} = L_{NLG,stat,max,LDG} + 0.31 \cdot L_{NLG,stat,max,LDG}
-\f]
+$
**Maximum dynamic nose gear takeoff load**
The maximum dynamic nose gear load at takeoff can be calculated in accordance with CS 52.733 (b)(3):
-\f[
+$
L_{NLG,dyn,max,TO} = L_{NLG,stat,max} + 0.2 \cdot L_{NLG,stat,max}
-\f]
+$
### Main landing gear loads
The total main gear load can be estimated using the following equation:
-\f[
+$
L_{MLG,max} = \frac{100 - L_{NLG,stat,min}}{100} \cdot MRW
-\f]
+$
In which
-- \f$L_{NLG,stat,min}\f$ - minimum static nose gear load **in percent**
+- $L_{NLG,stat,min}$ - minimum static nose gear load **in percent**
### Nose landing gear position
The maximum possible foremost and aft position of the nose landing gear can be determined based on the loads.
#### Foremost nose landing gear position
-A maximum of 20 percent of the maximum ramp weight is allowed as the maximum static nose gear load \f$ L_{NLG,stat,max,possible}\f$:
-\f[
+A maximum of 20 percent of the maximum ramp weight is allowed as the maximum static nose gear load $ L_{NLG,stat,max,possible}$:
+$
L_{NLG,stat,max,possible} = 0.06 \cdot MRW
-\f]
+$
The foremost nose landing gear position therefore results in:
-\f[
+$
d_{NLG\_front\_CG\_min} = \frac{MRW \cdot d_{NLG\_MLG} - L_{NLG,stat,max,possible} \cdot d_{NLG\_MLG}}{MRW}
-\f]
+$
In which
-- \f$MRW\f$ - maximum ramp weight
-- \f$d_{NLG\_MLG}\f$ - distance between nose and main gear
+- $MRW$ - maximum ramp weight
+- $d_{NLG\_MLG}$ - distance between nose and main gear
#### Aft nose landing gear position
-A minimum of 6 percent of the maximum ramp weight is allowed as the minimum static nose gear load \f$ L_{NLG,stat,min,possible}\f$:
-\f[
+A minimum of 6 percent of the maximum ramp weight is allowed as the minimum static nose gear load $ L_{NLG,stat,min,possible}$:
+$
L_{NLG,stat,min,possible} = 0.2 \cdot MRW
-\f]
+$
The aft nose landing gear position therefore results in:
-\f[
+$
d_{NLG\_aft\_CG\_max} = \frac{MRW \cdot d_{NLG\_MLG} - L_{NLG,stat,min,possible} \cdot d_{NLG\_MLG}}{MRW}
-\f]
+$
## Tires {#tires}
Tire selection in accordance to CS 25.733<sup>[2]</sup> und EASA ETSO tire list<sup>[3]</sup>, bridgestone aircraft tires<sup>[4]</sup> from landing gear lib (see [getting started](getting_started.md) page for more information).
If a maximum takeoff stall speed exists, the maximum design speed **(in miles per hour)** corresponds to the greater of the two values maximum approach speed or maximum takeoff stall speed*1.3:
-\f[
+$
v_{max\_des} = max(v_{app,max},v_{s,TO} \cdot 1.3)
-\f]
+$
In which
-- \f$v_{app,max}\f$ - maximum approach speed (in mph)
-- \f$v_{s,TO}\f$ - takeoff stall speed (in mph)
+- $v_{app,max}$ - maximum approach speed (in mph)
+- $v_{s,TO}$ - takeoff stall speed (in mph)
Otherwise, the following applies:
-\f[
+$
v_{max\_des} = v_{app,max}
-\f]
+$
### Nose gear
-For both, the number of nose gear struts \f$n_{NLG\_struts}\f$ as well as the number of nose gear tires per strut \f$n_{NLG\_tires\_per\_strut}\f$, the user can define specific values. These values are checked for compliance and parameters, e.g., the number of axis, are set accordingly. If no values are given, default values are used.
+For both, the number of nose gear struts $n_{NLG\_struts}$ as well as the number of nose gear tires per strut $n_{NLG\_tires\_per\_strut}$, the user can define specific values. These values are checked for compliance and parameters, e.g., the number of axis, are set accordingly. If no values are given, default values are used.
#### Design load estimation
-The **single tire design load** \f$v_{NLG\_tire\_des}\f$ is calculated according to CS 25.733 (b)(1):
-\f[
+The **single tire design load** $v_{NLG\_tire\_des}$ is calculated according to CS 25.733 (b)(1):
+$
v_{NLG\_tire\_des} = \frac{\frac{L_{NLG,stat,max}}{g} \cdot 2.2}{n_{NLG\_tires\_per\_strut} \cdot n_{NLG\_struts}}
-\f]
+$
In which
-- \f$ L_{NLG,stat,max}\f$ - maximum static nose gear load
-- \f$ g\f$ - gravitational acceleration
+- $ L_{NLG,stat,max}$ - maximum static nose gear load
+- $ g$ - gravitational acceleration
-Subsequently, the **single tire dynamic landing load** \f$v_{NLG\_tire\_LDG}\f$ is estimated based on CS 25.733 (b)(2):
-\f[
+Subsequently, the **single tire dynamic landing load** $v_{NLG\_tire\_LDG}$ is estimated based on CS 25.733 (b)(2):
+$
v_{NLG\_tire\_LDG} = \frac{\frac{L_{NLG,dyn,max,LDG}}{g} \cdot 2.2}{n_{NLG\_tires\_per\_strut} \cdot n_{NLG\_struts}}
-\f]
+$
In which
-- \f$ L_{NLG,dyn,max,LDG}\f$ - maximum dynamic load at landing
+- $ L_{NLG,dyn,max,LDG}$ - maximum dynamic load at landing
-Afterwards, the calculation of the **single tire dynamic takeoff load** \f$v_{NLG\_tire\_TO}\f$ for nose gear tires is in accordance to CS 25.733 (b)(3):
-\f[
+Afterwards, the calculation of the **single tire dynamic takeoff load** $v_{NLG\_tire\_TO}$ for nose gear tires is in accordance to CS 25.733 (b)(3):
+$
v_{NLG\_tire\_TO} = \frac{\frac{L_{NLG,dyn,max,TO}}{g} \cdot 2.2}{n_{NLG\_tires\_per\_strut} \cdot n_{NLG\_struts}}
-\f]
+$
In which
-- \f$ L_{NLG,dyn,max,TO}\f$ - maximum dynamic load at takeoff
+- $ L_{NLG,dyn,max,TO}$ - maximum dynamic load at takeoff
#### Tire selection
Knowing the design speed and loads, a suitable tire is selected from the database.
### Main gear tire selection
-Similar to the nose landing gear, the number of main gear struts \f$n_{MLG\_struts}\f$ as well as the number of main gear tires per strut \f$n_{MLG\_tires\_per\_strut}\f$ can be defined by the user. These values are checked for compliance and parameters, e.g., the number of axis, are set accordingly. If no values are given, default values are used.
+Similar to the nose landing gear, the number of main gear struts $n_{MLG\_struts}$ as well as the number of main gear tires per strut $n_{MLG\_tires\_per\_strut}$ can be defined by the user. These values are checked for compliance and parameters, e.g., the number of axis, are set accordingly. If no values are given, default values are used.
#### Design load estimation
The **single tire design load** is calculated according to CS 25.733 (a)(1):
-\f[
+$
v_{MLG\_tire\_des} = \frac{\frac{L_{MLG,max}}{g} \cdot 2.2}{n_{MLG\_tires\_per\_outer\_strut} \cdot n_{MLG\_outer\_struts} + n_{MLG\_tires\_per\_inner\_strut} \cdot n_{MLG\_inner\_struts}} \cdot f_{safety}
-\f]
+$
In which
-- \f$L_{MLG,max}\f$ - maximum main gear load
-- \f$g\f$ - gravitational acceleration
-- \f$n_{MLG\_tires\_per\_outer\_strut}\f$ - number of tires per outer strut
-- \f$n_{MLG\_outer\_struts}\f$ - number of outer struts
-- \f$n_{MLG\_tires\_per\_inner\_strut}\f$ - number of tires per inner strut
-- \f$n_{MLG\_inner\_struts}\f$ - number of inner struts
-- \f$f_{safety}\f$ - safety factor
+- $L_{MLG,max}$ - maximum main gear load
+- $g$ - gravitational acceleration
+- $n_{MLG\_tires\_per\_outer\_strut}$ - number of tires per outer strut
+- $n_{MLG\_outer\_struts}$ - number of outer struts
+- $n_{MLG\_tires\_per\_inner\_strut}$ - number of tires per inner strut
+- $n_{MLG\_inner\_struts}$ - number of inner struts
+- $f_{safety}$ - safety factor
-If only one main gear tyre is mounted to one main landing gear strut, \f$f_{safety} = 1\f$. If more than one tire is mounted to one main landing gear strut, an additional safety load margin according to CS 25.733 (c)(1) is required that results in \f$f_{safety} = 1.07\f$.
+If only one main gear tyre is mounted to one main landing gear strut, $f_{safety} = 1$. If more than one tire is mounted to one main landing gear strut, an additional safety load margin according to CS 25.733 (c)(1) is required that results in $f_{safety} = 1.07$.
#### Tire selection
Knowing the design speed and loads, a suitable tire is selected from the database.
@@ -291,42 +292,42 @@ With the known values, the landing gear placement and dimensions are estimated m
Ground clearance angles for nacelles and wing tips are calculated and verified in accordance to Torenbeek<sup>[6]</sup> and CS-25<sup>[2]</sup>.
### Nacelle clearance
-The ground clearance \f$c_{nacelle}\f$ for each nacelle is given as:
-\f[
+The ground clearance $c_{nacelle}$ for each nacelle is given as:
+$
c_{nacelle} = d_{GND\_to\_FCL} - |z_{nacelle}| - |h_{nacelle}|
-\f]
+$
In which
-- \f$d_{GND\_to\_FCL}\f$ - vertical distance between ground and fuselage center line
-- \f$z_{nacelle}\f$ - z position of nacelle
-- \f$h_{nacelle}\f$ - height of nacelle
+- $d_{GND\_to\_FCL}$ - vertical distance between ground and fuselage center line
+- $z_{nacelle}$ - z position of nacelle
+- $h_{nacelle}$ - height of nacelle
The nacelle clearance angle can then be determined:
-\f[
+$
\theta_{nacelle} = \arctan\left(\frac{c_{nacelle}}{|y_{nacelle}| - y_{MLG\_outer\_strut}}\right) \cdot \frac{180}{\pi}
-\f]
+$
In which:
-- \f$y_{nacelle}\f$ - y position of nacelle
-- \f$y_{MLG\_outer\_strut}\f$ - y position of outer main landing gear strut
+- $y_{nacelle}$ - y position of nacelle
+- $y_{MLG\_outer\_strut}$ - y position of outer main landing gear strut
This value is then checked regarding the minimum required clearance angle of 5 degree, defined by CS 25.149, and the user-specified nacelle clearance angle.
### Wing tip clearance
-The wing tip ground clearance \f$c_{wing\_tip}\f$ is known from the positions of the wing tip section.
-\f[
+The wing tip ground clearance $c_{wing\_tip}$ is known from the positions of the wing tip section.
+$
c_{wing\_tip} = d_{GND\_to\_FCL} - z_{wing\_tip}
-\f]
+$
In which
-- \f$d_{GND\_to\_FCL}\f$ - vertical distance between ground and fuselage center line
-- \f$z_{wing\_tip}\f$ - z position of wing tip
+- $d_{GND\_to\_FCL}$ - vertical distance between ground and fuselage center line
+- $z_{wing\_tip}$ - z position of wing tip
The wing tip clearance angle is calculated using the wing tip's position relative to the main gear outer strut:
-\f[
+$
\theta_{wing\_tip} = \arctan\left(\frac{c_{wing\_tip}}{|y_{wing\_tip}| - y_{MLG\_outer\_strut}}\right) \cdot \frac{180}{\pi}
-\f]
+$
In which:
-- \f$y_{wing\_tip}\f$ - y position of wing tip
-- \f$y_{MLG\_outer\_strut}\f$ - y position of outer main landing gear strut
+- $y_{wing\_tip}$ - y position of wing tip
+- $y_{MLG\_outer\_strut}$ - y position of outer main landing gear strut
This value is then validated against the minimum required clearance angle of 5 degree, defined by CS 25.149, and the user-specified wing tip clearance angle.
@@ -342,16 +343,17 @@ The undercarriage masses are calculated in accordance to Torenbeek<sup>[6]</sup>
Under the use of these coefficients, the mass for the nose as well as the main landing gear can be calculated using the following equation:
-\f[
+$
m = c_{wing} \cdot \left( A + B \cdot MTOM^{0.75} + C \cdot MTOM + D \cdot MTOM^{1.5} \right) \cdot f_{corr}
-\f]
+$
In which:
-- \f$c_{wing}\f$ - wing position coefficient (`1.0`for low or mid wing position, `1.8`for high wing position)
-- \f$MTOM\f$ - maximum takeoff mass
-- \f$f_{corr}\f$ - landing gear correction factor (taken from user specification)
-- \f$ A,B,C,D\f$ - coefficients from above table
+- $c_{wing}$ - wing position coefficient (`1.0`for low or mid wing position, `1.8`for high wing position)
+- $MTOM$ - maximum takeoff mass
+- $f_{corr}$ - landing gear correction factor (taken from user specification)
+- $ A,B,C,D$ - coefficients from above table
-@note If the maximum takeoff mass is not available, it is calculated by dividing the maximum ramp weight by the gravitational acceleration.
+!!! note
+ If the maximum takeoff mass is not available, it is calculated by dividing the maximum ramp weight by the gravitational acceleration.
The total nose/main landing gear mass divided by the number of struts per nose/main landing gear results in the per-strut mass.
@@ -359,8 +361,9 @@ The total nose/main landing gear mass divided by the number of struts per nose/m
The calculation is based on the COMFAA Tool developed by the Federal Aviation Administration (FAA) that is specifically used for computing the ACN (Aircraft Classification Number) in line with ICAO standards.
Detailed information can be taken from the website:
-@note By clicking on the following link, you will leave the UNICADO website. Please note that we are not responsible for the content of the linked website and do not assume any liability.<br>
-https://www.airporttech.tc.faa.gov/Products/Airport-Safety-Papers-Publications/Airport-Safety-Detail/comfaa-30
+!!! note
+ By clicking on the following link, you will leave the UNICADO website. Please note that we are not responsible for the content of the linked website and do not assume any liability.<br>
+ https://www.airporttech.tc.faa.gov/Products/Airport-Safety-Papers-Publications/Airport-Safety-Detail/comfaa-30
The Aircraft Classification Number (ACN) is a standardized measure that describes the load a particular aircraft imposes on the surface of a runway or taxiway. It is defined by the International Civil Aviation Organization (ICAO) in Annex 14<sup>[7]</sup> and is used to assess whether an aircraft is compatible with a specific pavement's structural capacity, expressed as the Pavement Classification Number (PCN).
The subsequent section provides some information on the method.
@@ -373,7 +376,8 @@ The subsequent section provides some information on the method.
- The ACN is determined for two types of pavements:
- Rigid pavements: Concrete surfaces with a stiff structure.
- Flexible pavements: Asphalt or other elastic materials.
- @note Currently only flexible pavement implemented.
+ !!! note
+ Currently only flexible pavement implemented.
- Subgrade strength (the strength of the ground beneath the pavement) is divided into four categories: High (H), Medium (M), Low (L), Very Low (VL).
3. Standardization
- The ACN is normalized to a reference Single Wheel Load (SWL) of 10 tons.
diff --git a/docs/documentation/sizing/landing_gear_design/getting-started.md b/docs/documentation/sizing/landing_gear_design/getting-started.md
index b113ee6..6bdeea4 100644
--- a/docs/documentation/sizing/landing_gear_design/getting-started.md
+++ b/docs/documentation/sizing/landing_gear_design/getting-started.md
@@ -7,7 +7,8 @@ This section will guide you through the necessary steps to get the _landing\_gea
- [Additional requirements](#additional-requirements) - Is anything else necessary to get the module running?
- [Next steps](#next-steps) - How to proceed?
-@note It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
+!!! note
+ It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
Generally, we use two files to set or configure modules in UNICADO:
- The aircraft exchange file (or _acXML_) includes
@@ -89,7 +90,8 @@ The following data should be available in the _acXML_ (2. and 3. are optional):
<sup>*</sup> Available from the second iteration loop.
-@note When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
+!!! note
+ When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
## Module configuration file {#module-configuration-file}
The _configXML_ is structured into two blocks: the control and program settings.
@@ -99,7 +101,8 @@ The control settings are standardized in UNICADO and will not be described in de
- the `console_output` at least to `mode_1`, and
- the `plot_output` to false (or define `inkscape_path` and `gnuplot_path`).
-@note If the tool is executed via the workflow, those settings are set by the workflow settings.
+!!! note
+ If the tool is executed via the workflow, those settings are set by the workflow settings.
The program settings are structured like this (descriptions can be found in the `landing_gear_design_conf.xml`):
diff --git a/docs/documentation/sizing/landing_gear_design/index.md b/docs/documentation/sizing/landing_gear_design/index.md
index 80ee5a9..8eab731 100644
--- a/docs/documentation/sizing/landing_gear_design/index.md
+++ b/docs/documentation/sizing/landing_gear_design/index.md
@@ -6,9 +6,9 @@ Here’s a quick rundown of what the tool currently does, along with a sneak pee
Undercarriage definition | Energy carrier | Fidelity | Methods | Status |
-----------------------------|------------------|-----------|-----------|:-------------------------------------:|
-Wing-mounted | Kerosene | Empirical | TUB | running \emoji white_check_mark |
-Wing-mounted | Liquid hydrogen | ... | ... | under development \emoji construction |
-Body-mounted | ... | ... | ... | under development \emoji construction |
+Wing-mounted | Kerosene | Empirical | TUB | running :white_check_mark: |
+Wing-mounted | Liquid hydrogen | ... | ... | under development :construction:|
+Body-mounted | ... | ... | ... | under development :construction:|
## A user's guide to landing gear design
The _landing\_gear\_design_ tool is your key to designing the aircraft's landing gear. In this user documentation, you’ll find all the information you need to understand the tool, as well as the necessary inputs and configurations to run a landing gear design from the ground up.
@@ -21,7 +21,7 @@ For a comprehensive understanding of the tool’s functionality, the documentati
- a [software architecture](software_architecture.md)
section.
-Ready to dive in? Let’s get started! \emoji airplane
+Ready to dive in? Let’s get started! :airplane:
<!-- ## You are a Developer?
diff --git a/docs/documentation/sizing/landing_gear_design/run_your_first_design.md b/docs/documentation/sizing/landing_gear_design/run_your_first_design.md
index 4504378..aa5198a 100644
--- a/docs/documentation/sizing/landing_gear_design/run_your_first_design.md
+++ b/docs/documentation/sizing/landing_gear_design/run_your_first_design.md
@@ -106,7 +106,8 @@ In the following, a short overview is given on the generated reports:
- plots in the `plots` folder
### Write data to the aircraft exchange file {#acxml}
-@note The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
+!!! note
+ The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
Results are saved in the aircraft exchange file at the `/aircraft_exchange_file/component_design/landing_gear` node. The following information is written to the _acXML_:
```plaintext
diff --git a/docs/documentation/sizing/landing_gear_design/software_architecture.md b/docs/documentation/sizing/landing_gear_design/software_architecture.md
index 05446b9..4c59c73 100644
--- a/docs/documentation/sizing/landing_gear_design/software_architecture.md
+++ b/docs/documentation/sizing/landing_gear_design/software_architecture.md
@@ -1,2 +1,2 @@
# Software architecture
-This site is currently under development. \emoji construction
\ No newline at end of file
+This site is currently under development. :construction:
\ No newline at end of file
diff --git a/docs/documentation/sizing/propulsion_design/changelog.md b/docs/documentation/sizing/propulsion_design/changelog.md
index 7403ff4..d6f5738 100644
--- a/docs/documentation/sizing/propulsion_design/changelog.md
+++ b/docs/documentation/sizing/propulsion_design/changelog.md
@@ -14,11 +14,12 @@ The following changes are introduced:
### Bugfixes
During the development of this release the following bugs were found and fixed:
-- When designing a *rubber* engine, the engine length was scaled incorrectly. The correct formula with \f${scale_{engine}}^{0.4} \f$ is now implemented.
+- When designing a *rubber* engine, the engine length was scaled incorrectly. The correct formula with ${scale_{engine}}^{0.4} $ is now implemented.
### Changes in the CSR designs
The implemented changes and bugfixes lead to the following changes in the results of the CSR designs.
-@note Only changes which exceed a 10 % change are listed.
+!!! note
+ Only changes which exceed a 10 % change are listed.
#### CSR-02
|Parameter|Changed introduced by|Old Value|New Value|Unit|
diff --git a/docs/documentation/sizing/propulsion_design/engineering_principles.md b/docs/documentation/sizing/propulsion_design/engineering_principles.md
index d0cd301..0a8220b 100644
--- a/docs/documentation/sizing/propulsion_design/engineering_principles.md
+++ b/docs/documentation/sizing/propulsion_design/engineering_principles.md
@@ -2,6 +2,7 @@
# Engineering principles {#engineeringprinciples}
Designing the propulsion with this tool includes different engineering disciplines. Here 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.
@@ -33,43 +34,45 @@ The **engine designer** bases its principle on the common modelling practice usi
The _dataset_ (also called _EngineXML_) includes parameter which are independent of the flight condition such as outer engine dimensions.
-The three-dimensional _engine deck_ contain engine performance data for different values of altitude \f$h\f$, Mach number \f$Ma\f$ and low-pressure engine spool speed \f$N1\f$. 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 newton. The first block contains data for \f$N1=1\f$ for \f$Ma=0...0.9\f$ and \f$h=0...14000\f$. The second block below is for \f$N1=0.95\f$.
+The three-dimensional _engine deck_ contain engine performance data for different values of altitude $h$, Mach number $Ma$ and low-pressure engine spool speed $N1$. 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 newton. The first block contains data for $N1=1$ for $Ma=0...0.9$ and $h=0...14000$. The second block below is for $N1=0.95$.
-@note Detailed information on required dataset and deck data will be updated in near future.
+!!! note
+ Detailed information on required dataset and deck data will be updated in near future.
The _scale factor_ is necessary because (as conceptual aircraft designer), 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 \f$0.5\f$ and for the mass its \f$0.4\f$. **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.
+@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 $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.
So, the scaling is based on continuity principle assuming that the operating condition is constant (commonly known station numbering; assuming no pressure drop).
-\f$[
- T = \dot m \cdot (V_9 - V_0)
-]\f$
+$ T = \dot m \cdot (V_9 - V_0) $
-Therefore, thrust \f$T\f$ is proportional to the mass flow \f$\dot m\f$, which is related to the cross-sectional area \f$A\f$ of the engine.
+Therefore, thrust $T$ is proportional to the mass flow $\dot m$, which is related to the cross-sectional area $A$ of the engine.
-\f$ \dot m = \rho \cdot V \cdot A = \rho \cdot V \cdot \pi \frac{d}{2}^2 \f$
+$ \dot m = \rho \cdot V \cdot A = \rho \cdot V \cdot \pi \frac{d}{2}^2 $
-Because area \f$A\f$ is proportional to the square of the diameter \f$d\f$ , it follows that the diameter should be proportional to the square root of the scale factor.
+Because area $A$ is proportional to the square of the diameter $d$ , it follows that the diameter should be proportional to the square root of the scale factor.
-\f$ d_{new} = d_{ref} \cdot ( \frac{T_{new}}{T_{ref}} )^{0.5} \f$
+$ d_{new} = d_{ref} \cdot ( \frac{T_{new}}{T_{ref}} )^{0.5} $
-An exemplary simplified calculation (data from the V2527-A5): the current engine provides \f$127.27~kN\f$ as sea level static thrust, but for the design only \f$100~kN\f$ are needed. The scaling factor would be \f$0.7857\f$. Assuming an initial diameter \f$2~m\f$, the new diameter would be \f$1.773~m\f$ with the scaling factor of \f$(0.7857)^{0.5} = 0.8864\f$.
+An exemplary simplified calculation (data from the V2527-A5): the current engine provides $127.27~kN$ as sea level static thrust, but for the design only $100~kN$ are needed. The scaling factor would be $0.7857$. Assuming an initial diameter $2~m$, the new diameter would be $1.773~m$ with the scaling factor of $(0.7857)^{0.5} = 0.8864$.
So, again, always access the engine data via the `engine` library to ensure that you have the correctly scaled data 🙂
-@note Actually, the sea level static thrust is not at \f$N1=1\f$ if you compare the dataset for this engine (for 110.31kN around \f$N1=0.95\f$). 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.31kN around $N1=0.95$). So the scaling factor will be 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 emipirical 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!
+!!! note
+ *empirical* and *propulsionsystem* is in preparation - not implemented yet!
For all these methods, the approach of using the _scale factor_ is the same (see explaination [here](#generalprinciples)). A deck is either first created or assumed and then data is drawn with the `engine` library with the scaling approach.
@@ -98,7 +101,7 @@ 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).
@@ -106,6 +109,7 @@ After the integration, the nacelle geometry is defined (however its actually ind
### Methods description
For the **nacelle designer**, only one method is implemented:
+
- *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.
@@ -114,7 +118,8 @@ In the current implemented method, there is no differentiation between short and
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
+ The implementation include currently Turbofan Kerosene only
## Pylon designer {#pylondesigner}
The pylon is the structural component to connect the engine to the aircraft.
@@ -122,6 +127,7 @@ 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
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_.
@@ -129,7 +135,8 @@ In the current method, the mounting is attached to the beginning to the nacelle
-@note the implementation include currently Turbofan Kerosene only
+!!!note
+ the implementation include currently Turbofan Kerosene only
## Mass analyzer {#massanalyzer}
Lastly, the mass properties for engine, nacelle and pylon are calculated separate for center of gravity, mass and inertia.
@@ -137,6 +144,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
@@ -147,5 +155,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
+ the implementation include currently Turbofan Kerosene only
diff --git a/docs/documentation/sizing/propulsion_design/getting-started.md b/docs/documentation/sizing/propulsion_design/getting-started.md
index 8c6dc34..fafd391 100644
--- a/docs/documentation/sizing/propulsion_design/getting-started.md
+++ b/docs/documentation/sizing/propulsion_design/getting-started.md
@@ -3,7 +3,7 @@ This guide will show you the basic usage of **propulsion_design**. Following ste
## Step-by-step
-It is assumed that you have the `UNICADO Package` installed including the executables and the engine database. In case you are a developer, you need to build the tool first (see [build instructions on UNICADO website](https://unicado.pages.rwth-aachen.de/unicado.gitlab.io/developer/build/cpp/)).
+It is assumed that you have the `UNICADO Package` installed including the executables and the engine database. In case you are a developer, you need to build the tool first (see [build instructions on UNICADO website](../../../get-involved/build/cpp/)).
1. Create a dummy `aircraft_exchange_file` (minimal required input see [here](#acXML))
2. Fill out the configuration file - change at least:
@@ -17,14 +17,17 @@ It is assumed that you have the `UNICADO Package` installed including the execut
3. Open terminal and run **propulsion_design**
Following will happen:
+
- you see output in the console window
- a HTML report is created in the directory of `aircraft_exchange_file_directory` (no plots of engine if they are turned off)
- results are saved in the `/aircraft_exchange_file/component_design/propulsion`
-@note The dummy does not include geometry data for e.g. fuselage or wing. Therefore the positioning of the engine will not work and warnings are expected in the output.
+!!! note
+ The dummy does not include geometry data for e.g. fuselage or wing. Therefore the positioning of the engine will not work and warnings are expected in the output.
## Settings and outputs {#settingsandoutputs}
Generally, we use 2 files to set or configure in UNICADO:
+
- the aircraft exchange file (or _acXML_) includes
- data related inputs (e.g. thrust, offtakes or type of engine)
- data related outputs (e.g. engine position)
@@ -33,28 +36,30 @@ Generally, we use 2 files to set or configure in UNICADO:
- program settings (e.g. set technology factors or methods)
### Aircraft exchange file
-@note _acXML_ is an exchange file - we agreed on that only data will be saved as output which is needed by another tool!
+!!! note
+ _acXML_ is an exchange file - we agreed on that only data will be saved as output which is needed by another tool!
**Inputs**:
Following is needed from the _acXML_:
+
1) the total required thrust,
2) the system off-takes,
3) the user settings of the propulsion architecture
Naturally, the propulsion need an assumption for thrust or power to be designed. Currently, in UNICADO, the requirement is set via the tool _initialSizing_. Here, initial estimation based on the TLARs are calculated like the thrust-to-weight via an design chart or the maximum take-off mass based on regressions. For this, **propulsion_design** currently assumes:
-The sea level static thrust \f$ T_0 \f$ is given by:
+The sea level static thrust $T_0$ is given by:
-\f$
-T_0 = \frac{T}{W} \cdot MTOM
-\f$
+$ T_0 = \frac{T}{W} \cdot MTOM $
Where:
-- \f$ T_0 \f$ is the sea level static thrust.
-- \f$ \frac{T}{W} \f$ is the thrust-to-weight ratio (specified as `/aircraft_exchange_file/sizing_point/thrust_to_weight`).
-- \f$ MTOM \f$ is the maximum takeoff mass (specified as `/aircraft_exchange_file/analysis/masses_cg_inertia/maximum_takeoff_mass`).
-@note This might change with new propulsion architectures!
+- $T_0$ is the sea level static thrust.
+- $\frac{T}{W}$ is the thrust-to-weight ratio (specified as `/aircraft_exchange_file/sizing_point/thrust_to_weight`).
+- $MTOM$ is the maximum takeoff mass (specified as `/aircraft_exchange_file/analysis/masses_cg_inertia/maximum_takeoff_mass`).
+
+!!! note
+ This might change with new propulsion architectures!
Not only the thrust is important, but also the system off-takes. Current engine provide power to the systems and therefore, the thrust specific consumption can increase. To include that, the nodes `average_bleed_air_demand` and `average_bleed_air_demand` in `/aircraft_exchange_file/component_design/systems/specific/`are necessary (is set to default values if not existing).
@@ -78,7 +83,7 @@ Propulsion
| |- Thrust Share
```
Let's assume you want to design an aircraft with 5 engine - 2 on each side of the wing and one in the empennage. Additionally, you want to use 3 energy carrier: hydrogen, kerosene and battery-electric.
-For that, you need to define 3 energy carriers with each a type and a density with \f$ID=[0,1,2]\f$. Then you create 5 propulsor nodes with \f$ID=[0,...,4]\f$ and assign them each an a powertrain, type, ..., and thrust share. E.g. Engine 0 shall be a kerosene-powered turbofan in the empennage with a thrust share of \f$10\%\f$. Then it has the position with `parent_component=empennage`, `x=front`, `y=mid`, `z=in`. If the type of the energy carrier with ID=0 is set to kerosene, you need to assign `energy_carrier_id=0`. Also `powertrain=turbo`, `type=fan`, and `thrust_share=0.1`. Then Engine 1 could be a hydrogen-powered turboprop located under the left front inner wing with a thrust share of \f$25\%\f$. Then it has the position with `parent_component=wing`, `x=front`, `y=left`, `z=under`. If the type of the energy carrier with ID=1 is set to hydrogen, you need to assign `energy_carrier_id=1`. Also `powertrain=turbo`, `type=prop`, and `thrust_share=0.25`. The same procedure needs to be done for the other 3 engine.
+For that, you need to define 3 energy carriers with each a type and a density with $ID=[0,1,2]$. Then you create 5 propulsor nodes with $ID=[0,...,4]$ and assign them each an a powertrain, type, ..., and thrust share. E.g. Engine 0 shall be a kerosene-powered turbofan in the empennage with a thrust share of $10\%$. Then it has the position with `parent_component=empennage`, `x=front`, `y=mid`, `z=in`. If the type of the energy carrier with ID=0 is set to kerosene, you need to assign `energy_carrier_id=0`. Also `powertrain=turbo`, `type=fan`, and `thrust_share=0.1`. Then Engine 1 could be a hydrogen-powered turboprop located under the left front inner wing with a thrust share of $25\%$. Then it has the position with `parent_component=wing`, `x=front`, `y=left`, `z=under`. If the type of the energy carrier with ID=1 is set to hydrogen, you need to assign `energy_carrier_id=1`. Also `powertrain=turbo`, `type=prop`, and `thrust_share=0.25`. The same procedure needs to be done for the other 3 engine.
**Outputs**: The results are saved in the _acXML_ node `/aircraft_exchange_file/component_design/propulsion`.
diff --git a/docs/documentation/sizing/propulsion_design/index.md b/docs/documentation/sizing/propulsion_design/index.md
index 9dbf8b6..9caaff8 100644
--- a/docs/documentation/sizing/propulsion_design/index.md
+++ b/docs/documentation/sizing/propulsion_design/index.md
@@ -1,11 +1,12 @@
# Introduction {#mainpage}
The tool _propulsion_design_ is one of the core design tools in UNICADO. The overall goal is the design the propulsion based on...
+
- the architecture (e.g. 2 turbofan at rear fuselage, 4 fuel cell prop engine over the front wing) set by the user and,
- the total required thrust and system off-takes.
This tool is exciting!🔥 because the propulsion is THE critical component providing the thrust or power, enabling to propel the aircraft forward and move through the skies.🌍
To give you a general taste, here are a few illustrations of possible concepts.
-
+
The [getting started](getting_started.md) gives you a first insight in how to execute the tool and how it generally works. To understand how the tools works in detail, the documentation is split into a [engineering principles](engineering_principles.md) and a [software architecture](software_architecture.md) section.
diff --git a/docs/documentation/sizing/propulsion_design/software_architecture.md b/docs/documentation/sizing/propulsion_design/software_architecture.md
index e8f2c95..294c85b 100644
--- a/docs/documentation/sizing/propulsion_design/software_architecture.md
+++ b/docs/documentation/sizing/propulsion_design/software_architecture.md
@@ -23,6 +23,7 @@ Some additional words on the **propulsionStrategy**:
As you might also see in the [class diagram](figures/class_diagram.png), the core of it is the functor `operator()` for specific engine types to allow the `engine` object to be used as functions. This object is, depending on the user settings, based on the propulsion type classes (e.g. `Turbofan<Kerosene>`). As also shown in @ref propulsion.md, the type is combined with 3 "building blocks"
- *powertrain*: Way the power is generated from the source: turbo, electric, fuel_cell
+ -
- *type*: Type of main thrust generator: fan or prop
- *energy_carrier*: kerosene, liquid_hydrogen, battery (handled over IDs)
diff --git a/docs/documentation/sizing/tank_design/getting-started.md b/docs/documentation/sizing/tank_design/getting-started.md
index 4994d01..4b81a6a 100644
--- a/docs/documentation/sizing/tank_design/getting-started.md
+++ b/docs/documentation/sizing/tank_design/getting-started.md
@@ -8,7 +8,8 @@ This section will guide you through the necessary steps to get the _tank\_design
- [Additional requirements](#additional-requirements) - Is anything else necessary to get the module running?
- [Next steps](#next-steps) - How to proceed?
-@note It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
+!!! note
+ It is assumed that you have the `UNICADO package` installed including the executables and UNICADO libraries.
Generally, we use two files to set or configure modules in UNICADO:
- The aircraft exchange file (or _acXML_) includes
@@ -55,7 +56,8 @@ The following data should then be available in the _acXML_:
- Wing
- Empennage
-@note When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
+!!! note
+ When the UNICADO workflow is executed the tool is run automatically. In this case, all the required data should be available anyway.
## Configuring tank design parameters in the aircraft exchange file {#configuring-tank-design-parameters-in-the-aircraft-exchange-file}
The desired tank configuration is defined by the user in the aircraft exchange file. The information can be found in the `aircraft_exchange_file/requirements_and_specifications/design_specification/configuration/tank_definition` block.
@@ -230,10 +232,11 @@ The following `tank_definition` code block snippet shows how to configure a stan
```
<br>
-@note For aircraft with a single trapezoidal wing, please delete the `Outer left tank` and `Outer right tank` elements and adjust the other tank IDs accordingly.
+!!! note
+ For aircraft with a single trapezoidal wing, please delete the `Outer left tank` and `Outer right tank` elements and adjust the other tank IDs accordingly.
### Liquid hydrogen driven aircraft configurations {#lh2-driven}
-tbd. \emoji construction
+tbd. :construction:
## Module configuration file {#module-configuration-file}
The _configXML_ is structured into two blocks: the control and program settings.
@@ -243,7 +246,8 @@ The control settings are standardized in UNICADO and will not be described in de
- the `console_output` at least to `mode_1`, and
- the `plot_output` to false (or define `inkscape_path` and `gnuplot_path`).
-@note If the tool is executed via the workflow, those settings are set by the workflow settings.
+!!! note
+ If the tool is executed via the workflow, those settings are set by the workflow settings.
The program settings are structured like this (descriptions can be found in the `tank_design_conf.xml`):
diff --git a/docs/documentation/sizing/tank_design/index.md b/docs/documentation/sizing/tank_design/index.md
index b27c974..9b314d9 100644
--- a/docs/documentation/sizing/tank_design/index.md
+++ b/docs/documentation/sizing/tank_design/index.md
@@ -6,9 +6,9 @@ Here’s a quick rundown of what the tool currently does, along with a sneak pee
Configuration | Energy carrier | Fidelity | Methods | Status |
------------------|------------------|-----------|-----------|:------------------------------------:|
-Tube-and-wing |Kerosene |Empirical |TUB |running \emoji white_check_mark |
-Tube-and-wing |Liquid hydrogen |Empirical |TUB |under development \emoji construction |
-Blended-wing-body |... |... |... |under development \emoji construction |
+Tube-and-wing |Kerosene |Empirical |TUB |running :white_check_mark: |
+Tube-and-wing |Liquid hydrogen |Empirical |TUB |under development :construction: |
+Blended-wing-body |... |... |... |under development :construction: |
## A user's guide to tank design
The _tank\_design_ tool is your key to designing the aircraft's fuel storage. In this user documentation, you’ll find all the information you need to understand the tool, as well as the necessary inputs and configurations to run a tank design from the ground up.
@@ -21,7 +21,7 @@ For a comprehensive understanding of the tool’s functionality, the documentati
- a [software architecture](software_architecture.md)
section.
-Ready to dive in? Let’s get started! \emoji airplane
+Ready to dive in? Let’s get started! :airplane:
<!-- ## You are a Developer?
diff --git a/docs/documentation/sizing/tank_design/run_your_first_tank_design.md b/docs/documentation/sizing/tank_design/run_your_first_tank_design.md
index 50d4998..400fe0a 100644
--- a/docs/documentation/sizing/tank_design/run_your_first_tank_design.md
+++ b/docs/documentation/sizing/tank_design/run_your_first_tank_design.md
@@ -88,7 +88,8 @@ In the following, a short overview is given on the generated reports:
@warning Steffi: Check if additional output written
### Write data to the aircraft exchange file {#acxml}
-@note The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
+!!! note
+ The _acXML_ is an exchange file - we agreed on that only data will be saved as output that is needed by another tool!
Results are saved in the aircraft exchange file at the `/aircraft_exchange_file/component_design/tank`. node. The following information is written to the _acXML_:
```plaintext
diff --git a/docs/documentation/sizing/tank_design/software_architecture.md b/docs/documentation/sizing/tank_design/software_architecture.md
index e2e5717..b947e4a 100644
--- a/docs/documentation/sizing/tank_design/software_architecture.md
+++ b/docs/documentation/sizing/tank_design/software_architecture.md
@@ -1,5 +1,5 @@
# Software architecture
-This site is currently under development. \emoji construction
+This site is currently under development. :construction:
<!--
## Module structure
diff --git a/docs/documentation/sizing/tank_design/tank_design_method.md b/docs/documentation/sizing/tank_design/tank_design_method.md
index 24b1085..dd7c72b 100644
--- a/docs/documentation/sizing/tank_design/tank_design_method.md
+++ b/docs/documentation/sizing/tank_design/tank_design_method.md
@@ -11,13 +11,13 @@ For kerosene-powered aircraft, the fuel is stored in the wing. Additional tanks
<!-- The tank design process starts with determining the required energy amount since the energy amount is necessary to
check whether the tank capacity is big enough to store the mission energy. If this information is not yet available
in the _acXML_ in the first iteration loop, an initial estimate is made:
-\f[
+$
E_{\text{mission}} = n_{\text{PAX}} \cdot R \cdot fc_{\text{approx}}
-\f]
+$
In which
-- \f$n_{\text{PAX}}\f$ - number of passengers
-- \f$R\f$ - range in km
-- \f$fc_{\text{approx}}\f$ - approx. fuel consumption per passenger per 100 km (ca. 3.5 L/100 km) -->
+- $n_{\text{PAX}}$ - number of passengers
+- $R$ - range in km
+- $fc_{\text{approx}}$ - approx. fuel consumption per passenger per 100 km (ca. 3.5 L/100 km) -->
The tank design starts with the wing tanks. Initially, the available volume of the complete wing is calculated which is then followed by the dimensioning of the vent tank. Afterwards, the wing is divided into several tanks based on its geometry. The gross volume of these tanks is calculated using the [obelisk method](#obelisk-method). This is followed by accounting for volume losses due to structural components and thermal expansion, resulting in the net [usable tank volume](#net-tank-volume).
The [energy stored](#calculate-energy) in the tanks is then calculated using the volumetric energy density of kerosene.
@@ -46,81 +46,83 @@ The obelisk volume can be determined using two different approaches that are des
The user can select the desired method via the following node in the `program_settings` section of the _confXML_:
`configuration[@ID="tube_and_wing"]/specific/kerosene_tank_design_parameter/obelisk_calculation_method`.
-@note The obelisk method is explained using the wing as an example. The volume of a [trim tank](#trim-tank) located in the horizontal stabilizer is determined analogously.
+!!! note
+ The obelisk method is explained using the wing as an example. The volume of a [trim tank](#trim-tank) located in the horizontal stabilizer is determined analogously.
##### Obelisk volume according to Torenbeek<sup>[1]</sup>
The volume can be calculated using the following equation:
-\f[
+$
V_{\text{obelisk}} = \frac{l}{3} \cdot \left( S_1 + S_2 + \frac{h_1 \cdot w_2 + h_2 \cdot w_1}{2}\right)
-\f]
+$
In which
-- \f$l\f$ - length
-- \f$S_1\f$, \f$S_2\f$ - end face areas
-- \f$h_1\f$, \f$w_1\f$ - height and width of end face \f$S_1\f$
-- \f$h_2\f$, \f$w_2\f$ - height and width of end face \f$S_2\f$
+- $l$ - length
+- $S_1$, $S_2$ - end face areas
+- $h_1$, $w_1$ - height and width of end face $S_1$
+- $h_2$, $w_2$ - height and width of end face $S_2$
-The parallel end faces \f$S_1\f$ and \f$S_2\f$ are derived from the position of the spars of the wing box, that are
+The parallel end faces $S_1$ and $S_2$ are derived from the position of the spars of the wing box, that are
known from the wing design.
<!-- Based on the formula for determining the area of a rectangle:
-\f[
+$
S_{i} = h_i \cdot w_i
-\f]
-the size of the parallel end surfaces \f$S_1\f$ and \f$S_2\f$ is obtained by extending it with the chord length
-\f$l_{chord}\f$:
-\f[
+$
+the size of the parallel end surfaces $S_1$ and $S_2$ is obtained by extending it with the chord length
+$l_{chord}$:
+$
S_{i} = \frac{h_i}{l_{chord}} \cdot l_{chord} \cdot w_i
-\f]
-By multiplying with the maximum thickness \f$h_{max}\f$ and substituting the width \f$w_i = p_{fs}-p_{rs}\f$, we get:
-\f[
+$
+By multiplying with the maximum thickness $h_{max}$ and substituting the width $w_i = p_{fs}-p_{rs}$, we get:
+$
S_{i} = \frac{h_{max}}{l_{chord}} \cdot \frac{h_{i}}{h_{max}} \cdot l_{chord} \cdot (p_{rs} - p_{fs})
-\f]
+$
Where
-- \f$\frac{h_{max}}{l_{chord}}\f$ - maximum thickness ratio of used profile
-- \f$\frac{a_{max}}{d_{max}}\f$ - ...
-- \f$p_{rs}\f$ - position rear spar
-- \f$p_{fs}\f$ - position front spar
+- $\frac{h_{max}}{l_{chord}}$ - maximum thickness ratio of used profile
+- $\frac{a_{max}}{d_{max}}$ - ...
+- $p_{rs}$ - position rear spar
+- $p_{fs}$ - position front spar
- -->
+ -->
##### Obelisk volume according to Simpson
The Simpson's rule is a method of numerical integration that is often used to calculate the volume of bodies whose
cross-sections are known at different positions. In the case of an obelisk - i.e. a body with square or rectangular
-cross-sections that vary along the height - the volume is integrated as the sum of the cross-sectional areas \f$S(x)\f$
-along the length \f$l\f$:
-\f[
+cross-sections that vary along the height - the volume is integrated as the sum of the cross-sectional areas $S(x)$
+along the length $l$:
+$
V_{\text{obelisk}} = \int_0^l S(x) \, dx
-\f]
+$
-If the cross-sectional areas \f$S(x)\f$ at \f$i+1\f$ uniformly distributed points are known (which is the case for the
+If the cross-sectional areas $S(x)$ at $i+1$ uniformly distributed points are known (which is the case for the
tank design), Simpson's rule can be applied.
-Two end surfaces are known for each tank, so that a third middle surface \f$S_{12}\f$ can be determined by linear
+Two end surfaces are known for each tank, so that a third middle surface $S_{12}$ can be determined by linear
interpolation (see following figure). Each tank is thus divided into two sections.
The tank volume can therefore be determined using a simplified Simpson's rule:
-\f[
+$
V_{\text{obelisk}} = \frac{l}{6.0} \cdot (S_{1} + 4.0 \cdot S_{12} + S_{2})
-\f]
+$
#### Calculate net tank volume {#net-tank-volume}
-The volume must then be converted from cubic meter to liter. A portion of the volume of the obelisk is lost to the internal structure of the integral tanks (e.g., ribs), with a reduction factor \f$ f_{\text{volume,usable}} = 0.95\f$.
-Additionally, the expansion of the fuel due to heating must be considered, with a temperature expansion allowance of \f$ a_{\text{temperature,expansion}} = 0.95\f$. Thus, the wing tank volume is calculated as:
-\f[
+The volume must then be converted from cubic meter to liter. A portion of the volume of the obelisk is lost to the internal structure of the integral tanks (e.g., ribs), with a reduction factor $ f_{\text{volume,usable}} = 0.95$.
+Additionally, the expansion of the fuel due to heating must be considered, with a temperature expansion allowance of $ a_{\text{temperature,expansion}} = 0.95$. Thus, the wing tank volume is calculated as:
+$
V_{\text{tank}} = f_{\text{volume,usable}} \cdot a_{\text{temperature,expansion}} \cdot V_{\text{obelisk}}
-\f]
+$
-@note As the wing has a vent tank at each wing tip to allow for the thermodynamic expansion of the fuel, this factor is `1.0` for the wing tanks.
+!!! note
+ As the wing has a vent tank at each wing tip to allow for the thermodynamic expansion of the fuel, this factor is `1.0` for the wing tanks.
#### Calculate energy {#calculate-energy}
-Using the volumetric energy density of kerosene \f$\eta_{\text{v,kerosene}}\f$, the energy contained in each tank can be determined:
-\f[
+Using the volumetric energy density of kerosene $\eta_{\text{v,kerosene}}$, the energy contained in each tank can be determined:
+$
V_{\text{tank}} = \eta_{\text{v,kerosene}} \cdot V_{\text{obelisk}}
-\f]
+$
### Additional center tank
The module allows the installation of an additional center tank in the form of an LD3-45 container. The process includes the following steps:
@@ -130,25 +132,26 @@ The module allows the installation of an additional center tank in the form of a
2. **Installation placement**: The LD3-45 container is positioned 10 cm behind the end of the landing gear bay, aligning approximately with the trailing edge of the wing.
3. **Container data**: The volume and dimensions of the LD3-45 container are predefined and referenced from the Lufthansa Cargo website<sup>[2]</sup>.
-The energy contained in an additional center tank is calculated by first determining the usable volume and then taking into account the volumetric energy density of kerosene. With the known factors \f$ f_{\text{volume,usable}}\f$ and \f$a_{\text{temperature,expansion}}\f$, the usable volume of an additional center tank results in \f$V_{\text{ACT,usable}} = 3068.5\text{ L}\f$ which is equal to an energy amount of \f$ E_{\text{ACT}} = 99189262.5\text{ MJ}\f$.
+The energy contained in an additional center tank is calculated by first determining the usable volume and then taking into account the volumetric energy density of kerosene. With the known factors $ f_{\text{volume,usable}}$ and $a_{\text{temperature,expansion}}$, the usable volume of an additional center tank results in $V_{\text{ACT,usable}} = 3068.5\text{ L}$ which is equal to an energy amount of $ E_{\text{ACT}} = 99189262.5\text{ MJ}$.
#### Limitations
**Single Center Tank Limit:** The program currently supports the calculation of only one additional center tank. Attempts to add more tanks will not be processed.
-@note Verify that the cargo compartment dimensions are correctly provided to ensure accurate installation.
+!!! note
+ Verify that the cargo compartment dimensions are correctly provided to ensure accurate installation.
### Trim tank {#trim-tank}
-The procedure for the trim tank is the same as for the wing tanks. The geometry of the horizontal stabilizer is simplified and divided into several obelisks whose volume is calculated. The usable volume is then determined, taking the already known factors \f$ f_{\text{volume,usable}}\f$ and \f$ a_{\text{temperature,expansion}}\f$ into account. Finally, the available energy is determined.
+The procedure for the trim tank is the same as for the wing tanks. The geometry of the horizontal stabilizer is simplified and divided into several obelisks whose volume is calculated. The usable volume is then determined, taking the already known factors $ f_{\text{volume,usable}}$ and $ a_{\text{temperature,expansion}}$ into account. Finally, the available energy is determined.
<!-- ### Assumptions and tool limitations
-tbd. \emoji construction -->
+tbd. :construction -->
<!-- - All tanks with the same energy carrier (e.g. liquid_hydrogen) have the same design parameters -->
<!-- - Design point for tank design: Point B, design mission -->
<!-- - Der Rumpf wird gestretcht. Es gibt keine Option, die Kabine kleiner zu machen bisher. -->
<!-- - Positionsangaben beziehen sich immer auf vordersten und innersten Punkt, wobei z die Mitte der Ebene angibt (dabei liegt die Annahme zugrunde, dass beim wing auch immer die center line des profils bei der z-Koordinate angegeben wird) -->
## Liquid hydrogen tanks {#liquid-hydrogen-tanks}
-tbd. \emoji construction
+tbd. :construction:
---
<sup>[1]</sup> E. Torenbeek, 1982. *Synthesis of Subsonic Airplane Design*.<br>
--
GitLab