diff --git a/web/content/.markdownlint.yaml b/web/content/.markdownlint.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..0874b844c3f6e680c9e5d58902153e9ea6f10b38
--- /dev/null
+++ b/web/content/.markdownlint.yaml
@@ -0,0 +1,4 @@
+comment: OpenGeoSys rules
+default: true
+line-length: false
+no-inline-html: false
diff --git a/web/content/books/bmb-2.pandoc b/web/content/books/bmb-2.pandoc
index 90eaab08a54c9abdbd0cddfa9e6535d8075aea4f..ab38907173def5dbed1998c74da8777e163ae9ed 100644
--- a/web/content/books/bmb-2.pandoc
+++ b/web/content/books/bmb-2.pandoc
@@ -19,11 +19,15 @@ Also have a look at [Volume 1](http://www.springer.com/de/book/9783642271762) of
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Benchmarks Chapter 2](https://ogsstorage.blob.core.windows.net/web/Books/Benchmark-Book-2/Chapter-02.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "kolditz:2015" >}}
 :::
diff --git a/web/content/books/bmb-3.pandoc b/web/content/books/bmb-3.pandoc
index 4c446a4bc230f9dda511110bf0b4c5b58de39967..ca844889ac39091e736a1fc9338b7d719606764b 100644
--- a/web/content/books/bmb-3.pandoc
+++ b/web/content/books/bmb-3.pandoc
@@ -17,11 +17,15 @@ This book presents a new suite of benchmarks for and examples of porous media me
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Input files Chapter 4.7.8](https://ogsstorage.blob.core.windows.net/web/Books/Benchmark-Book-3/Input-files-Vogel-Chapter-4_7_8.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "kolditz:2016" >}}
 :::
diff --git a/web/content/books/bmb-4.pandoc b/web/content/books/bmb-4.pandoc
index ef0663edd522f4561e1f8c7beb12a5c8e138e59b..73ea17bd1d0425a7a4871b60a8394aa4d522e3a7 100644
--- a/web/content/books/bmb-4.pandoc
+++ b/web/content/books/bmb-4.pandoc
@@ -19,6 +19,8 @@ The book comprises the 3rd  collection of benchmarks and examples for porous and
 TODO!
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "kolditz:2018" >}}
 :::
