From 02278c9197f83ceb6aae8b2cf82c0aee4a40aeb6 Mon Sep 17 00:00:00 2001
From: Alfin Johny <alfin.johny@tum.de>
Date: Tue, 28 Jan 2025 15:00:01 +0100
Subject: [PATCH] Fix broken links
---
.gitlab-ci.yml | 3 ++
docs/documentation/libraries.md | 4 +--
.../libraries/aircraftGeometry2/index.md | 8 ++---
.../sizing/empennage_design/dfe.md | 4 +--
.../landing_gear_design/design_method.md | 4 +--
.../engineering_principles.md | 6 ++--
.../software_architecture.md | 6 ++--
.../sizing/tank_design/tank_design_method.md | 6 ++--
docs/documentation/sizing/wing_design/dfw.md | 2 +-
mkdocs.yml | 31 ++++++++++---------
10 files changed, 39 insertions(+), 35 deletions(-)
diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 943ac59..a08f136 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -41,6 +41,8 @@ clone:
# Save the generated documentation as artifacts so they can be accessed later in the pipeline
paths:
- $CI_PROJECT_DIR/aircraft-design
+ - $CI_PROJECT_DIR/libraries
+ - $CI_PROJECT_DIR/docs/documentation
rules:
- if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH' # Run when the commit is on the default branch
when: on_success # Only run if the previous jobs are successful
@@ -67,6 +69,7 @@ pages:
- pipenv install --dev # Install all necessary dependencies
script:
# Build the MkDocs documentation site
+ - cp -r $CI_PROJECT_DIR/aircraft-design $CI_PROJECT_DIR/docs/documentation # Copy aircraft-design to the docs/documentation folder
- pipenv run mkdocs build --verbose --site-dir $CI_PROJECT_DIR/public
needs:
- clone # This job depends on the successful completion of the clone job
diff --git a/docs/documentation/libraries.md b/docs/documentation/libraries.md
index 2537022..b39adfa 100644
--- a/docs/documentation/libraries.md
+++ b/docs/documentation/libraries.md
@@ -39,7 +39,7 @@ The modularity and flexibility is achieved by using the high performance [Comput
|Module Version|Language|License|Documentation|Dependencies|
|:---:|:---:|:---:|---|---|
-|2.1.0|:simple-cplusplus: |GPLv3|[Link](libraries/aircraftGeometry2/content/index.md)| [Eigen3](https://eigen.tuxfamily.org/index.php?title=Main_Page), [CGAL](https://www.cgal.org/)|
+|2.1.0|:simple-cplusplus: |GPLv3|[Link](libraries/aircraftGeometry2/index.md)| [Eigen3](https://eigen.tuxfamily.org/index.php?title=Main_Page), [CGAL](https://www.cgal.org/)|
---
@@ -181,7 +181,7 @@ The `simple vector library` by Andrew Willmott provides vector and matrix classe
|Module Version|Language|License|Documentation|Dependencies|
|:---:|:---:|:---:|---|---|
-|2.1.0|:simple-cplusplus: | |[Link](https://www.cs.cmu.edu/~ajw/svl.html)|-|
+|2.1.0|:simple-cplusplus: | |[Link](https://www.cs.cmu.edu/~ajw/doc/svl.html)|-|
!!! note
This will soon be replaced by `Eigen`.
diff --git a/docs/documentation/libraries/aircraftGeometry2/index.md b/docs/documentation/libraries/aircraftGeometry2/index.md
index 0db0ce1..5286723 100644
--- a/docs/documentation/libraries/aircraftGeometry2/index.md
+++ b/docs/documentation/libraries/aircraftGeometry2/index.md
@@ -23,7 +23,7 @@ If you want to use the full flexibility of **CGAL** you need to implement your t
## 2D Geometry
The base of every geometry are 2D sections. The base properties of such a shape are shown here:
-{html: width=30%}
+{html: width=30%}
A section **always** defines its local axes as `X` and `Y`. Where `X` is the *horizontal* axis and `Y` the *vertical* axis.
The origin point of the section is the origin point of the local coordinate system.
@@ -47,7 +47,7 @@ For example: An **AirfoilSection** can only set the *chord length* as opposed to
## 3D Geometry
The connection from the 2D section to create 3D surfaces are [multi-section surfaces](@ref geom2.MultisectionSurface). A multi-section surface consists of multiple sections which form the single segments of the the surface. A projected view of such a surface might look like this:
-{html: width=30%}
+{html: width=30%}
The example consists of three surface sections which result in **two** surface segments.
Note, that the library rather uses sections and not segments and therefore does not allow for disconnected steps in between the sections directly. You can however insert two section at the same location, which have different shapes. This effectively gives a stepped shape when viewed from any side, but the data structure itself is still connected.
@@ -80,7 +80,7 @@ Whenever one entity is contained within another parent entity, the **parent coor
### Transform from 2D to 3D
Let's look at a simple example, which mainly uses 2D coordinates:
-{html: width=30%}
+{html: width=30%}
The *local point* `p` has 2D coordinates and is defined within the *local coordinate* system of `child`. The `child` represents a 2D section here, so it technically does not have a `Z` axis in its local coordinate space. It is just shown here for completeness to always remember the right-hand convention.
@@ -123,6 +123,6 @@ In the end, you do not need to understand this in great detail to use the librar
## Class Diagram
Here is an overview how the library is structured:
-{html: width=1000}
+{html: width=1000}
@note This is still work in progress and can change!
diff --git a/docs/documentation/sizing/empennage_design/dfe.md b/docs/documentation/sizing/empennage_design/dfe.md
index d9d7613..66dd141 100644
--- a/docs/documentation/sizing/empennage_design/dfe.md
+++ b/docs/documentation/sizing/empennage_design/dfe.md
@@ -153,7 +153,7 @@ Let's have a look at it.
## Reporting
The HTML report is splitted - on the left half, one can see numerical information of the empennage design. The right side contains plots and visual information.
-
+
It starts with general information for the vertical stabilizer by section parameters. Then you get information on spars and control devices. It concludes with mass information.
@@ -165,7 +165,7 @@ Lets change a parameter for the vertical stabilizer → we reduce the rudder
The resulted output in the console will not change, however you see that the rudder area is quite small:
-
+
Soo .... Now it is your turn!
diff --git a/docs/documentation/sizing/landing_gear_design/design_method.md b/docs/documentation/sizing/landing_gear_design/design_method.md
index f678d16..896cc0b 100644
--- a/docs/documentation/sizing/landing_gear_design/design_method.md
+++ b/docs/documentation/sizing/landing_gear_design/design_method.md
@@ -24,7 +24,7 @@ Afterwards, critical distances (lever arms) and tipping points for estimating lo
Default values are assigned if parameters are not explicitly provided.
### Horizontal distances
-
+
#### Distance between nose and main landing gear
The distance between the nose and the main landing gear can be estimated using the following equation:
@@ -65,7 +65,7 @@ Otherwise, \f$d_{NLG\_rear\_CG}\f$ is determined by using a first estimation:
If no distance between the main landing gear and the rearmost center of gravity is available from earlier iterations, it equals `1`.
### Vertical distances
-
+
#### 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.
diff --git a/docs/documentation/sizing/propulsion_design/engineering_principles.md b/docs/documentation/sizing/propulsion_design/engineering_principles.md
index 4168395..d0cd301 100644
--- a/docs/documentation/sizing/propulsion_design/engineering_principles.md
+++ b/docs/documentation/sizing/propulsion_design/engineering_principles.md
@@ -34,12 +34,12 @@ 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$.
-
+
@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.
@@ -126,7 +126,7 @@ For the **pylon designer**, only one method is implemented:
In the current method, the mounting is attached to the beginning to the nacelle to the leading edge of the wing. The length is the engine length which is extruded to the wing. the profile is, likewise for the nacelle, defined in the _configXML_.
-
+
@note the implementation include currently Turbofan Kerosene only
diff --git a/docs/documentation/sizing/propulsion_design/software_architecture.md b/docs/documentation/sizing/propulsion_design/software_architecture.md
index 3fed44e..e8f2c95 100644
--- a/docs/documentation/sizing/propulsion_design/software_architecture.md
+++ b/docs/documentation/sizing/propulsion_design/software_architecture.md
@@ -2,7 +2,7 @@
## Software Architecture Overview
-The software architecture is structured into various modules and packages, each handling specific task. Below is a description of the main components (some classes, interfaces etc. are left out to keep it understandable for now - for more information see the [class diagram](img/class_diagram.png) or the source code):
+The software architecture is structured into various modules and packages, each handling specific task. Below is a description of the main components (some classes, interfaces etc. are left out to keep it understandable for now - for more information see the [class diagram](figures/class_diagram.png) or the source code):
- classes:
- **propulsionDesign** is like the "coordinator" responsible for the overall propulsion system design including _initialize_, _run_, _update_, _report_ and _save_ (inherits from `Module` class from **moduleBasics**). These include e.g. method selection function for each disciplines
@@ -21,7 +21,7 @@ The software architecture is structured into various modules and packages, each
Some additional words on the **propulsionStrategy**:
-As you might also see in the [class diagram](img/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"
+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)
@@ -31,4 +31,4 @@ So, if you want to use different combinations in UNICADO, you need to make sure
## Class Diagram {#classdiagram}
Here is an overview how the module is structured:
-{html: width=1000}
+{html: width=1000}
diff --git a/docs/documentation/sizing/tank_design/tank_design_method.md b/docs/documentation/sizing/tank_design/tank_design_method.md
index 8f331b1..24b1085 100644
--- a/docs/documentation/sizing/tank_design/tank_design_method.md
+++ b/docs/documentation/sizing/tank_design/tank_design_method.md
@@ -40,7 +40,7 @@ Knowing the necessary vent tank volume, the remaining volume of the wing tanks c
#### Obelisk method {#obelisk-method}
The obelisk method simplifies the wing by dividing it into several volumes. Depending on the geometry, this results in three (single trapezoidal wing) or five (double trapezoidal/kinked wing) individual wing tanks, each of which has the shape of an obelisk. In the case of a double trapezoidal geometry, it is assumed that the wing can be divided into an inner tank (wing root to kink) and an outer tank (kink to vent tank position) per side as well as a wing center tank.
-
+
The obelisk volume can be determined using two different approaches that are described in the following.
The user can select the desired method via the following node in the `program_settings` section of the _confXML_:
@@ -49,7 +49,7 @@ The user can select the desired method via the following node in the `program_se
@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[
@@ -100,7 +100,7 @@ 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
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[
diff --git a/docs/documentation/sizing/wing_design/dfw.md b/docs/documentation/sizing/wing_design/dfw.md
index fd9968a..4b207fc 100644
--- a/docs/documentation/sizing/wing_design/dfw.md
+++ b/docs/documentation/sizing/wing_design/dfw.md
@@ -225,7 +225,7 @@ Let's have a look at it.
## Reporting
The HTML report is splitted - on the left half, one can see numerical information of the wing design. The right side contains plots and visual information.
-
+
It starts with general information followed by section parameters. Then you get information on spars and control devices. It concludes with mass information.
diff --git a/mkdocs.yml b/mkdocs.yml
index 5bb700d..43e8a02 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -256,20 +256,20 @@ nav: # Customizes the main navigation struc
- systems_design/namespaces.md
- systems_design/files.md
- systems_design/functions.md
- - Analysis:
- - Modules: documentation/analysis.md # Link to analysis module page.
- - Weight and Balance Analysis:
+ - Analysis:
+ - Modules: documentation/analysis.md # Link to analysis module page.
+ - Weight and Balance Analysis:
- Introduction: documentation/analysis/weight_and_balance_analysis/index.md
- Basic Concepts: documentation/analysis/weight_and_balance_analysis/basic-concepts.md
- Usage: documentation/analysis/weight_and_balance_analysis/usage.md
# - API Reference: # TODO define for Python
- - Cost Estimation:
+ - Cost Estimation:
- Introduction: documentation/analysis/cost_estimation/index.md
- Getting Started: documentation/analysis/cost_estimation/getting-started.md
- Methods: documentation/analysis/cost_estimation/operating_cost_method.md
- Run your First Estimation: documentation/analysis/cost_estimation/run_your_first_cost_estimation.md
# - API Reference: # TODO define for Python
- - Ecological Assessment:
+ - Ecological Assessment:
- Introduction: documentation/analysis/ecological_assessment/index.md
- Getting Started: documentation/analysis/ecological_assessment/getting-started.md
- Changelog: documentation/analysis/ecological_assessment/changelog.md
@@ -278,16 +278,17 @@ nav: # Customizes the main navigation struc
- ecological_assessment/namespaces.md
- ecological_assessment/files.md
- ecological_assessment/functions.md
- - Libraries: documentation/libraries.md # Link to libraries overview.
- - AircraftGeometry2:
- - Introduction: documentation/libraries/aircraftGeometry2/index.md
- - Getting Started: documentation/libraries/aircraftGeometry2/getting-started.md
- - Tutorial: documentation/libraries/aircraftGeometry2/tutorial.md
- - API Reference:
- - aircraftGeometry2/classes.md
- - aircraftGeometry2/namespaces.md
- - aircraftGeometry2/files.md
- - aircraftGeometry2/functions.md
+ - Libraries:
+ - Overview: documentation/libraries.md # Link to libraries overview.
+ - AircraftGeometry2:
+ - Introduction: documentation/libraries/aircraftGeometry2/index.md
+ - Getting Started: documentation/libraries/aircraftGeometry2/getting-started.md
+ - Tutorial: documentation/libraries/aircraftGeometry2/tutorial.md
+ - API Reference:
+ - aircraftGeometry2/classes.md
+ - aircraftGeometry2/namespaces.md
+ - aircraftGeometry2/files.md
+ - aircraftGeometry2/functions.md
- Utilities: documentation/additional_software.md
- Workflow: 'workflow.md' # Link to the workflow page.
- Get Involved:
--
GitLab