diff --git a/README.md b/README.md
index a8adcc1976b53ee4793a66afcb7bf9be55a82823..d3168f8d82682b39b60e81b1ab728998e1f32254 100644
--- a/README.md
+++ b/README.md
@@ -21,4 +21,22 @@ This will start a local webserver which you can access with your webbrowser and
For features of the site generator and its theme please refer to their excellent documentation:
- [⤷ MkDocs](https://www.mkdocs.org/user-guide/)
-- [⤷ MkDocs Material](https://squidfunk.github.io/mkdocs-material/)
\ No newline at end of file
+- [⤷ MkDocs Material](https://squidfunk.github.io/mkdocs-material/)
+
+## Page Template
+The pages are written in plain *markdown*.
+The site generator has the option the extract some meta data from the content.
+A template might look like this:
+```
+---
+title: Displayed Title of Page
+summary: Summary of the page content.
+authors:
+ - Author 1
+ - Author 2
+date: yyyy-mm-dd
+---
+# MyPage
+
+<Content goes here>
+```
\ No newline at end of file
diff --git a/docs/assets/images/logo-bmwk.png b/docs/assets/images/logos/bmwk.png
similarity index 100%
rename from docs/assets/images/logo-bmwk.png
rename to docs/assets/images/logos/bmwk.png
diff --git a/docs/assets/images/icon.png b/docs/assets/images/logos/unicado-icon.png
similarity index 100%
rename from docs/assets/images/icon.png
rename to docs/assets/images/logos/unicado-icon.png
diff --git a/docs/assets/images/logo.png b/docs/assets/images/logos/unicado.png
similarity index 100%
rename from docs/assets/images/logo.png
rename to docs/assets/images/logos/unicado.png
diff --git a/docs/assets/images/screenshots/cmake-gui.png b/docs/assets/images/screenshots/cmake-gui.png
new file mode 100644
index 0000000000000000000000000000000000000000..5ab6cb0a45203bfcd336e3d28e1987d7f8b96809
--- /dev/null
+++ b/docs/assets/images/screenshots/cmake-gui.png
@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:212a282280ddf11616e720c08a4fe4ec9a40eb24c691f552dd23ac6125ec9070
+size 49802
diff --git a/docs/assets/images/screenshot-rce.png b/docs/assets/images/screenshots/rce.png
similarity index 100%
rename from docs/assets/images/screenshot-rce.png
rename to docs/assets/images/screenshots/rce.png
diff --git a/docs/assets/images/screenshot-tigl.png b/docs/assets/images/screenshots/tigl.png
similarity index 100%
rename from docs/assets/images/screenshot-tigl.png
rename to docs/assets/images/screenshots/tigl.png
diff --git a/docs/developer/build-cpp.md b/docs/developer/build-cpp.md
new file mode 100644
index 0000000000000000000000000000000000000000..dd3ba20c4ed4a90ca7dc4307d0c263cc2e08886f
--- /dev/null
+++ b/docs/developer/build-cpp.md
@@ -0,0 +1,199 @@
+---
+title: Building C++ Modules
+summary: How to build C++ modules of UNICADO.
+authors:
+ - Sebastian Oberschwendtner
+date: 2023-09-12
+---
+**UNICADO** uses [CMake :octicons-link-external-16:](https://cmake.org/) for generating the build files.
+CMake is a build system generator, which allows for cross-platform compilation.
+For more information about this system, please refer to its [Documentation :octicons-link-external-16:](https://cmake.org/cmake/help/latest/).
+
+## Configure CMake
+Since **CMake** is independent of the used platform, it needs to figure out on which platform you are running your current build. This process is called *Configuration*. During configuration, **CMake** checks on which platform you are and selects the appropriate build system/compiler.
+**CMake** wants to separate the build specific files from the source files. Usually, this is done by providing a separate *build* directory, where all the intermediate files are stored before actually executing the build.
+With this information in mind the configuration steps are:
+
+1. Open a terminal inside the root directory of the *rAircraftDesign* repository.
+2. Create a folder called `build` if it does not exist yet with `mkdir build`.
+
+ !!! note
+ This *build* folder is not part of the repository.
+
+3. Configure **CMake** by explicitly telling it to generate build files for your platform with the option `-G`:
+
+=== "Windows"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "Visual Studio 16 2019" -A x86 -T ClangCL,hosT=x86
+ ```
+
+=== "MinGW"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "MinGW Makefiles"
+ ```
+=== "Unix"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "Unix Makefiles"
+ ```
+
+During this configuration, **CMake** generates a cache file which remembers some parameters which are re-used when you configure **CMake** again.
+This cache files is __not__ automatically deleted/updated, which can lead to some unexpected behavior.
+When this happens, you can tell **CMake** explicitly to refresh this cache by:
+
+=== "Windows"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "Visual Studio 16 2019" -A x86 -T ClangCL,hosT=x86 --fresh
+ ```
+
+=== "MinGW"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "MinGW Makefiles" --fresh
+ ```
+=== "Unix"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "Unix Makefiles" --fresh
+ ```
+
+Alternatively, you can just delete everything inside the build directory before configuring **CMake** again.
+
+The default build configuration of **CMake** is ^^Release^^. The build configuration can be changed, for example to ^^Debug^^, by:
+
+=== "Windows"
+
+ !!! quote
+ :fontawesome-solid-arrow-right: The *Windows* build system is a so-called **multi configuration generator**.
+ This means its build type can be set during build and does not have to be configured.
+
+=== "MinGW"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "MinGW Makefiles" -DCMAKE_BUILD_TYPE:STRING=Debug
+ ```
+=== "Unix"
+
+ ``` { .sh .copy }
+ cmake -B build -S . -G "Unix Makefiles"-DCMAKE_BUILD_TYPE:STRING=Debug
+ ```
+
+### GUI
+**CMake** also comes with a GUI which can be used for the configuration process.
+The GUI looks like this:
+
+
+
+It works the same as the command line interface.
+You have to specify the path to the source files and to the build directory.
+You also see the exposed options of the project.
+And as the GUI already tells you:
+> Press Configure to update and display new values in red, then press Generate to generate selected build files.
+
+### Options
+These project options are currently available during configuration time:
+
+| Name | Default | Description |
+| --- | :---: | ---|
+|**BUILD_BLACKBOXTESTS**| `OFF` | Whether to build the blackbox tests. (If available)|
+|**BUILD_UNITTEST**| `OFF` |Whether to build the unit tests. (If available)|
+|**BUILD_SHARED_LIBS**| `OFF` | Decide whether the libraries are built as static or shared libraries.|
+|**PACKAGE_SYSTEM_LIBRARIES**| `OFF` | Whether to include all system libraries when creating release packages. *(Only available in `rUNICADO`)* |
+|**FIND_LIBRARIES_AS_PACKAGE**| `OFF` |If *true* the libraries are included with `find_package()`, otherwise the *submodule* with `add_subdirectory()` is used.|
+|**STATIC_GLIBS**| `OFF` | Whether to link the *GCC runtime libraries* as static libraries. :warning: ^^**Experimental**^^ |
+
+The other options shown in the GUI are specific to **CMake**.
+(*Not all options shown in the table are part of the screenshot, since the screenshot was taken before these options were introduced.*)
+
+---
+
+## Build with CMake
+**CMake** also provides a convenient interface to invoke the build system without you needing to know which build system is actually used.
+The different modules or executables are called *targets* in the **CMake** language.
+So to build a specific target you call **CMake** with the following command, where `build` is the created build directory and `the-target` is the name of the module you want to compile:
+
+=== "Windows"
+
+ ```sh
+ cmake --build build --target the-target --config build-type
+ ```
+ :fontawesome-solid-arrow-right: The `build-type` can be one of the usual suspects:
+
+ - **Release**
+ - **Debug**
+ - **MinSizeRel**
+
+=== "MinGW"
+
+ ```sh
+ cmake --build build --target the-target
+ ```
+
+ !!! tip
+ Remember: the build type is already specified when configuring **CMake** :point_up:.
+
+=== "Unix"
+
+ ```sh
+ cmake --build build --target the-target
+ ```
+
+ !!! tip
+ Remember: the build type is already specified when configuring **CMake** :point_up:.
+
+When you want to compile all the modules ^^at once^^, you can just omit the *target* option and call **CMake** with:
+
+=== "Windows"
+
+ ```sh
+ cmake --build build --config build-type
+ ```
+
+=== "MinGW"
+
+ ```sh
+ cmake --build build
+ ```
+
+=== "Unix"
+
+ ```sh
+ cmake --build build
+ ```
+
+You can also clean the build before re-compiling:
+
+=== "Windows"
+
+ ```sh
+ cmake --build build --target the-target --config build-type --clean-first
+ ```
+
+=== "MinGW"
+
+ ```sh
+ cmake --build build --target the-target --clean-first
+ ```
+
+=== "Unix"
+
+ ```sh
+ cmake --build build --target the-target --clean-first
+ ```
+
+That's all folks. This should compile *UNICADO* just fine. ๐
+
+!!! warning
+ Make sure to update your **PATH** with the new runtime libraries (when compiled as shared libraries), which are located in: /path-to-libs-submodule/unicadoRuntimeLibs/
+
+### Improve Compilation Speed
+You can increase the build speed by enabling parallel jobs of the build tool. This is as easy as this:
+
+```sh
+cmake --build build --target the-target -j n-jobs
+```
+
+This builds the project using `n-jobs` processes. You can give any number here, but it should correspond to the number of processors available on your machine.
diff --git a/docs/developer/build-python.md b/docs/developer/build-python.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/developer/contribute.md b/docs/developer/contribute.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/developer/environment-cpp.md b/docs/developer/environment-cpp.md
new file mode 100644
index 0000000000000000000000000000000000000000..50653fd6398181da47047564bd8b7daa045a1171
--- /dev/null
+++ b/docs/developer/environment-cpp.md
@@ -0,0 +1,10 @@
+
+## Build
+
+=== "Unix"
+
+ When using Unix
+
+=== "Windows"
+
+ When using windows
\ No newline at end of file
diff --git a/docs/developer/environment-python.md b/docs/developer/environment-python.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/developer/ide-setup.md b/docs/developer/ide-setup.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/developer/including-libraries.md b/docs/developer/including-libraries.md
new file mode 100644
index 0000000000000000000000000000000000000000..25989ca258a70b99581f04829c47a0b44b2002de
--- /dev/null
+++ b/docs/developer/including-libraries.md
@@ -0,0 +1,39 @@
+---
+title: Build and Include the Libraries
+summary: Some remarks on including the UNICADO libraries.
+authors:
+ - Sebastian Oberschwendtner
+date: 2023-09-12
+---
+= A word about including the libraries =
+
+Oh yes, the //UNICADO// [[unicado_description/#libraries | libraries]]. ๐ When you start developing and building the //UNICADO// modules you will quickly discover the importance of the libraries. There are many ways how you can include libraries in C++ projects and all have their advantages and disadvantages. In the //UNICADO// project, the most important decisions to make are:
+- Whether to include the libraries as **static** (`*.a`) or **dynamic** (`*.dll` or `*.so`) libraries.
+- Whether to include the libraries as **CMake** //targets// and always recompile the libraries when building the modules or to import the libraries as a **CMake** //package// somewhere from the hard drive. ( {icon arrow-right} Look in [[ build_instructions/include_library_package | Include Library Package ]] to find out what this actually means.)
+
+> Note that each decision is completely independent from the other decision.
+
+Each of those decisions has a corresponding option when configuring **CMake**. So you can decide for your situation what suits your workflow the best. The default configuration when [[#configure-cmake | configuring]] and [[ #build-with-cmake | building]] //UNICADO// is:
+- `BUILD_SHARED_LIBS=OFF` {icon arrow-right} Build **static** libraries.
+- `FIND_LIBRARIES_AS_PACKAGE=OFF` {icon arrow-right} Include //targets// from the submodule and recompile libraries each time there are changes.
+
+NOTE: The default configuration is usually best suited for most situations.
+
+=== Changing to dynamic libraries ===
+When you want to decrease the binary size of the executables or want to test changes in the libraries without having to recompile the executables, you can build the libraries as **dynamic** libraries by configuring **CMake** with:
+ lang=sh
+ cmake -B build -S . -G "your-generator" -DBUILD_SHARED_LIBS=ON
+
+This will build all libraries as **dynamic** libraries and link the executables against those libraries. It does not matter where you set this option. When you build the libraries on their own, the option does the same thing as when you build the complete project where the libraries are included as a submodule.
+
+NOTE: Do not forget to add the location of the **dynamic** libraries to your **PATH** afterwards. ๐
+
+=== Changing to the library package ===
+
+When you want to save some compilation time or do not want to copy the libraries everywhere, you can include them as a package by:
+ lang=sh
+ cmake -B build -S . -G "your-generator" -DFIND_LIBRARIES_AS_PACKAGE=ON -DCMAKE_PREFIX_PATH=path-to-libs
+
+IMPORTANT: When including the libraries as a package you __HAVE__ to set `CMAKE_PREFIX_PATH` as described in [[ build_instructions/include_library_package | Include Library Package ]]. You also have to make sure that the libraries this path is pointing to are compiled and exist!
+
+With this mechanism you can have mutliple projects using the same libraries without having to copy and recompile them all the time. The added downside is that **CMake** can no longer handle the automatic compilation and you have to manually make sure that the libraries are ready to be used.
\ No newline at end of file
diff --git a/docs/developer/build-instructions.md b/docs/developer/prerequisites.md
similarity index 100%
rename from docs/developer/build-instructions.md
rename to docs/developer/prerequisites.md
diff --git a/docs/developer/style/cpp.md b/docs/developer/style/cpp.md
new file mode 100644
index 0000000000000000000000000000000000000000..478b28130ab28ae7a31801c4185aee496d5db71e
--- /dev/null
+++ b/docs/developer/style/cpp.md
@@ -0,0 +1,239 @@
+---
+title: C++ Style Guide
+summary: The most important C++ style rules for UNICADO.
+authors:
+ - Sebastian Oberschwendtner
+date: 2023-09-12
+---
+# UNCIADO C++ Style Guide
+
+!!! tip
+ Consistency in code style is the most important thing!
+
+---
+
+## Standard Module Design
+- Calculations not in `aircraft.cpp` (aircraft is pure data object)
+- `myTool.cpp` for calculations, has (smart) pointers to Aircraft and Settings objects
+- Do not edit standard files like aircraft.cpp, functions.cpp etc. ->use own files (myToolFunctions, myToolspecificAicraftData,...)
+
+### Structure main()
+1. Create Settings object
+2. Create aircraft object
+3. Create myTool-object, if necessary call init()
+4. Call myTool.run()
+5. Create output and call writeOutput()
+6. Done
+
+!!! warning
+ :fontawesome-solid-arrow-right: The module structure changed in newer releases of **UNICADO**. See [Module Structure]().
+
+---
+
+## Header Files
+### Inline Functions
+- Define inline functions only if they are small (~ 10 lines or less).
+
+### Function Parameter Ordering
+- The sequence of parameters of a function is: first input parameters, then output parameters.
+- Input parameters are passed either as value or const reference.
+- Output or input/output parameters are passed as pointers.
+
+:fontawesome-solid-arrow-right: In general, try to use **value semantics** instead of reference/pointer semantics.
+
+---
+
+## Classes
+### Doing Work in Constructors
+- No errors may be thrown in the constructor.
+- Short initialization in the constructor is ok.
+- Transfer complex initialization with larger calculation in initialization method (e.g. `Init()`).
+- Do not call `init()` in the constructor, but after constructor call!
+
+### Inheritance
+- Destructor must always be virtual if it should be a base class for other classes.
+
+### Declaration Order
+- Declaration sequence: public, protected, private. In every section:
+ - Typedefs and Enums
+- Constants (static const data members)
+- Constructors
+- Destructor
+- methods, incl. static methods
+- Data Members (except static const data members)
+- for constants: first const then data type, e.g.: `const int i = 1;`
+
+### Write Short Functions
+- Prefer small and focused functions.
+- For more than 40 lines: split the function
+
+### Ownership and Smart Pointers
+- Always use Smart Pointers instead of normal pointers (raw pointers), since Smart Pointers free up storage space at a suitable location.
+- Do not use `auto_ptr` (obsolete and not container-compatible) but `unique_ptr`.
+- Use `shared_ptr` only if several pointers to the same object are needed, because more memory is used for the reference counting.
+
+---
+
+## Other C++ Features
+### Preincrement and Predecrement
+- For primitive data types, post-increment `i++` is the same as pre-increment `++i`.
+- Pre-increment is faster for iterators because no copy is created.
+- For iterators: use pre-increment
+
+### auto
+- Only use `auto` when the type is still clear to the reader.
+- Example:
+
+```cpp
+/* static_cast holds the type clearly visible */
+auto value = std::static_cast<int>(other_value);
+```
+- Use `auto` for **trailing return types** of functions, because we are doing **Modern C++** ๐ :
+
+```cpp
+auto some_function(int input) -> double
+{
+ /* do stuff */
+ return value;
+}
+```
+- Do __not__ use `auto` when the type is not clearly visible.
+- Don't:
+
+```cpp
+auto value = get_value(); // type ist not readable
+```
+
+### Comparison of variables of type double
+- In order to avoid a compiler warning if floating values are compared (== or !=) use the function `fabs(a-b) < ACCURACY_LOW / _MEDIUM / _HIGH`. **LOW**, **MEDIUM** and **HIGH** correspond to accuracies of **10e-4**, **10e-7** and **10e-10**, respectively. Choose the accuracy as necessary for each case. Alternatively, you can also use the function `accuracyCheck(a, b, ACCURACY_LOW / _MEDIUM / _HIGH)`.
+- Accuracy constants can be found in the :fontawesome-solid-file: `constants.h` file within the unitConversion library.
+
+---
+
+## Naming
+- Function names, variable names and file names should be descriptive: no simple letters such as "b" for span.
+- Avoid abbreviations: Don't delete letters from words in the name to make it shorter e.g.: acft_dsgn instead of aircraft_design (usual and common abbreviations are fine in case of doubt)
+- Lowercase file names, variable names and function names; capitalize new word
+- Capitalize Structs, Typdefs and Enums
+- Names should be as short as possible, but as long as necessary
+
+---
+
+## Comments
+- The best code is self-explaining --> good type & variable names, etc.
+- Documentation with Doxyblocks; see also "Documentation with Doxyblocks.pptx".
+- You can use `\` and `@` to mark the __doxygen__ keywords.
+- Generally everywhere, where the code is not directly understandable by itself, comments on readability and comprehensibility are necessary.
+- But don't describe the code itself. Assume that the reading person knows C++.
+- Do not use umlauts (รค -> ae etc.)
+
+### File Comments
+- Line comments for attributes in header: Declaration `/**<Comment*//`
+- Each file should have a comment at the beginning describing its contents.
+- Header file `.h`: Describes the classes declared in the file. [icon arrow-right} what are they for, how are they used?
+- Source file `.cpp`: Contains more information about implementation details / algorithms.
+- Implementation details and information about algorithms can also be mentioned in.h file, but then mention in `.cpp` file Location of documentation.
+- The files should always start with a copyright statement.
+- After the copyright, give some information about the file with:
+
+```cpp
+/**
+ * \file name.extension
+ * \author Name (Email)
+ * \brief Short description of the content
+ * \version major.minor.bugfix
+ * \date yyyy-mm-dd
+ */
+```
+
+### Class Comments
+- Each class should have an accompanying comment describing what the class is for and how it is used
+- Block comments for classes in source:
+
+```cpp
+/**
+ * \class name
+ * \brief short description of the class
+ * \details detailed description of the class
+ */
+```
+
+### Function Comments
+- Function declaration: Describe what the function does and how it is used.
+- Does the memory function occupy memory that must be released again by the caller?
+- Can one of the arguments be a null pointer?
+- Definition of function: Describe how the function performs its task.
+- Give an overview of the individual steps.
+- Explain the used "coding tricks".
+- Explain why this implementation was chosen.
+- Block comments for methods/constructors in Source:
+
+```cpp
+/**
+ * \brief description of the function/method/constructor
+ * \details detailed description of the method
+ * \param name Description of the transfer parameter
+ * \return name Description of the return value
+ */
+```
+
+- Additional comments in the code only via `//`.
+- Instructions for creating documentation with Doxyblocks can be found in the wiki.
+
+### TODO Comments
+- Use **TODO** comments to mark temporary code, temporary solutions or parts in need of improvement.
+- Example for formatting: `// TODO(Name#_#MantisID:_) Comment`
+- A **TODO** is not an obligation that the specified person will solve the problem.
+- Specify an approximately date/time frame, if necessary, in which the problem is to be solved.
+
+---
+
+## Formatting
+- General (ANSI) style with 4 spaces as indentation.
+
+### Line Length
+- Each line of code max. 120 charactersโ long.
+- Exception: Comment line with example or URL.
+
+### Spaces vs. Tabs
+- Use only spaces, 4 spaces for an indentation.
+- IDE can be set to output spaces at "TAB".
+
+:fontawesome-solid-arrow-right: For a more detailed description of settings see Wiki article on [Linter Setup]().
+
+== Function Declarations and Definitions ==
+- Return type and function name in one line.
+- Parameter in the same line if it does not match: Parameters in several lines
+- No space between function name and opening parenthesis.
+- No space between parenthesis and parameter.
+- Example:
+
+```cpp
+auto ClassName::functionName(Type par_name1, Type par_name2) -> return_type
+{
+ DoSomething(); // 2 space indent
+}
+```
+
+### Horizontal Whitespace
+- No spaces at end of line.
+- For operators (=, <, >, +, -, ...): space before and after: `int a = 0;` (not `int a=0;`)
+- Sometimes spaces can be removed by factors: `v = w*x + y/z;`
+- In loops and conditions: Spaces before the beginning of parentheses and after semicolons; no additional spaces in parentheses.
+- Can be automated in the IDE under the button Source "Formatter Insert Spaces around operators".
+
+### Vertical Whitespace
+- Minimize empty lines!
+- Basic rule: The more code fits on the screen, the easier it is to follow the program flow.
+- Blank lines at the beginning and end of functions can sometimes improve readability.
+
+!!! tip
+ This code style is based on the Google C++ Style Guide [GSG :octicons-link-external-16:](https://google.github.io/styleguide/cppguide.html) and contains some guidelines. For more information or more detailed specifications, read the Google Guide.
+
+---
+
+## Bibliography
+
+**GSG**: Google, [Google C++ Style Guide :octicons-link-external-16:](https://google.github.io/styleguide/cppguide.html)
+
+**ISOCPP**: IsoCpp, Bjarne Stroustrop & Herb Sutter, [C++ Core Guidelines :octicons-link-external-16:](http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines)
diff --git a/docs/developer/style/python.md b/docs/developer/style/python.md
new file mode 100644
index 0000000000000000000000000000000000000000..e69de29bb2d1d6434b8b29ae775ad8c2e48c5391
diff --git a/docs/index.md b/docs/index.md
index 167d218750db5cb9806615c3cd78b3df3be5258d..8991514bcb7839d5640159000514d2a1b5d14fdc 100644
--- a/docs/index.md
+++ b/docs/index.md
@@ -6,7 +6,7 @@ authors:
date: 2023-09-08
glightbox: false
---
-
+
# Welcome to UNICADO
**UNICADO** is a preliminary aircraft design tools which groups many design modules.
@@ -59,4 +59,4 @@ Get an overview which tools and components are available within **UNICADO**.
</div>
</div>
-{width="400"}
\ No newline at end of file
+{width="400"}
\ No newline at end of file
diff --git a/docs/modules/additional-software.md b/docs/modules/additional-software.md
index 77cdf2a8614a8c43fb8ace7aa4b668631a5050be..340b7a9df547d90c6f9b5102641afa9816776d62 100644
--- a/docs/modules/additional-software.md
+++ b/docs/modules/additional-software.md
@@ -51,6 +51,6 @@ It is mainly an automation tool written specifically for the **UNICADO** project
|Module Version|Language|License|Documentation|
|:---:|:---:|:---:|---|
-|2.1.0|:simple-cplusplus: |GPLv3|[Link]()|
+|2.1.0|:simple-python: |GPLv3|[Link]()|
---
diff --git a/docs/modules/libraries.md b/docs/modules/libraries.md
index 336a70e41a526c4e5621a63a945f77cab05b4ed3..c5a8d6642d29e5fe5519687755f67df919182a50 100644
--- a/docs/modules/libraries.md
+++ b/docs/modules/libraries.md
@@ -41,7 +41,7 @@ The library furthermore provides functions to extract and measure geometry prope
---
## aircraftGeometry2
-{.overview-img align=left}
+{.overview-img align=left}
This library is based on the older [aircraftGeometry](#aircraftgeometry) library and extends it to be more modular.
The modularity and flexibility is achieved by using the high performance [Computational Geometry Algorithms Library](https://www.cgal.org/) also known as **CGAL**.
{.overview-item}
@@ -127,7 +127,7 @@ The library gives a template how modules should be structured and gives helpers
---
## propulsionsystem
-{.overview-img align=left}
+{.overview-img align=left}
This is a versatile tool which can be used to simulate and analyse the power flow within an aircraft.
The power flow is mainly determined by the propulsive systems onboard, but the tool can account for other power needed during operation as well.
The propulsion systems are not limited to conventional types.
@@ -146,7 +146,7 @@ Due to the flexible abstraction via so-called *two-terminal block*, any system w
## runtimeInfo
{.overview-img align=left}
This library handles the user interface during the modules execution.
-In provides custom output streams, which automatically handel the log files and error outputs according to the configuration files.
+In provides custom output streams, which automatically handle the log files and error outputs according to the configuration files.
{.overview-item}
|Module Version|Language|License|Documentation|
diff --git a/docs/workflow.md b/docs/workflow.md
index 1d967d091c514b44809667e0df832eccf19cb019..5d37eb59798e3290a090d89c1199bd3bc71622de 100644
--- a/docs/workflow.md
+++ b/docs/workflow.md
@@ -11,7 +11,7 @@ date: 2023-09-08
## Workflow
The workflow looks like this:
<figure markdown>
- {width="800"}
+ {width="800"}
<figcaption>UNICADO Workflow</figcaption>
</figure>
@@ -19,6 +19,6 @@ The workflow looks like this:
The aicrafts can be view by the Tigl Viewer when they are converted to the **CPACS** format:
<figure markdown>
- {width="800"}
+ {width="800"}
<figcaption>Aircraft shown in Tigl Viewer</figcaption>
</figure>
\ No newline at end of file
diff --git a/mkdocs.yml b/mkdocs.yml
index cf4b5c5c514ec62fa6bbeeb8a5555b3dbb440722..66f4f38b13c4580df903eff296aa9fd8492e89dc 100644
--- a/mkdocs.yml
+++ b/mkdocs.yml
@@ -22,13 +22,28 @@ markdown_extensions:
- attr_list
- admonition
- md_in_html
- - pymdownx.details
- - pymdownx.superfences
- toc:
- permalink: "#"
+ permalink: '#'
+ - pymdownx.tabbed:
+ alternate_style: true
- pymdownx.emoji:
emoji_index: !!python/name:materialx.emoji.twemoji
emoji_generator: !!python/name:materialx.emoji.to_svg
+ - pymdownx.highlight:
+ anchor_linenums: true
+ line_spans: __span
+ pygments_lang_class: true
+ - pymdownx.details
+ - pymdownx.superfences
+ - pymdownx.inlinehilite
+ - pymdownx.snippets
+ - pymdownx.critic
+ - pymdownx.caret
+ - pymdownx.keys
+ - pymdownx.mark
+ - pymdownx.tilde
+
+
extra_javascript:
- assets/javascripts/katex.js
@@ -47,7 +62,7 @@ plugins:
theme:
name: material
favicon: assets/favicon.png
- logo: assets/images/icon.png
+ logo: assets/images/logos/unicado-icon.png
palette:
scheme: slate
primary: blue grey
@@ -76,8 +91,19 @@ nav:
- 'getting-started/installation.md'
- 'getting-started/takeoff.md'
- 'Developer':
- - 'developer/build-instructions.md'
- - 'developer/setup.md'
+ - 'How to Contribute': 'developer/contribute.md'
+ - 'Build Environment':
+ - 'IDE Setup': 'developer/ide-setup.md'
+ - 'C++ Environment': 'developer/environment-cpp.md'
+ - 'Python Environment': 'developer/environment-python.md'
+ - 'Build Instructions':
+ - 'Prerequisites': 'developer/prerequisites.md'
+ - 'Building C++ Modules': 'developer/build-cpp.md'
+ - 'Build Python Modules': 'developer/build-python.md'
+ - 'Libraries': 'developer/including-libraries.md'
+ - 'Style Guide':
+ - 'C++': 'developer/style/cpp.md'
+ - 'Python': 'developer/style/python.md'
- 'About':
- 'license.md'
- 'contact.md'