diff --git a/web/content/books/computational-geotechnics-i.pandoc b/web/content/books/computational-geotechnics-i.pandoc
index c5e090605f4859b8e44904ffd1a79463d78157d9..d75057198d116cbff37b79071de0126660ad591b 100644
--- a/web/content/books/computational-geotechnics-i.pandoc
+++ b/web/content/books/computational-geotechnics-i.pandoc
@@ -16,16 +16,22 @@ In this book, effective computational methods to facilitate those pivotal simula
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Input Files](https://ogsstorage.blob.core.windows.net/web/Books/Comp-Geotechnics-I/inputFiles.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "nagel:2017" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/computational-hydrology-i-groundwater-flow-modeling.pandoc b/web/content/books/computational-hydrology-i-groundwater-flow-modeling.pandoc
index 05b7c7007c7062ce5fabf3f302678b53c43ba602..dc69871034ee3f4933d11094c1e7030f72ec72e8 100644
--- a/web/content/books/computational-hydrology-i-groundwater-flow-modeling.pandoc
+++ b/web/content/books/computational-hydrology-i-groundwater-flow-modeling.pandoc
@@ -20,17 +20,23 @@ This book is intended primarily for graduate students and applied scientists who
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Linux Input Files](https://ogsstorage.blob.core.windows.net/web/Books/Computational-Hydrology-I/input_files_linux.zip)  
 - [<i class="far fa-file-archive"></i> Windows Input Files](https://ogsstorage.blob.core.windows.net/web/Books/Computational-Hydrology-I/input_files_win.zip)
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "sachse:2015" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/computational-hydrology-ii.pandoc b/web/content/books/computational-hydrology-ii.pandoc
index fd5219d29e14280f63b70831402425ec62766a6c..c85ba12b4eaeea58dd17e856b4dc486df6e0252a 100644
--- a/web/content/books/computational-hydrology-ii.pandoc
+++ b/web/content/books/computational-hydrology-ii.pandoc
@@ -17,17 +17,23 @@ This book explores the application of the open-source software OpenGeoSys (OGS)
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Input Files](https://ogsstorage.blob.core.windows.net/web/Books/Computational-Hydrology-II/CompHydroII-Input.zip)  
 - [<i class="far fa-file-archive"></i> Tools](https://ogsstorage.blob.core.windows.net/web/Books/Computational-Hydrology-II/CompHydroII-Tools.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "sachse:2017" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/computational-hydrology-iii.pandoc b/web/content/books/computational-hydrology-iii.pandoc
index 661a9aa0821869628b9876224f1688279221a367..e31e3c7d575b497a8a22aba8b2031c33e8fe901f 100644
--- a/web/content/books/computational-hydrology-iii.pandoc
+++ b/web/content/books/computational-hydrology-iii.pandoc
@@ -19,16 +19,22 @@ The tutorial book is intended primarily for graduate students and applied scient
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Benchmark Input Files](https://ogsstorage.blob.core.windows.net/web/Books/Computational-Hydrology-III/Computational-Hydrology-III-Files.zip)
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "jang:2018" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/geoenergy-modeling-i.pandoc b/web/content/books/geoenergy-modeling-i.pandoc
index 6542fca454287c0dd9319036bebc463de729509d..39d5654ea9063790b4eca03d3799599f446da910 100644
--- a/web/content/books/geoenergy-modeling-i.pandoc
+++ b/web/content/books/geoenergy-modeling-i.pandoc
@@ -20,16 +20,22 @@ This introduction to geothermal modeling deals with flow and heat transport proc
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Files for exercise <i>Computational Geothermics</i>](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-I/ComputationalGeothermicsExercises.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "boettcher:2016" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/geoenergy-modeling-ii.pandoc b/web/content/books/geoenergy-modeling-ii.pandoc
index 04b49996fb2732621922ca7328aa3954efb9697e..ef078d690994876c7652bddab061a68fdbf13c79 100644
--- a/web/content/books/geoenergy-modeling-ii.pandoc
+++ b/web/content/books/geoenergy-modeling-ii.pandoc
@@ -19,7 +19,9 @@ This book is dedicated to the numerical modeling of shallow geothermal systems.
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Benchmarks](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-II/benchmarks.zip)  
 - [<i class="far fa-file-archive"></i> BHE Setup Tool](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-II/bhe_setup_tool.zip)  
 - [<i class="far fa-file-archive"></i> Taucha Model](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-II/taucha_model.zip)  
@@ -27,11 +29,15 @@ This book is dedicated to the numerical modeling of shallow geothermal systems.
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "shao:2016" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/geoenergy-modeling-iii.pandoc b/web/content/books/geoenergy-modeling-iii.pandoc
index e582ec5f0e83424fa8ec1a08f887bba7594ca901..a5f77a4ccc1de1a0701a75b8dab98d199a798b77 100644
--- a/web/content/books/geoenergy-modeling-iii.pandoc
+++ b/web/content/books/geoenergy-modeling-iii.pandoc
@@ -19,17 +19,23 @@ The book explains basic mathematical equations and numerical methods to modeling
 :::
 
 ::: {.note}
+
 ### <i class="far fa-download"></i> Downloads
+
 - [<i class="far fa-file-archive"></i> Input Files Linux](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-III/GeoEnergyModelingIII_input-files_unix.zip)  
 - [<i class="far fa-file-archive"></i> Input Files Windows](https://ogsstorage.blob.core.windows.net/web/Books/Geoenergy-Model-III/GeoEnergyModelingIII_input-files_windows.zip)  
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "watanabe:2017" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires [OpenGeoSys-5](/ogs-5/).
 :::
diff --git a/web/content/books/models-of-thermochemical-heat-storage.pandoc b/web/content/books/models-of-thermochemical-heat-storage.pandoc
index 52e7b70829afdc2adfacf48248fbeb52c8829b27..224891e79c6f1d2a29e33e6b9c31967b1754deef 100644
--- a/web/content/books/models-of-thermochemical-heat-storage.pandoc
+++ b/web/content/books/models-of-thermochemical-heat-storage.pandoc
@@ -20,11 +20,15 @@ This book is intended primarily for graduate students and applied scientists wor
 :::
 
 ::: {.note}
+
 ### <i class="far fa-book"></i> Bibliography
+
 {{< bib "lehmann:2018" >}}
 :::
 
 ::: {.note}
+
 ### <i class="far fa-code-branch"></i> OpenGeoSys Version Info
+
 This book requires OpenGeoSys-6.
 :::
diff --git a/web/content/docs/benchmarks/bgr_verification_examples/heatconduction.pandoc b/web/content/docs/benchmarks/bgr_verification_examples/heatconduction.pandoc
index 4bbfcb15c525447d59de6cc8179134c95ffe68c7..f524e172ae3737148390711ba68e158c1238d537 100644
--- a/web/content/docs/benchmarks/bgr_verification_examples/heatconduction.pandoc
+++ b/web/content/docs/benchmarks/bgr_verification_examples/heatconduction.pandoc
@@ -33,6 +33,6 @@ chapters in the benchmark books.
 | *Kolditz et al. 2018*||
 -->
 
-
 ## References
+
 {{< bib "kolditz:2015" >}}
diff --git a/web/content/docs/benchmarks/bgr_verification_examples/hydromechanics.pandoc b/web/content/docs/benchmarks/bgr_verification_examples/hydromechanics.pandoc
index 25f0fe06d6be6df65273e8fd3ee1086a1bec183c..24ce7e95136a3dd2e2846c3cbb9b37d0237d3c23 100644
--- a/web/content/docs/benchmarks/bgr_verification_examples/hydromechanics.pandoc
+++ b/web/content/docs/benchmarks/bgr_verification_examples/hydromechanics.pandoc
@@ -40,5 +40,6 @@ chapters in the benchmark books.
 -->
 
 ## References
+
 {{< bib "kolditz:2015" >}}
 {{< bib "kolditz:2016" >}}
diff --git a/web/content/docs/benchmarks/bgr_verification_examples/liquid_flow.pandoc b/web/content/docs/benchmarks/bgr_verification_examples/liquid_flow.pandoc
index fce94f5a282ceb93c70c254d28bba288c8620771..b3510b0762c69914aaa999b385806936b5ad3a8d 100644
--- a/web/content/docs/benchmarks/bgr_verification_examples/liquid_flow.pandoc
+++ b/web/content/docs/benchmarks/bgr_verification_examples/liquid_flow.pandoc
@@ -34,6 +34,6 @@ chapters in the benchmark books.
 | *Kolditz et al. 2018*||
 -->
 
-
 ## References
+
 {{< bib "kolditz:2015" >}}
diff --git a/web/content/docs/benchmarks/bgr_verification_examples/thermomechanics.pandoc b/web/content/docs/benchmarks/bgr_verification_examples/thermomechanics.pandoc
index 0a5ef226eef6c2fdc2d0b1b57709184131707ef4..f3c8b9ef49e58d77742f05a40db255653272c1e1 100644
--- a/web/content/docs/benchmarks/bgr_verification_examples/thermomechanics.pandoc
+++ b/web/content/docs/benchmarks/bgr_verification_examples/thermomechanics.pandoc
@@ -36,7 +36,6 @@ chapters in the benchmark books.
 |9.1   |  tm1_1Dfixa
 |9.2   |  tm1_1Dfixb
 
-
 ## References
 
 {{< bib "kolditz:2015" >}}
diff --git a/web/content/docs/benchmarks/creep-after-excavation-bgra/CreepAfterExcavation.pandoc b/web/content/docs/benchmarks/creep-after-excavation-bgra/CreepAfterExcavation.pandoc
index 8d650842b02edcde5df25bafeb4c1ff987306db9..e8869a9d92be1f8afa51ba9effadf021df1fb07d 100644
--- a/web/content/docs/benchmarks/creep-after-excavation-bgra/CreepAfterExcavation.pandoc
+++ b/web/content/docs/benchmarks/creep-after-excavation-bgra/CreepAfterExcavation.pandoc
@@ -43,7 +43,6 @@ material group is for rock salt. The material properties of the rocks are given
 The parameters of the BGRa creep model are $A=0.18\, \mbox{d}^{-1}$,
 $m=5$, $Q=54 \mbox{ kJ/mol}$ for the rock salt. For the cap rock, $A$ is set to zero.
 
-
 The width
 and the height of of the domain are 300 m and 340 m, respectively. The
 height of the cap rock portion is 40 m. The drift to be excavated has a
@@ -54,15 +53,15 @@ assume a steady state of stress and temperature of excavation at the
 beginning of the current simulation. For this assumption, the boundary
 conditions are given as:
 
--   top boundary: $\tau_x =$$\sigma_x$$_y=0$, $\tau_y=\sigma_y=-10$ MPa,
+- top boundary: $\tau_x =$$\sigma_x$$_y=0$, $\tau_y=\sigma_y=-10$ MPa,
     $T=310$ K.
 
--   two lateral boundaries: normal displacement is fixed, and no heat
+- two lateral boundaries: normal displacement is fixed, and no heat
     flux.
 
--   bottom boundary: normal displacement is fixed, and $T=320$ K.
+- bottom boundary: normal displacement is fixed, and $T=320$ K.
 
--   circle of drift surface: traction free
+- circle of drift surface: traction free
     (${ \mathbf\sigma}\cdot \mathbf n = 0$), and $T=300$ K as excavation
     conditions.
 
@@ -99,7 +98,6 @@ green vertical line in it marks the time of the displayed stress field.
     <figcaption>Stress distribution at the time of 1000 days.</figcaption>
 </figure>
 
-
 The above three figures show that the absolute value of the horizontal stress increase
 signification in the areas above and beneath the drift due to the creep,
 and the change of the vertical stress is slow compared to that of the
@@ -112,17 +110,18 @@ end of the simulation time at 1000 days.
     <figcaption>Strain distribution at the time of 1000 days.</figcaption>
 </figure>
 
-
 The steady-state temperature distribution is displayed in the following figure
 <figure>
     <img src="../T.png" alt="Temperature distribution at the time of 1000 days." id="fig_6">
     <figcaption>Temperature distribution at the time of 1000 days.</figcaption>
 </figure>
 
-## Note:
+## Note
+
 For the automatic benchmarking, the time duration of creep is reduced to 50 days in order to reduce the run time.
- If one wants to test this benchmark for 1000 days' creep, please change the end time in the tag of `<t_end> `
+ If one wants to test this benchmark for 1000 days' creep, please change the end time in the tag of `<t_end>`
 in the project file as
+
  ```
 <t_end>86400.0e+3</t_end>
 ```
diff --git a/web/content/docs/benchmarks/creepbgra/CreepBRGa.pandoc b/web/content/docs/benchmarks/creepbgra/CreepBRGa.pandoc
index 330ddd41508274b5e1d5f57c544fa36e9a26cdaf..43c75c9d9e495aed812925fa85f10cde9138beff 100644
--- a/web/content/docs/benchmarks/creepbgra/CreepBRGa.pandoc
+++ b/web/content/docs/benchmarks/creepbgra/CreepBRGa.pandoc
@@ -103,7 +103,8 @@ Newton-Raphson is applied to .
  Let $$\begin{gathered}
  \mathbf{r}= { \mathbf \sigma}^{n+1} -
  { \mathbf \sigma}^{n} - \mathbf{C} (\Delta { \mathbf \epsilon} - \alpha_T \Delta T \mathbf I)
- + 2bG \Delta t {\left\Vert{\mathbf s}^{n+1}\right\Vert}^{m-1}
+
++ 2bG \Delta t {\left\Vert{\mathbf s}^{n+1}\right\Vert}^{m-1}
  {\mathbf s}^{n+1}
 \end{gathered}$$
 
@@ -132,7 +133,8 @@ If the model is used for the thermo-mechanical problems and the problems
 are solved by the monolithic scheme, the displacement-temperature block
 of the global Jacobian can be derived as
  $$\begin{aligned}
- - 2G\dfrac{Q}{R} {{\int}_{\Omega} \dfrac{b}{T^2} {\left\Vert{\mathbf s}^{n+1}\right\Vert}^{m-1}  \mathbf{B}^T  {\mathbf s}^{n+1} \mathrm{d} \Omega}
+
+- 2G\dfrac{Q}{R} {{\int}_{\Omega} \dfrac{b}{T^2} {\left\Vert{\mathbf s}^{n+1}\right\Vert}^{m-1}  \mathbf{B}^T  {\mathbf s}^{n+1} \mathrm{d} \Omega}
  \end{aligned}$$
 
 *Note*: The above rate form of stress integration is implemented in ogs6.
@@ -184,9 +186,9 @@ obtained by the present multidimensional scheme with the analytical
 solution is shown in the following figure:
 {{< img src="../bgra0.png" >}}
 
-
 Python code
 -----------
+
 A short python snippet, to compute the values.
 <details>
 <summary>
diff --git a/web/content/docs/benchmarks/elliptic/elliptic-dirichlet-volumetric-source-term.pandoc b/web/content/docs/benchmarks/elliptic/elliptic-dirichlet-volumetric-source-term.pandoc
index 90a50f487f73847be5828bb2aebcbf43238d90ad..d1d30d1396b2a19298ec42c2f23476f185fddd72 100644
--- a/web/content/docs/benchmarks/elliptic/elliptic-dirichlet-volumetric-source-term.pandoc
+++ b/web/content/docs/benchmarks/elliptic/elliptic-dirichlet-volumetric-source-term.pandoc
@@ -18,6 +18,7 @@ weight = 102
 We start with Poisson equation:
 $$
 \begin{equation}
+
 - k\; \Delta p = Q \quad \text{in }\Omega
 \end{equation}$$
 w.r.t boundary conditions
@@ -56,8 +57,9 @@ boundary meshes associated with the bulk mesh.
 ## Running simulation
 
 To start the simulation (after successful compilation) run:
+
 ```bash
-$ ogs square_1e2_volumetricsourceterm.prj
+ogs square_1e2_volumetricsourceterm.prj
 ```
 
 OGS writes the computed results (pressure, darcy velocity) into the output file
@@ -65,6 +67,7 @@ OGS writes the computed results (pressure, darcy velocity) into the output file
 directly visualized and analysed in paraview for example.
 
 The output on the console will be similar to:
+
 ```
 info: ConstantParameter: K
 info: ConstantParameter: p0
diff --git a/web/content/docs/benchmarks/elliptic/elliptic-dirichlet.pandoc b/web/content/docs/benchmarks/elliptic/elliptic-dirichlet.pandoc
index 33f852b2bccc6673a9aebd632f6b2f3bf227573f..a647c5aa633ad62da6c8527bf53122f27e0c836a 100644
--- a/web/content/docs/benchmarks/elliptic/elliptic-dirichlet.pandoc
+++ b/web/content/docs/benchmarks/elliptic/elliptic-dirichlet.pandoc
@@ -48,9 +48,10 @@ $$
 The main project file is `square_1e2.prj`. It describes the processes to be solved and the related process variables together with their initial and boundary conditions. It also references the mesh and geometrical objects defined on the mesh.
 
 As of now a small portion of possible inputs is implemented; one can change:
- - the mesh file
- - the geometry file
- - introduce more/different Dirichlet boundary conditions (different geometry or values)
+
+- the mesh file
+- the geometry file
+- introduce more/different Dirichlet boundary conditions (different geometry or values)
 
 The geometries used to specify the boundary conditions are given in the `square_1x1.gml` file.
 
@@ -59,8 +60,9 @@ The input mesh `square_1x1_quad_1e2.vtu` is stored in the VTK file format and ca
 ## Running simulation
 
 To start the simulation (after successful compilation) run:
+
 ```bash
-$ ogs square_1e2.prj
+ogs square_1e2.prj
 ```
 
 It will produce the output files `square_1e2_pcs_0.pvd`,
@@ -69,6 +71,7 @@ It will produce the output files `square_1e2_pcs_0.pvd`,
 computed in the first time step.
 
 The output on the console will be similar to the following one (ignore the spurious error messages "Could not find POINT..."):
+
 ```
 error: GEOObjects::getGeoObject(): Could not find POINT "left" in geometry.
 error: GEOObjects::getGeoObject(): Could not find POINT "right" in geometry.
diff --git a/web/content/docs/benchmarks/elliptic/elliptic-neumann.pandoc b/web/content/docs/benchmarks/elliptic/elliptic-neumann.pandoc
index bc12faf7fcf64b442f61a68196372160aeb7006c..da37b05e87a0859cefa72d695180fc05067883d3 100644
--- a/web/content/docs/benchmarks/elliptic/elliptic-neumann.pandoc
+++ b/web/content/docs/benchmarks/elliptic/elliptic-neumann.pandoc
@@ -50,10 +50,11 @@ where $C_k = \frac{2k-1}{2} \pi$ and $A_k = 2 \Big/ \Big(C_k^2 \cosh\big(C_k\big
 The main project file is [square_1e2_neumann.prj](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Elliptic/square_1x1_SteadyStateDiffusion/square_1e2.prj). It describes the processes to be solved and the related process variables together with their initial and boundary conditions. It also references the mesh and geometrical objects defined on the mesh.
 
 As of now a small portion of possible inputs is implemented; one can change:
- - the mesh file
- - the geometry file
- - introduce more/different Dirichlet boundary conditions (different geometry or other constant values)
- - introduce more/different Neumann boundary conditions (different geometry or other constant values)
+
+- the mesh file
+- the geometry file
+- introduce more/different Dirichlet boundary conditions (different geometry or other constant values)
+- introduce more/different Neumann boundary conditions (different geometry or other constant values)
 
 The geometries used to specify the boundary conditions are given in the [square_1x1.gml](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Elliptic/square_1x1_SteadyStateDiffusion/square_1x1.gml) file.
 
@@ -62,13 +63,15 @@ The input mesh `square_1x1_quad_1e2.vtu` is stored in the VTK file format and ca
 ## Running simulation
 
 To start the simulation (after successful compilation) run:
+
 ```bash
-$ ogs square_1e2_neumann.prj
+ogs square_1e2_neumann.prj
 ```
 
 It will produce some output and write the computed result into the `square_1e2_neumann.vtu` for visualization with Paraview.
 
 The output on the console will be similar to the following one (ignore the spurious error messages "Could not find POINT..."):
+
 ```
 info: This is OpenGeoSys-6 version 6.0.7-619-ge761162.
 info: OGS started on 2016-12-05 11:16:47+0100.
diff --git a/web/content/docs/benchmarks/elliptic/elliptic-pde-with-dirichlet-and-nodal-source-term.pandoc b/web/content/docs/benchmarks/elliptic/elliptic-pde-with-dirichlet-and-nodal-source-term.pandoc
index 0bb2042761be5e285e36274680ac964ef3ebdebf..b0a81c5803d8a843af273eddcb65944eea73a9f1 100644
--- a/web/content/docs/benchmarks/elliptic/elliptic-pde-with-dirichlet-and-nodal-source-term.pandoc
+++ b/web/content/docs/benchmarks/elliptic/elliptic-pde-with-dirichlet-and-nodal-source-term.pandoc
@@ -49,7 +49,6 @@ $$
 h(x,y) = \frac{1}{2 \pi} \ln \sqrt{x^2 + y^2}.
 $$
 
-
 ## Input files
 
 The main project file is `square_1e6_with_nodal_sources.prj`. It describes the process to be solved and the related process variables together with their initial and boundary conditions as well as the definition of the nodal source term. It also references the mesh and geometrical objects defined on the mesh.
@@ -61,13 +60,13 @@ The input mesh `square_1x1_quad_1e6.vtu` is stored in the VTK file format and ca
 ## Running simulation
 
 To start the simulation (after successful compilation) run:
+
 ```bash
-$ ogs circle_1e6_axi.prj
+ogs circle_1e6_axi.prj
 ```
 
 It will produce some output and write the computed result into a data array of the written vtu file.
 
-
 ## Results and evaluation
 
 ### Comparison of the analytical solution and the computed solution
@@ -77,4 +76,3 @@ It will produce some output and write the computed result into a data array of t
 {{< img src="../circle_1e6_gwf_with_nodal_source_term_diff_analytical_solution_head.png" >}}
 
 {{< img src="../circle_1e6_gwf_with_nodal_source_term_diff_analytical_solution_head_log_scale.png" >}}
-
diff --git a/web/content/docs/benchmarks/elliptic/elliptic-robin.pandoc b/web/content/docs/benchmarks/elliptic/elliptic-robin.pandoc
index 85de83416986c7b18a8affc8d25ed3e5a479a048..9f3399a7d611d3dc819b2c35a0b05b4e7902ab41 100644
--- a/web/content/docs/benchmarks/elliptic/elliptic-robin.pandoc
+++ b/web/content/docs/benchmarks/elliptic/elliptic-robin.pandoc
@@ -155,4 +155,3 @@ $$
 h(x) = x + 1.
 \end{equation*}
 $$
-
diff --git a/web/content/docs/benchmarks/elliptic/poisson_equation.pandoc b/web/content/docs/benchmarks/elliptic/poisson_equation.pandoc
index cfe1d1f83f489618dc2a404cd937d16a149885cd..f7f97fd5eba1405b41dcf19671c740a20bb8eab7 100644
--- a/web/content/docs/benchmarks/elliptic/poisson_equation.pandoc
+++ b/web/content/docs/benchmarks/elliptic/poisson_equation.pandoc
@@ -18,6 +18,7 @@ weight = 102
 The Poisson equation is:
 $$
 \begin{equation}
+
 - k\; \Delta p = Q \quad \text{in }\Omega
 \end{equation}$$
 w.r.t boundary conditions
@@ -89,10 +90,13 @@ $Q$ is in a [Python
 script](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/Tests/Data/Elliptic/square_1x1_SteadyStateDiffusion_Python/sin_x_sin_y_source_term.py).
 The script for setting the source terms is referenced in the project file as
 follows:
+
 ```
 <python_script>sin_x_sin_y_source_term.py</python_script>
 ```
+
 In the source term descripition
+
 ```
 <source_term>
     <mesh>square_1x1_quad_1e3_entire_domain</mesh>
@@ -100,9 +104,11 @@ In the source term descripition
     <source_term_object>sinx_siny_source_term</source_term_object>
 </source_term>
 ```
+
 the domain is specified by the mesh-tag. The function $Q$ is defined by the
 Python object `sinx_sinx_source_term` that is created in the last line of the
 Python script:
+
 ```python
 import OpenGeoSys
 from math import pi, sin
@@ -132,8 +138,9 @@ sinx_siny_source_term = SinXSinYSourceTerm()
 ## Running simulation
 
 To start the simulation (after successful compilation) run:
+
 ```bash
-$ ogs square_1e3_poisson_sin_x_sin_y.prj
+ogs square_1e3_poisson_sin_x_sin_y.prj
 ```
 
 It will produce some output and write the computed result into the
@@ -141,6 +148,7 @@ It will produce some output and write the computed result into the
 directly visualized and analysed in paraview for example.
 
 The output on the console will be similar to the following on:
+
 ```
 info: This is OpenGeoSys-6 version 6.1.0-1132-g00a6062a2.
 info: OGS started on 2018-10-10 09:22:17+0200.
@@ -186,7 +194,7 @@ Since a coarse mesh ($32 \times 32$ elements) is used for the simulation the
 difference between the numerical and the analytical solution is relatively large.
 
 #### Comparison for higher resolution mesh ($316 \times 316$ elements)
+
 {{< img src="../square_1e5_poisson_sin_x_sin_y_sourceterm_Diff_Pressure_AnalyticalSolution_PythonSourceTerm.png" >}}
 The difference between the numerical and the analytical solution is much smaller
 than in the coarse mesh case.
-
diff --git a/web/content/docs/benchmarks/heat-transport-bhe/3D_3BHEs_array.pandoc b/web/content/docs/benchmarks/heat-transport-bhe/3D_3BHEs_array.pandoc
index 6f77637c45325265078c365f682ddc3da8f4365c..1769c86f06a9076bcf50bc2eed7542028e66463b 100644
--- a/web/content/docs/benchmarks/heat-transport-bhe/3D_3BHEs_array.pandoc
+++ b/web/content/docs/benchmarks/heat-transport-bhe/3D_3BHEs_array.pandoc
@@ -18,6 +18,7 @@ project = "Parabolic/T/3D_3BHEs_array/3bhes_1U.prj"
 For large-scale Ground Source Heat Pump (GSHP) systems, it is often coupled with an array of multiple Borehole Heat Exchangers in order to extract more heat from the subsurface. When operated over a long period of time, there can be thermal interference occurring among the BHEs. This can lead to thermal imbalance occurring in the subsurface. Since all BHEs are connected with each other through a pipeline network, the heat extraction rate on each individual BHE depends strongly on the inflow and outflow temperatures. As these temperature values were controlled by the pipeline network, it has an intrinsic feature of balancing thermal extraction rates among different BHEs. In order to quantitatively consider the thermal imbalance in the subsurface and the effect of the pipeline network, the calculation of hydraulic and heat transport in the pipe network must be included in the numerical simulation. This benchmark tests the pipe network feature with a 3D numerical model to show the phenomena of heat extraction rate shifting over a heating season. Since only 3 BHEs were included in this test, the percentage of shifted thermal load is limited. However, when dozens of BHEs are involved, the amount of shifted thermal load can be significant.
 
 ## Model Setup
+
 OGS {#OGS .unnumbered .unnumbered}
 ===
 
@@ -59,12 +60,10 @@ The evolution of the soil temperature at 1 m distance away from the 3 BHEs are s
 
 Figure 2: Evolution of the soil temperature located at the 1 m distance away from each BHE
 
-
 {{< img src="../3D_3BHEs_array_figures/Inflow_and_outflow_temperature.png" width="200">}}
 
 Figure 3: Evolution of the inflow and outflow refrigerant temperature of each BHE
 
-
 {{< img src="../3D_3BHEs_array_figures/Heat_extraction_rate.png" width="200">}}
 
 Figure 4: Evolution of the heat extraction rate of each BHE
@@ -73,4 +72,4 @@ Figure 4: Evolution of the heat extraction rate of each BHE
 
 [1] Diersch, H. J., Bauer, D., Heidemann, W., Rühaak, W., & Schätzl, P. (2011). Finite element modeling of borehole heat exchanger systems: Part 1. Fundamentals. Computers & Geosciences, 37(8), 1122-1135.
 
-[2] Francesco Witte, Thermal engineering systems in python, 2019. URL: https://doi.org/10.5281/zenodo.2555866. doi:10.5281/zenodo.2555866.
+[2] Francesco Witte, Thermal engineering systems in python, 2019. URL: <https://doi.org/10.5281/zenodo.2555866>. doi:10.5281/zenodo.2555866.
diff --git a/web/content/docs/benchmarks/heat-transport-bhe/3D_BHE_GW_advection.pandoc b/web/content/docs/benchmarks/heat-transport-bhe/3D_BHE_GW_advection.pandoc
index b3239e2b643c419ffe3f9d5e52258a8cb7252caf..0000173660c0eaa8c78668d1bcf17a778d9444d5 100644
--- a/web/content/docs/benchmarks/heat-transport-bhe/3D_BHE_GW_advection.pandoc
+++ b/web/content/docs/benchmarks/heat-transport-bhe/3D_BHE_GW_advection.pandoc
@@ -14,6 +14,7 @@ project = "Parabolic/T/3D_BHE_GW_advection/BHE_GW_advection.prj"
 {{< data-link >}}
 
 ## Problem description
+
 When groundwater flow is present, advective heat transport in the soil matrix
 has to be considered. Hence, the governing equation for advective and
 conductive heat transport in an isotropic porous media can be expressed (in
@@ -49,6 +50,7 @@ solution can be applied to solve the spatio-temporal distribution of the
 induced ground temperature.
 
 ## Model Setup
+
 The input files for the full simulation including the analytical solution for
 the soil temperature can be found [here](../BHE_GW_advection_2years.zip). The
 geometry of the model is
@@ -111,4 +113,3 @@ groundwater advection. International Journal of Thermal Sciences, 50(12),
 
 [3] P. Eskilson, Thermal analysis of heat extraction boreholes, Ph.D. Thesis,
 University of Lund, Lund, Sweden, 1987.
-
diff --git a/web/content/docs/benchmarks/heat-transport-bhe/3D_Beier_sandbox.pandoc b/web/content/docs/benchmarks/heat-transport-bhe/3D_Beier_sandbox.pandoc
index 66d64dfe379a19aaf59d7ac1fc9b4651da19f4e4..28dfa3b451e78d51866e8545346e95658ded13e8 100644
--- a/web/content/docs/benchmarks/heat-transport-bhe/3D_Beier_sandbox.pandoc
+++ b/web/content/docs/benchmarks/heat-transport-bhe/3D_Beier_sandbox.pandoc
@@ -34,7 +34,6 @@ The numerical model was established using dual continuum method Diersch et al. (
 | Grout thermal conductivity         | $\lambda_{g}$      | 0.806               | $\mathrm{W m^{-1} K^{-1}}$  |
 | Grout heat capacity                | $(\rho c)_{grout}$ | $3.8\times10^{6}$   | $\mathrm{Jm^{-3}K^{-1}}$    |
 
-
 {{< img src="../3D_Beier_sandbox_figures/numerical_geometry_of_BHE.png" width="200">}}
 
 Figure 1: Sandbox model
diff --git a/web/content/docs/benchmarks/heat-transport-bhe/3D_coaxial_deep_BHE.pandoc b/web/content/docs/benchmarks/heat-transport-bhe/3D_coaxial_deep_BHE.pandoc
index e76d956755ea19e499a41a8b2aeb4a6b25d23bcc..2a22b5d2e13d43a5ff74536c5f688ce62e8d2568 100644
--- a/web/content/docs/benchmarks/heat-transport-bhe/3D_coaxial_deep_BHE.pandoc
+++ b/web/content/docs/benchmarks/heat-transport-bhe/3D_coaxial_deep_BHE.pandoc
@@ -14,6 +14,7 @@ project = "Parabolic/T/3D_deep_BHE/3D_deep_BHE_CXA.prj"
 {{< data-link >}}
 
 ## Problem description
+
 In recent years, Borehole Heat Exchangers (BHE) are very widely utilized to extract geothermal energy for building heating. For coaxial type of BHEs, an inner pipe is installed inside of an outer pipe, allowing the downward and upward flow to be seperated. In some projects, very long coaxial BHEs are installed down to a 2-km depth, in order to extract more energy from the deep subsurface (Kong et al., 2017). Based on the flow directions, there are two types of coaxial BHEs. When downward flow is located in the inner pipe, it is called Coaxial-Centred (CXC) type. On the countary, if the inflow is introduced in the annular space, it is called a CXA type. Detailed schematization of the CXA-type BHE system is shown in Figure 1. In this benchmark, the numerical model in OGS-6 has been tested for the 2 coaxial types of BHEs. The simulation results are compared with previous OGS-5 results and also the analytical solution proposed by [Beier et al. (2014)](../Analytical_coaxial_BHE.zip).
 
 {{< img src="../3D_coaxial_deep_BHE_figures/coaxial_deep_BHE.png" width="200">}}
@@ -21,6 +22,7 @@ In recent years, Borehole Heat Exchangers (BHE) are very widely utilized to extr
 Figure 1: Coaxial BHE of CXA (Kong et al. (2017))
 
 ## Model Setup
+
 The implemented numerical model was established based on the dual continuum approach (Diersch et al. (2011)). The BHE is represented by the line elements co-located in the 3D mesh composed mainly by prisms. There are altoghether 3 primary variables on the line elements, namely 1) the inflow temperature 2) the outflow temperature and 3) the grout temperature. The geometry of the model is visualized in Figure 2. The length of the whole domain is 70 m with a square cross section of 20 m by 20 m. The mesh was intentionally extended in the horizontal direction, so that the impact of boundary conditions on the soil temperature distribution can be avoided even for the long-term simulation. The top of the DBHE is situated 10 m below the ground surface, with a total length of 50 m. Detailed parameters for the model configuration can be found in the following table.
 
 | Parameter                                          | Symbol            |  Value              | Unit                        |
@@ -38,7 +40,6 @@ The implemented numerical model was established based on the dual continuum appr
 | Grout thermal conductivity                         | $\lambda_{g}$     | 0.73                | $\mathrm{W m^{-1} K^{-1}}$  |
 | Grout heat capacity                                | $(\rho c)_{g}$    | $3.8\times10^{6}$   | $\mathrm{Jm^{-3}K^{-1}}$    |
 
-
 {{< img src="../3D_coaxial_deep_BHE_figures/numerical_geometry_model.png" width="80">}}
 
 Figure 2: Geometry and mesh of the coaxial BHE model
diff --git a/web/content/docs/benchmarks/heatconduction/BHE_array_benchmark.pandoc b/web/content/docs/benchmarks/heatconduction/BHE_array_benchmark.pandoc
index d5145334b7a2c67a098160dea2f075d315ab42bf..58bf38dbb2a0656d3170745732328c55c9f283f0 100644
--- a/web/content/docs/benchmarks/heatconduction/BHE_array_benchmark.pandoc
+++ b/web/content/docs/benchmarks/heatconduction/BHE_array_benchmark.pandoc
@@ -59,7 +59,6 @@ In this model, the quad element was adopted to compose the mesh. The initial tem
 
 {{< img src="../BHE_array_benchmark_figures/figure_1.png" >}}
 
-
 Figure 1: Model geometry, BHE location, and the observation profile
 
 Different meshes were adopted to analyse the impact of mesh density on the numerical results. According to Diersch et al. (2011) the different element size can affect the accuracy of the numerical result significantly for such type of BHE simulation. The optimal element size $\triangle$ in a 2D model around the BHE node should have the following relationship with respect to the BHE diameter:
@@ -82,7 +81,6 @@ where $r_b$ is the BHE radius. n denotes the number of surrounding nodes. n = 8
 
 Figure 2 and 3 show the comparison of the temperature distribution along the observation profile (position see Figure 1) using analytical solution with the numerical results from OGS5 and OGS6 for every 4 months in the whole simulated time. It shows the numerical solution has a very good agreement with the analytical solution.
 
-
 {{< img src="../BHE_array_benchmark_figures/figure_2.png" width="200">}}
 
 Figure 2: The temperature evolution of the BHEs field along the observation profile
@@ -108,7 +106,7 @@ In this benchmark, a 2D numerical model has been constructed to simulate the gro
 ## References
 
 [1] Bayer, P., de Paly, M., Beck, M., 2014. Strategic optimization of borehole heat exchanger field for seasonal geothermal heating and cooling. Applied Energy 136, 445-453.
-URL http://dx.doi.org/10.1016/j.apenergy.2014.09.029
+URL <http://dx.doi.org/10.1016/j.apenergy.2014.09.029>
 
 [2] Diersch, H.-J., Bauer, D., Heidemann, W., Ruehaak, W., Sch¨atzl, P., 2011. Finite element modeling of borehole heat exchanger systems: Part 2. Numerical simulation. Computers & Geosciences 37, 1136-1147.
 
diff --git a/web/content/docs/benchmarks/heatconduction/heatconduction-dirichlet.pandoc b/web/content/docs/benchmarks/heatconduction/heatconduction-dirichlet.pandoc
index a785c6355f9d517be150d2b0fa9c5a67e6f653e0..19d67fc8425c4f69a614f363ab29979ef8871644 100644
--- a/web/content/docs/benchmarks/heatconduction/heatconduction-dirichlet.pandoc
+++ b/web/content/docs/benchmarks/heatconduction/heatconduction-dirichlet.pandoc
@@ -54,10 +54,11 @@ where $T_\textrm{b}$ is the boundary temperature, $\textrm{erfc}$ is the complem
 The main project file is [line_60_heat.prj](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Parabolic/T/1D_dirichlet/line_60_heat.prj). It describes the processes to be solved and the related process variables together with their initial and boundary conditions. It also references the mesh and geometrical objects defined on the mesh.
 
 As of now a small portion of possible inputs is implemented; one can change:
- - the mesh file
- - the geometry file
- - introduce more/different Dirichlet boundary conditions (different geometry or other constant values)
- - introduce more/different Neumann boundary conditions (different geometry or other constant values)
+
+- the mesh file
+- the geometry file
+- introduce more/different Dirichlet boundary conditions (different geometry or other constant values)
+- introduce more/different Neumann boundary conditions (different geometry or other constant values)
 
 The geometries used to specify the boundary conditions are given in the `line_60_heat.gml` file.
 
diff --git a/web/content/docs/benchmarks/heatconduction/heatconduction-line_source_term.pandoc b/web/content/docs/benchmarks/heatconduction/heatconduction-line_source_term.pandoc
index 3095cc5caae3439ae3c1bb9d62d19ef9c4f4eee6..c66fd412072eb80f89428d8d2d5c9da929bc5813 100644
--- a/web/content/docs/benchmarks/heatconduction/heatconduction-line_source_term.pandoc
+++ b/web/content/docs/benchmarks/heatconduction/heatconduction-line_source_term.pandoc
@@ -65,6 +65,7 @@ $$
 
 Since the analytical solution has a singularity at $(x, y) = (0, 0)$ the
 analytical solution in paraview is generated as follow:
+
 ```
 if (coordsX^2<0.0001 & coordsY^2<0.0001, temperature, -1/(4*asin(1))*ln(sqrt(coordsX^2+coordsY^2))
 ```
@@ -88,7 +89,6 @@ the error grows in the vicinity of the boundary and in the center.
 {{< img
 src="../LineSourceTermFigures/comparison_plot_over_line_rel_diff_analytical_solution_temperature_and_simulated_temperature_line_source_term_in_cylinder.png" >}}
 
-
 #### Input files
 
 The project files for the described models are
@@ -106,6 +106,7 @@ The Poisson equation on cylindrical domain of heigth $1$ and radius
 $r=1$ is solved. The cylindrical domain is defined as axisymmetric.
 
 #### Results and evaluation
+
 {{< img
 src="../LineSourceTermFigures/simulated_temperature_distribution_line_source_term_in_axisymmetric_cylinder.png" >}}
 The above figure shows the computed temperature distribution.
diff --git a/web/content/docs/benchmarks/hydro-component/HC_ogs6-vs-ogs5.pandoc b/web/content/docs/benchmarks/hydro-component/HC_ogs6-vs-ogs5.pandoc
index aea47b302a9acf8b562bb45bc2ee207e735da13e..062f00e8b2027c406daa23bf077078794e57cc00 100644
--- a/web/content/docs/benchmarks/hydro-component/HC_ogs6-vs-ogs5.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/HC_ogs6-vs-ogs5.pandoc
@@ -13,14 +13,12 @@ title = "Heterogeneous Saturated Mass Transport"
 
 {{< data-link >}}
 
-
 ## Overview
 
 This example involves the usage of a cell-based heterogeneous parameterization for the parameter "intrinsic permeability". We show a 2D and a 3D setup and compared the results to those from OGS5; the original examples are described in chapter "5.2 Groundwater flow in a heterogeneous medium" in Kolditz et al. (2012).
 
 We extended the setup to show mass transport in the heterogeneous medium for testing.
 
-
 ## Problem description
 
 The setups are steady-state for flow, with an extent of a $100$ m x $100$ m horizontal plane for the 2D setup and a $100$ m x $100$ m x $50$ m cube for the 3D setup. Mesh elements have side lengths of $1$ m. The initial conditions are hydrostatic and concentration $c=0$. The boundary conditions are translated into equivalent hydrostatic pressure values from hydraulic heads $h_{left}=10$ m and $h_{right}=9$ m and for concentration $c_{left}=1$, $c_{right}=0$ for left and right sides, respectively. All other sides are defined as no-flow (Zero-Neumann).
@@ -45,7 +43,6 @@ The mass transport simulation results (figures below) show an expected heterogen
 [The project files for the 2D setup are here.]({{< data-url "Parabolic/ComponentTransport/heterogeneous/ogs5_H_2D/ogs5_H_2d.prj" >}})
 [The project files for the 3D setup are here.]({{< data-url "Parabolic/ComponentTransport/heterogeneous/ogs5_H_3D/ogs5_H_3d.prj" >}})
 
-
 ## Literature
 
 Kolditz, O., Görke, U.-J., Shao, H., Wang, W., 2012. Thermo-Hydro-Mechanical-Chemical Processes in Porous Media: Benchmarks and Examples, Lecture notes in computational science and engineering. Springer. ISBN: 3642271766.
diff --git a/web/content/docs/benchmarks/hydro-component/contracer/ConTracer.pandoc b/web/content/docs/benchmarks/hydro-component/contracer/ConTracer.pandoc
index 27e8356a87a1f3ba60dd1d90026447b4e87e2956..dcef7b3fb4febba827ef341802cae70b472a6663 100644
--- a/web/content/docs/benchmarks/hydro-component/contracer/ConTracer.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/contracer/ConTracer.pandoc
@@ -16,6 +16,7 @@ title = "Conservative tracer transport with time varying source (1D/2D)"
 # "Conservative tracer transport with time varying source(1D/2D)"
 
 ## Overview
+
 This benchmark describes the transport of a conservative tracer through a saturated porous media. Simulations have been performed with OGS-6 and OGS-5 in both, 1D and 2D domains.
 Additionally, simulations have been compared with experimental data obtained from a hydraulic tracer experiment conducted in a pilot--scale horizontal flow constructed wetland (Boog, 2013; Boog *et al.*, 2019)
 
@@ -72,7 +73,6 @@ Table 1: Material Properties
 
 Table 2: Initial and boundary conditions for the 1D scenario
 
-
 ## Problem description (2D)
 
 For the 2D simulation, the domain was discretized into a rectangular mesh with 1880 quadratic elements (element size of 0.05 m).
diff --git a/web/content/docs/benchmarks/hydro-component/elder.pandoc b/web/content/docs/benchmarks/hydro-component/elder.pandoc
index 8c24200278cb7aef4573ddc999fd634ad068acff..4810b42733f4c0a21b9d9bc2ae36536cee610aed 100644
--- a/web/content/docs/benchmarks/hydro-component/elder.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/elder.pandoc
@@ -13,19 +13,16 @@ title = "Saturated Variable-Density Flow and Mass Transport (Elder)"
 
 {{< data-link >}}
 
-
 ## Overview
 
 This benchmark is one of the classical free-convection density-driven flow and mass transport setups. It was originally published by Elder (1965) and has since then been used as a basic test case (Diersch & Kolditz, 1998; Guo & Langevin, 2002), or has been subject to various investigations concerning grid convergence (Graf & Degener, 2011) and numerical stability (Musuuza et al., 2009; Johannsen, 2003).
 
 For the setup and parameterization, see the chapter "Density dependent flow - The Elder Problem" in Kolditz et al. (2012).
 
-
 ## Problem description
 
 The Elder benchmark describes free convection of a dense fluid in mixable, single-phase environment. A high-concentration solute increases fluid density on the upper boundary and perpetrates the domain by evolving concentration fingers. Here, we compare numerical results of OGS-6 to those of OGS-5. Settings of both simulators were chosen to be as identical as possible. Simulation times were $3300 s$ and $7800 s$ for OGS-6 and OGS-5, respectively.
 
-
 ### Model results
 
 A comparison of the numerical data is shown in the figure below. The numerical results of OGS-6 coincide with those of OGS-5.
diff --git a/web/content/docs/benchmarks/hydro-component/goswami.pandoc b/web/content/docs/benchmarks/hydro-component/goswami.pandoc
index fc0990538695bd2a9dd4d5a6f75034b43352ad47..1cedb0e0c1bb45e27e6e45f8d01c48625dab2d58 100644
--- a/web/content/docs/benchmarks/hydro-component/goswami.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/goswami.pandoc
@@ -13,19 +13,18 @@ title = "Saturated Variable-Density Flow and Mass Transport (Goswami)"
 
 {{< data-link >}}
 
-
 ## Overview
 
 This benchmark features an Henry-like variable-density flow and transport setup that evaluates saltwater intrusion on laboratory scale. The original benchmark was published by Goswami & Clement (2007); OpenGeoSys5 has been verified for all steady and transient states of the original benchmark (see Kolditz et al., 2012).
 
 For the setup and parameterization, see the chapter "Density dependent flow - The Goswami Problem" in Kolditz et al. (2012).
 
-
 ## Problem description
 
 The Goswami-Clement benchmark is based on experiment observations for intruding and receding saltwater in a laboratory-scale sand tank. Here, we compare numerical results of ogs6 to the original observation data.
 
 ### Model results
+
 An example for the intruding salt front is shown below. The numerical results of OGS-6 coincide with those of OGS-5.
 
 {{< img src="../gif/goswami.gif" title="Results for numerical experiment. The steady state SS2 from the original experimental work is well reproduced.">}}
@@ -36,10 +35,8 @@ A comparison of numerical and laboratory data is shown in the figure below. The
 
 {{< img src="../Goswami_Exp_Num_Comp.png" title="Results for numerical (colored diamonds) and laboratory data (colored straight lines) on the steady state location of the concentration front (see original research paper).">}}
 
-
 {{< img src="../Goswami_Transient_States.png" title="Results for numerical (colored diamonds) and laboratory data (colored straight lines) on the transient state locations of the concentration front (see original research paper).">}}
 
-
 ## Literature
 
 Goswami, R.R., Clement, T.P., 2007. Laboratory-scale investigation of saltwater intrusion dynamics. Water Resour. Res. 43, 1–11. doi:10.1029/2006WR005151.
diff --git a/web/content/docs/benchmarks/hydro-component/hydro-component.pandoc b/web/content/docs/benchmarks/hydro-component/hydro-component.pandoc
index 70a36bae22eb7ba08a4f4803ae10c254c1ba0ca1..6456ed25e675575ba0315cc76a6ee2a687024bbb 100644
--- a/web/content/docs/benchmarks/hydro-component/hydro-component.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/hydro-component.pandoc
@@ -13,14 +13,12 @@ title = "Saturated Mass Transport"
 
 {{< data-link >}}
 
-
 ## Overview
 
 This benchmark compiles a number of simple, synthetic setups to test different processes of saturated component transport of a solute.
 
 The development of the equation system is given in [this PDF](../HC-Process.pdf). In the following, we present the different setups.
 
-
 ## Problem description
 
 We use quadratic mesh with $0 < x < 1$ and $0 < y < 1$ and a resolution of 32 x 32 quad elements with edge length $0.03125 m$. The domain material is homogeneous and anisotropic. Porosity is $0.2$, storativity is $10^{-5}$, intrinic permeability is $1.239 \cdot 10^{-7} m^2$, dynamic viscosity is $10^{-3} Pa \cdot s$, fluid density is $1 kg\cdot m^{-3}$, molecular diffusion is $10^{-5} m^2\cdot s^{-1}$. If not stated otherwise, retardation coefficient is set to $R=1$, relation between concentration and density is $\beta_c = 0$, decay rate is $\theta = 0$, and dispersivity is $\alpha = 0$.
@@ -64,7 +62,6 @@ Boundary condition for this setup is pressure $p=0$ for the top left corner and
 
 {{< img src="../gif/DiffusionAndStorageAndGravityAndDispersionHalf.gif" title="*Diffusion, Storage, Gravity, and Dispersion Half*">}}
 
-
 #### Diffusion, Storage, Advection, and Decay
 
 Left side boundary conditions for this setup are pressure $p=1$ and concentration $c=1$. Decay rate is $\theta = 0.001 s^{-1}$.
@@ -73,7 +70,6 @@ Left side boundary conditions for this setup are pressure $p=1$ and concentratio
 
 {{< img src="../gif/DiffusionAndStorageAndAdvectionAndDecay.gif" title="*Diffusion, Storage, Advection, and Decay*">}}
 
-
 #### Changes With Inclusion of Non Boussinesq-Effects ####
-The changes to the original setup are described in [this PDF](../HC-NonBoussinesq.pdf).
 
+The changes to the original setup are described in [this PDF](../HC-NonBoussinesq.pdf).
diff --git a/web/content/docs/benchmarks/hydro-component/theis/HC_Theis.pandoc b/web/content/docs/benchmarks/hydro-component/theis/HC_Theis.pandoc
index 3e815687c2c0ea69e58c710dc70a093f0af65c83..13b824e08cb7ffeefb675e0ac168681de4c30a0e 100644
--- a/web/content/docs/benchmarks/hydro-component/theis/HC_Theis.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/theis/HC_Theis.pandoc
@@ -13,14 +13,12 @@ title = "Theis solution for well pumping"
 
 {{< data-link >}}
 
-
 ## Overview
 
 Abstraction of water from an aquifer is a common procedure, as groundwater is usually better protected from contamination and steadily available even in dry seasons. For a sustainable water usage, the evaluation of the spatio-temporal behaviour of the water level for a specified abstraction rate is of high importance for water management.
 
 This benchmark verifies the groundwater level drawdown for an aquifer that is subjected to pumping.
 
-
 ## Problem description
 
 For pumping from a well, Theis (1935) proposed an analytical solution to calculate the water level drawdown over time and distance from the well. A short summary of the solution can be seen in
@@ -28,7 +26,6 @@ web/content/docs/benchmarks/liquid-flow/liquid-flow-theis-problem.pandoc
 
 Here, we verify pumping abstraction with Theis for the `ComponentTransport` process using a 3D setup. The setup is adapted from Walther (2014), section 3.2.
 
-
 ### Model setup
 
 The setup comprises a 1/8th slice of a full circle (see figure 1).
@@ -37,14 +34,12 @@ The setup comprises a 1/8th slice of a full circle (see figure 1).
 
 The outer boundary condition is set as Dirichlet with a hydrostatic pressure along the shell surface of the slice equivalent to a head of $h = 0 m$ (i.e. water level equals top of domain). For mass transport, a Dirichlet boundary conditions with concentration $c = 0$ is set at the outer shell. The inner boundary condition is equivalent to the eighth of a total abstraction rate of $Q_t = 15 m^3/d$ for a full cylinder. *NB: In the `ComponentTransport` process, the Neumann BC is given as mass flux and has to be calculated per area, such that the value for the project file is $Q = Q_t / 8 / A \cdot \rho_0 = 2.83542E-03 m^3/s/m^2 \cdot kg/m^3$ (units equal $\frac{kg}{s m^2}$) with fluid reference density $\rho_0 = 1000 kg/m^3$ and abstraction area $A = 7.65 m^2$.*
 
-
 The homogeneous, isotropic domain is defined for the radius $1 < r < 100 m$ and a thickness $b = 10 m$. Saturated intrinsic permeability is $\kappa = 7.6453E-13 m^2$ yielding a transmissivity of $T = 7.5E-05 m^2/s$; porosity is $\phi = 0.2$; specific storage is $S_s = 1.0E-03$ and defined through compressibility $\gamma = 5.0968E-08 s^2/m/kg$ (input tag fluid_density_pressure_difference_ratio is $\gamma = \frac{1}{\rho_0} \frac{\partial \rho}{\partial p}$, which can be used to incorporate $S_s$ with $\gamma = \frac{S_s}{b \phi g \rho_0}$ with gravitational acceleration $g = 9.81 m^2/s$).
 
 Mass transport properties are irrelevant as no transport processes are calculated.
 
 Initial conditions are $c = 0$ and hydrostatic pressure conditions.
 
-
 ### Results
 
 The figure below compares the analytical Theis solution vs. the simulated values from OGS6.
@@ -55,7 +50,6 @@ The top figure shows drawdown (i.e. the difference in water level compared to an
 
 The lower figure shows drawdown over radius at time $t = 5000 s$; the top figure also signifies this with a green vertical: over the whole domain, the analytical and numerical solutions are coinciding very well. *NB: With higher values of $S_s$, one has to take care to convert the simulated water level to equivalent freshwater head; in this case, fluid density variation is very low such that a conversion is not required.*
 
-
 ## References
 
 Theis, C.V., 1935. The relation between the lowering of the piezometric surface and the rate and duration of discharge of a well using groundwater storage. Trans. Amer. Geophys. Union 16, 513–514.
diff --git a/web/content/docs/benchmarks/hydro-component/vdbc.pandoc b/web/content/docs/benchmarks/hydro-component/vdbc.pandoc
index 4c81dd98b7378a8e12a6a1f83888d486c984913d..e1f5fed09cb77713739d7fb4ed3aff7e154bd788 100644
--- a/web/content/docs/benchmarks/hydro-component/vdbc.pandoc
+++ b/web/content/docs/benchmarks/hydro-component/vdbc.pandoc
@@ -13,7 +13,6 @@ title = "Variable Dependent Boundary Condition"
 
 {{< data-link >}}
 
-
 ## Overview
 
 The component transport process is used for the benchmark setup. Here, a analytical solution of a simple setup is derived and compared to the numerical results.
@@ -21,10 +20,6 @@ This Benchmark is described in [this PDF](../HC-VDBCTest.pdf).
 
 For the setup and parameterization, see the chapter "Density dependent flow - The Goswami Problem" in Kolditz et al. (2012).
 
-
 ## Results
 
 {{< img src="../VDBC_num_ana_comp.png" title="UPPER PART: Analytical solution on the right boundary in dependance of time $t$ of the problem indicated with red dashed line in comparison to numerical solution indicated by blue crosses; LOWER PART: development of relative error in dependance of time $t$. Grid spacing for simulations: 0.1; widest timestep 10. The relative error is below $5 \times 10^{-5}$ for all simulation times.">}}
-
-
-
diff --git a/web/content/docs/benchmarks/hydro-mechanics/InjectionProduction.pandoc b/web/content/docs/benchmarks/hydro-mechanics/InjectionProduction.pandoc
index cfedcddbe9226ba8ab5d5e083747a5a5a9e0efa9..c6e498cebb6ab5de48ac01e5b2129a464d81ece9 100644
--- a/web/content/docs/benchmarks/hydro-mechanics/InjectionProduction.pandoc
+++ b/web/content/docs/benchmarks/hydro-mechanics/InjectionProduction.pandoc
@@ -14,7 +14,8 @@ author = "Wenqing Wang"
 {{< data-link >}}
 
 ---
-#     Consolidation example based on fluid injection and production    application
+
+# Consolidation example based on fluid injection and production    application
 
 {{< img src="../InjectionProduction.png" >}}
 
diff --git a/web/content/docs/benchmarks/hydro-mechanics/lie-hm-linear-single-fracture.pandoc b/web/content/docs/benchmarks/hydro-mechanics/lie-hm-linear-single-fracture.pandoc
index 6a4de65ef23656572aa53be739533546a812ad66..839eab452144ac6bc24d007fcc8e746175f249b4 100644
--- a/web/content/docs/benchmarks/hydro-mechanics/lie-hm-linear-single-fracture.pandoc
+++ b/web/content/docs/benchmarks/hydro-mechanics/lie-hm-linear-single-fracture.pandoc
@@ -20,7 +20,6 @@ We solve a hydromechanics problem (small deformation, linear elastic, Darcy flow
 
 See [this PDF](../LIE_HM.pdf) for detailed problem description.
 
-
 ## Results and evaluation
 
 Result showing pore pressure increase due to the injection and subsequent fracture aperture increases at t=500s. A small discrepancy of the aperture near the injection is due to the interpolation method for converting cell data to point data in ParaView.
diff --git a/web/content/docs/benchmarks/hydro-thermal/decovalex-TH.pandoc b/web/content/docs/benchmarks/hydro-thermal/decovalex-TH.pandoc
index 0caf2c8ed8d08f1ad4dce6604613dc59e7091771..fbc1d3d9a8dbc910a6ce1364f3823da6f5dd62fc 100644
--- a/web/content/docs/benchmarks/hydro-thermal/decovalex-TH.pandoc
+++ b/web/content/docs/benchmarks/hydro-thermal/decovalex-TH.pandoc
@@ -121,6 +121,7 @@ The TASK D_THM1 of the DECOVALEX-THMC project studies the coupled thermal hydrau
 </table>
 
 ## Solution
+
 <p>As the reference results, the temperature and pressure distributions in the
  domain at the time of 18 years are shown in the following figure, in which the
  thermal convection effective can be seen clearly.</p>
diff --git a/web/content/docs/benchmarks/liquid-flow/buildup_test.pandoc b/web/content/docs/benchmarks/liquid-flow/buildup_test.pandoc
index 0819f6f010f50fbaca19611f62d022fd21fbb2fb..a59a42993f57096a2dceef703d5e9e5e02aea334 100644
--- a/web/content/docs/benchmarks/liquid-flow/buildup_test.pandoc
+++ b/web/content/docs/benchmarks/liquid-flow/buildup_test.pandoc
@@ -15,7 +15,6 @@ project = "/Parabolic/LiquidFlow/BuildupTest/buildup_test.prj"
 
 ## Problem description
 
-
 The pressure buildup test is performed by shutting in a producing well
 at time $t=t_p$, after which a smooth rise of the well head pressure can
 be observed. For a geothermal reservoir, the buildup test result is
@@ -55,7 +54,6 @@ linear section appears at the left side of the diagram.
 
 Figure 1: Horner plot ($p$ vs $(t_p+\Delta t)/\Delta t$) for buildup test showing the inferred Horner straight line
 
-
 The slope $m$ of the Horner straight line is expressed as:
 $$m=0.1832\frac{Q\mu}{\kappa b}$$ in which $Q\  \mathrm{[L^3/T]}\ (Q>0)$
 is the production rate of the well before shut-in,
@@ -100,7 +98,6 @@ $$\Delta p=\rho g \frac{-Q}{4\pi T}W\left(\frac{r^2S}{4Tt}\right)+\rho g \frac{Q
 
 ## Results and evaluation
 
-
 The pressure evolution is simulated throughout the domain and the result
 is compared with the analytical solution at $r=10.287\ \mathrm{m}$. In
 Figure 2, it can be observed that the numerical model
@@ -110,12 +107,10 @@ Figure 3.
 
 {{< img src="../comparison.png" >}}
 
-
 Figure 2: OGS 6 result compared with analytical solution
 
 {{< img src="../error.png" >}}
 
-
 Figure 3: Absolute and relative error
 
 ## References
diff --git a/web/content/docs/benchmarks/liquid-flow/liquid-flow-theis-problem.pandoc b/web/content/docs/benchmarks/liquid-flow/liquid-flow-theis-problem.pandoc
index 6b4c796ecfc3c4d5a85951b2f1a191a478b51934..a4b08929197471346652cb11f7212bdd035c1a4a 100644
--- a/web/content/docs/benchmarks/liquid-flow/liquid-flow-theis-problem.pandoc
+++ b/web/content/docs/benchmarks/liquid-flow/liquid-flow-theis-problem.pandoc
@@ -18,6 +18,7 @@ author = "Wenqing Wang"
 Theis' problem examines the transient lowering of the water table induced by a pumping well. Theis' fundamental insight was to recognize that Darcy's law is analogous to the law of heat flow by conduction, i.e., hydraulic pressure being analogous to temperature, pressure-gradient to thermal gradient.
 
 The assumptions required by the Theis solution are:
+
 - the aquifer is homogeneous, isotropic, confined, infinite in radial extent,
 - the aquifer has uniform thickness, horizontal piezometric surface
 - the well is fully penetrating the entire aquifer thickness,
@@ -25,7 +26,6 @@ The assumptions required by the Theis solution are:
 - the well has a constant pumping rate,
 - no other wells or long term changes in regional water levels.
 
-
 ## Analytical solution
 
 The analytical solution of the drawdown as a function of time and distance is expressed by
diff --git a/web/content/docs/benchmarks/liquid-flow/primary-variable-constrain-dirichlet-boundary-condition.pandoc b/web/content/docs/benchmarks/liquid-flow/primary-variable-constrain-dirichlet-boundary-condition.pandoc
index 23cc48060e2045d974fdff90e0a8cfe8092cebde..609eff114c3a75012a92532a145832d86036297b 100644
--- a/web/content/docs/benchmarks/liquid-flow/primary-variable-constrain-dirichlet-boundary-condition.pandoc
+++ b/web/content/docs/benchmarks/liquid-flow/primary-variable-constrain-dirichlet-boundary-condition.pandoc
@@ -20,6 +20,7 @@ $$
 \left( c \rho_R + \phi \frac{\partial \rho_R}{\partial p}\right) \frac{\partial
 p}{\partial t} - \nabla \cdot
 \left[ \rho_R \frac{\kappa}{\mu} \left( \nabla p + \rho_R g \right) \right]
+
 - Q_p = 0.
 $$
 where
@@ -45,7 +46,7 @@ $$
 \Gamma^\ast_D = \{ x \in \mathbb{R}^d, x \in \Gamma_D, \text{Condition}(p(x))  \}
 $$
 
-## Examples:
+## Examples
 
 On the left (x=0) and right side (x=1) of the domain $\Omega = [0,1]^3$ the
 usual Dirichlet-type boundary conditions are set, i.e.,
@@ -63,4 +64,3 @@ after the first time step and the PVCDBC is activated in the second time step.
 The effect is depicted in the figure:
 
 {{< img src="../PVCDBC_1_ts_2.png" >}}
-
diff --git a/web/content/docs/benchmarks/liquid-flow/time-dependent-heterogeneous-source-term-and-boundary-conditions.pandoc b/web/content/docs/benchmarks/liquid-flow/time-dependent-heterogeneous-source-term-and-boundary-conditions.pandoc
index 1fc33f8fa5843ffccc16cd4cbcdcdf367788ba2a..3eb48f6b4ee5ca555c6d753a60415a8289760096 100644
--- a/web/content/docs/benchmarks/liquid-flow/time-dependent-heterogeneous-source-term-and-boundary-conditions.pandoc
+++ b/web/content/docs/benchmarks/liquid-flow/time-dependent-heterogeneous-source-term-and-boundary-conditions.pandoc
@@ -23,6 +23,7 @@ TimeDependentHeterogeneousParameter for boundary conditions or source terms.
 
 In the parameter specification section of the project file it is possible to add
 a parameter type with the type `TimedependentHeterogeneousParameter`.
+
 ```
 <parameter>
     <name>ParameterForSourceTerm</name>
@@ -44,10 +45,10 @@ a parameter type with the type `TimedependentHeterogeneousParameter`.
     </time_series>
 </parameter>
 ```
+
 Of course, the referenced parameters for the particular time steps have to be
 defined also. Values of the parameter are piecewise linear interpolated.
 
-
 ## Example
 
 This simple example should demonstrate the use of the time depenendent
diff --git a/web/content/docs/benchmarks/liquid-flow/unconfined-aquifer.pandoc b/web/content/docs/benchmarks/liquid-flow/unconfined-aquifer.pandoc
index 719f3b97cd7c7e2840486f85c095b86607a46646..1417e9549aafd2528703cdc6dcfa5b3e05a6cf7f 100644
--- a/web/content/docs/benchmarks/liquid-flow/unconfined-aquifer.pandoc
+++ b/web/content/docs/benchmarks/liquid-flow/unconfined-aquifer.pandoc
@@ -33,8 +33,6 @@ $$
 \end{eqnarray}
 $$
 
-
-
 where $h[m]$ is the hydraulic head, $S_y$ is the specific yield and $K$ is the
 hydraulic conductivity. The Specific Yield $S_y$, also known as the drainable
 porosity, is a quantity that is smaller or equal to the effective porosity in a
@@ -60,15 +58,13 @@ $$
 
 For the model parameterization this means:
 
-- Gravity must be switched off:  		g=0
-- The density gets the value 1:			ρ=1
-- The viscosity gets the value 1:		μ=1
+- Gravity must be switched off:    g=0
+- The density gets the value 1:   ρ=1
+- The viscosity gets the value 1:  μ=1
 
 Note: in such a case, the result is also an output of hydraulic head in [m] and not Pressure in [Pa].
 
-
-
-## Examples:
+## Examples
 
 The following simple examples, which have been compared with Modflow simulations, shall verify the result and demonstrate the basic parameterization.
 
@@ -79,34 +75,34 @@ The basic scenario for the two-dimensional unconfined aquifer:
 - The material is a homogeneous coarse-grained sand with an isotropic hydraulic conductivity of 160 m/day (0.00185 m/s).
 - The aquifer thickness is 25m.
 
-### Scenario A:
+### Scenario A
+
 * Steady-state model.
 * In the north there is a fixed head boundary condition with 15 m.
 * The southern boundary has a fixed head boundary condition with 25 m.
 * the Specific Yield is set to $S_y = 0.0$
 {{< img src="../Dupuit_Scenario_A.jpg" >}}
 
+### Scenario B
 
-### Scenario B:
 * Like scenario A and additionally
 * with an average groundwater recharge rate = 3.54745E-09 m/s
 {{< img src="../Dupuit_Scenario_B.jpg" >}}
 
+### Scenario C
 
-### Scenario C:
 * like scenario A but
 * with an inflow rate of 4.62963E-05 m3/s per meter at the southern boundary
 {{< img src="../Dupuit_Scenario_C.jpg" >}}
 
-
-### Scenario D:
+### Scenario D
 
 - like scenario A but transient and
 - with a Specific Yield $S_y_ = 0.25$.
 - Simulation time = 100 days.
 {{< img src="../Dupuit_Scenario_D.jpg" >}}
 
-### References:
+### References
 
 For more information see e.g.
 
@@ -117,5 +113,3 @@ For more information see e.g.
 - _Forchheimer P. Grundwasserspiegel bei Brunnenanlagen. Z. Osterreichhissheingenieur Architecten Ver, 44:629–635, 1898._
 - _Kolditz, O., Görke, U.-J., Shao, H., Wang, W.: Thermo-Hydro-Mechanical-Chemical Processes in Porous Media - Benchmarks and Examples, Lecture Notes in Computational Science and Engineering, 2012._
 - _Mishra P.K., Kuhlman K.L. (2013) Unconfined Aquifer Flow Theory: From Dupuit to Present. In: Mishra P., Kuhlman K. (eds) Advances in Hydrogeology. Springer, New York, NY 2013._
-
-
diff --git a/web/content/docs/benchmarks/phase-field/phasefield.pandoc b/web/content/docs/benchmarks/phase-field/phasefield.pandoc
index dc38dca252b70feb5c6f1c82d6859e76bfa333a5..27fef57fa3ea6dd16ceddc16ab45235c461f10d0 100644
--- a/web/content/docs/benchmarks/phase-field/phasefield.pandoc
+++ b/web/content/docs/benchmarks/phase-field/phasefield.pandoc
@@ -16,6 +16,7 @@ weight = 158
 ## Problem description
 
 We solve a homogeneous beam model under a given displacement loading. The length of the beam is 2\,mm. Detailed model description can refer [this PDF](../Miao_Biot2017.pdf).
+
 ## Results and evaluation
 
 Results show crack Phase-Field and displacement field distributions through the length of the beam:
diff --git a/web/content/docs/benchmarks/python-bc/hertz-contact/hertz-contact.pandoc b/web/content/docs/benchmarks/python-bc/hertz-contact/hertz-contact.pandoc
index e16d7f52724ae7b26c94cd94286aa305a0106f61..64067364b7f5abb0a71baf79285feb1e5b6283a3 100644
--- a/web/content/docs/benchmarks/python-bc/hertz-contact/hertz-contact.pandoc
+++ b/web/content/docs/benchmarks/python-bc/hertz-contact/hertz-contact.pandoc
@@ -38,7 +38,6 @@ Compared to the sketch above the prescribed $y$ displacements correspond
 to $w_0/2$, because due to symmetry only half of the system (a section of the
 lower sphere) is simulated.
 
-
 ## Analytical solution
 
 The derivation of the formulae below can be found, e.g.,
@@ -75,7 +74,6 @@ F = \frac{8 a^3}{3\kappa}
 \end{equation}
 $$
 
-
 ## Results
 
 Contact radii:
diff --git a/web/content/docs/benchmarks/python-bc/laplace-equation/python-laplace-eq.pandoc b/web/content/docs/benchmarks/python-bc/laplace-equation/python-laplace-eq.pandoc
index b35ad4a0d8562e1d0d714cd84c14a6134e079d21..2d4d0c2fd18ffb37715da2768b4672e0daa58a88 100644
--- a/web/content/docs/benchmarks/python-bc/laplace-equation/python-laplace-eq.pandoc
+++ b/web/content/docs/benchmarks/python-bc/laplace-equation/python-laplace-eq.pandoc
@@ -33,6 +33,7 @@ We solve Laplace's Equation in 2D on a $1 \times 1$ square domain.
 Laplace's equation is
 $$
 \begin{equation}
+
 - \mathop{\mathrm{div}} (a \mathop{\mathrm{grad}} u) = 0
 \end{equation}
 $$
@@ -82,7 +83,6 @@ On the right boundary of the domain a Neumann BC is applied.
 There $n = (1, 0)$, which implies that $a \mathop{\mathrm{grad}} u \cdot n
 = a \, \partial u / \partial x$.
 
-
 ## Results
 
 The numerical result obtained from OpenGeoSys is:
diff --git a/web/content/docs/benchmarks/python-bc/piston/piston.pandoc b/web/content/docs/benchmarks/python-bc/piston/piston.pandoc
index c0894d69265c9355dadd3b6422a2ca4d72ebe0f8..60e7dc5d4b2a4052fdcffe9d2d2426a906ca4251 100644
--- a/web/content/docs/benchmarks/python-bc/piston/piston.pandoc
+++ b/web/content/docs/benchmarks/python-bc/piston/piston.pandoc
@@ -30,7 +30,6 @@ For simplicitly, also initially the elastic piston is in an unstressed state.
 
 {{<img src="../sketch-piston.png" >}}
 
-
 ## Results
 
 {{<img src="../load-steps.png" >}}
diff --git a/web/content/docs/benchmarks/reactive-transport/calcite.pandoc b/web/content/docs/benchmarks/reactive-transport/calcite.pandoc
index 7ec4cd839f785e9e1e64d5b85cba299e2240505b..1dc3befae607f9478bfb959e5c7e639d627a8a4b 100644
--- a/web/content/docs/benchmarks/reactive-transport/calcite.pandoc
+++ b/web/content/docs/benchmarks/reactive-transport/calcite.pandoc
@@ -13,7 +13,6 @@ title = "Precipitation/dissolution equilibrium reactions in a saturated column"
 
 {{< data-link >}}
 
-
 ## Overview
 
 This benchmark was firstly described in Kolditz *et al.* (2012) as a reactive transport benchmark including precipitation and dissolution reactions along a saturated column of calcite which is fluxed with a diluted solution of MgCl$_2$. Three different codes (OGS-5#ChemApp, OGS-5#IPhreeqc and OGS-5#GEMS) were used in that exercise.
@@ -69,11 +68,8 @@ At the simulated time, it can be clearly seen that the MgCl$_2$ solution front h
 
 {{< img src="../calcite-Figures/ResultComparisonPH.png" title="pH value profiles obtained with OGS-6#IPhreeqc (empty triangle symbol) and OGS-5#IPhreeqc (empty circle symbol) at 350 min.">}}
 
-
-
 {{< data-link >}}
 
-
 ## Literature
 
 He, W., Beyer, C., Fleckenstein, J.H., Jang, E., Kolditz, O., Naumov, D., Kalbacher, T., 2015. A parallelization scheme to simulate reactive transport in the subsurface environment with OGS#IPhreeqc 5.5.7-3.1.2. Geosci. Model Dev. 8 (10), 3333 - 3348
diff --git a/web/content/docs/benchmarks/reactive-transport/kineticreactant_allascomponents/KineticReactant2.pandoc b/web/content/docs/benchmarks/reactive-transport/kineticreactant_allascomponents/KineticReactant2.pandoc
index 5b2dbf5658a95fabb1451dfd2bc9232aa6ae9288..1d7a6951a4f87a70957a7b06ddb73cba36702d7c 100644
--- a/web/content/docs/benchmarks/reactive-transport/kineticreactant_allascomponents/KineticReactant2.pandoc
+++ b/web/content/docs/benchmarks/reactive-transport/kineticreactant_allascomponents/KineticReactant2.pandoc
@@ -13,9 +13,6 @@ title = "Solute transport including kinetic reaction"
 
 {{< data-link >}}
 
-
-
-
 ## Overview
 
 This scenario describes the transport of two solutes (Snythetica and Syntheticb) through a saturated media.
@@ -25,7 +22,6 @@ The coupling of OGS-6 and IPhreeqc used for simulation requires to simulate the
 This is required to adjust the compulsory charge balance computation executed by Phreeqc.
 The solution by OGS-6--IPhreeqc will be compared to the solution by a coupling of OGS-5--IPhreeqc.
 
-
 ## Problem Description
 
 **1d scenario:**
@@ -61,7 +57,6 @@ The horizontal domain is 0.5 m in x and 0.5 m in y direction, and,  discretized
 
 Table: Media, material and component properties
 
-
 -----------------------------------------
 
 | Parameter | Description | Value | Unit |
@@ -80,8 +75,6 @@ Table: Media, material and component properties
 
 Table: Initial and boundary conditions
 
-
-
 ## Results
 
 The kinetic reaction results in the expected decline of the concentration of Synthetica and Syntheticb, which is super-positioned by the influx of these two educts through the left side.
diff --git a/web/content/docs/benchmarks/reactive-transport/wetland/Wetland.pandoc b/web/content/docs/benchmarks/reactive-transport/wetland/Wetland.pandoc
index abe663a674ed2845f5867911d0cc276bac782248..9fd478a748c6c70fdd52068eb431d4e036373d7b 100644
--- a/web/content/docs/benchmarks/reactive-transport/wetland/Wetland.pandoc
+++ b/web/content/docs/benchmarks/reactive-transport/wetland/Wetland.pandoc
@@ -13,25 +13,19 @@ title = "Complex kinetic reaction network"
 
 {{< data-link >}}
 
-
-
-
 ## Overview
 
 The studied system represents a treatment wetland, which can be considered as an engineered ecosystem that mimics natural occuring microbiological processes to treat wastewater.
 Basically, such a system consists of a basin filled with a grained solid media (e.g. gravel or sand) and wastewater is passed through it.
 Multiple types of microbial organisms are present that can metabolize chemical pollutants (e.g. ammoni or organic molecules) present in wastewater, which drives the cycling of carbon and nutrients.
 
-
 The scenario presented here is a modification of a case already described in Boog et al. (2019) without considering heat transport.
 The experimental system consists of a basin of 4.7 m in length, 1.2 m in width and 0.9 m in depth (Figure 1) filled with gravel and saturated with water.
 The domestic wastewater enters the system at a constant flow rate on the left side and leaves it via an overflow at the right side.
 
-
 The coupling of OGS-6 and IPhreeqc used in the simulation requires to include the transport of H^+^--ions to adjust the compulsory charge balance computated by Phreeqc.
 The results obtained by OGS-6--IPhreeqc will be compared to the ones of OGS-5--IPhreeqc.
 
-
 ## Problem Description
 
 The scenario includes the transport of multiple solutes (i.e. organic molecules, ammonia, etc.) through a saturated media (during 20 days) involving a complex biokinetic reaction network.
@@ -50,7 +44,6 @@ Respective material properties, initial and boundary conditions are listed in Ta
 
 ![Network of microbiological reactions described by CWM1. $S_I$ = inert soluble organic matter (COD), $X_I$ = inert particulated COD, $X_S$ = Slowly biodegradable particulate COD, $S_F$ = Fermentable, readily biodegradable soluble COD, $S_A$ = Fermentation products as acetate, $S_{NH}$ = Ammonium and ammonia nitrogen, $S_{NO}$ = Nitrate and nitrite nitrogen, $S_O$ = Dissolved oxygen, $S_{SO}$ = Sulphate sulfur, $S_{H2S}$ = Sulphide sulfur; different type of bacterias are identified as $X_H$, $X_A$, $X_{FB}$, $X_{AMB}$, $X_{ASRB}$ and $X_{SOB}$](../Wetland_cwm1.png){width=60%}
 
-
 -----------------------------------------
 
 |Parameter | Description | Value | Unit |
@@ -70,7 +63,6 @@ Respective material properties, initial and boundary conditions are listed in Ta
 
 Table 1: Media, material and component properties
 
-
 -----------------------------------------
 
 | Parameter | Description | Value | Unit |
@@ -88,10 +80,8 @@ Table 1: Media, material and component properties
 
 Table 2: Initial and boundary conditions
 
-
 -----------------------------------------
 
-
 ## Results
 
 Influent wastewater components (oxygen and pollutants) spread through the model domain by advective--dispersive transport (Figure 3).
@@ -114,6 +104,6 @@ Please note that due to the long computation time of the simulation (~13 h), the
 
 ## References
 
-Boog, J., Kalbacher, T., Nivala, J., Forquet, N., van Afferden, M., Müller, R.A., 2019. Modeling the relationship of aeration, oxygen transfer and treatment performance in aerated horizontal flow treatment wetlands. Water Research. 157 , 321 - 334. https://doi.org/10.1016/j.watres.2019.03.062.
+Boog, J., Kalbacher, T., Nivala, J., Forquet, N., van Afferden, M., Müller, R.A., 2019. Modeling the relationship of aeration, oxygen transfer and treatment performance in aerated horizontal flow treatment wetlands. Water Research. 157 , 321 - 334. <https://doi.org/10.1016/j.watres.2019.03.062>.
 
-Langergraber, G., Rousseau, D.P.L., García, J., Mena, J., 2009. CWM1: A general model to describe biokinetic processes in subsurface flow constructed wetlands. Water Science and Technology, 59 (9), 1687-1697. https://doi.org/10.2166/wst.2009.131.
+Langergraber, G., Rousseau, D.P.L., García, J., Mena, J., 2009. CWM1: A general model to describe biokinetic processes in subsurface flow constructed wetlands. Water Science and Technology, 59 (9), 1687-1697. <https://doi.org/10.2166/wst.2009.131>.
diff --git a/web/content/docs/benchmarks/richards-flow/richards-component-transport.pandoc b/web/content/docs/benchmarks/richards-flow/richards-component-transport.pandoc
index 9d0a7bf67848d1fa6ac444da941f532ea74b3f82..a29168f9ee2ebe801ac0b36ef7968398ac7ce0e4 100644
--- a/web/content/docs/benchmarks/richards-flow/richards-component-transport.pandoc
+++ b/web/content/docs/benchmarks/richards-flow/richards-component-transport.pandoc
@@ -13,19 +13,16 @@ title = "Unsaturated Mass Transport"
 
 {{< data-link >}}
 
-
 ## Overview
 
 The Richards equation is often used to describe water movement in the unsaturated zone, while the mass transport equation describes solute movement in the liquid phase. Here, we use a monolithic approach to simulate mass transport in an unsaturated medium.
 
 The development of the equation system is given in [this PDF](../RichardsComponentTransport_Equations.pdf). In the following, we present a numerical benchmark that uses experimental data as reference.
 
-
 ## Problem description
 
 We use the Padilla et al. (1999) problem which features a series of saturated and unsaturated laboratory column experiments to validate the implementation. In specific, we refer to experiments "NaCl1" (saturated flow) and "NaCl6" (unsaturated flow) - see also table 1 in Padilla et al. (1999) - and use the following parameters as model input.
 
-
 ### Model setup
 
 We use a 1D domain with $0 < x < 0.25 m$, and a spatial resolution of $1.25 mm$ with a total of 200 elements. Top boundary conditions are concentration $c = 1$ (as Dirichlet) for both setups, and a specific flux $q_{NaCl1} = 2.12789E-05$ and $q_{NaCl6} = 6.46004E-06$ (as Neumann) for saturated and unsaturated cases, respectively. Bottom boundary conditions are a free exit boundary for mass transport, and Dirichlet pressure values are chosen so that the saturation in the column follows the respective values according to table 1 in Padilla et al. (1999) as $p_{NaCl1} = 0 Pa$ and $p_{NaCl6} = -4800 Pa$.
@@ -37,7 +34,6 @@ Initial conditions are $c = 0$ and hydrostatic pressure conditions with steady s
 {{< data-link "The NaCl1 project file" "Parabolic/RichardsComponentTransport/Padilla/Padilla_NaCl1/Padilla_NaCl1.prj" >}}
 {{< data-link "The NaCl6 project file" "Parabolic/RichardsComponentTransport/Padilla/Padilla_NaCl6/Padilla_NaCl6.prj" >}}
 
-
 ### Results
 
 The figure below shows breakthrough curves vs experimental result at the bottom of the simulation domain, together with averaged saturation values at the two observation points with distance of 0.075 cm from both ends of the column (as stated in Padilla et al., 1999) over pore volume.
@@ -53,4 +49,3 @@ Here is the [ParaView state file]({{< data-url "Parabolic/RichardsComponentTrans
 ## References
 
 Padilla, I. Y., T.-C. J. Yeh, and M. H. Conklin (1999), The effect of water content on solute transport in unsaturated porous media, Water Resour. Res., 35(11), 3303–3313, doi:10.1029/1999WR900171.
-
diff --git a/web/content/docs/benchmarks/small-deformations/lie-m-linear-single-fracture.pandoc b/web/content/docs/benchmarks/small-deformations/lie-m-linear-single-fracture.pandoc
index 78fdd52ef5d41de8892d343c4fd61a9462de77c3..c0b34a153fd3cd6d4bdb2e4550882b32f7056e59 100644
--- a/web/content/docs/benchmarks/small-deformations/lie-m-linear-single-fracture.pandoc
+++ b/web/content/docs/benchmarks/small-deformations/lie-m-linear-single-fracture.pandoc
@@ -28,7 +28,6 @@ Result showing sliding of the upper part of the domain along the fracture:
 
 {{< img src="../LIE_SD_m_result_uy.png" >}}
 
-
 Same benchmark setup with plane strain conditions in 3D:
 {{< img src="../single_joint_3D.png" >}}
 
diff --git a/web/content/docs/benchmarks/small-deformations/mechanics-linear-disc-with-hole.pandoc b/web/content/docs/benchmarks/small-deformations/mechanics-linear-disc-with-hole.pandoc
index 58a700e968c653cd4c7be906db37c25b166f0870..f9f55a26270fee43a6eda649d0dabd5122d6ecc5 100644
--- a/web/content/docs/benchmarks/small-deformations/mechanics-linear-disc-with-hole.pandoc
+++ b/web/content/docs/benchmarks/small-deformations/mechanics-linear-disc-with-hole.pandoc
@@ -19,7 +19,6 @@ We solve a linear elastic small deformation problem on a quarter of a plate with
 
 See [this PDF](../Circular_hole.pdf) for detailed problem description.
 
-
 ## Results and evaluation
 
 Result showing the displacement field:
diff --git a/web/content/docs/benchmarks/small-deformations/mechanics-linear-element_deactivation.pandoc b/web/content/docs/benchmarks/small-deformations/mechanics-linear-element_deactivation.pandoc
index ba4447887247023b1f5e450fbb946f6f58f128ae..a03937808b6993c83f3072b767b8ce8e5c45f8a8 100644
--- a/web/content/docs/benchmarks/small-deformations/mechanics-linear-element_deactivation.pandoc
+++ b/web/content/docs/benchmarks/small-deformations/mechanics-linear-element_deactivation.pandoc
@@ -41,6 +41,7 @@ The input data set of the element deactivation approach is specified inside the
 * [3D](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/Tests/Data/Mechanics/Linear/ElementDeactivation3D/element_deactivation_M_3D.prj)
 
 ## Mesh
+
 2D and 3D meshes:
 ![](../element_deactivation_2D_3D_mesh.png)
 
@@ -50,4 +51,3 @@ The input data set of the element deactivation approach is specified inside the
 ![](../element_deactivation_2D.png)
 3D results:
 ![](../element_deactivation_3D.png)
-
diff --git a/web/content/docs/benchmarks/small-deformations/mechanics-slope-stability.pandoc b/web/content/docs/benchmarks/small-deformations/mechanics-slope-stability.pandoc
index 28e1e80d0a5c0efe0d9383f0f5f6b32a56fbce6f..852357f671286846a0a7049fddb20b8bec3f03d0 100644
--- a/web/content/docs/benchmarks/small-deformations/mechanics-slope-stability.pandoc
+++ b/web/content/docs/benchmarks/small-deformations/mechanics-slope-stability.pandoc
@@ -18,4 +18,3 @@ title = "Strength reduction for slope stability"
 
 We perform a strength reduction to determine the factor of safety of a slope.
 See [this PDF](../slope_stability.pdf) for detailed problem description.
-
diff --git a/web/content/docs/benchmarks/small-deformations/pressure_bc/Pressure_BC.pandoc b/web/content/docs/benchmarks/small-deformations/pressure_bc/Pressure_BC.pandoc
index c5c0b0325f8798e71e3b77ac7bafd80ddef937f6..8e67734af15f3e8c23328cd54e8878f3179f2eae 100644
--- a/web/content/docs/benchmarks/small-deformations/pressure_bc/Pressure_BC.pandoc
+++ b/web/content/docs/benchmarks/small-deformations/pressure_bc/Pressure_BC.pandoc
@@ -34,4 +34,3 @@ Axisymmetric plastic sphere comparison between numerical and analytical results:
 
 Axisymmetric plastic sphere residuals of stress:
 {{< img src="../sphere_axisymmetric_pl_residual_stress.png" >}}
-
diff --git a/web/content/docs/benchmarks/thermo-hydro-mechanics/consolidation_pointheatsource.pandoc b/web/content/docs/benchmarks/thermo-hydro-mechanics/consolidation_pointheatsource.pandoc
index c09714e91f805c39e7b2cda92e485cc6faec2cf9..3b77a51d75afd427aa9d87b93fea587976db7914 100644
--- a/web/content/docs/benchmarks/thermo-hydro-mechanics/consolidation_pointheatsource.pandoc
+++ b/web/content/docs/benchmarks/thermo-hydro-mechanics/consolidation_pointheatsource.pandoc
@@ -29,7 +29,6 @@ The main project input file is `square_1e2.prj`. Geometry and mesh are stored in
 The problem equations can be found in the original work of Booker and Savvidou (1985) or Chaudhry et al. (2019).
 The analytical solution of the coupled THM consolidation problem can be expressed in terms of some derived parameters:
 
-
 \begin{equation}
     \kappa = \dfrac{K}{m}
 \end{equation}
@@ -94,10 +93,8 @@ The results below were taken from the benchmark published in Chaudhry et al. (20
 
 {{< img src="../images/resp_vs_t_square.png" >}}
 
-
 In the pictures above, the analytical and numerical results for temperature ($T$), pressure ($p$), displacement ($u_i$) and stress ($\sigma_{ij}$) are plotted as function of time ($t$) at point $P=(1.3,0.682,0.0)$ and along the radial coordinate ($r$ ) at time $t=5\cdot 10^5$ (below).
 
-
 {{< img src="../images/resp_vs_x_square.png" >}}
 
 (Figures were taken from Chaudhry et al. (2019).)
@@ -108,11 +105,8 @@ The absolute errors between OGS6 and the analytical solution for temperature, pr
 
 {{< img src="../images/errordispl_vs_t.png" >}}
 
-
-
 ## References
 
 [1] Booker, J. R.; Savvidou, C. (1985), Consolidation around a point heat source. International Journal for Numerical and Analytical Methods in Geomechanics, 1985, 9. Jg., Nr. 2, S. 173-184.
 
 [2] Chaudhry, A. A.; Buchwald, J.; Kolditz, O. and Nagel, T. (2019), Consolidation around a point heatsource (correction & verification). International Journal for Numerical and Analytical Methods in Geomechanics, 2019, <https://doi.org/10.1002/nag.2998>.
-
diff --git a/web/content/docs/devguide/advanced/build-with-ninja.pandoc b/web/content/docs/devguide/advanced/build-with-ninja.pandoc
index c072bedc45f0f6c9957bc9198d366631ae17a340..b776bb44657288cdcd3520196e60d026a0994386 100644
--- a/web/content/docs/devguide/advanced/build-with-ninja.pandoc
+++ b/web/content/docs/devguide/advanced/build-with-ninja.pandoc
@@ -19,29 +19,31 @@ Download *ninja.zip* from the [latest GitHub release](https://github.com/ninja-b
 Install with your package manager:
 
 ```bash
-$ sudo apt-get install ninja-build
+sudo apt-get install ninja-build
 ```
+
 :::
 
 ::: {.mac}
 Install via Homebrew:
 
 ```bash
-$ brew install ninja
+brew install ninja
 ```
-:::
 
+:::
 
 ## Configure for ninja and build
 
 Run CMake with the ninja-generator:
 
 ```bash
-$ cmake ../source/dir -G Ninja
-$ ninja
+cmake ../source/dir -G Ninja
+ninja
 ```
 
 ::: {.note}
+
 ### <i class="far fa-exclamation-triangle"></i> Visual Studio remarks
 
 When you configure with the Ninja generator you have to run CMake from the appropriate Visual Studio Command Prompt! From there you can both use `cmake` as well as `cmake-gui` which starts the GUI. In the GUI select the `Ninja` generator and leave the toggle `Use default native compilers` on.
diff --git a/web/content/docs/devguide/advanced/conan-package-manager.pandoc b/web/content/docs/devguide/advanced/conan-package-manager.pandoc
index 9ebcfcef11d58321c8b7e712cadb8d33a965650f..1d839675f4bf62b9253be6da8d8cf07343c9c7fa 100644
--- a/web/content/docs/devguide/advanced/conan-package-manager.pandoc
+++ b/web/content/docs/devguide/advanced/conan-package-manager.pandoc
@@ -10,6 +10,7 @@ weight = 1032
 +++
 
 ::: {.note}
+
 ### <i class="far fa-exclamation-triangle"></i> Conan 1.0.0 required
 
 As of OpenGeoSys 6.1.0 Conan version 1.0.0 is required! Please update Conan by running `pip install --upgrade conan` or by downloading the Windows installer.
@@ -19,7 +20,7 @@ The [Conan package manager](https://www.conan.io) helps to install all required
 
 ## Advanced usage
 
-Per default when Conan is enabled it will try to fetch prebuilt binaries from the [OGS Conan repository](https://ogs.jfrog.io/ogs/conan/) at https://ogs.jfrog.io/ogs/api/conan/conan. With the CMake option `OGS_CONAN_BUILD` you define what gets build locally. This option can be set to:
+Per default when Conan is enabled it will try to fetch prebuilt binaries from the [OGS Conan repository](https://ogs.jfrog.io/ogs/conan/) at <https://ogs.jfrog.io/ogs/api/conan/conan>. With the CMake option `OGS_CONAN_BUILD` you define what gets build locally. This option can be set to:
 
 - `missing` - Default, only builds packages which are not available as a prebuilt binary for the current configuration
 - `all` - Builds all packages locally
diff --git a/web/content/docs/devguide/advanced/configuration-options.pandoc b/web/content/docs/devguide/advanced/configuration-options.pandoc
index 83e3a42cada30de4d871fc44374a74e13ebb079f..5c2a16abefa8e037d044169d023465cfb94ad3ba 100644
--- a/web/content/docs/devguide/advanced/configuration-options.pandoc
+++ b/web/content/docs/devguide/advanced/configuration-options.pandoc
@@ -40,7 +40,6 @@ CMake switches to enable / disable parts of OGS.
 
 - `OGS_COVERAGE` - Enables code coverage measurements with gcov/lcov. TODO
 
-
 #### Advanced options
 
 - `OGS_CXX_FLAGS` - Appends user-given compiler flags. Note that existing (CMake-given) flags are not replaced.
diff --git a/web/content/docs/devguide/advanced/docker.pandoc b/web/content/docs/devguide/advanced/docker.pandoc
index 02602f5bd099c109ae3233f4b5a3e4152a5141b7..37105a264031cae123ed1d0502bd6009c390561d 100644
--- a/web/content/docs/devguide/advanced/docker.pandoc
+++ b/web/content/docs/devguide/advanced/docker.pandoc
@@ -32,7 +32,7 @@ RUN ...
 Run the `build` command:
 
 ```bash
-$ docker build --rm -t repo/image_name path/to/directory
+docker build --rm -t repo/image_name path/to/directory
 ```
 
 - `--rm` Cleans up after exiting the container
@@ -46,19 +46,19 @@ Now you can see your build image with `$ docker images`.
 To run commands inside a container:
 
 ```bash
-$ docker run --rm -t image_name command_to_run
+docker run --rm -t image_name command_to_run
 ```
 
 To run an interactive shell add the `-i`-switch:
 
 ```bash
-$ docker run --rm -i -t image_name
+docker run --rm -i -t image_name
 ```
 
 It is useful to mount folders from the host operating system in the Docker container, e.g. to edit source code on your host with your favorite editor:
 
 ```bash
-$ docker run --rm -i -t -v /host/directory:/container/directory image_name
+docker run --rm -i -t -v /host/directory:/container/directory image_name
 ```
 
 ## Prebuilt OGS-6 Docker images
diff --git a/web/content/docs/devguide/advanced/gitlab-migration.pandoc b/web/content/docs/devguide/advanced/gitlab-migration.pandoc
index d8f2f2c148b79d4812717545b61e253df6a3823e..d26d0e69bf8b5c0eb68433f6dfcb8bb4f682f5f2 100644
--- a/web/content/docs/devguide/advanced/gitlab-migration.pandoc
+++ b/web/content/docs/devguide/advanced/gitlab-migration.pandoc
@@ -16,7 +16,9 @@ To migrate your repository run the following commands in your local repository (
 We used Git LFS to store large files but [switched back to plain git](https://github.com/ufz/ogs/issues/2961).
 
 ::: {.note}
+
 ### <i class="far fa-info-circle"></i> IMPORTANT: Normalize LFS files in your existing branches
+
 If you have branches from pre-GitLab times with e.g. newly created LFS files (benchmark files, images, ...) you have to convert them back to plain git:
 
 ```bash
diff --git a/web/content/docs/devguide/advanced/redistributable-builds.pandoc b/web/content/docs/devguide/advanced/redistributable-builds.pandoc
index 561614360d6ca7d2b38a1c0935ecc3a8e3504ec9..2b106e27b63c2083fea72cdde43ce712da631500 100644
--- a/web/content/docs/devguide/advanced/redistributable-builds.pandoc
+++ b/web/content/docs/devguide/advanced/redistributable-builds.pandoc
@@ -16,6 +16,7 @@ If a binary runs on a different machine depends on a lot of factors. The followi
 ## CPU Architecture Optimization
 
 ::: {.win}
+
 ### Default compiler flags
 
 - `/favor:blend`: Optimizes for AMD **and** Intel architectures, see [MSDN docs](https://msdn.microsoft.com/en-us/library/ms173505.aspx)
@@ -28,6 +29,7 @@ If a binary runs on a different machine depends on a lot of factors. The followi
 :::
 
 ::: {.linux}
+
 ### Default compiler flags
 
 - `-march=native`: Optimizes for current cpu
@@ -48,7 +50,6 @@ If a binary runs on a different machine depends on a lot of factors. The followi
 See Linux-tab!
 :::
 
-
 ## Shared vs. static libraries
 
 Try to use static libraries as much as possible. For OGS itself use `BUILD_SHARED_LIBS=OFF`, which already defaults to `OFF`.
@@ -64,4 +65,3 @@ make package
 ```
 
 This creates a zip- or tar-archive which should be redistributable.
-
diff --git a/web/content/docs/devguide/advanced/third-party-libraries.pandoc b/web/content/docs/devguide/advanced/third-party-libraries.pandoc
index 74baa7670b46e51b6855ba364a0ce5855b601109..09795cef093039b4ea5241b765d16f225f20ff49 100644
--- a/web/content/docs/devguide/advanced/third-party-libraries.pandoc
+++ b/web/content/docs/devguide/advanced/third-party-libraries.pandoc
@@ -10,7 +10,8 @@ weight = 1039
 +++
 
 ::: {.note}
-### <i class="far fa-exclamation-triangle"></i> Attention!
+
+### <i class="far fa-exclamation-triangle"></i> Attention
 
 We strongly recommend to simply use [Conan]({{< ref "conan.pandoc" >}}) for handling required third-party libraries.
 :::
diff --git a/web/content/docs/devguide/advanced/using-ccache.pandoc b/web/content/docs/devguide/advanced/using-ccache.pandoc
index ec76d875d815d54630623c65d5e6d772402f7c86..0c3d137b37fffafd04bb6f153769e41a9b576941 100644
--- a/web/content/docs/devguide/advanced/using-ccache.pandoc
+++ b/web/content/docs/devguide/advanced/using-ccache.pandoc
@@ -10,6 +10,7 @@ weight = 1038
 +++
 
 ::: {.note}
+
 ### <i class="far fa-exclamation-triangle"></i> GCC-like compilers only
 
 Tested on GCC and Clang.
diff --git a/web/content/docs/devguide/advanced/working-on-eve.pandoc b/web/content/docs/devguide/advanced/working-on-eve.pandoc
index fba3c22341bedd478e96016896cc3230cc033c73..a026d7b00a221d3563ea84ff4c1d663aa849e186 100644
--- a/web/content/docs/devguide/advanced/working-on-eve.pandoc
+++ b/web/content/docs/devguide/advanced/working-on-eve.pandoc
@@ -26,6 +26,7 @@ Also on eve the installed git module (2.10) is over 2 years old and we recommend
 ml use /global/apps/modulefiles
 ml git/2.20.1
 ```
+
 :::
 
 ## Run OGS within a container
@@ -37,7 +38,7 @@ Eve has [Singularity](https://www.sylabs.io/singularity) container runtime insta
 Load required modules by sourcing the environment script:
 
 ```bash
-$ source scripts/env/eve/cli.sh
+source scripts/env/eve/cli.sh
 ```
 
 Then do the [build configuration]({{< ref "build-configuration.pandoc" >}}) and [build]({{< ref "/docs/devguide/getting-started/build.pandoc" >}}) the project.
@@ -53,18 +54,18 @@ Follow the instructions on using Python's `virtualenv` [on the Eve-wiki](https:/
 Generating Doxygen documentation:
 
 ```bash
-$ module load Doxygen/1.8.14
+module load Doxygen/1.8.14
 ```
 
 You can [build with Ninja]({{< ref "build-with-ninja" >}}):
 
 ```bash
-$ module load ninja/1.9.0
+module load ninja/1.9.0
 ```
 
 ## Build OGS-5
 
 ```bash
-$ module load CMake/3.11.4
-$ module load GCC/6.4.0-2.28
+module load CMake/3.11.4
+module load GCC/6.4.0-2.28
 ```
diff --git a/web/content/docs/devguide/development-workflows/development-ides.pandoc b/web/content/docs/devguide/development-workflows/development-ides.pandoc
index 0203b4bc236c83b967aabef1420af0cb3105f22e..fe51f93b041fa9253cc104a5d4ee8de3d7ce8480 100644
--- a/web/content/docs/devguide/development-workflows/development-ides.pandoc
+++ b/web/content/docs/devguide/development-workflows/development-ides.pandoc
@@ -24,17 +24,19 @@ Here is a **link list** without specific order:
 The steps to get things started with an IDE basically include **generating** the project files, **importing** them in the IDE and know where to **provide arguments** to the debugging binary.
 
 I will assume, that you have the sources (eg. checked out from github) and that they lie in the **source directory**
+
 ```bash
 /home/user/ogs6/sources
 ```
+
 Please, create a seperate **build directory** for your favorite IDE like
+
 ```bash
 /home/user/ogs6/build_gdb
 ```
 
 __________
 
-
 ## GDB
 
 <https://www.sourceware.org/gdb/download>
@@ -47,13 +49,17 @@ __________
 
 1. CD to the build directory
 2. Generate project files with CMake:
+
 ```bash
 cmake ../sources/
 ```
+
 3. Start gdb in graphical mode, without license info (quiet) and with arguments:
+
 ```bash
 gdb -tui -q --args ./bin/ogs ./path/to/BenchmarkName.prj
 ```
+
 4. Have fun...
 
 Documentation: <https://sourceware.org/gdb/onlinedocs/gdb/index.html>
@@ -74,16 +80,20 @@ Choose "Eclipse IDE for C/C++ Developers"
 
 1. CD to the build directory
 2. Generate project files with CMake:
+
 ```bash
 cmake -G "Eclipse CDT4 - Unix Makefiles" ../sources/
 ```
+
 3. Open Eclipse and choose *File - Import - Existing Project into Workspace*
 4. Select the **build directory** and click Finish (***Attention:*** Make sure to **not** check the option *Copy projects into workspace*!)
 5. To provide arguments, you will have to run the project once: *Run - Debug* (running will start building first, if not already done).
 6. Then, give arguments via *Run - Debug Configuration - C/C++ Application - ogs*. Choose *Arguments* tab on right side and add your arguments to the line *C/C++ Application*, e.g.
+
 ```bash
 ./path/to/BenchmarkName.prj
 ```
+
 7. Start debugging...
 
 Documentation: <http://wiki.eclipse.org/Main_Page>
@@ -106,18 +116,22 @@ The latter includes already plugins for Fortran, in case you want to cross-compi
 
 1. CD to the build directory
 2. Generate project files with CMake:
+
 ```bash
 cmake -G "CodeBlocks - Unix Makefiles" ../sources/
 ```
+
 3. *Open an existing project* and choose before created .cbp file
 4. Choose your compilation target
 5. Give arguments: *Project - Set Programs' Arguments*, select correct target and add *Program arguments* in the bottom
+
 ```bash
 ./path/to/BenchmarkName.prj
 ```
+
 6. Rock the show...
 
-### Documentation:
+### Documentation
 
 - <http://www.codeblocks.org/user-manual>
 - <http://wiki.codeblocks.org/index.php?title=Main_Page>
@@ -141,9 +155,11 @@ __________
 5. Click *Next >* until *Finish*
 6. Give arguments via *Run - Set Project Configuration - Customize*
 7. Under *Run*, give *Run Command* on right side:
+
 ```bash
 "${OUTPUT_PATH}" ./path/to/BenchmarkName.prj
 ```
+
 7. When starting debugging, choose correct target
 8. Have a great time...
 
diff --git a/web/content/docs/devguide/documentation/introduction.pandoc b/web/content/docs/devguide/documentation/introduction.pandoc
index 59b0d35db0c768be60c6a3663c7dc01e3174c0ac..b57d7237f20a4fe60f1fdc66866645c6d421e562 100644
--- a/web/content/docs/devguide/documentation/introduction.pandoc
+++ b/web/content/docs/devguide/documentation/introduction.pandoc
@@ -96,7 +96,6 @@ Files belonging directly to a page (e.g. images shown on that same page) should
 
 Bibliography items from *Documentation/bibliography/*.bib can be referenced by their id (always use lowercase ids) with the `bib`-shortcode:
 
-
 ```
 {{< bib "kolditz2012" >}}
 ```
diff --git a/web/content/docs/devguide/getting-started/build-configuration.pandoc b/web/content/docs/devguide/getting-started/build-configuration.pandoc
index 9aa50468fbcacf6e1ab803d8f7a7a9e7064bdd8b..c2bcc931b011bbfadac7200d3cc6e7bacbd17796 100644
--- a/web/content/docs/devguide/getting-started/build-configuration.pandoc
+++ b/web/content/docs/devguide/getting-started/build-configuration.pandoc
@@ -32,6 +32,7 @@ When you want to start over with a new configuration simply delete the build-dir
 
 ::: {.win}
 ::: {.note}
+
 ### <i class="far fa-exclamation-triangle"></i> Supported Visual Studio Generators
 
 - `Visual Studio 15 2017 Win64`
@@ -47,17 +48,18 @@ Instead of using Conan you can optionally [install the required libraries manual
 
 ::: {.win}
 ::: {.note}
+
 #### <i class="far fa-exclamation-triangle"></i> Multi-configuration with Conan and Visual Studio
 
 With Conan one build directory corresponds to one configuration. If you want to have e.g. a release and a debug build you need to create two build directories. This is nothing new new to Linux / GCC user but differs to Visual Studios default behavior having just one build-folder / project with different configurations. A typical Visual Studio setup with both Release and Debug configs would be initialized as follows:
 
 ```bash
-$ [assuming you are at the same directory where the source code directory is located]
-$ mkdir ogs-build && cd ogs-build
-$ mkdir debug && cd debug
-$ cmake ../../ogs -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Debug
-$ cd .. && mkdir release && cd release
-$ cmake ../../ogs -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release
+[assuming you are at the same directory where the source code directory is located]
+mkdir ogs-build && cd ogs-build
+mkdir debug && cd debug
+cmake ../../ogs -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Debug
+cd .. && mkdir release && cd release
+cmake ../../ogs -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release
 ```
 
 `..\..\ogs` represents the relative path to the source code (please adapt if you have a different directory layout).
@@ -71,18 +73,19 @@ Please also note that in Visual Studio you have to choose the correct configurat
 CMake can be run from the shell by invoking the cmake command inside a build directory. You can pass any CMake variable or option with `-DVARIABLE_NAME=VALUE` (note the `-D` in front!). You can also pass the generator you want to use (e.g. `Unix Makefiles` or `Visual Studio 15 2017 Win64`-project files) with the `-G` parameter (to see all available generators just run `cmake --help`), although in most cases the appropriate generator will be chosen automatically. The last parameter to the CMake command is the path to the source code directory. A typical call would look like this:
 
 ```bash
-$ cmake -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release ../ogs
+cmake -G "Visual Studio 15 2017 Win64" -DCMAKE_BUILD_TYPE=Release ../ogs
 ```
 
 CMake tries to autodetect your compiler so in most cases this should be enough:
 
 ```bash
-$ cmake ../ogs
+cmake ../ogs
 ```
 
 {{< asciinema url="https://asciinema.org/a/249004" >}}
 
 ::: {.note}
+
 #### <i class="far fa-check"></i> Pro Tip: Use the Visual Studio command line
 
 In the Start menu under *Visual Studio 2017* you find a application link to *x64 Native Tools Command Prompt for VS 2017*. This starts a command line setup for Visual Studio 64-bit. When you run CMake commands in this command line the correct generator will be picked up automatically:
@@ -108,7 +111,7 @@ CMake comes with a graphical tool called **cmake-gui**. You can find it in the *
 A more convenient way of running cmake on the command line is to use the `ccmake` tool. This is a shell tool but with some graphical user interface. To use it just run `ccmake` inside your build directory with the path to the source code (and optionally the generator you want to use) as parameter:
 
 ```bash
-$ ccmake ../ogs
+ccmake ../ogs
 ```
 
 First press <kbd>C</kbd> to **Configure**. You are now presented the available configuration options. You can navigate in the list with the cursor keys and toggle / alter options with <kbd>Enter</kbd>. You may also press <kbd>T</kbd> to toggle (previously hidden) advanced options. Press <kbd>C</kbd> again until the **Generate**-option becomes visible. Press <kbd>G</kbd> to generate the project files and exit `ccmake`.
diff --git a/web/content/docs/devguide/getting-started/build.pandoc b/web/content/docs/devguide/getting-started/build.pandoc
index 86036af8ea0c24a3bcc055e16f2deaa66643d3cc..3170b4be5c2b01d2205a4054c8818aecc3e1b027 100644
--- a/web/content/docs/devguide/getting-started/build.pandoc
+++ b/web/content/docs/devguide/getting-started/build.pandoc
@@ -12,6 +12,7 @@ weight = 1005
 ## Build the project
 
 ::: {.win}
+
 ### Step: Build with Visual Studio
 
 Open the OGS.sln either by double-clicking it in the file browser or opening in Visual Studio via **File / Open / Project**.
@@ -28,19 +29,20 @@ You can work normally in Visual Studio but remember that you have to make projec
 :::
 
 ::: {.linux}
+
 ### Option: Make
 
 To build with the `make` tool on the shell go to your previously created build directory and type `make`:
 
 ```bash
-$ cd build
-$ make
+cd build
+make
 ```
 
 To speedup the compilation process append the number of cores of your cpu to the make command. E.g. for 8 cores:
 
 ```bash
-$ make -j 8
+make -j 8
 ```
 
 {{< asciinema url="https://asciinema.org/a/249005" preload="1" >}}
@@ -50,32 +52,33 @@ $ make -j 8
 To let CMake generate the Eclipse project files change the generator argument to the CMake run:
 
 ```bash
-$ cmake [your configuration options] -G"Eclipse CDT4 - Unix Makefiles" ../sources
+cmake [your configuration options] -G"Eclipse CDT4 - Unix Makefiles" ../sources
 ```
 
 Or with ccmake
 
 ```bash
-$ ccmake -G"Eclipse CDT4 - Unix Makefiles" ../sources
+ccmake -G"Eclipse CDT4 - Unix Makefiles" ../sources
 ```
 
 Start the Eclipse ide. From the menu choose **File / Import**. In the import dialog choose **General / Existing projects into workspace** and click **Next**. In **Select root directory** select your build directory and make sure that **Copy project into workspace** is unchecked. Click **Finish**.
 :::
 
 ::: {.mac}
+
 ### Option: Make
 
 To build with the `make` tool on the shell go to your previously created build directory and type `make`:
 
 ```bash
-$ cd build
-$ make
+cd build
+make
 ```
 
 To speedup the compilation process append the number of cores of your cpu to the make command. E.g. for 8 cores:
 
 ```bash
-$ make -j 8
+make -j 8
 ```
 
 ### Option: Xcode
@@ -83,31 +86,29 @@ $ make -j 8
 To let CMake generate the Xcode project files change the generator argument on the CMake run:
 
 ```bash
-$ cmake [your configuration options] -G Xcode ../sources
+cmake [your configuration options] -G Xcode ../sources
 ```
 
 Or with ccmake
 
 ```bash
-$ ccmake -G Xcode ../sources
+ccmake -G Xcode ../sources
 ```
 
 Then load the generated project file by either clicking the **OGS.xcodeproj** or via
 
 ```bash
-$ open OGS.xcodeproj
+open OGS.xcodeproj
 ```
 
 In Xcode choose `ogs` or `ogs-gui` from the drop-down menu on the top right and then hit the Run-button.
 :::
 
-
 ## Waiting
 
 So now the build process is running... This can take some time because maybe there are external libraries which get automatically downloaded and compiled. This step is only done once per build directory, so subsequent builds will be much faster. See [this]({{< ref "third-party-libraries" >}}) for more.
 
-
-## Finished!
+## Finished
 
 Congratulations you have finished the **Getting Started**-section!
 
diff --git a/web/content/docs/devguide/getting-started/get-the-source-code.pandoc b/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
index 9f1598f62ffd38b21ddf573677d9e19cf3b0c121..623e2c4654145aea313434dee65450e8b2c1698d 100644
--- a/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
+++ b/web/content/docs/devguide/getting-started/get-the-source-code.pandoc
@@ -10,28 +10,27 @@ weight = 1003
 +++
 
 ::: {.note}
+
 ### Attribution
 
 The content of this page is largely taken from the [GitHub-blog](https://github.com/blog/2042-git-2-5-including-multiple-worktrees-and-triangular-workflows).
 :::
 
-
 ## Create a fork
 
 [Create a new fork](https://gitlab.opengeosys.org/ogs/ogs/-/forks/new) from the [official OGS-6 repository](https://gitlab.opengeosys.org/ogs/ogs).
 
 This creates a new fork under your account with the URL `https://gitlab.opengeosys.org/YOUR-USERNAME/ogs`.
 
-
 ## Setup your local clone
 
 You can use the git command line tool to clone the remote repository on GitLab to your PC:
 
 ```bash
-$ git clone --filter=blob:limit=100k git@gitlab.opengeosys.org:YOUR-USERNAME/ogs.git
-$ cd ogs
-$ git config remote.pushdefault origin
-$ git config push.default current
+git clone --filter=blob:limit=100k git@gitlab.opengeosys.org:YOUR-USERNAME/ogs.git
+cd ogs
+git config remote.pushdefault origin
+git config push.default current
 ```
 
 This creates a new folder `ogs` in your current working directory with the OGS source code. After this step, the remote called `origin` refers to your fork on GitLab. It also sets the default remote for pushes to be `origin` and the default push behavior to `current`. Together this means that if you just type `git push`, the current branch is pushed to the `origin` remote.
@@ -43,8 +42,8 @@ The `--filter=blob:limit=100k`-parameter instructs git to only fetch files which
 Create a second remote called `upstream` that points at the main OGS repository and fetch from it:
 
 ```bash
-$ git remote add upstream https://gitlab.opengeosys.org/ogs/ogs.git
-$ git fetch upstream
+git remote add upstream https://gitlab.opengeosys.org/ogs/ogs.git
+git fetch upstream
 ```
 
 <!-- TODO: rerecord with GitLab -->
@@ -74,7 +73,7 @@ You only have to follow the above steps once. From then on, whenever you want to
 Make sure that your local repository is up-to-date with the upstream repository:
 
 ```bash
-$ git fetch upstream
+git fetch upstream
 ```
 
 Create a branch `feature-name` off of upstream `master`-branch to work on a new feature, and check out the branch:
@@ -86,19 +85,19 @@ git checkout -b feature-name upstream/master
 This automatically sets up your local `new-feature`-branch to track the upstream `master`-branch. This means that if more commits are added to `master` upstream, you can merge those commits into your `feature`-branch by typing
 
 ```bash
-$ git pull
+git pull
 ```
 
 or rebase your branch on top of the new master by typing
 
 ```bash
-$ git pull --rebase
+git pull --rebase
 ```
 
 Now after you implemented the feature and committed your work you can push the new commits to the `feature-name`-branch on your GitLab fork:
 
 ```bash
-$ git push
+git push
 ```
 
 If your work is done submit a [merge request](https://gitlab.opengeosys.org/ogs/ogs/-/merge_requests/new).
diff --git a/web/content/docs/devguide/getting-started/prerequisites.pandoc b/web/content/docs/devguide/getting-started/prerequisites.pandoc
index 505f080ea27e6b3e02113ca7029f6f3f1746b040..cf407314f702a29ddb1646982e2f1c9db7a7420f 100644
--- a/web/content/docs/devguide/getting-started/prerequisites.pandoc
+++ b/web/content/docs/devguide/getting-started/prerequisites.pandoc
@@ -24,6 +24,7 @@ The minimum prerequisites to build OGS are:
 ::: {.win}
 
 ::: {.note}
+
 ### Alternative setup
 
 Please note that the following setup on Windows is the **native Windows development setup**. This native setup is **quite involved** and **heavy on system resources**. We can recommend an alternative setup in which the [Windows Subsystem for Linux](https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux) is used: Setup and development of OGS follows the Linux way but you can use your Windows IDE (especially Visual Studio Code) for development and debugging. If this sounds interesting please [follow the steps here]({{< ref "wsl.pandoc" >}})!
@@ -41,7 +42,7 @@ As we use lots of features of the C++17-standard we support **Visual Studio {{<
 On Debian-based (e.g. Ubuntu) you need to install the `build-essential`-package (which contains the `gcc`-compiler and the `make`-tool):
 
 ```bash
-$ sudo apt install build-essential
+sudo apt install build-essential
 ```
 
 You need to have at least **gcc {{< dataFile "versions.minimum_version.gcc" >}}**:
@@ -52,6 +53,7 @@ gcc (GCC) {{< dataFile "versions.minimum_version.gcc" >}}.0
 ```
 
 ::: {.note}
+
 ### Install a newer compiler on Ubuntu
 
 We recommend using Ubuntu {{< dataFile "versions.tested_version.ubuntu" >}} as its standard `gcc` package is already at version 9. If you are on an older Ubuntu version you can install a newer compiler from the `ubuntu-toolchain-r/test`-repository:
@@ -74,6 +76,7 @@ If you do not do this you have to specify the compiler during the first CMake ru
 ```bash
 CC=gcc-9 CXX=c++-9 cmake ../ogs [more CMake options]
 ```
+
 :::
 
 :::
@@ -82,7 +85,7 @@ CC=gcc-9 CXX=c++-9 cmake ../ogs [more CMake options]
 Please install Xcode from the App Store. Then please run the following command in the terminal to install the command line tools:
 
 ```bash
-$ xcode-select --install
+xcode-select --install
 ```
 
 Open Xcode one time to install some other Xcode stuff.
@@ -90,8 +93,8 @@ Open Xcode one time to install some other Xcode stuff.
 Now also install the [Homebrew](http://brew.sh) package manager:
 
 ```bash
-$ /usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
-$ brew doctor
+/usr/bin/ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"
+brew doctor
 ```
 
 The Homebrew package manager is needed for installing other libraries and packages. It is just like a linux package manager.
@@ -111,8 +114,8 @@ This install a new command line called *Git Bash* which should be used for all g
 Let Git know who you are:
 
 ```bash
-$ git config --global user.name "Your Name Here"
-$ git config --global user.email "your_email@example.com"
+git config --global user.name "Your Name Here"
+git config --global user.email "your_email@example.com"
 ```
 
 In some corporate environments you may have to use a proxy server. In this case tell git about it:
@@ -120,6 +123,7 @@ In some corporate environments you may have to use a proxy server. In this case
 ```bash
 git config --global http.proxy http://yourproxy.example.com
 ```
+
 :::
 
 ::: {.linux}
@@ -133,20 +137,20 @@ git version {{< dataFile "versions.minimum_version.git" >}}
 Otherwise please install Git with your favorite package manager:
 
 ```bash
-$ sudo apt-get install git
+sudo apt-get install git
 ```
 
 Let Git know who you are:
 
 ```bash
-$ git config --global user.name "Your Name Here"
-$ git config --global user.email "your_email@example.com"
+git config --global user.name "Your Name Here"
+git config --global user.email "your_email@example.com"
 ```
 
 Optionally enable password storing when interacting with a remote server:
 
 ```bash
-$ git config --global credential.helper store
+git config --global credential.helper store
 ```
 
 In some corporate environments you may have to use a proxy server. In this case tell git about it:
@@ -154,20 +158,21 @@ In some corporate environments you may have to use a proxy server. In this case
 ```bash
 git config --global http.proxy http://yourproxy.example.com
 ```
+
 :::
 
 ::: {.mac}
 Install Git with Homebrew:
 
 ```bash
-$ brew install git
+brew install git
 ```
 
 Let Git know who you are:
 
 ```bash
-$ git config --global user.name "Your Name Here"
-$ git config --global user.email "your_email@example.com"
+git config --global user.name "Your Name Here"
+git config --global user.email "your_email@example.com"
 ```
 
 The [graphical GitHub client](http://mac.github.com/) is also maybe worth a look.
@@ -177,6 +182,7 @@ In some corporate environments you may have to use a proxy server. In this case
 ```bash
 git config --global http.proxy http://yourproxy.example.com
 ```
+
 :::
 
 ## Step: Install Python 3
@@ -209,11 +215,13 @@ Install Python 3 with Homebrew:
 ```bash
 brew install python
 ```
+
 :::
 
 ## Step: Install CMake
 
 ::: {.win}
+
 - Download the installer, at the [CMake download page](http://www.cmake.org/cmake/resources/software.html) choose the **Windows (Win32 Installer)**.
 - Execute the installer, please check the **Add CMake to the system path for all users**-option
 :::
@@ -228,8 +236,9 @@ For other linux distributions you want to use your distributions package manager
 Install CMake with Homebrew:
 
 ```bash
-$ brew install cmake
+brew install cmake
 ```
+
 :::
 
 ## Step: Install Conan package manager
diff --git a/web/content/docs/devguide/testing/test-data.pandoc b/web/content/docs/devguide/testing/test-data.pandoc
index a1ecadb579ab7c356b570613402757a2d0023812..aacb27a3d93cc512e442af5a61946e3ef54aaca9 100644
--- a/web/content/docs/devguide/testing/test-data.pandoc
+++ b/web/content/docs/devguide/testing/test-data.pandoc
@@ -38,4 +38,3 @@ In the OGS-cli outputting to `[build-dir]/Tests/Data` is already handled (via th
 In code `BaseLib::BuildInfo::data_path` (from `BuildInfo.h`) references the data source directory and `BaseLib::BuildInfo::data_binary_path` references the data output directory.
 
 For adding new data files simply commit the new files as usual.
-
diff --git a/web/content/docs/devguide/troubleshooting/conan.pandoc b/web/content/docs/devguide/troubleshooting/conan.pandoc
index 4446f1c43fdee5a82315d42e0b1cb0a4ee13aa89..602e95e133876c30ce62f97863747f2848573a0f 100644
--- a/web/content/docs/devguide/troubleshooting/conan.pandoc
+++ b/web/content/docs/devguide/troubleshooting/conan.pandoc
@@ -32,7 +32,6 @@ Requirements
 
 You can always delete the Conan cache directory in `$HOME/.conan` to start fresh. This can fix errors.
 
-
 ### ERROR: Invalid setting 'X' is not a valid 'settings.compiler.version' value
 
 In `~/.conan/settings.yml` it is defined which compiler versions are supported by Conan on your machine. Unfortunately (and this is also a bit inconvenient) this file is not updated automatically when upgrading Conan. Three possible ways to fix it:
@@ -41,7 +40,7 @@ In `~/.conan/settings.yml` it is defined which compiler versions are supported b
 - simply delete the file, Conan will re-create it on the next run (easiest method)
 - when upgrading Conan it creates a file `~/.conan/settings.new.yml` or similar which you can just rename to `~/.conan/settings.yml`
 
-See also: http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting
+See also: <http://docs.conan.io/en/latest/faq/troubleshooting.html#error-invalid-setting>
 
 ### ERROR: Error in system requirements
 
diff --git a/web/content/docs/tools/fileio/GocadTSurfaceReader/index.pandoc b/web/content/docs/tools/fileio/GocadTSurfaceReader/index.pandoc
index 6dcd5ebe4593e53b905e82bbbe1e36bbfcad2ba8..13f2001fe803a6c4d13218fda8db6b71a96f45a9 100644
--- a/web/content/docs/tools/fileio/GocadTSurfaceReader/index.pandoc
+++ b/web/content/docs/tools/fileio/GocadTSurfaceReader/index.pandoc
@@ -18,7 +18,7 @@ At the moment, this utility can read:
 * PLINE (Polyline)
 * TSURF (Triangulated Surfaces)
 
-Expected file extensions for these data types include *.vs, *.pl, *.ts, and *.mx (the last one for **m**i**x**ed data).
+Expected file extensions for these data types include *.vs,*.pl, *.ts, and*.mx (the last one for **m**i**x**ed data).
 
 Another data type, SGRID (Structured Grid, usually saved to *.sg files) can be converted via the [GoCadSGridReader](../../meshing/gocadsgridreader).
 
@@ -53,10 +53,10 @@ Unless specified otherwise, the utility will convert all datasets and write them
 
 Datasets may have additional scalar data assigned to nodes. If so, this data is also added to the output data.
 
-
 ## Simple example
 
 **Command:**
+
 ```
 GocadTSurfaceReader -i d:\GoCAD_data\Top-Lower_Sandy.ts -o d:\GoCAD_data
 ```
@@ -68,4 +68,3 @@ GocadTSurfaceReader -i d:\GoCAD_data\Top-Lower_Sandy.ts -o d:\GoCAD_data
 **Output:**
 
 ![Converted surface visualised in ParaView with scalar data added to nodes.](./Surface-ParaView.png)
-
diff --git a/web/content/docs/tools/fileio/Mesh2Raster/index.pandoc b/web/content/docs/tools/fileio/Mesh2Raster/index.pandoc
index 5b87f20222315e79c6b1cbf0447ebaf758e259e9..93b9cb190e51cfd880243577e9475033d088296b 100644
--- a/web/content/docs/tools/fileio/Mesh2Raster/index.pandoc
+++ b/web/content/docs/tools/fileio/Mesh2Raster/index.pandoc
@@ -41,6 +41,7 @@ The parameter ```c``` specifies the cell size (i.e. pixel size) of the raster. W
 The input mesh for this example is a homogeneous, unstructured triangle mesh with an average edge length of 100m.
 
 **Command:**
+
 ```
 Mesh2Raster -i input.vtu -o output.asc -c 50
 ```
@@ -49,6 +50,7 @@ Mesh2Raster -i input.vtu -o output.asc -c 50
 The generated output raster has a size of 340x333 pixels and represents the original surface well. Given the average edge length of 100m in the original mesh, an even smaller cellsize would not have contained more details but resulted in a larger file size.[^1]
 
 **Command:**
+
 ```
 Mesh2Raster -i input.vtu -o output.asc -c 200
 ```
@@ -57,6 +59,7 @@ Mesh2Raster -i input.vtu -o output.asc -c 200
 The generated output raster has a size of 85x84 pixels and still represents the original surface reasonably well, despite visible undersampling.
 
 **Command:**
+
 ```
 Mesh2Raster -i input.vtu -o output.asc -c 1000
 ```
diff --git a/web/content/docs/tools/fileio/Mesh2Shape/index.pandoc b/web/content/docs/tools/fileio/Mesh2Shape/index.pandoc
index 97435116c79bfeed119fb7d16037c9422bc218a2..6562d24b0a4bb5d598c813edab6f2435574e535d 100644
--- a/web/content/docs/tools/fileio/Mesh2Shape/index.pandoc
+++ b/web/content/docs/tools/fileio/Mesh2Shape/index.pandoc
@@ -35,6 +35,7 @@ Where:
 2D surface mesh with scalar data assigned to cells, here displayed via the OGS Data Explorer. In this particular case, the simulation result of groundwater flow simulation (originally assigned to mesh nodes) has been converted onto cells via VTK's PointToCell-Filter.
 
 **Command:**
+
 ```
 Mesh2Shape -i Mueglitz2D_Point2Cell.vtu -o Mueglitz2D_Point2Cell.shp
 ```
@@ -42,11 +43,9 @@ Mesh2Shape -i Mueglitz2D_Point2Cell.vtu -o Mueglitz2D_Point2Cell.shp
 ![](./Mesh2Shape-output1.png){ width=66% }
 Exported shapefile displayed in a geographic information system (here, QGIS).
 
-
 ![](./Mesh2Shape-output2.png)
 The result of an OGS-simulation showing the groundwater head of the Müglitz-catchment imported into QGIS and combined with other data from an existing GIS-project of this region.
 
-
 ## Application
 
 The utility allows to export meshes, and in particular simulation results, into existing GIS-projects and use the data as input for subsequent workflows.
diff --git a/web/content/docs/tools/fileio/TecPlotTools/index.pandoc b/web/content/docs/tools/fileio/TecPlotTools/index.pandoc
index 1d6795a66b7c7a82b4de240b68aeaf99eb01e0e5..e8adb2bc606760779eea381054e6f0dd58fe8589 100644
--- a/web/content/docs/tools/fileio/TecPlotTools/index.pandoc
+++ b/web/content/docs/tools/fileio/TecPlotTools/index.pandoc
@@ -38,6 +38,7 @@ Where:
 ## Simple example
 
 **Command:**
+
 ```
 TecPlotTools -i Lake.plt -o Lake.vtu -c
 ```
@@ -49,4 +50,3 @@ TecPlotTools -i Lake.plt -o Lake.vtu -c
 **Output:**
 
 ![Converted file visualised in ParaView with all scalar data available.](./PoyangLake-ParaView.png)
-
diff --git a/web/content/docs/tools/getting-started/first_steps/index.pandoc b/web/content/docs/tools/getting-started/first_steps/index.pandoc
index 08195fb206a6fd3e51da1dab8bd330ca80e8261f..dbd9cbf50329abb6eed9e72a160e54065c6ffabc 100644
--- a/web/content/docs/tools/getting-started/first_steps/index.pandoc
+++ b/web/content/docs/tools/getting-started/first_steps/index.pandoc
@@ -24,4 +24,3 @@ To use a mesh created by SALOME it must be converted to the GMSH file format fir
 To extract a surface mesh (in order to define appropriate boundary conditions) one can use the tool [ExtractSurface]({{< ref "extract-surface" >}}) for different kinds of 3D meshes. If you are using a different tool (e.g. paraview), keep in mind that the dimensions of the boundary mesh need to be `d-1`, where `d` is the dimension of the bulk mesh (i.e. `connectivity`, `offsets` and `types` cell properties need to be set correctly in the unstructured grid file).
 
 Finally, the subdomains need to be identified. This can be done by the tool [identifySubdomains]({{< ref "identifySubdomains" >}}) which is also part of the official [OpenGeoSys git repository](https://github.com/ufz/ogs).
-
diff --git a/web/content/docs/tools/meshing-submeshes/constructMeshesFromGeometry/index.pandoc b/web/content/docs/tools/meshing-submeshes/constructMeshesFromGeometry/index.pandoc
index b89a3f332a39cb6d5c6256173edb3561d82591e3..2bca966724ec376bd2925d3d02206e6472ba13a1 100644
--- a/web/content/docs/tools/meshing-submeshes/constructMeshesFromGeometry/index.pandoc
+++ b/web/content/docs/tools/meshing-submeshes/constructMeshesFromGeometry/index.pandoc
@@ -21,6 +21,7 @@ ids mappings to the bulk mesh.
 
 For example a conversion of a mesh from `Tests/Data/LIE/Hydromechanics` single
 fracture 3D project:
+
 ```
 constructMeshesFromGeometry -m single_fracture_3D.vtu -g single_fracture_3D.gml
 
@@ -44,6 +45,7 @@ debug: Found 25 elements in the mesh
 debug: Creating mesh from geometry single_fracture_3D top.
 debug: Found 25 elements in the mesh
 ```
+
 yields new meshes for each named geometry: `single_fracture_3D_inlet.vtu`,
 `single_fracture_3D_right.vtu`, `single_fracture_3D_outlet.vtu`,
 `single_fracture_3D_left.vtu`, `single_fracture_3D_front.vtu`,
diff --git a/web/content/docs/tools/meshing-submeshes/extract-surface/index.pandoc b/web/content/docs/tools/meshing-submeshes/extract-surface/index.pandoc
index 2d1779c8053496071bbea96e566b5b6025bd8961..2658e7abbbd9772577c2f8764d4a33d2e75aa591 100644
--- a/web/content/docs/tools/meshing-submeshes/extract-surface/index.pandoc
+++ b/web/content/docs/tools/meshing-submeshes/extract-surface/index.pandoc
@@ -16,8 +16,8 @@ The tool extracts 2d surface elements of a mesh given either in the vtu or msh f
 
 ```
 ExtractSurface -i [<file name of input mesh>] [-o <file name of output mesh>]
-	[-x <floating point value>] [-y <floating point value>] [-z <floating point value>]
-	[-a <floating point value>]
+ [-x <floating point value>] [-y <floating point value>] [-z <floating point value>]
+ [-a <floating point value>]
     [--face-property-name <string>]
     [--element-property-name <string>]
     [--node-property-name <string>]
@@ -30,6 +30,7 @@ The normal of the surface that should be extracted is given by the arguments `-x
 ![](TopBottomSideSurface.png)
 
 Extracted top, bottom and side surfaces:
+
 - top `ExtractSurface -i Input.vtu -o TopSurface.vtu`
 - bottom `ExtractSurface -i Input.vtu -o BottomSurface.vtu -x 0 -y 0 -z 1`
 - side `ExtractSurface -i Input.vtu -o SideSurface.vtu -x 1 -y 1 -z 0 -a 45`
diff --git a/web/content/docs/tools/meshing-submeshes/identifySubdomains/index.pandoc b/web/content/docs/tools/meshing-submeshes/identifySubdomains/index.pandoc
index 2aba8157136d386a7c9eb5bce6e1126dff994fd3..b21e1de44b16d7371c469f038602c0e7bbba29b5 100644
--- a/web/content/docs/tools/meshing-submeshes/identifySubdomains/index.pandoc
+++ b/web/content/docs/tools/meshing-submeshes/identifySubdomains/index.pandoc
@@ -29,10 +29,12 @@ points.](disc_with_hole_and_bondary.png){width=50%}
 </center>
 
 To create this mappings we run
+
 ```
 identifySubdomains -m Tests/Data/Mechanics/Linear/disc_with_hole.vtu -s 1e-6 -o
 new_ -- quater_circle.vtu
 ```
+
 The tool will first try to find all unique nodes in the "bulk" mesh using search
 radius 1e-6, and create the `bulk_node_ids` mapping upon success. Then the
 `bulk_element_ids` mapping is created by finding a unique element containing all
@@ -42,10 +44,12 @@ mappings and is prepared for usage as a boundary condition mesh.
 
 ## Notes
 
- - The double dash is separating the subdomain meshes, so the input can have
+- The double dash is separating the subdomain meshes, so the input can have
    multiple subdomain inputs:
+
    ```
    identifySubdomains -m bulk.vtu -- bc1.vtu bc2.vtu source_term_meshes*.vtu
    ```
- - The output prefix `-o` can contain a path too and is relative to the current
+
+- The output prefix `-o` can contain a path too and is relative to the current
    working directory.
diff --git a/web/content/docs/tools/meshing-submeshes/submeshes/index.pandoc b/web/content/docs/tools/meshing-submeshes/submeshes/index.pandoc
index 79025677e3528f5514c4f86799c054c1e5909eb7..031e3e39ea4f430b2071186d5b10670bdbd0d11b 100644
--- a/web/content/docs/tools/meshing-submeshes/submeshes/index.pandoc
+++ b/web/content/docs/tools/meshing-submeshes/submeshes/index.pandoc
@@ -45,4 +45,3 @@ shows the bulk mesh and the id's of the nodes on the top of it. Furthermore,
 the translated top surface mesh with the corresponding bulk node id's are
 represented.
 ![](03_bulk_mesh_with_ids_top_surface_bulk_node_ids.png)
-
diff --git a/web/content/docs/tools/meshing/addlayer/index.pandoc b/web/content/docs/tools/meshing/addlayer/index.pandoc
index e85afe5e5c17935ba0b7d79f51a592b17a2dbe56..ce0f8011fba06a5225cc7f87fc13dbda5d60a5e4 100644
--- a/web/content/docs/tools/meshing/addlayer/index.pandoc
+++ b/web/content/docs/tools/meshing/addlayer/index.pandoc
@@ -35,6 +35,7 @@ AddLayer -i <input-mesh> -o <output-mesh> [-t <thickness>]
 *Left*: A simple cube mesh with one material group (red). *Right*: The updated mesh where an additional layer (blue) was added on top of the domain with a second material group.
 
 Usage for example:
+
 ```
 AddLayer -i quad.vtu -o quad_with_new_top_layer.vtu -t 1
 ```
diff --git a/web/content/docs/tools/meshing/gocadsgridreader/index.pandoc b/web/content/docs/tools/meshing/gocadsgridreader/index.pandoc
index 561fda84283ff5eea3a3f7b0ba4c732c5932ead6..6acca3860521bde77dbfb420e5256ae316f5d6fe 100644
--- a/web/content/docs/tools/meshing/gocadsgridreader/index.pandoc
+++ b/web/content/docs/tools/meshing/gocadsgridreader/index.pandoc
@@ -21,6 +21,7 @@ and is build when the `OGS_BUILD_UTILS` cmake switch is set `ON`. The build
 executable `GocadSGridReader` is placed in the `bin` directory. The tool is a command line tool.
 
 ## Usage
+
 Running `GocadSGridReader` tool will print the required arguments and a short usage message; for detailed usage add the `--help` argument.
 
 ```bash
@@ -44,6 +45,7 @@ Where:
 ```
 GocadSGridReader -s flow_simulation_grid_klein_Rinne.sg -o flow_simulation_grid_klein_Rinne.vtu
 ```
+
 ![](flow_simulation_klein_Grid_Rinne.png)
 
 ## Applications
diff --git a/web/content/docs/tools/meshing/remove-mesh-elements/index.pandoc b/web/content/docs/tools/meshing/remove-mesh-elements/index.pandoc
index cd39ba83033ac4a2e87987c4dde23841146374a8..617206c62715a090628376658f4c92c8a7dccf0f 100644
--- a/web/content/docs/tools/meshing/remove-mesh-elements/index.pandoc
+++ b/web/content/docs/tools/meshing/remove-mesh-elements/index.pandoc
@@ -11,6 +11,7 @@ author = "Thomas Fischer"
 ## General
 
 The tool `removeMeshElements` removes those elements from a given input mesh that fulfills a user specified criterion. The resulting mesh will be written to the specified output file. The user can choose between 4 different removal criterions:
+
  1. Remove elements by assigned properties, for instance material ids.
  2. Remove elements by element type, for instance remove line elements.
  3. Remove elements that have zero volume.
@@ -24,11 +25,12 @@ Another application is to cut out patches of a (top) surface (tool [ExtractSurfa
 
 ```
 removeMeshElements -i <input-mesh> -o <output-mesh>
-	[-n <property_name>] [--int-property-value <number value>] ...
-	[--element-type <element type>] ...
-	[--zero-volume]
+ [-n <property_name>] [--int-property-value <number value>] ...
+ [--element-type <element type>] ...
+ [--zero-volume]
     [--x-min <value>] [--x-max <value>] [--y-min <value>] [--y-max <value>] [--z-min <value>] [--z-max <value>]
 ```
+
 Each particular line with optional arguments refers to one of the different removal criteria mentioned in the general section.
 The corresponding element types differ from vtk cell types and can be found in MeshLib/MeshEnums.cpp.
 
@@ -38,6 +40,7 @@ The corresponding element types differ from vtk cell types and can be found in M
 ![](ExampleRemoveElements-Output.png)
 
 The left figure above is the result of the repeated application of [SetPropertiesInPolygonalRegion]({{< ref "set-properties-in-polygonal-region" >}}). It contains material ids 0 (red), 1 (yellow), 2 (turquoise) and 3 (blue). On the right figure the result of the following command line input is depicted:
+
 ```
 removeMeshElements -i TestCube-ResetPropertiesInPolygonalRegion.vtu -o TestCube-removeMeshElements.vtu -n MaterialIDs --int-property-value 1 --int-property-value 2 --int-property-value 3
 ```
@@ -47,7 +50,9 @@ removeMeshElements -i TestCube-ResetPropertiesInPolygonalRegion.vtu -o TestCube-
 The tool was used to cut the Unstrut catchment out of the Thuringian syncline model and to remove some geological units not necessary for the modeling within the INFLUINS project, see reference [GO2OGS].
 
 ::: {.note}
+
 ### Example Files
+
 [TestCube-removeMeshElements.vtu](TestCube-removeMeshElements.vtu)  
 [TestCube-ResetPropertiesInPolygonalRegion](TestCube-ResetPropertiesInPolygonalRegion.vtu)  
 :::
diff --git a/web/content/docs/tools/meshing/structured-mesh-generation/index.pandoc b/web/content/docs/tools/meshing/structured-mesh-generation/index.pandoc
index 09efae3519bf3e59e31a9f806c81819dabda4bd9..13c536154ddf970b1c795dbd7a3d8fc8add92b7c 100644
--- a/web/content/docs/tools/meshing/structured-mesh-generation/index.pandoc
+++ b/web/content/docs/tools/meshing/structured-mesh-generation/index.pandoc
@@ -15,6 +15,7 @@ Generation of simple meshes in all dimensions can be accomplished with following
 The mesh generation tools are build when the `OGS_BUILD_UTILS` cmake switch is set `ON`. The build executable `generateStructuredMesh` is placed in the `bin` directory. The tool is a command line tool.
 
 Running `generateStructuredMesh` tool will print the required arguments and a short usage message; for detailed usage add the `--help` argument.
+
 ```bash
 > bin/generateStructuredMesh --help ⏎
 ```
@@ -23,13 +24,15 @@ To generate a mesh two arguments are required: file name for the resulting mesh,
 
 ## Examples
 
- - To generate a simple 2-dimensional mesh measuring 3 by 4 length units call
+- To generate a simple 2-dimensional mesh measuring 3 by 4 length units call
+
 ```
 > bin/generateStructuredMesh -o quad_3x4.vtu -e quad --lx 3 --ly 4 ⏎
 info: Mesh created: 20 nodes, 12 elements
 ```
 
- - To generate a simple 3-dimensional mesh measuring 4 by 5 by 6 length units call
+- To generate a simple 3-dimensional mesh measuring 4 by 5 by 6 length units call
+
 ```
 > bin/generateStructuredMesh -o hex_4x5x6.vtu -e hex --lx 4 --ly 5 --lz 6 ⏎
 info: Mesh created: 210 nodes, 120 elements.
@@ -44,13 +47,15 @@ info: Mesh created: 210 nodes, 120 elements.
 Depending on the file ending `.msh` or `.vtu` either a legacy OGS5 mesh file or VTK unstructured grid file is generated. Unsupported file endings will result in an error.
 
 ### Mesh element type `-e <line|tri|quad|hex|tet>`
- - Line elements are available for the 1-dimensional meshes.
- - Quad (and triangle) elements are available for the 2-dimensional meshes. The triangle meshes will be constructed from the quad meshes by dividing each of the quad elements into two triangle elements.
- - Hex and tetrahedron elements are available for the 3-dimensional meshes.
+
+- Line elements are available for the 1-dimensional meshes.
+- Quad (and triangle) elements are available for the 2-dimensional meshes. The triangle meshes will be constructed from the quad meshes by dividing each of the quad elements into two triangle elements.
+- Hex and tetrahedron elements are available for the 3-dimensional meshes.
 
 __Note:__ The generated FEM elements will be all of the first order corresponding to Line1, Tri3/Quad4, Hex8, Tet4, Prism6, and Pyramid5.
 
 ### Lengths `--lx`, `--ly`, `--lz`
+
 The mesh lengths for each direction can be specified. If not given in `--dx*` arguments the default elements' lengths are 1. The last element in the corresponding direction can be of different size if the ratio of mesh's length in that direction to element's length in the same direction is not an integer.
 
 The parameters must be positive real numbers.
@@ -65,7 +70,6 @@ _Note:_ This parameter overrides any specifications given with `--dx*` arguments
 
 The parameters must be positive integers.
 
-
 ### Element length  `--dx0`, `--dy0`, `--dz0`
 
 Another possibility to control the number of generated elements is to specify the elements' lengths in each direction. All of the elements will be of given size (if not overridden by `--n*` or `--m*` arguments) but the last (in each direction), which can be of different size to close the gap to the given mesh length, _i.e._ if for example the ratio `--lx` over `--dx0` is not an integer.
@@ -75,7 +79,9 @@ _Note:_ This parameter is overridden by the `--n*` parameters, or by `--d*-max`
 The parameters must be positive real numbers
 
 ### Example
+
 Hexahedral mesh as above but with 10 elements in y-direction and element length of 1.5 in z-direction:
+
 ```
 > bin/generateStructuredMesh -o hex_4x5x6.vtu -e hex --lx 4 --ly 5 --lz 6 --ny 10 --dz0 1.5 ⏎
 info: Mesh created: 275 nodes, 160 elements.
@@ -100,10 +106,8 @@ l_{i+1} &= 0.1 \cdot 2^i = 0.2, 0.4, 0.8, \text{\ldots,}
 }
 $$
 
-
 The parameters must be positive real numbers
 
-
 ### Maximum element length  `--dx-max`, `--dy-max`, `--dz-max`
 
 To limit fast growing element lengths the maximum element length can be used. After the elements' length reached given maximum value the growth stops and the maximum value is used until the specified mesh length in that direction is reached.
@@ -111,10 +115,12 @@ To limit fast growing element lengths the maximum element length can be used. Af
 The parameters must be positive real numbers
 
 ### Example
+
 Hexahedral mesh as above but with three different non-uniform mesh refinements:
- - x-direction: Element shrinking (growth factor < 1) starting with default element length 1.
- - y-direction: Element growth (factor 1.1) starting with specified element length 0.1.
- - z-direction: Fast element growth (factor 2) starting with specified element length 0.1 and limited by maximum length 1. (The last element is larger than maximum because of the gap to be filled for the given mesh length as described in uniform-mesh refinement section.)
+
+- x-direction: Element shrinking (growth factor < 1) starting with default element length 1.
+- y-direction: Element growth (factor 1.1) starting with specified element length 0.1.
+- z-direction: Fast element growth (factor 2) starting with specified element length 0.1 and limited by maximum length 1. (The last element is larger than maximum because of the gap to be filled for the given mesh length as described in uniform-mesh refinement section.)
 
 ```
 bin/generateStructuredMesh -o hex_4x5x6.vtu -e hex --lx 4 --ly 5 --lz 6 --mx 0.8 --my 1.1 --dy0 0.1 --mz 2 --dz-max 1 --dz0 0.1 ⏎
diff --git a/web/content/docs/tools/meshing/vtu2grid/index.pandoc b/web/content/docs/tools/meshing/vtu2grid/index.pandoc
index abbdc26ba5ef5a3cc363ff31e4c32044b2008b9e..fa080fff92ccb14b7df01c71b41ff1dd4502d61e 100644
--- a/web/content/docs/tools/meshing/vtu2grid/index.pandoc
+++ b/web/content/docs/tools/meshing/vtu2grid/index.pandoc
@@ -45,30 +45,38 @@ The ```x```/```y```/```z```-parameters determine the raster size. If only ```x``
 Original, unstructured grid consisting of 217,128 prism-elements. The subsurface represented by this mesh consists of a number of layers of very different thickness. The very thin layers at the top (reddish tones) and in the middle (green and cyan tones) are particularly difficult to handle during numerical simulation.
 
 **Command:**
+
 ```
 Vtu2Grid -i input.vtu -o output.vtu -x 200
 ```
+
 ![](./vtu2grid-200.png){ width=66% }
 Rasterised grid consisting of 9,240 cubes (equilateral hexahedral elements with an edge length of 200m). The result is severely undersampled and a continuous layer structure is no longer visible.
 
 **Command:**
+
 ```
 Vtu2Grid -i input.vtu -o output.vtu -x 100
 ```
+
 ![](./vtu2grid-100.png){ width=66% }
 Rasterised grid consisting of 74,048 equilateral hexahedral elements with an edge length of 100m. The result is still undersampled but layers become already visible.
 
 **Command:**
+
 ```
 Vtu2Grid -i input.vtu -o output.vtu -x 50
 ```
+
 ![](./vtu2grid-50.png){ width=66% }
 Rasterised grid consisting of 591,757 equilateral hexahedral elements with an edge length of 50m. There's still undersampling in regions containing thin layers but the overall structure is reasonably well represented.
 
 **Command:**
+
 ```
 Vtu2Grid -i input.vtu -o output.vtu -x 50 -y 50 -z 10
 ```
+
 ![](./vtu2grid-50x50x10.png){ width=66% }
 Rasterised grid consisting of 2,959,656 cuboid hexahedral elements with an edge length of 50m x 50m x 10m. The structure of the original mesh is very well represented while the number of elements has increased by an order of magnitude.
 
diff --git a/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.pandoc b/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.pandoc
index 2211e559b5fe684d1fe7d3a832eea86175e4167d..823fdd7b573a8bf1436ce439b465cec10ef058ce 100644
--- a/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.pandoc
+++ b/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.pandoc
@@ -19,6 +19,7 @@ ComputeNodeAreasFromSurfaceMesh -i <file name of input mesh>
     [-p <output path and base name as one string>]
     [--id-prop-name <property name>]
 ```
+
 If the option `-p` is not given the output path is extracted from the input path. The default value for the `--id-prop-name` argument is "bulk_node_ids". This name is also used by [ExtractSurface]({{< ref "extract-surface" >}}) for storing the subsurface node ids.
 
 ## Example
@@ -26,6 +27,7 @@ If the option `-p` is not given the output path is extracted from the input path
 ![](ExampleComputeSurfaceNodeAreasFromSurfaceMesh.png)
 
 The following steps were performed to obtain the example data:
+
  1. The hexahedral example domain was created by [generateStructuredMesh]({{< ref "structured-mesh-generation">}}) `generateStructuredMesh -o hex_6x7x3.vtu -e hex --lx 6 --ly 7 --lz 3`.
  2. The tool [ExtractSurface]({{< ref "extract-surface" >}}) was applied:
  `ExtractSurface -i hex_6x7x3.vtu -o hex_6x7x3_surface.vtu`
diff --git a/web/content/docs/tools/model-preparation/convert-data-array-to-data-array/index.pandoc b/web/content/docs/tools/model-preparation/convert-data-array-to-data-array/index.pandoc
index 607a90d372df48ef8354320db6bd29ab15853235..045aefb13de0d4452bfa2d340f332b4b7ef20af3 100644
--- a/web/content/docs/tools/model-preparation/convert-data-array-to-data-array/index.pandoc
+++ b/web/content/docs/tools/model-preparation/convert-data-array-to-data-array/index.pandoc
@@ -47,6 +47,8 @@ convertVtkDataArrayToVtkDataArray
 ```
 
 ::: {.note}
+
 ### Example Files
+
 [doubleValuedMaterialIDs.vtu](doubleValuedMaterialIDs.vtu)
 :::
diff --git a/web/content/docs/tools/model-preparation/map-geometric-object-to-the-surface-of-a-mesh/index.pandoc b/web/content/docs/tools/model-preparation/map-geometric-object-to-the-surface-of-a-mesh/index.pandoc
index bca78bbde90ff9a9678fbf89cea66995ee009a80..3f966d545da6111d99a143d27b8eb797089de54f 100644
--- a/web/content/docs/tools/model-preparation/map-geometric-object-to-the-surface-of-a-mesh/index.pandoc
+++ b/web/content/docs/tools/model-preparation/map-geometric-object-to-the-surface-of-a-mesh/index.pandoc
@@ -34,6 +34,7 @@ Often, the mesh resolution and the resolution of the geometric objects like poly
 In the first figure such a situation is depicted. In the second figure the result of the application of the algorithm is shown.
 
 Usage for the example:
+
 ```
 MapGeometryToMeshSurface -m SubsurfaceMesh.vtu -i TestPolyline.gml -o TestMappedPolyline.gml
 ```
@@ -46,7 +47,9 @@ DOI:10.1007/s12665-013-2970-2 [download](http://link.springer.com/article/10.100
 *MW: the citation is not used in the description*
 
 ::: {.note}
+
 ### Example Files
+
 [SubsurfaceMesh.vtu](SubsurfaceMesh.vtu)  
 [TestPolyline.gml](TestPolyline.gml)  
 :::
diff --git a/web/content/docs/tools/model-preparation/set-properties-in-polygonal-region/index.pandoc b/web/content/docs/tools/model-preparation/set-properties-in-polygonal-region/index.pandoc
index afa6304a06da6c1057e6cb03e34e14073c131125..1dfe645a14868ad39a36173649d87564392ed283 100644
--- a/web/content/docs/tools/model-preparation/set-properties-in-polygonal-region/index.pandoc
+++ b/web/content/docs/tools/model-preparation/set-properties-in-polygonal-region/index.pandoc
@@ -47,6 +47,7 @@ The first figure shows the input mesh with the material ID 0 (red). Furthermore,
 The second figure shows the result. The material ids for the mesh cells have at least one node within the polygonal region changed to the value 1 and are colored now in blue.
 
 Example usage:
+
 ```
 ResetPropertiesInPolygonalRegion
     -m TestCube.vtu
@@ -56,6 +57,7 @@ ResetPropertiesInPolygonalRegion
     -p Back
     -o TestCube-BackPolylinePropertyChange.vtu
 ```
+
 Creates a new property "ValidCells" and sets the value for the property of elements in the polygonal region "Back" to "B".
 
 ### Second Example
@@ -66,6 +68,7 @@ The left figure shows the input mesh (transparent) with the original 10 layers
 symbolized by the different colours. At the bottom of the cube two regions are
 depicted by their bounding polygons. The intermediated mesh in the middle figure
 was generated by the following command:
+
 ```
 ResetPropertiesInPolygonalRegion
     -m hex_5x5x5.vtu
@@ -76,10 +79,12 @@ ResetPropertiesInPolygonalRegion
     -r 2
     -o hex_5x5x5_Region1-Layer1.vtu
 ```
+
 Here the elements with material ids 11 are displayed non-transparent.
 
 The final mesh containing 12 material groups is represented in the right figure
 and was created by the command
+
 ```
 ResetPropertiesInPolygonalRegion
     -m hex_5x5x5_Region1-Layer2.vtu
@@ -90,6 +95,7 @@ ResetPropertiesInPolygonalRegion
     -r 5
     -o hex_5x5x5_Region1-Layer2_Region2-Layer5.vtu
 ```
+
 Again, the elements that are assigned to the new material group 12 are displayed
 non-transparent.
 
@@ -103,7 +109,9 @@ This workflow was successful used in the INFLUINS project cutting out the Unstru
 {{< bib "fischer:2015" >}}
 
 ::: {.note}
+
 ### Example Files
+
 - [TestCube.vtu](TestCube.vtu)
 - [TestPolylines.gml](TestPolylines.gml)
 - [hex_5x5x5.vtu](hex_5x5x5.vtu)
diff --git a/web/content/docs/tools/preprocessing/createIntermediateRasters/index.pandoc b/web/content/docs/tools/preprocessing/createIntermediateRasters/index.pandoc
index f109e314a3b846939f66caa3a7e55a0b04773f9b..5890860d957acd60f3f2d476f7127bc03f86de30 100644
--- a/web/content/docs/tools/preprocessing/createIntermediateRasters/index.pandoc
+++ b/web/content/docs/tools/preprocessing/createIntermediateRasters/index.pandoc
@@ -43,6 +43,7 @@ The parameter ```n``` determines how many layers are created between the two inp
 Two input rasters as well as their 3D surface representation. Darker pixels represent values at a lower elevation while brighter pixels represent higher elevaton. In the 3D visualisation, the left-most raster is represented by the green surface and the right-most raster by the yellow surface.
 
 **Command:**
+
 ```
 createIntermediateRasters --file1 raster1.asc --file2 raster2.asc -o output.asc -n 1
 ```
@@ -51,6 +52,7 @@ createIntermediateRasters --file1 raster1.asc --file2 raster2.asc -o output.asc
 A new raster is created in the exact center between the two input rasters. In the 3D representation, the new layer is shown in red.
 
 **Command:**
+
 ```
 createIntermediateRasters --file1 raster1.asc --file2 raster2.asc -o output.asc -n 2
 ```
diff --git a/web/content/docs/tools/workflows/Example-of-a-DGM-to-model-workflow/index.pandoc b/web/content/docs/tools/workflows/Example-of-a-DGM-to-model-workflow/index.pandoc
index 0722992a655c201948a5451d82b8d72d5c1f86e4..e2f3f31c07bfae853f968ac614fa03cae33de3c8 100644
--- a/web/content/docs/tools/workflows/Example-of-a-DGM-to-model-workflow/index.pandoc
+++ b/web/content/docs/tools/workflows/Example-of-a-DGM-to-model-workflow/index.pandoc
@@ -12,123 +12,117 @@ author = "Marc Walther"
 
 This documentation describes an exemplified workflow to create a groundwater flow model based on available data of a digital elevation model (here [SRTM data](https://earthexplorer.usgs.gov/)) and bathymetry data (here [GPDN](https://www.gpdn.de/?pgId=219)). As tools, it uses a GIS (here [QGIS](https://www.qgis.org)), the OGS DataExplorer and several [OGS tools](https://www.opengeosys.org/docs/tools/), as well as the meshing tool [GMSH](http://gmsh.info) and visualization tool [ParaView](http://www.paraview.org). The first part of this documentation deals with the GIS work, the second with the OGS model setup.
 
-
 ## GIS data preparation and extraction
 
 This part will prepare the DGM and bathymetry data as input for the model setup. For all the QGIS editing steps, you may additionally define an output file (but this is no requirement); if this is not defined, QGIS will load the results into the active project.
 
-
 ### Prepare elevation data
 
 1. It is likely that you will need to download more than one remote sensing image when the study area is large or overlapping the borders of one section. Download the required DGM data (here `.tif` files) of the study area and load them into QGIS.
 
-	![Load DGM tifs](01_load-tifs.png)
+ ![Load DGM tifs](01_load-tifs.png)
 
 2. Merge the images with `Raster` -> `Miscellaneous` -> `Merge...`; select the `Input Layer`s.
 
-	![Merge multiple DGM tifs](02_merge-DEMs.png)
+ ![Merge multiple DGM tifs](02_merge-DEMs.png)
 
 3. Extract a subregion of the (merged) DGMs and define the study area through a shape file. One may also use a predefined shape file and continue with step 5. Choose `New Shapefile Layer...` from the toolbar and enter a `File name` and a projection.
 
-	![Create clipping shape](03_create-shp-for-clipping.png)
+ ![Create clipping shape](03_create-shp-for-clipping.png)
 
 4. Edit the shape (`Toggle Editing` in toolbar), add points, and save the layer edits.
 
-	![Save layer edits](04_edit-save-new-polygon.png)
+ ![Save layer edits](04_edit-save-new-polygon.png)
 
 5. Clip the DGM with the shape file with `Raster` -> `Extraction` -> `Clip Raster by Mask Layer...`; define `Input Layer` and `Mask layer`, and assign the `Nodata value`.
 
-	![Clip DGM with shape](05_clip.png)
+ ![Clip DGM with shape](05_clip.png)
 
 6. If the raster does not have the correct projection, you will have to reproject it with the appropriate target system with `Raster` -> `Projections` -> `Warp (Reproject)`; select the `Input Layer` and the `Target CRS`.
 
-	![Reprojection](06_reproject-raster.png)
+ ![Reprojection](06_reproject-raster.png)
 
 7. This example also includes bathymetry data, which was available as vector data (isoline in a shape file). This file must be reprojected to the same coordinate system as the raster before with `Vector` -> `Data Management Tools` -> `Reproject Layer`; select `Input Layer` and the `Target CRS`.
 
-	![Reproject shape bathymetry data](07_reproject-vector-layers.png)
+ ![Reproject shape bathymetry data](07_reproject-vector-layers.png)
 
 8. Before merging DGM and bathymetry, the shape data needs to be converted to raster data with `Raster` -> `Conversion` -> `Rasterize (Vector to Raster)`; define `Input Layer`, the z-value (`burn-in value`), the resolutions, and the `nodata value`.
 
-	![Rasterize vector data](08_vector-to-raster.png)
+ ![Rasterize vector data](08_vector-to-raster.png)
 
 9. As bathymetry was given as "depth", this parameter needs to be converted to an "elevation"; use `Raster` -> `Raster Calculator` and define the `Output layer`, the `Output format` and the `Raster Calculator Expression` (shown formula only inverts the sign).
 
-	![Depth to elevation with the raster calculator](09_bathymetry-depth-to-elev.png)
+ ![Depth to elevation with the raster calculator](09_bathymetry-depth-to-elev.png)
 
 10. Merge the DGM and bathymetry rasters (as done in step 2), and save the merged file as a `.asc` file with `Raster` -> `Conversion` -> `Translate (Convert Format)`; define the `Input Layer` and the `Converted` output file.
 
-	![Convert to .asc format](10_save-asc.png)
-
+ ![Convert to .asc format](10_save-asc.png)
 
 ### Prepare study area features
 
 11. To make the coastline part of the mesh, the merged DGM-bathymetry will be used to create a contour isoline at an elevation of `0.01 m` with `Extraction` -> `Contour...`; select the `Input Layer`, set the `Interval between contour lines` to a high value and set the `Offset from zero`.
 
-	![Raster to contour](11_contour-for-coastline.png)
+ ![Raster to contour](11_contour-for-coastline.png)
 
 12. If more than the `0.01 m` contour is present in the new shape file, remove the not required contours by right-clicking the new shape file and `Open Attribute Table`; click `Select features using an expression` and define the contours based on your liking that you want to exclude (here, anything with an elevation larger than 1 is removed).
 
-	![Select features](12_select-non-coast.png)
+ ![Select features](12_select-non-coast.png)
 
 13. Finish the selection (close attribute table) and remove the selected features by editing the shape (`Toggle Editing`) and clicking `Delete Selected`; save the changes.
 
-	![Remove selected features](13_remove-non-coast.png)
+ ![Remove selected features](13_remove-non-coast.png)
 
 14. The remaining features may be too highly resoluted (see red line in below figure); choose `Vector` -> `Geometry Tools` -> `Simplify...`, and select an `Input Layer` as well as the `Simplification method` with an appropriate `Tolerance`.
 
-	![Simplify extracted coastline](14_simplify-coast.png)
+ ![Simplify extracted coastline](14_simplify-coast.png)
 
 15. Further, it might be useful to manually remove even more vertices from the polygon; `Toggle Editing` of the simplified shape and select and remove vertices.
 
- 	![Further thinning of simplified coastline](15_delete-unnecessary-vertices.png)
+  ![Further thinning of simplified coastline](15_delete-unnecessary-vertices.png)
 
 16. The shape file used to clip the study area in step 5 will be used as the boundary of the model setup and be combined with the coastline. Firstly, convert the polygon of the study area to a polyline with `Vector` -> `Geometry Tools` -> `Polygons to Lines`; select the `Input Layer`.
 
-	![Convert polygon to line](16_polygone-to-line.png)
+ ![Convert polygon to line](16_polygone-to-line.png)
 
 17. Before merging the boundary and the coastline shapes, remove all fields from the boundary polyline through the `Attribute Table`; select everything and click `Delete field`.
 
-	![Delete fields of polyline](17_remove-all-fields.png)
+ ![Delete fields of polyline](17_remove-all-fields.png)
 
 18. Merge the boundary polyline and the coastline with `Vector` -> `Data Management Tools` -> `Merge Vector Layers`; select `Input Layers`.
 
-	![Merge vector layers boundary polyline and coastline](18_merge-vector-layers.png)
-
+ ![Merge vector layers boundary polyline and coastline](18_merge-vector-layers.png)
 
 ## OGS model setup
 
 The next steps will use the OGS DataExplorer, GMSH, and ParaView to prepare the model input files. A 2D mesh will be generated from the merged shape file containing the study area boundary and the coastline; the elevation data will be used to define the surface of the model and subsurface layer information will be used to define the aquifer structure.
 
-
 ### 3D Mesh creation
 
 19. Load the merged boundary-coastline shape into the DataExplorer (`File` -> `Import` -> `Shape Files`). Creation of the 2D mesh can be done in two ways:
 
     a) Either use GMSH: Save the geometry as a `.geo` file for usage in GMSH by choosing the tab `Geometry` and clicking the save icon. Afterwards, use GMSH to generate a 2D mesh to your liking and import it with `File` -> `Import Files` -> `GMSH files...`.
 
-	![Save imported boundary shape as GMSH .geo file](19a_save-gmsh.png)
+ ![Save imported boundary shape as GMSH .geo file](19a_save-gmsh.png)
 
     b) Or use the DataExplorer interface for GMSH: Use `Tools` -> `Create Mesh From Input Data...`.
 
-	![Select meshing option](19b_create-2d-mesh.png)
+ ![Select meshing option](19b_create-2d-mesh.png)
 
     From the dialogue, select the geometry which should be used and let it show up on the right side (`Employed information`).
 
-  	![Select geometry](19c_create-2d-mesh.png)
+   ![Select geometry](19c_create-2d-mesh.png)
 
     Select the `Advanced` tab, choose `Adaptive meshing`, and remove the tick at `Delete GMSH geo-file after generating mesh` (in case you still want to manipulate the `.geo` file); click `OK`.
 
-  	![Advanced meshing settings](19d_create-2d-mesh.png)
+   ![Advanced meshing settings](19d_create-2d-mesh.png)
 
 20. To create a 3D mesh, the previously defined elevation data and subsurface layer data will be used to define multiple layers of the model. In the left-side tab `Meshes`, right-click the newly created (or imported) mesh, and choose `Edit mesh...`
 
-  	![Start creation of 3D mesh](20_create-3d-mesh.png)
+   ![Start creation of 3D mesh](20_create-3d-mesh.png)
 
 21. In the new dialogue, `Specify the number of layers to add` (here 10), click `Add layers based on raster files`, and load all `.asc` files that define the different layers into the interface. Also, define a `Minimum thickness of layers` (here 5 height units).
 
-	![Create layered 3D mesh](21_create-3d-mesh.png)
-
+ ![Create layered 3D mesh](21_create-3d-mesh.png)
 
 ### Boundary condition definition
 
@@ -136,7 +130,7 @@ For the creation of the boundary conditions, use the following workflow.
 
 22. Save the created 3D mesh as a `.vtu` file by selecting the 3D mesh in the `Meshes` tab and clicking the save icon. In the new dialogue, choose a output directory, filename, and the `Data mode`.
 
-	![Save 3D mesh as `.vtu` file](22_save-3d-mesh.png)
+ ![Save 3D mesh as `.vtu` file](22_save-3d-mesh.png)
 
 23. To define water level and groundwater recharge, the top surface of the mesh will be used. Extract the surface with the tool [`ExtractSurface`]({{< ref "extract-surface" >}}). The following command is an example:
   `ExtractSurface -i SubsurfaceMesh.vtu -o exSurf.vtu -x 0 -y 0 -z -1 -a 30`
@@ -153,4 +147,4 @@ For boundary conditions, a separation of the water level (Dirichlet) and recharg
 
 25. Define the `.prj` file of your setup, including the 3D mesh and boundary condition meshes and run the simulation.
 
-	![Simulation result](25_simulation-result.png)
\ No newline at end of file
+ ![Simulation result](25_simulation-result.png)
diff --git a/web/content/docs/tools/workflows/create-a-simple-parallel-model/index.pandoc b/web/content/docs/tools/workflows/create-a-simple-parallel-model/index.pandoc
index c2cce63f51337dc30b610d68e7509550b3097e39..2188413675d32e10d4eafb4010eaaac641c3d210 100644
--- a/web/content/docs/tools/workflows/create-a-simple-parallel-model/index.pandoc
+++ b/web/content/docs/tools/workflows/create-a-simple-parallel-model/index.pandoc
@@ -9,6 +9,7 @@ author = "Thomas Fischer"
 +++
 
 ## Unsupported Processes
+
 So far, the parallel FEM scheme with PETSc cannot be used by the all processes
  using linear and quadratic function spaces simultaneously. They are
 
@@ -29,7 +30,6 @@ So far, the parallel FEM scheme with PETSc cannot be used by the all processes
   - `cmake <path_to_source> -DOGS_USE_PETSC=ON`
 - Build the source code with `make`
 
-
 ## Create a structured mesh
 
 In order to discretize the domain of a unit cube do
@@ -49,18 +49,17 @@ where `a`, `b`, and `c` should be choosen according to the needs.
 |  422  |  422  |  422  | ~ 75.15 | 240 | yes |
 |  465  |  465  |  465  | ~ 100.54 | 320 | |
 
-
 For the boundary conditions, if they are simple (_i.e._ homogeneous), the
 simplest `.gml` file is sufficient for the serial case, but for heterogeneous
 boundary conditions and parallelization boundary mesh files are needed. There
 are two possibilities to create such files:
 
- - If there is a `.gml` file, use [`constructMeshesFromGeometry`
+- If there is a `.gml` file, use [`constructMeshesFromGeometry`
    tool]({{<ref "../../meshing-submeshes/constructMeshesFromGeometry">}})  which
    takes the mesh file and geometry and creates all the boundaries which are
    named in the `.gml` file with the required `bulk_node_ids` and
    `bulk_element_ids` mappings.
- - If there is a boundary mesh (generated by gmsh or salome, or extracted in
+- If there is a boundary mesh (generated by gmsh or salome, or extracted in
    paraview, for example) use the [`identifySubdomains`
    tool]({{<ref "../../meshing-submeshes/identifySubdomains">}}) to create or
    verify the needed `bulk_node_ids` and `bulk_element_ids` mappings.
diff --git a/web/content/docs/tools/workflows/create-boundary-condition-in-polygonal-region/index.pandoc b/web/content/docs/tools/workflows/create-boundary-condition-in-polygonal-region/index.pandoc
index b73cfd12b023593f02fd8a31f037cba021728d48..f91569c189dc2faf9716fdc3dbea238ff232a39b 100644
--- a/web/content/docs/tools/workflows/create-boundary-condition-in-polygonal-region/index.pandoc
+++ b/web/content/docs/tools/workflows/create-boundary-condition-in-polygonal-region/index.pandoc
@@ -30,4 +30,3 @@ In order to create boundary conditions in a polygonal region the following workf
 4. Compute the associated area for the nodes of the surface mesh deploying tool [ComputeNodeAreasFromSurfaceMesh]({{< ref "compute-node-areas-from-surface-mesh" >}})
 
 The surface mesh patches (created until step 3) can be used as input for OGS-6 simulations. For OGS-5 simulations only the additional step 4 has to be performed.
-
diff --git a/web/content/docs/userguide/basics/introduction.pandoc b/web/content/docs/userguide/basics/introduction.pandoc
index 80c680cefe8286352cc54b49559fdb4591c0b60a..18a68c5dd7c3c17e5ddf10f01ee32106aee3d1e3 100644
--- a/web/content/docs/userguide/basics/introduction.pandoc
+++ b/web/content/docs/userguide/basics/introduction.pandoc
@@ -60,8 +60,9 @@ You can see that there is the project-file missing.
 Then simply supply the path to a project file as an argument to the OGS executable:
 
 ```
-$ ogs .\Path\to\BenchmarkName.prj
+ogs .\Path\to\BenchmarkName.prj
 ```
+
 :::
 
 ::: {.linux}
@@ -85,8 +86,9 @@ You can see that there is the project-file missing.
 Then simply supply the path to a project file as an argument to the OGS executable:
 
 ```
-$ ogs ./path/to/BenchmarkName.prj
+ogs ./path/to/BenchmarkName.prj
 ```
+
 :::
 
 ::: {.mac}
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE.pandoc b/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE.pandoc
index 48dd760e2844060d373adf0afdcac7bf1c5e8c28..d35720e5fe9b173288b5817528ad07ecae1a293d 100644
--- a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE.pandoc
+++ b/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE.pandoc
@@ -24,8 +24,8 @@ This part aims to give an explanation of the mathematical framework in configuri
 $$
 \begin{equation}
 \frac{\partial}{\partial t}  \left[ \epsilon \rho_f c_f + ( 1-\epsilon ) \rho_s c_s \right]  T_s
-    + \nabla \cdot \left(  \rho_f c_f \mathbf{v_f} T_s  \right)
-    - \nabla \cdot \left(  \Lambda_s \cdot \nabla T_s  \right) = H_s,
+  + \nabla \cdot \left(  \rho_f c_f \mathbf{v_f} T_s  \right)
+  - \nabla \cdot \left(  \Lambda_s \cdot \nabla T_s  \right) = H_s,
 \end{equation}
 $$
 Here, $\Lambda_s$ denotes the tensor of thermal hydrodynamic dispersion and $H_s$ represents the heat source and sink term.
@@ -53,6 +53,7 @@ In the configuration of `Heat_Transport_BHE` process, it is generally configured
 ### < borehole >
 
 The borehole < length > and < diameter > are difined here. The unit of these parameters are in $\mathrm{m}$. Here is an example of a borehole with 18 m in length and 0.13 m in diameter.
+
 ```bash
 <borehole>
     <length>18.0</length>
@@ -67,6 +68,7 @@ Currently there are 4 types of BHE available. Following the convention in Diersc
 ```bash
 <type>2U</type>
 ```
+
 * 1U: means there is only one single U-tube installed in the borehole;
 * 2U: double U-tubes installed in the borehole;
 * CXA: coaxial pipe with annular space as the inlet downwards flow and the centre part as outlet upwards flow;
@@ -78,8 +80,6 @@ The cross-sections of these 4 types of BHEs are illustrated in the following fig
 
 {{< img src="../coaxial.png" width="50">}}
 
-
-
 ### < pipes >
 
 The properties of the pipes are defined in this section. For different types of BHE, the pipes are also configured differently.
@@ -128,6 +128,7 @@ The unit of < power > is in $\mathrm{W}$ and < flow_rate > is in $\mathrm{m^{3}/
 For all the flow and temperature control options, OpenGeoSys calculates the inlet temperature of each BHE internally. For each BHE, temperature on its inlet pipe is always set as a Dirichlet type boundary condition. Depending on the choice of < flow_and_temperature_control >, the inflow temperature will be calculated dynamically in each time step and iteration to satisfy the given constrains.
 
 Here is an example using `TemperatureCurveConstantFlow`.
+
 ```bash
 <flow_and_temperature_control>
     <type>TemperatureCurveConstantFlow</type>
@@ -146,6 +147,7 @@ The thermal properties of the grout material is defined here.
 * /thermal_conductivity/: thermal conductivity of grout which has the unit of $\mathrm{W·m^{-1} K^{-1}}$.
 
 Here is an example how the typical parameters of borehole grout looks like.
+
 ```bash
 <grout>
     <density>2190.0</density>
@@ -154,6 +156,7 @@ Here is an example how the typical parameters of borehole grout looks like.
     <thermal_conductivity>0.73</thermal_conductivity>
 </grout>
 ```
+
 ### < refrigerant >
 
 The thermal properties of the circulating fluid is defined here. The parameters and their units are listed below.
@@ -165,6 +168,7 @@ The thermal properties of the circulating fluid is defined here. The parameters
 * /reference_temperature/: When the < flow_and_temperature_control > was not set to TemperatureCurveConstantFlow, OGS needs to have an initial outlet temperature value in the first time step to start the simulation. A reference temperature has to be defined for the calcualtion of initial inflow temperature. The unit of refenrence temperature is in $^{\circ}$C.
 
 Here is an example in which the circulating fluid is water at about 15 $^{\circ}$C.
+
 ```bash
 <refrigerant>
     <density>998</density>
@@ -185,4 +189,4 @@ Here is an example in which the circulating fluid is water at about 15 $^{\circ}
 
 [4] Hein, P., Kolditz, O., Görke, U.-J., Bucher, A., Shao, H.: A numerical study on the sustainability and efficiency of borehole heat exchanger coupled ground source heat pump systems. Appl. Therm. Eng. 100, 421–433 (2016).
 
-[5] Shao, Haibing, Philipp Hein, Agnes Sachse, and Olaf Kolditz. Geoenergy modeling II: shallow geothermal systems. Springer International Publishing, 2016.
\ No newline at end of file
+[5] Shao, Haibing, Philipp Hein, Agnes Sachse, and Olaf Kolditz. Geoenergy modeling II: shallow geothermal systems. Springer International Publishing, 2016.
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork.pandoc b/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork.pandoc
index 2c1ddc5a45561f8e9737a3c295c3dc1ade0ab67f..0294f6f643b97b0f2c4b9d0bc3da29ee8d6d4672 100644
--- a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork.pandoc
+++ b/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork.pandoc
@@ -16,11 +16,11 @@ project = "Parabolic/T/3D_3BHEs_array/3bhes_1U.prj"
 In a large borehole heat exchanger (BHE) array, all BHEs are connected with each other through a pipeline network. As the circulating fluid temperatures within each BHE are controlled by the network, the array itself has an intrinsic feature of balancing thermal extraction rates among different BHEs. This leads to the BHE thermal load shifting phenomena in the long-term operation. In OGS-6, this process can be simulated by using the PipeNetwork feature in the `Heat_Transport_BHE` process.
 
 This short tutorial aims to give the user a guide to the PipeNetwork feature. It includes the following main parts:\
+
 * The basic requirements for the PipeNetwork feature.\
 * The workflow of creating a pipeline network model using the software TESPy.\
 * The workflow of connecting the TESPy pipeline network model with the OGS model.\
 
-
 ## Requirements on the computer
 
 In order to use the PipeNetwork feature, the computer running the `Heat_Transport_BHE` process of OpenGeoSys is required to have a Python 3 environment with the TESPy program installed. For the Python 3 environmental installation, there are various tutorial availabe on the Internet. For the TESPy package, one can install it with the following command line in the Python3 environment:
@@ -31,7 +31,7 @@ pip3 install tespy
 
 ## Creating a pipeline network model with the software TESPy
 
-The Thermal Engineering Systems in Python (TESPy (https://doi.org/10.5281/zenodo.2555866)) is a software package developed by Francesco Witte. It is capable of simulating coupled thermal-hydraulic status of working fluids in thermal engineering applications. Such systm typically involves a cirulation network that is composed of pre-defined components including pipes, heat exchangers and different types of turbo machinery. Interested readers may refer to the online documentation (https://tespy.readthedocs.io/en/master/index.html#) of TESPy for more detailed introduction of the software. The workflow in this part is built based on the benchmark example "A 3-BHE Array Coupled With Pipe Network" from the OpenGeoSys Documentation (https://www.opengeosys.org/docs/benchmarks/heat-transport-bhe/3d_3bhes_array/). One can refer to this benchmark and download its latest benchmark files from GitHub (https://www.opengeosys.org/docs/userguide/basics/introduction/) for creating the pipeline network TESPy model. The OpenGeoSys and TESPy version used for this tutorial is (OpenGeoSys 6.2.2) and 0.2.0 accordingly.
+The Thermal Engineering Systems in Python (TESPy (<https://doi.org/10.5281/zenodo.2555866>)) is a software package developed by Francesco Witte. It is capable of simulating coupled thermal-hydraulic status of working fluids in thermal engineering applications. Such systm typically involves a cirulation network that is composed of pre-defined components including pipes, heat exchangers and different types of turbo machinery. Interested readers may refer to the online documentation (<https://tespy.readthedocs.io/en/master/index.html>#) of TESPy for more detailed introduction of the software. The workflow in this part is built based on the benchmark example "A 3-BHE Array Coupled With Pipe Network" from the OpenGeoSys Documentation (<https://www.opengeosys.org/docs/benchmarks/heat-transport-bhe/3d_3bhes_array/>). One can refer to this benchmark and download its latest benchmark files from GitHub (<https://www.opengeosys.org/docs/userguide/basics/introduction/>) for creating the pipeline network TESPy model. The OpenGeoSys and TESPy version used for this tutorial is (OpenGeoSys 6.2.2) and 0.2.0 accordingly.
 
 The coupled model that is going to be built is demonstrated in Figure 1. It consists of a pipeline network connected with 3 BHEs, a water pump, a virtual heat pump as the consumer, a splitter to split up the feeding fluid flow and a merge to returned flow. These devices are all defined as `components` in TESPy. A full list of available components can be found in the TESPy components module. In the pipeline network, these components are connected with each other through `connections` parts, which are illustrated by the black lines in the figure. With these two main parts, a completely TESPy pipeline network model can be set up.
 
@@ -261,6 +261,7 @@ To use the PipeNetwork feature, several input parameters need to be adjusted in
     <geometry>3bhes_1U.gml</geometry>
     <python_script>bcs_tespy.py</python_script>
 ```
+
 ```bash
 <borehole_heat_exchangers>
     <borehole_heat_exchanger>
@@ -270,11 +271,10 @@ To use the PipeNetwork feature, several input parameters need to be adjusted in
 
 After the configuration of the OGS project file, all the required files for using the PipeNetwork feature are prepared. The process explicitly couple the BHE and the pipe network can be simulated in the `Heat_Transport_BHE` process by OGS.
 
-
 ## References
 
-[1] Francesco Witte, Thermal engineering systems in python, 2019. URL: https://doi.org/10.5281/zenodo.2555866. doi:10.5281/zenodo.2555866.
+[1] Francesco Witte, Thermal engineering systems in python, 2019. URL: <https://doi.org/10.5281/zenodo.2555866>. doi:10.5281/zenodo.2555866.
 
 [2] Haibing Shao, Philipp Hein, Agnes Sachse, and Olaf Kolditz. Geoenergy modeling II: shallow geothermal systems. Springer International Publishing, 2016.
 
-[3] Shuang Chen, Francesco Witte, Olaf Kolditz, and Haibing Shao (2020). Shifted thermal extraction rates in large Borehole Heat Exchanger array – A numerical experiment. Applied Thermal Engineering, 167(July 2019), 114750.
\ No newline at end of file
+[3] Shuang Chen, Francesco Witte, Olaf Kolditz, and Haibing Shao (2020). Shifted thermal extraction rates in large Borehole Heat Exchanger array – A numerical experiment. Applied Thermal Engineering, 167(July 2019), 114750.
diff --git a/web/content/docs/userguide/troubleshooting/project-file.pandoc b/web/content/docs/userguide/troubleshooting/project-file.pandoc
index 69a9587bdd33be73920e12d5663234659cbdf60b..5449135d729d01adc992b6bad8095ce8193b8acd 100644
--- a/web/content/docs/userguide/troubleshooting/project-file.pandoc
+++ b/web/content/docs/userguide/troubleshooting/project-file.pandoc
@@ -28,12 +28,15 @@ choco install xsltproc
 ```
 
 ::: {.note}
+
 ### <i class="far fa-info-circle"></i> Alternative installation
+
 Another method is to use the [Windows Subsystem for Linux](https://docs.microsoft.com/en-us/windows/wsl/install-win10) where you can simply install Linux packages:
 
 ```bash
 sudo apt-get install libxml2-utils
 ```
+
 :::
 
 :::
@@ -52,4 +55,5 @@ sudo apt-get install libxml2-utils
 ```bash
 brew install xmlstarlet
 ```
+
 :::
diff --git a/web/content/imprint.pandoc b/web/content/imprint.pandoc
index b40a0dee2d1131be158bb2fec538201eabb04e1d..5d1a7e0387d3a085f32208c21a590bc6f0c81df2 100644
--- a/web/content/imprint.pandoc
+++ b/web/content/imprint.pandoc
@@ -21,7 +21,7 @@ All information under the default copyright is licensed under a [Creative Common
 
 ### Source code
 
-The source code of this website is available at https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/web. Please take a look at the repository if you want to know the exact list of copyright holders.
+The source code of this website is available at <https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/web>. Please take a look at the repository if you want to know the exact list of copyright holders.
 
 ### Third-party
 
@@ -42,7 +42,7 @@ In case of questions about the website or any of its contents, please contact us
 
 ## Impressum
 
-Verantwortlich für https://opengeosys.org im Sinne des Presserechts:
+Verantwortlich für <https://opengeosys.org> im Sinne des Presserechts:
 
 Prof. Dr. Olaf Kolditz, Helmholtz-Zentrum für Umweltforschung GmbH - UFZ, Permoserstr. 15, 04318 Leipzig.
 
diff --git a/web/content/ogs-5/index.pandoc b/web/content/ogs-5/index.pandoc
index 68af22293e232eb6bfc05d6e0242cd017451b4ad..a857be1eac83cffe6e45d41427b7f2b7802fce96 100644
--- a/web/content/ogs-5/index.pandoc
+++ b/web/content/ogs-5/index.pandoc
@@ -17,10 +17,12 @@ As OGS-6 is a reimplementation of OGS-5 with new concepts and methodologies ther
 ### OpenGeoSys 5.7
 
 #### Linux
+
 - [Linux](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs-5.7.0-Linux-2.6.32-573.8.1.el6.x86_64-x64.tar.gz)
 - [Linux Data Explorer](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs5-data_explorer-x64-linux.tar.gz)
 
 #### Windows
+
 - [Windows](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs-5.7.0-Windows-6.1.7601-x64.zip)
 - [Windows Data Explorer](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs5-data_explorer-x64.zip)
 - [Windows 32-Bit (Windows XP)](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs-5.7.0-Windows-6.1.7601-x32.zip)
@@ -32,6 +34,7 @@ On Windows you may have to install the appropriate Visual Studio Redistributable
 - [Windows Visual Studio Redistributable 32-Bit (Windows XP)](https://ogsstorage.blob.core.windows.net/binaries/ogs5/vcredist_x86.exe)
 
 #### macOS
+
 - [macOS](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs-5.7.0-Darwin-15.2.0-x64.tar.gz)
 - [macOS Data Explorer](https://ogsstorage.blob.core.windows.net/binaries/ogs5/ogs5-data_explorer-x64-mac.dmg)