diff --git a/web/content/docs/_index.md b/web/content/docs/_index.md
index 5be4fc8d710dd70831eeeb1ea7a5a701a3b7b489..3f19e7a26843678b8866c889552792a1fd5b3efb 100644
--- a/web/content/docs/_index.md
+++ b/web/content/docs/_index.md
@@ -5,4 +5,8 @@ title = "Docs"
name = "Docs"
identifier = "docs"
weight = 2
+
+[cascade]
+breadcumbs = false
+collapsed = true
+++
diff --git a/web/content/docs/userguide/post-processing/_index.md b/web/content/docs/tools/post-processing/_index.md
similarity index 75%
rename from web/content/docs/userguide/post-processing/_index.md
rename to web/content/docs/tools/post-processing/_index.md
index 4206b91dd41ec2d6c34db639476da39245954f43..7ef9e455d3b979e4e55fb155d58011179eb307e1 100644
--- a/web/content/docs/userguide/post-processing/_index.md
+++ b/web/content/docs/tools/post-processing/_index.md
@@ -1,4 +1,4 @@
+++
title = "Postprocessing"
-weight = 3
+weight = 7
+++
diff --git a/web/content/docs/userguide/post-processing/paraview-on-eve/index.md b/web/content/docs/tools/post-processing/paraview-on-eve/index.md
similarity index 100%
rename from web/content/docs/userguide/post-processing/paraview-on-eve/index.md
rename to web/content/docs/tools/post-processing/paraview-on-eve/index.md
diff --git a/web/content/docs/userguide/basics/cli-arguments/index.md b/web/content/docs/userguide/basics/cli-arguments/index.md
index 72e981a86feba38aae0101a14166b6756d6a6bf2..3ba04798d314acb9ab64265dfefe24ef0aca7cec 100644
--- a/web/content/docs/userguide/basics/cli-arguments/index.md
+++ b/web/content/docs/userguide/basics/cli-arguments/index.md
@@ -2,7 +2,7 @@
date = "2021-05-06T13:00:13+01`:00"
title = "Command-line arguments"
author = "Lars Bilke"
-weight = 3
+weight = 2
+++
The following arguments are available:
diff --git a/web/content/docs/userguide/basics/container/index.md b/web/content/docs/userguide/basics/container/index.md
index c4524d3232f9f0f3fda3ad79e8410b4e32e4a354..82df9ce8c7b3e023ced133209a44d2e4eee8e2a3 100644
--- a/web/content/docs/userguide/basics/container/index.md
+++ b/web/content/docs/userguide/basics/container/index.md
@@ -2,7 +2,7 @@
date = "2018-11-14T15:00:13+01:00"
title = "Running OGS in a container"
author = "Lars Bilke"
-weight = 2
+weight = 3
+++
<div class='note'>
diff --git a/web/content/docs/userguide/basics/conventions/index.md b/web/content/docs/userguide/basics/conventions/index.md
index fe55707043e14987d508783022425da064413805..757e2ba0050d21725609460784e89bbee5f5e88e 100644
--- a/web/content/docs/userguide/basics/conventions/index.md
+++ b/web/content/docs/userguide/basics/conventions/index.md
@@ -2,7 +2,7 @@
date = "2021-06-17T11:00:13+01:00"
title = "OGS Conventions"
author = "Joerg Buchwald"
-weight = 6
+weight = 7
+++
## Units
diff --git a/web/content/docs/userguide/basics/jupyter-notebooks/index.md b/web/content/docs/userguide/basics/jupyter-notebooks/index.md
index 797277d02c6fc236e096138e36bfe204757a1ba3..ebbd1b6bdaefd5426f493c6093bf226f6a800b0d 100644
--- a/web/content/docs/userguide/basics/jupyter-notebooks/index.md
+++ b/web/content/docs/userguide/basics/jupyter-notebooks/index.md
@@ -2,7 +2,7 @@
date = "2021-09-09T15:00:13+01:00"
title = "Jupyter Notebooks"
author = "Lars Bilke"
-weight = 5
+weight = 6
+++
[Jupyter Notebooks](https://jupyter.org) are documents which can contain live (Python) code, equations, visualizations and narrative text and can be used as an intuitive interface for OGS projects. The following video gives an introduction to using OpenGeoSys with Jupyter Notebooks:
diff --git a/web/content/docs/userguide/basics/project-file/index.md b/web/content/docs/userguide/basics/project-file/index.md
index 5df482a00ca1c7cd989ce92a39c02cbca41c0670..9c20c90fe997bf98f8f49577e6f18563d232e78a 100644
--- a/web/content/docs/userguide/basics/project-file/index.md
+++ b/web/content/docs/userguide/basics/project-file/index.md
@@ -1,6 +1,6 @@
+++
date = "2018-11-14T11:00:13+01`:00"
-title = "Project file syntax"
+title = "Modularizing project files"
author = "Lars Bilke"
weight = 4
+++
diff --git a/web/content/docs/userguide/basics/project_file_intro.md b/web/content/docs/userguide/basics/project_file_intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..2a7583914fd7daf34edb7b340209ae5c30bc4a98
--- /dev/null
+++ b/web/content/docs/userguide/basics/project_file_intro.md
@@ -0,0 +1,96 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Project file structure"
+author = "Feliks Kiszkurno"
+weight = 3
++++
+
+The main input taken by OpenGeoSys is path to project file. This file has a ".prj" extension and describes all aspects of the simulation that OpenGeoSys is expected to execute.
+
+The syntax of the project file follows the syntax of a typical xml file and can be edited with any editor capable of working with this kind of files.
+
+The structure of the project file is relatively flexible: as long as the semantics of the file are intact, the main blocks can be provided in any order.
+
+Depending on what the simulation is about, the content of project file will differ. However, there are some basic minimum requirement that have to be fulfilled.
+
+<div class="note">
+This page is not a complete description of XML standard. It only provides enough information to interact with and understand OpenGeoSys "*.prj" files. More details can be found here: <a href="https://www.w3.org/standards/xml/">XML Standard</a>.
+</div>
+
+The XML files structure follows an abstract idea of a tree: from roots to leaves. The main tag within any XML file is called root. In OpenGeoSys project files the root tag looks like this: `<OpenGeoSysProject> </OpenGeoSysProject>`. Between opening and closing tags all the project relevant information is contained. Everything between those tags follows a hierarchical structure. There will be thematic blocks that cover specific aspects of the simulation. They define for example mesh files, or process used in the simulation. Following snippet shows a small structure containing those two (for now empty) blocks:
+
+```xml
+<OpenGeoSysProject>
+ <mesh>
+ ...
+ </mesh>
+
+ <process>
+ ...
+ </process>
+</OpenGeoSysProject>
+```
+
+The blocks `<mesh> </mesh>` and `<processes> </processes>` are at the same "level" indicated by the indent. Those are the child elements of the root `<OpenGeoSysProject>`, which is their parent element. As they are on the same level, they can be described as siblings. This hierarchy is recursive. This means, that each of the child elements can have it's own child elements and be parent to them (think of family structure: grandparents -> parent -> children -> grandchildren).
+
+In following snippet you can see a `<processes> </processes>` element containing child element `<processes> </processes>`, which again contains two child elements: `<name> </name>` and `<type> </type>`:
+
+```xml
+<OpenGeoSysProject>
+ <process>
+ <process>
+ <name>SteadyStateDiffusion</name>
+ <type>STEADY_STATE_DIFFUSION</type>
+ </process>
+ </process>
+</OpenGeoSysProject>
+```
+
+This snippet can be understood in more human readable way as follows:
+
+*In this project file used by OpeGeoSys there is one instance of processes, which is called SteadyStateDiffusion and is implemented in OpenGeoSys as type STEADY_STATE_DIFFUSION*.
+
+## Attributes
+
+If a value is set between `<` and `>`, beside the tag, it is called attribute. For example:
+
+```xml
+<planet satellite_name="Moon">
+```
+
+Entity "planet" has attribute "satellite_name" set to "Moon".
+
+In project files, attributes are used in some blocks to distinguished between multiple instances of the same entity. For example [media](/docs/userguide/blocks/media/#media) are identified by their attribute "id":
+
+```xml
+<medium id="0">
+```
+
+and processes in [time loop](/docs/userguide/blocks/time_loop/#process) by the "ref" attribute:
+
+```xml
+<process ref="SteadyStateDiffusion">
+```
+
+## Comments
+
+If you want to switch between two version of a certain part of the project file, two values etc, but without need to remove those fragments completely from the file, you can comment them out:
+
+```xml
+<!--value>this value will be comment out and ignored by OpenGeoSys</value-->
+<value>this value will be read and used by OpenGeoSys</value>
+```
+
+Comments cannot be nested. If you try to comment out a block that already contains a commented section - it will result in an error.
+
+## More information
+
+More details on what blocks are required/available in the project file and what can they contain, please see: [Project file over view](/docs/userguide/blocks/intro/).
+
+## File encoding
+
+In order to ensure correct encoding, it is a good practice to add following line at the beginning of the project file:
+
+```xml
+<?xml version="1.0" encoding="ISO-8859-1"?>
+```
diff --git a/web/content/docs/userguide/basics/quadrature.md b/web/content/docs/userguide/basics/quadrature.md
index 1901e0d051f110a6fb3cc07e7fd062bfc94a146d..7c3cba31bf0f33f6c6fdb552b265fde635f20a49 100644
--- a/web/content/docs/userguide/basics/quadrature.md
+++ b/web/content/docs/userguide/basics/quadrature.md
@@ -2,7 +2,7 @@
date = "2022-03-02T09:30:00+01:00"
title = "Quadrature schemes and extrapolation"
author = "Christoph Lehmann"
-weight = 7
+weight = 8
[menu]
diff --git a/web/content/docs/userguide/basics/working_with_project_files.md b/web/content/docs/userguide/basics/working_with_project_files.md
new file mode 100644
index 0000000000000000000000000000000000000000..58005edb94e10e5e936de7c3a65e6beb9f405ce8
--- /dev/null
+++ b/web/content/docs/userguide/basics/working_with_project_files.md
@@ -0,0 +1,31 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Working with project files"
+author = "Feliks Kiszkurno"
+weight = 5
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+## Setting up a project file
+The best starting point for setting your own project with OGS is to browse a catalogue of benchmarks (either at documentation page or gitlab).
+
+## Creating a new project file
+
+## Modifying an existing project file
+
+### Operation on project file using ogs6py
+
+
+
diff --git a/web/content/docs/userguide/blocks/_index.md b/web/content/docs/userguide/blocks/_index.md
new file mode 100644
index 0000000000000000000000000000000000000000..c85e34a86e9c63404a154d9e947b97104e75daa8
--- /dev/null
+++ b/web/content/docs/userguide/blocks/_index.md
@@ -0,0 +1,4 @@
++++
+title = "Project file - Building blocks"
+weight = 2
++++
\ No newline at end of file
diff --git a/web/content/docs/userguide/blocks/boundary_conditions.md b/web/content/docs/userguide/blocks/boundary_conditions.md
new file mode 100644
index 0000000000000000000000000000000000000000..7a591d6e72ecd2ea871190be61221dbac4a3e6b7
--- /dev/null
+++ b/web/content/docs/userguide/blocks/boundary_conditions.md
@@ -0,0 +1,78 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Boundary conditions"
+author = "Feliks Kiszkurno"
+weight = 8
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+All types of boundary conditions discussed in this article can be defined directly in the project file (more details can be found [here](/docs/userguide/blocks/process_variables/#boundary-conditions)).
+Additionally Dirichlet and Neumann boundary conditions can be defined using [Python boundary conditions functionality](/docs/userguide/features/python-bc/).
+
+## Dirichlet
+
+TODO: add description of Dirichlet boundary condition (including different subvariants) and how it can be used in prj file
+
+### Constrained Dirichlet
+
+### Dirichlet within time interval
+
+### Primary variable constraint Dirichlet boundary condition
+
+### Solution dependent Dirichlet
+
+## Neumann
+
+TODO: add description of Dirichlet boundary condition (including different subvariants) and how it can be used in prj file
+
+Can be used to define [source terms](/docs/userguide/blocks/process_variables/#sources) at the boundary of the mesh.
+
+### Non uniform variable dependent Neumann
+
+### HC non advective free component flow boundary
+
+### Normal traction
+
+## Robin
+
+## Python
+
+Can be used to define [Dirichlet](/docs/userguide/blocks/boundary_conditions/#dirichlet) and [Neumann](/docs/userguide/blocks/boundary_conditions/#neumann) boundary conditions. More details can be found in [this article](/docs/userguide/features/python_bc/).
+
+## Setting source term at a boundary
+
+In some models, the position of the source (of for example heat) can coincide with the boundary condition.
+It is possible to use boundary condition to define source.
+You need to keep in mind, that in such a case, from the numerical point of view, the source term defined as boundary condition is a boundary condition. It will be integrated not over the domain (as it would be if it was defined as source term), but over the boundary condition. This is why it has to be scaled (see [next section](/docs/userguide/blocks/boundary_conditions/#scaling-a-source)).
+
+Defining it as boundary condition can be done in the same way as it was described in the paragraph above.
+
+### Scaling a source
+
+Neumann boundary condition should be scaled by the surface of the source:
+
+$$ Q_{scaled} = Q_{term} / a $$
+
+where $Q$ is source term, $a$ and resulting unit is power over scaling surface area or length depending on dimension ($[W / L^{dim-1}]$).
+For example if the source is 2D, the scaling factor $a$ will be the length of it's circumference (or the relevant part of it if the source is at the boundary of the domain) and similarly in 3D case, the relevant area.
+If the mesh is axially symmetric, it has to be considered that it is fully symmetric.
+The 2D source will be rotated by $360°$.
+For example a rectangular source at the axis of symmetry, will have to be considered as a cylinder.
+For scaling the surface of the cylinder has to be used,not the relevant part of the circumference of the rectangle.
+
+If source is placed on the axially symmetrical boundary and has radius equal to 0, it has to be defined as boundary condition not as source term.
+If radius is non zero, it can be defined using source term.
+
+For more detailed description see [scaling a source term](/docs/userguide/blocks/misc/scaling_source_term/).
\ No newline at end of file
diff --git a/web/content/docs/userguide/blocks/curves.md b/web/content/docs/userguide/blocks/curves.md
new file mode 100644
index 0000000000000000000000000000000000000000..b2da5145bd7a341be68597cbd46a48221e39453c
--- /dev/null
+++ b/web/content/docs/userguide/blocks/curves.md
@@ -0,0 +1,70 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Curves"
+author = "Feliks Kiszkurno"
+weight = 10
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+TODO: Add general description
+
+This block can be used to define one or more ...
+
+They can be accessed from within `<type>Curve</type>` or `<type>CurveScaled</type>` parameters (more details on [curves](/docs/userguide/blocks/parameters/#curve) and [curves scales](/docs/userguide/blocks/parameters/#curvescaled)).
+
+Following variables are accessible from CurveScaled:
+
+- spatial: x, y, z
+- temporal: t
+
+## Example
+
+Curves can be defined using the following block:
+
+```xml
+<curves>
+ <curve>
+ <name>CurveName</name>
+ <coords>
+ x_1 x_2 ... x_n
+ </coords>
+ <values>
+ y(x_1) y(x_2) ... y(x_n)
+ </values>
+ </curve>
+</curves>
+```
+
+and can be called in "Properties" and "Parameters" inside "Expression":
+`CurveName(evaluation_value)`
+
+where `evaluation_value` is always exactly one value and refers to values provided inside `<coords> </coords>`.
+In the `<expression>`s using curves, time $t$ and global coordinate $x$, $y$, and $z$ can be used, and passed as curve's argument for example:
+
+```xml
+<parameter>
+ <name>density</name>
+ <type>Function</type>
+ <expression>2000 - CurveName(x^2 + y^2) * TimeDependentCurve(t)</expression>
+</parameter>
+```
+
+Curves can be useful to include information on variation of time dependent parameters.
+Those values can be called from 'equation' tag in 'parameter' if 'type' 'formula' is selected.
+
+## Interpolation
+
+Curve represents a piece-wise linear function---the values between coordinates are interpolated linearly.
+Outside of the curve's range of definition the curve becomes a constant using first value on the left and last value on the right.
diff --git a/web/content/docs/userguide/blocks/figures/curve.drawio b/web/content/docs/userguide/blocks/figures/curve.drawio
new file mode 100644
index 0000000000000000000000000000000000000000..f60683420c5864df52641e13526c47ef1c3ebcf8
--- /dev/null
+++ b/web/content/docs/userguide/blocks/figures/curve.drawio
@@ -0,0 +1 @@
+<mxfile host="Electron" modified="2022-11-11T12:21:50.034Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/16.5.1 Chrome/96.0.4664.110 Electron/16.0.7 Safari/537.36" etag="utLgP5gkDPGpq37WXZQ8" version="16.5.1" type="device"><diagram id="Ea5Xswr2lk4uTsUS1zHi" name="Page-1">5Vldb5swFP01PHYCGwh5bNN067ZOlfqw9WnywAW3BqeOach+/QyYDwPNVhWUoEmR4nt9bexz7vEHGHAVZx852kQ3LMDUAGaQGfDSAMCyATDynxnsS8/SdEpHyEmgghrHHfmNldNU3pQEeKsFCsaoIBvd6bMkwb7QfIhzttPDHhjVn7pBIe457nxE+97vJBCR8lrusqn4hEkYqUd7YFFWxKgKVjPZRihgu5YLrg244oyJshRnK0xz8CpcynZXr9TWA+M4Ef/SILr24+cz7F/fLz/ffKPm1frpy5maxQuiqZqwGqzYVwhwliYBzjsxDXixi4jAdxvk57U7ybn0RSKm0rJk8YElQpHo5uEPhNIVo4xLR8IS6b9QT8Rc4OzVqVg1QDKzMIux4HsZohrYClKVU64ydw1By8oXtbhxPOVEKinCuucGN1lQ0L0BxkUPxlvOHvN8BOYVkUh2QZVzFzpyW8HZE+5gNQAfoiRMpOlLrLD0X+RIEpmw56oiJkGQP2aQKp3MLlsjUOPq1Cz71EAwQA2cihlvlgnu6ShaAxlumwMw2vZUOFbrsQakS4WCREPUfU5ZVXG2LcA6lwGOucmaSlkK8/9bxJEcIubbqj85vrLLMuD/0Q6wFjrtXp/2oXVtMvFY1nTqcaZTjwV0+dT7xV9XITAZkuDd8rEPy2e26nFGU0+HdQccWT1wOvXY06nHcU9v87HfrR53UD2rlL/g+W489liHtkWH8qNvPM4sj22ueXIbzwBwOJA3XGUyLiIWsgTRdePtJFwT85WxjQL0EQuxV4iiVDAdbpwR8aNVvs+7+uAo6zJTPRfGvjISOd8fbaPVKjebZoVVtWtRC81ak9Vl3auZzad9mFeJEku5jw8lplsGCsRDLA4FLoczhWOKBHnRRzK+ftxZ6sfqbD21LFr6qTXV1g8wJ1uJ+lf7ce49xdYz251ntNcFjts5tMEj7zxDLwzexjcc5Fv+ozjHtOjLV+yXriqgqPrFtRT5mcjzfb9O705O9UCPs8uu0a4Etq2vJ97iyNk14ftWOOG5xj65dRkMvZpoS0LJZjyBDXV46kKCIwlpATsJMJ2QpNl8EynqWl+W4PoP</diagram></mxfile>
\ No newline at end of file
diff --git a/web/content/docs/userguide/blocks/figures/curve.svg b/web/content/docs/userguide/blocks/figures/curve.svg
new file mode 100644
index 0000000000000000000000000000000000000000..d1a8c18422d6f925f6bb2d34e21be7dbea9ff315
--- /dev/null
+++ b/web/content/docs/userguide/blocks/figures/curve.svg
@@ -0,0 +1,4 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!-- Do not edit this file with editors other than diagrams.net -->
+<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
+<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" version="1.1" width="961px" height="581px" viewBox="-0.5 -0.5 961 581" content="<mxfile host="Electron" modified="2022-11-11T12:21:55.026Z" agent="5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) draw.io/16.5.1 Chrome/96.0.4664.110 Electron/16.0.7 Safari/537.36" etag="tF4EcWwYNg0o4FzgD-ZK" version="16.5.1" type="device"><diagram id="Ea5Xswr2lk4uTsUS1zHi" name="Page-1">5Vldb5swFP01PHYCGwh5bNN067ZOlfqw9WnywAW3BqeOach+/QyYDwPNVhWUoEmR4nt9bexz7vEHGHAVZx852kQ3LMDUAGaQGfDSAMCyATDynxnsS8/SdEpHyEmgghrHHfmNldNU3pQEeKsFCsaoIBvd6bMkwb7QfIhzttPDHhjVn7pBIe457nxE+97vJBCR8lrusqn4hEkYqUd7YFFWxKgKVjPZRihgu5YLrg244oyJshRnK0xz8CpcynZXr9TWA+M4Ef/SILr24+cz7F/fLz/ffKPm1frpy5maxQuiqZqwGqzYVwhwliYBzjsxDXixi4jAdxvk57U7ybn0RSKm0rJk8YElQpHo5uEPhNIVo4xLR8IS6b9QT8Rc4OzVqVg1QDKzMIux4HsZohrYClKVU64ydw1By8oXtbhxPOVEKinCuucGN1lQ0L0BxkUPxlvOHvN8BOYVkUh2QZVzFzpyW8HZE+5gNQAfoiRMpOlLrLD0X+RIEpmw56oiJkGQP2aQKp3MLlsjUOPq1Cz71EAwQA2cihlvlgnu6ShaAxlumwMw2vZUOFbrsQakS4WCREPUfU5ZVXG2LcA6lwGOucmaSlkK8/9bxJEcIubbqj85vrLLMuD/0Q6wFjrtXp/2oXVtMvFY1nTqcaZTjwV0+dT7xV9XITAZkuDd8rEPy2e26nFGU0+HdQccWT1wOvXY06nHcU9v87HfrR53UD2rlL/g+W489liHtkWH8qNvPM4sj22ueXIbzwBwOJA3XGUyLiIWsgTRdePtJFwT85WxjQL0EQuxV4iiVDAdbpwR8aNVvs+7+uAo6zJTPRfGvjISOd8fbaPVKjebZoVVtWtRC81ak9Vl3auZzad9mFeJEku5jw8lplsGCsRDLA4FLoczhWOKBHnRRzK+ftxZ6sfqbD21LFr6qTXV1g8wJ1uJ+lf7ce49xdYz251ntNcFjts5tMEj7zxDLwzexjcc5Fv+ozjHtOjLV+yXriqgqPrFtRT5mcjzfb9O705O9UCPs8uu0a4Etq2vJ97iyNk14ftWOOG5xj65dRkMvZpoS0LJZjyBDXV46kKCIwlpATsJMJ2QpNl8EynqWl+W4PoP</diagram></mxfile>" style="background-color: rgb(255, 255, 255);"><defs/><g><rect x="0" y="0" width="960" height="580" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="20" y="30" width="320" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 318px; height: 1px; padding-top: 45px; margin-left: 21px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 60px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;">Project File</div></div></div></foreignObject><text x="180" y="63" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="60px" text-anchor="middle">Project File</text></switch></g><rect x="40" y="100" width="400" height="440" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="177" y="120" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 135px; margin-left: 178px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 60px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 50px">Parameters</font></div></div></div></foreignObject><text x="207" y="153" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="60px" text-anchor="middle">Pa...</text></switch></g><rect x="80" y="180" width="320" height="320" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="170" y="192" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 207px; margin-left: 171px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 50px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 40px">Parameter</font></div></div></div></foreignObject><text x="200" y="222" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="50px" text-anchor="middle">Par...</text></switch></g><rect x="520" y="100" width="400" height="440" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="630" y="120" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 135px; margin-left: 631px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 40px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 60px">Curves</font></div></div></div></foreignObject><text x="660" y="147" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="40px" text-anchor="middle">Cur...</text></switch></g><rect x="560" y="180" width="320" height="320" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><path d="M 360 360 L 580.56 360" fill="none" stroke="rgb(0, 0, 0)" stroke-width="8" stroke-miterlimit="10" pointer-events="stroke"/><path d="M 591.06 360 L 577.06 367 L 580.56 360 L 577.06 353 Z" fill="rgb(0, 0, 0)" stroke="rgb(0, 0, 0)" stroke-width="8" stroke-miterlimit="10" pointer-events="all"/><rect x="120" y="260" width="240" height="200" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="616" y="193" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 208px; margin-left: 617px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 60px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 50px">Curve</font></div></div></div></foreignObject><text x="646" y="226" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="60px" text-anchor="middle">Cu...</text></switch></g><rect x="204" y="327" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 342px; margin-left: 205px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 50px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><font style="font-size: 30px"><curve><br />Curve_name<br /></curve></font></div></div></div></foreignObject><text x="234" y="357" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="50px" text-anchor="middle"><cu...</text></switch></g><rect x="600" y="260" width="240" height="200" fill="none" stroke="rgb(0, 0, 0)" pointer-events="all"/><rect x="690" y="327" width="60" height="30" fill="none" stroke="none" pointer-events="all"/><g transform="translate(-0.5 -0.5)"><switch><foreignObject pointer-events="none" width="100%" height="100%" requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility" style="overflow: visible; text-align: left;"><div xmlns="http://www.w3.org/1999/xhtml" style="display: flex; align-items: unsafe center; justify-content: unsafe center; width: 58px; height: 1px; padding-top: 342px; margin-left: 691px;"><div data-drawio-colors="color: rgb(0, 0, 0); " style="box-sizing: border-box; font-size: 0px; text-align: center;"><div style="display: inline-block; font-size: 30px; font-family: Helvetica; color: rgb(0, 0, 0); line-height: 1.2; pointer-events: all; white-space: normal; overflow-wrap: normal;"><name><br />Curve_name<br /></name></div></div></div></foreignObject><text x="720" y="351" fill="rgb(0, 0, 0)" font-family="Helvetica" font-size="30px" text-anchor="middle"><nam...</text></switch></g></g><switch><g requiredFeatures="http://www.w3.org/TR/SVG11/feature#Extensibility"/><a transform="translate(0,-5)" xlink:href="https://www.diagrams.net/doc/faq/svg-export-text-problems" target="_blank"><text text-anchor="middle" font-size="10px" x="50%" y="100%">Text is not SVG - cannot display</text></a></switch></svg>
\ No newline at end of file
diff --git a/web/content/docs/userguide/blocks/geometry.md b/web/content/docs/userguide/blocks/geometry.md
new file mode 100644
index 0000000000000000000000000000000000000000..4b59297eb7c42fa49ee048c7f90d0045929a4032
--- /dev/null
+++ b/web/content/docs/userguide/blocks/geometry.md
@@ -0,0 +1,10 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Geometry"
+author = "Feliks Kiszkurno"
+weight = 12
++++
+
+TODO: describe what geometry block does
+
+TODO: describe how geometry files are structured
diff --git a/web/content/docs/userguide/blocks/intro.md b/web/content/docs/userguide/blocks/intro.md
new file mode 100644
index 0000000000000000000000000000000000000000..b3aedc1dc63872a4f1fff0f8c811819b8932df7b
--- /dev/null
+++ b/web/content/docs/userguide/blocks/intro.md
@@ -0,0 +1,34 @@
++++
+title = "Overview"
+author = "Feliks Kiszkurno"
+weight = 1
++++
+
+## Required blocks
+
+Following blocks with valid content have to be provided in each project file, their content will be discussed in following pages:
+
+- [Meshes](/docs/userguide/blocks/meshes/)
+- [Processes](/docs/userguide/blocks/processes/)
+- [Media](/docs/userguide/blocks/media/)
+- [Parameters](/docs/userguide/blocks/parameters/)
+- [Time loop](/docs/userguide/blocks/time_loop/)
+- [Process variables](/docs/userguide/blocks/process_variables/)
+- [Nonlinear solvers](/docs/userguide/blocks/nonlinear_solvers/)
+- [Linear solvers](/docs/userguide/blocks/linear_solvers/)
+
+## Optional blocks
+
+Blocks in this list are optional but may be convenient to use and are used in many benchmarks:
+
+- [Curves](/docs/userguide/blocks/curves/)
+- [Test definitions](/docs/userguide/blocks/test_definitions/)
+- [Geometry](/docs/userguide/blocks/geometry/)
+
+If you already have a project file but you are wondering how to modify it automatically or how it can be interacted with from external tools, please have a look at [Working with project files](/docs/userguide/basics/working_with_project_files/) section.
+
+## Minimum requirements for a valid project file
+
+Generally there is a certain degree of flexibility, when it comes to the internal structure of the project file.
+Still, there are some exceptions.
+In "Time loop" section, "set stepping" subsection has to be defined after "add process".
diff --git a/web/content/docs/userguide/blocks/linear_solvers.md b/web/content/docs/userguide/blocks/linear_solvers.md
new file mode 100644
index 0000000000000000000000000000000000000000..66975561573e166aa9c8c58d84848c9f7f22de97
--- /dev/null
+++ b/web/content/docs/userguide/blocks/linear_solvers.md
@@ -0,0 +1,33 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Linear solvers"
+author = "Feliks Kiszkurno"
+weight = 9
++++
+
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+An important parameter defined for each iterative linear solver is "error tolerance" (direct solvers don't use the tolerance settings).
+Combined with "abstols" from section [Time loop](/docs/userguide/blocks/time_loop/) it defines the acceptable level of error in the obtained result.
+Those two parameters are interconnected with each other. Setting either of them too high will result in error message referring to problems with setting up smaller time step.
+As the variables are interconnected, it is possible to avoid error when one of them is set too low, by setting the other one a bit too high.
+
+Generally, the error tolerance of linear solver should always be tighter than "abstols".
+Unlike "abstol", "error tolerance" is not specific to "process variables" and is defined as one value.
+For most cases value below $10^{-10}$ is recommended.
+
+## Eigen
+
+TODO: Add description of Eigen
diff --git a/web/content/docs/userguide/blocks/media.md b/web/content/docs/userguide/blocks/media.md
new file mode 100644
index 0000000000000000000000000000000000000000..9c1055daf556eaaa0655c79b2adc00e9abfa212d
--- /dev/null
+++ b/web/content/docs/userguide/blocks/media.md
@@ -0,0 +1,350 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Media"
+author = "Feliks Kiszkurno"
+weight = 4
++++
+
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+Inside of this block, all media in the simulation are defined.
+ There has to be a medium for every value of Material IDs used in the mesh.
+ Those IDs are assigned when mesh is created or converted by msh2vtu script.
+
+```xml
+<media>
+ <medium id="MaterialID_matching_mesh_file">
+
+ </medium>
+</media>
+```
+
+## Phases
+
+Medium can consist of multiple phases.
+For example porous geological would consist of solid phase (for example clay) and liquid phase (e.g.: water in the pores).
+
+In media with multiple phases, each of them can occur maximal once per medium.
+Phases within one medium are distinguished by their type:
+
+```xml
+<medium id="0">
+ <phases>
+ <phase>
+ <type>Solid</type>
+ </phase>
+ </phases>
+</medium>
+```
+
+If only one phase is considered inside a medium, the definition of that phase can be reduced to placing `<phases/>` as follows:
+
+```xml
+<medium id="MaterialID">
+ <phases/>
+<medium>
+```
+
+The available phases depend on the type of the process.
+
+TODO: Add overview of what mediums are available in different processes
+
+## Properties
+
+The tag `<properties> </properties>` contains all values describing the properties of the medium as whole or of the specific phase of the medium.
+The properties describing medium as a whole have to be placed on the same level as phases:
+
+```xml
+<medium id="0">
+ <phases>
+ ...
+ </phases>
+ <properties>
+ Properties describing the whole medium
+ </properties>
+</medium>
+```
+
+The properties belonging to a phase within a medium, have to be placed inside `<phase> </phase>` tag:
+
+```xml
+<medium id="0">
+ <phases>
+ <phase>
+ <type>Solid</type>
+ <properties>
+ Properties describing the solid phase medium 0
+ </properties>
+ </phase>
+ </phases>
+</medium>
+```
+
+The properties share very similar structure with [parameters](/docs/userguide/blocks/parameters/), but they are not interchangeable.
+
+Following basic types of properties are available:
+
+- [Constant](/docs/userguide/blocks/media/#constant)
+- [Linear](/docs/userguide/blocks/media/#linear)
+- [Function](/docs/userguide/blocks/media/#function)
+- [Curve](/docs/userguide/blocks/media/#curve)
+
+They can be used by the user to define the properties in a way, that is specific to their simulation.
+
+There are more general properties available.
+They are described in section [Other types of properties](/docs/userguide/blocks/media/#other-types-of-properties).
+
+Generally, it is the most safe to use "Constant" type for properties and when it is not sufficient, type "Parameter" can be used as fallback.
+Still, there are some limitations to what types of parameter can be used in different processes.
+
+Differently than the parameters in the Parameter block, in the Media block parameters can depend on more variables than x, y, z and t.
+
+Type linear, function and curve can depend on a set of variable listed in [MPL->VariableType.h](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/MaterialLib/MPL/VariableType.h):
+
+- capillary_pressure
+- concentration
+- density
+- displacement
+- effective_pore_pressure
+- enthalpy_of_evaporation
+- equivalent_plastic_strain
+- grain_compressibility
+- liquid_phase_pressure
+- liquid_saturation
+- mechanical_strain
+- molar_mass
+- molar_mass_derivative
+- molar_fraction
+- phase_pressure
+- porosity
+- solid_grain_pressure
+- stress
+- temperature
+- total_strain
+- total_stress
+- transport_porosity
+- vapour_pressure
+- volumetric_strain
+
+Keep in mind that not all of those variables will be available in all the processes. For example, in THM there is phase_pressure, but not liquid_phase_pressure.
+
+### Constant
+
+This is the most basic type. It only requires `<value> </value>` tag additionally where the value of the parameter is provided as a number. It will not change throughout the experiment. For example:
+
+```xml
+<parameter>
+ <name>earth_acceleration</name>
+ <type>Constant</type>
+ <value>9.81<value>
+</parameter>
+```
+
+For vectorial quantities use plural, `<values>0.5 1 2</values>`, for example will be interpreted as a 3d vector.
+
+### Linear
+
+Type linear, can be used to declare parameters that vary linearly depending on value of another parameter.
+
+Apart from standard required tags: `<name> </name>` and `<type> </type>`, `<reference_value> </reference_value>` has to be provided.
+
+Linear parameter can depend on values describing position (x, y and z) and time (t).
+Linear dependency on each independent variable requires `<reference_condition> </reference_condition>` and `<slope> </slope>`.
+
+Consider simple linear equation:
+$$
+y(x)=ax+b
+$$
+let's say that there is a parameter $y$ that depends linearly on time:
+$$
+y(T)=a*t+y_0
+$$
+Defining it as linear type would look like this in project file:
+
+```xml
+<property>
+ <name>y</name>
+ <type>Linear</type>
+ <reference_value>y_0</reference_value>
+ <independent_variable>
+ <variable_name>time</variable_name>
+ <reference_condition>t_0</reference_condition>
+ <slope>a</slope>
+ </independent_variable>
+</property>
+```
+
+where reference value $y_0$ is defined as follows:
+$$
+y_0=y(t_0)
+$$
+
+A more realistic example can be found in benchmark [A2](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/HydroMechanics/A2/A2.prj), where the fluid density linearly but independently depends on pressure and temperature:
+
+```xml
+<property>
+ <name>density</name>
+ <type>Linear</type>
+ <reference_value>1200</reference_value>
+ <independent_variable>
+ <variable_name>temperature</variable_name>
+ <reference_condition>298.15</reference_condition>
+ <slope>-6.0e-4</slope>
+ </independent_variable>
+ <independent_variable>
+ <variable_name>phase_pressure</variable_name>
+ <reference_condition>4e6</reference_condition>
+ <slope>0.5e-9</slope>
+ </independent_variable>
+</property>
+```
+
+The definition of density provided in the snippet above can be expressed by following equations:
+$$
+\rho(T=298.15, p=4e6)=1200
+$$
+$$
+\rho(T)=(-6*10^{-4})*T+1200
+$$
+$$
+\rho(p)=(0.5*10^{9})*p+1200
+$$
+
+### Function
+
+Type function extends the basic structure of [constant type](/docs/userguide/blocks/parameters/#constant).
+There are two major differences though.
+The expression that defines a function has to be placed inside of the `<expression> </expression>` tag nested inside of the `<value> </value>` tag.
+Additionally, derivations with respect to applicable process variables have to be provided inside following this template:
+
+```xml
+<dvalue>
+ <variable_name>primary variable derived over</variable_name>
+ <expression>expression of derivation of function w.r.t. specific primary variable </expression>
+</dvalue>
+```
+
+#### Convention & Syntax
+
+Powers are indicated by "^", e.g.: 2^3=8.
+
+In scientific notation, power can be appended by leading zeros. So `0.002=2e-3=2e-03`, those three expression will evaluate to the same value in OpenGeoSys.
+
+C++ functions (for example std::pow) cannot be called from the expression tag.
+
+The [`exprtk`](http://www.partow.net/programming/exprtk/) library interpreting such expressions is used in OGS and the full list of available functions and control structures can be found on its web page.
+
+#### Example
+
+Consider function defining viscosity of water depending on temperature:
+
+$$ \mu = ( -0.0002 * T^3 + 0.05 * T^2 - 4 * T + 178) * 10^{-5}$$
+
+and its partial derivative with respect to temperature:
+$$ \frac{\partial \mu}{\partial T} = ( -0.0006 * T^2 + 0.1 * T - 4) * 10^{-5} $$
+
+With the two equations above, the full implementation of water viscosity depending on phase pressure and temperature will look as follows:
+
+```xml
+<property>
+ <name>viscosity</name>
+ <type>Function</type>
+ <value>
+ <expression>(-0.0002*(temperature-273.15)^3+0.05*(temperature-273.15)^2-4*(temperature-273.15)+178)*1e-5</expression>
+ </value>
+ <dvalue>
+ <variable_name>temperature</variable_name>
+ <expression>(-0.0006*(temperature-273.15)^2+0.1*(temperature-273.15)-4)*1e-5</expression>
+ </dvalue>
+</property>
+```
+
+There are limitations of what variables can be used inside of the `<expression> </expression>` tags. Only the ones related to the process variables can be called. The values defined for example in parameter block are out of reach.
+TODO: Check if this is correct
+
+For example if ```thermal_conductivity``` is defined and density is provided as Function, the dvalue of density with respect to temperature will be ignored.
+
+Notice, that OpenGeoSys assumes self consistent set of units.
+In the code snippet above temperature has to be converted from kelvins (used by other temperature dependent parameters in the project from which this snippet comes) to degrees Celsius required by the provided formula.
+OpenGeoSys doesn't have an internal unit management system.
+It is your task to ensure, that the units used are consistent and compatible!
+
+### Curve
+
+Curve is a bit special type, as it requires presence of another block in the project file.
+Whether the parameter is defined in Parameters block, or anywhere else in the project file, type curve will always refer to curve defined in [curve block](/docs/userguide/blocks//curves/).
+Regardless, of whether there is only one curve defined or multiple, they are always identified by the content of tag `<name> </name>`.
+
+
+
+Parameter of type curve can be defined using the following template:
+
+```xml
+<property>
+ <name>property_name</name>
+ <type>Curve</type>
+ <independent_variable>curve_name_coords</independent_variable>
+ <curve>curve_name</curve>
+</property>
+```
+
+where independent variable refers the values in tag `<coords> </coords>` in block `<curves> </curves>`.
+For more details see [example of curve definition](/docs/userguide/blocks/curves/#example).
+
+Type "Curve" is different to the one "Properties" tag.
+In the "Expression" tag only numerical values and x, y, z, t variables and curves can be used.
+
+## Other types of properties
+
+Some properties that are valid for different simulation and can be reused are implemented in OpenGeoSys.
+In this section they will be discussed, but this list is not complete.
+
+### Water properties - IAPWS97 model
+
+The water property model [IAPWS97](http://www.iapws.org/relguide/IF97-Rev.html) ([International Association for the Properties of Water and Steam](http://www.iapws.org)) is implemented in the OpenGeoSys.
+Various properties of water can be called by providing an appropriate tag:
+
+- density `<type>WaterDensityIAPWSIF97Region1</type>`
+- viscosity `<type>WaterViscosityIAPWS</type>`
+- thermal conductivity `<type>WaterThermalConductivityIAPWS</type>`
+
+Those tags can be used only on the phase level. Please see following example:
+
+```xml
+<phase>
+ <type>AqueousLiquid</type>
+ <properties>
+ <property>
+ <name>density</name>
+ <type>WaterDensityIAPWSIF97Region1</type>
+ </property>
+ <property>
+ <name>viscosity</name>
+ <type>WaterViscosityIAPWS</type>
+ </property>
+ <property>
+ <name>viscosity</name>
+ <type>WaterThermalConductivityIAPWS</type>
+ </property>
+ </properties>
+</phase>
+```
+
+For those properties SI units are used, OpenGeoSys doesn't convert units internally.
+Users need to ensure, that the parameters that are provided in the project file use consistent and correct units.
+
+### Supported types of properties and special cases
+
+TODO: Add content
diff --git a/web/content/docs/userguide/blocks/meshes.md b/web/content/docs/userguide/blocks/meshes.md
new file mode 100644
index 0000000000000000000000000000000000000000..3568ac45eb729bfd04e8b2f5d0007242c41386c6
--- /dev/null
+++ b/web/content/docs/userguide/blocks/meshes.md
@@ -0,0 +1,31 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Meshes"
+author = "Feliks Kiszkurno"
+weight = 2
++++
+
+Minimum of two files has to be provided.
+One for the mesh of the domain and one for the boundaries. Arbitrary many mesh files can be provided.
+Generally, if the boundary conditions vary between boundaries, there should be one mesh file provided for each set of boundaries sharing the same conditions.
+Alternatively Python boundary conditions can be used.
+
+```xml
+ <mesh>mesh_file_name.mesh_extension</mesh>
+```
+
+## Axial symmetry
+
+Additionally it can be specified, that provided mesh is axially symmetric:
+
+```xml
+ <mesh axially_symmetric="true">
+ mesh_file_name.mesh_extension
+ </mesh>
+```
+
+if it is set to "True", the mesh will be "fully" - 360° symmetric.
+This is relevant for scaling of the source term (see [Source term](/docs/userguide/blocks/processes/#source-term)).
+
+OGS follows standard axis convention: XY is a horizontal plane and Z is vertical.
+By default the rotation will be around Y-axis. See [specific body force](/docs/userguide/blocks/processes/#specific-body-force) for details on including gravitational force.
diff --git a/web/content/docs/userguide/blocks/misc/constitutive_relations.md b/web/content/docs/userguide/blocks/misc/constitutive_relations.md
new file mode 100644
index 0000000000000000000000000000000000000000..a7dfcbf4c86b3e8668877b937dd7bff589cc89dc
--- /dev/null
+++ b/web/content/docs/userguide/blocks/misc/constitutive_relations.md
@@ -0,0 +1,65 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Constitutive relations"
+author = "Feliks Kiszkurno"
+weight = 14
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+## Overview
+
+## CreepBGRa
+TODO: Add content
+
+## Ehlers
+TODO: Add content
+
+## Linear Elastic Isotropic
+TODO: Add content
+
+## Linear Elastic Orthotropic
+TODO: Add content
+
+## Lubby2
+TODO: Add content
+
+## MFront
+
+This section only describes how to use an MFront constitutive relation inside of the project file. For details on how to create such a constitutive relation, please see [MFront](/docs/userguide/features/mfront/) section.
+
+In the project file, MFront model has to be selected as constitutive model in `<process> </process>` tag. See following example:
+
+```xml
+<constitutive_relation id="0">
+ <type>MFront</type>
+ <behaviour>ModelName</behaviour>
+ <material_properties>
+ <material_property name="MatPropName" parameter="ParameterName"/>
+ </material_properties>
+</constitutive_relation>
+```
+
+In this example ModelName has to match one of the MFront files in the OpenGeoSys source code. [Attribute](/docs/userguide/basics/project_file_intro/#attributes) "name" defines name of one of the material properties in the MFront file (see [next section](/docs/userguide/features/mfront/#preparing-opengeosys-to-use-new-mfront-model) for details on how to add new model).
+The value of "parameter" attribute in `<material_property/>` has to match one of the content of tag `<name> </name>` in one of the [parameters](/docs/userguide/blocks/parameters/) block. For example:
+
+```xml
+<parameter>
+ <name>ParameterName</name>
+ <type>Constant</type>
+ <value>value_of_parameter_Name</type>
+</parameter>
+```
+
+Tag `<material_properties> </material_properties>` can be used as many times as it is necessary.
diff --git a/web/content/docs/userguide/blocks/misc/figures/scalingsourceterm_mesh.png b/web/content/docs/userguide/blocks/misc/figures/scalingsourceterm_mesh.png
new file mode 100644
index 0000000000000000000000000000000000000000..e10b618ff11dbb4aeacd773fc71d35a07a99ba92
Binary files /dev/null and b/web/content/docs/userguide/blocks/misc/figures/scalingsourceterm_mesh.png differ
diff --git a/web/content/docs/userguide/blocks/misc/scaling_source_term.md b/web/content/docs/userguide/blocks/misc/scaling_source_term.md
new file mode 100644
index 0000000000000000000000000000000000000000..89befb5163b8a6fec38bd3ee15b2508214541004
--- /dev/null
+++ b/web/content/docs/userguide/blocks/misc/scaling_source_term.md
@@ -0,0 +1,71 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Scaling source term"
+author = "Feliks Kiszkurno"
+weight = 13
++++
+
+Consider a heat source defined as boundary in following mesh:
+
+
+|:--:|
+| *The "dent" in the right side of the mesh is a 2D, rectangular source* |
+
+With height alongside Y-axis defined as $h=8$ metres and width alongside X-axis as $r=0.095$ metre. Since Boundary parallel to Y-axis is [axially symmetrical](/docs/userguide/blocks/meshes/#axial-symmetry), the two dimensional rectangle will turn into a three dimensional cylinder after the mesh has been rotated by $360°$ with Y-axis boundary as rotation axis.
+
+The source term has to take this into account. Therefore its power has to be scaled - divided by the surface on which it will be delivered to the system.
+
+Following this example. Surface of the cylinder is defined as follows:
+
+$$A=2\pi r(h+r)$$
+
+which will result in following surface:
+
+$$A = 2\pi * 0.095 * (8 + 0.095) = 4.83$$
+
+in $m^2$.
+
+Let's assume that the heat supply is defined as 900W. Than we need to scale this value by the surface obtained from the previous equation:
+
+$$S_{scaled}=900/4.83=186.34$$
+
+and this is the value that has to be provided in the project file.
+
+In this example heat source is introduced as [Neumann boundary condition](/docs/userguide/blocks/boundary_conditions/#neumann) at part of the mesh. First we can define parameter called "heater" in the [parameters](/docs/userguide/blocks/parameters/) block:
+
+```xml
+<parameter>
+ <name>heater</name>
+ <!--values>900/(2*pi*0.095*(0.095+8)</values-->
+ <!--values>186.34</values-->
+ <type>Constant</type>
+ <value>186.34</value>
+</parameter>
+```
+
+Now we can refer to this value in the [process variables](/docs/userguide/blocks/process_variables/) block:
+
+```xml
+<process_variable>
+ <name>temperature</name>
+ <components>1</components>
+ <order>1</order>
+ <initial_condition>293.15</initial_condition>
+ <boundary_conditions>
+ <boundary_condition>
+ <mesh>Mesh_Boundary</mesh>
+ <type>Dirichlet</type>
+ <component>0</component>
+ <parameter>293.15</parameter>
+ </boundary_condition>
+ <boundary_condition>
+ <mesh>Mesh_Heat_Source</mesh>
+ <type>Neumann</type>
+ <component>0</component>
+ <parameter>heater</parameter>
+ </boundary_condition>
+ </boundary_conditions>
+</process_variable>
+```
+
+Notice how different type of boundary condition is used for the heat source and rest of the boundary. More details on boundary conditions can be found [here](/docs/userguide/blocks/boundary_conditions/).
diff --git a/web/content/docs/userguide/blocks/nonlinear_solvers.md b/web/content/docs/userguide/blocks/nonlinear_solvers.md
new file mode 100644
index 0000000000000000000000000000000000000000..0577bbdc18ede5cdad0cfe72959ea516649092dc
--- /dev/null
+++ b/web/content/docs/userguide/blocks/nonlinear_solvers.md
@@ -0,0 +1,45 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Nonlinear solvers"
+author = "Feliks Kiszkurno"
+weight = 8
++++
+
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+Following non-linear solvers are available in OpenGeoSys:
+
+- [Newton](/docs/userguide/blocks/nonlinear_solvers/#newton)
+- [Picard](/docs/userguide/blocks/nonlinear_solvers/#picard)
+
+## Newton
+
+TODO: add content
+
+The nonlinear solver of "Newton" type is the implementation of the Newton-Raphson method.
+Basic definition of non-linear solver follows this template:
+
+```xml
+<nonlinear_solver>
+ <name>basic_newton</name>
+ <type>Newton</type>
+ <max_iter>100</max_iter>
+ <linear_solver>linear_solver</linear_solver>
+</nonlinear_solver>
+```
+
+## Picard
+
+TODO: add content
diff --git a/web/content/docs/userguide/blocks/parameters.md b/web/content/docs/userguide/blocks/parameters.md
new file mode 100644
index 0000000000000000000000000000000000000000..66d7de6e1099c6d6edb072f6f2b0ae94b3af1ef2
--- /dev/null
+++ b/web/content/docs/userguide/blocks/parameters.md
@@ -0,0 +1,109 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Parameters"
+author = "Feliks Kiszkurno"
+weight = 5
++++
+
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+This block contains various parameters which are used by other blocks within the project file.
+
+The possible content of this block in not limited to physical properties of materials used in the experiment but also to values of [boundary](/docs/userguide/blocks/process_variables/#boundary-conditions) and [initial conditions](/docs/userguide/blocks/process_variables/#initial-conditions) or [source terms](/docs/userguide/blocks/process_variables/#sources), physical constants, etc.
+
+## Where can the parameters be used?
+
+The parameters defined in this block can be used in blocks:
+
+- [Media](/docs/userguide/blocks/media/)
+- [Process variables](/docs/userguide/blocks/process_variables/)
+
+## Parameters vs properties
+
+TODO: describe differences in access to parameters and properties
+
+## How to define a parameter?
+
+To create a parameter within the `<parameters> </parameters>` tag, following template can be used:
+
+```xml
+<parameter>
+ <name>...</name>
+ <type>...</type>
+</parameter>
+```
+
+Tags `<name> </name>` and `<type> </type>` are mandatory and define human-readable name of specific parameter and declare one of available types with which it will be defined.
+Other tags depend on what is the content of `<type> </type>`.
+There are following types available:
+
+- [Constant](/docs/userguide/blocks/parameters/#constant)
+- [CurveScaled](/docs/userguide/blocks/parameters/#curvescaled)
+
+Each of them will be discussed below.
+The same types can be used to define media properties in the [media block](/docs/userguide/blocks/media/).
+
+### Constant
+
+This is the most basic type.
+It only requires `<value> </value>` tag additionally where the value of the parameter is provided as a number.
+It will not change throughout the experiment.
+For example:
+
+```xml
+<parameter>
+ <name>earth_acceleration</name>
+ <type>Constant</type>
+ <value>9.81<value>
+</parameter>
+```
+
+For vectorial quantities use plural, `<values>0.5 1 2</values>`, for example will be interpreted as a 3d vector:
+
+```xml
+<parameter>
+ <name>some_anisotropic_parameter</name>
+ <type>Constant</type>
+ <value>0.5 1 2</value>
+</parameter>
+```
+
+### CurveScaled
+
+It requires tags: `<curve> </curve>` and `<parameter> </parameter>`.
+The first one contains name of a curve defined in the `<curves> </curves>` block (for more detail see [curves](/docs/userguide/blocks/curves/)).
+It is not the same type as [Curve](/docs/userguide/blocks/media/#curve) discussed in Media block.
+
+Following variables are accessible from CurveScaled:
+
+- spatial: x, y, z
+- temporal: t
+
+```xml
+<parameter>
+ <name>p_Dirichlet_right</name>
+ <type>CurveScaled</type>
+ <curve>p_Dirichlet_right_temporal</curve>
+ <parameter>t</parameter>
+</parameter>
+```
+
+```xml
+<curve>
+ <name>p_Dirichlet_right_temporal</name>
+ <coords>0.0 10.0</coords>
+ <values>0.0 10.0</values>
+</curve>
+```
diff --git a/web/content/docs/userguide/blocks/process_variables.md b/web/content/docs/userguide/blocks/process_variables.md
new file mode 100644
index 0000000000000000000000000000000000000000..8efc389b8c31ce10aa5f74722c19ab757e68adf3
--- /dev/null
+++ b/web/content/docs/userguide/blocks/process_variables.md
@@ -0,0 +1,113 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Process variables"
+author = "Feliks Kiszkurno"
+weight = 7
++++
+
+All "process parameters" defined in "Process" Section has to be addressed here (see [processes](/docs/userguide/blocks/processes/)).
+
+```xml
+<process_variable>
+ <name>"process_variable"</name>
+ <components>integer</components>
+ <order>integer</order>
+ <initial_condition>variable_name</initial_condition>
+ <boundary_conditions>
+ <boundary_condition>
+ <type>Dirichlet</type>
+ <mesh>Temp_Dis_mesh_boundary</mesh>
+ <component>1</component>
+ <parameter>dirichlet0</parameter>
+ </boundary_condition>
+ </boundary_conditions>
+</process_variable>
+```
+The block `<process_variable>` has be defined separately for each process variable defined in [Block "Process/Process variables"](/docs/userguide/blocks/process/#process-variables).
+
+There are three major blocks in this one.
+Two of them are mandatory, in following order:
+
+- [Initial conditions](/docs/userguide/blocks/process_variables/#initial-conditions)
+- [Boundary conditions](/docs/userguide/blocks/process_variables/#boundary-conditions)
+
+and optionally:
+
+- [Source terms](/docs/userguide/blocks/process_variables/#sources)
+
+can be defined.
+
+Tag "components" refers to how many directional components variable has, for example for displacement in 2D THM process will have 2 (for x and y directions).
+
+`<initial_conditions>`tag should contain the name of variable defined in [parameters block](/docs/userguide/blocks/parameters/).
+
+## Initial conditions
+
+Initial conditions define the state of the primary variables in the domain at $t=0$.
+Each process will require a different set of them, see [process variables](/docs/userguide/blocks/processes/#process-variables) for more details.
+
+The value of initial temperature can be defined in [parameters block](/docs/userguide/blocks/parameters/) and called from `<process_variable> </process_variable>` by the content of `<name> </name>` tag.
+See following example:
+
+```xml
+...
+ <name>temperature</name>
+ <initial_condition>initial_temperature</initial_condition>
+...
+...
+<parameter>
+ <name>initial_temperature</name>
+ <type>Constant</type>
+ <value>273.15</value>
+</parameter>
+```
+
+## Boundary conditions
+
+ The two most commonly used boundary conditions types are [Dirichlet](/docs/userguide/blocks/boundary_conditions/#dirichlet) and [Neumann](/docs/userguide/blocks/boundary_conditions/#neumann).
+ First one can be used to set boundary condition at a set value, Neumann can be used for flow (energy for example).
+ For more details on both issues, see [sources](/docs/userguide/blocks/process_variables/#sources).
+ For simulations which require more complicated values at boundaries (for example spatially variable), [Python boundary conditions](/docs/userguide/blocks/boundary_conditions/#python) can be used.
+
+ It is possible to define source at the boundaries of the simulation domain using boundary conditions.
+ For more details, see [Setting source term at a boundary](/docs/userguide/blocks/boundary_conditions/#setting-source-term-at-a-boundary)
+
+## Sources
+
+Providing sources is not mandatory and will not prevent simulation from running.
+There are two ways how sources can be defined in the project file: as boundary condition and as source term.
+
+### Source term
+
+There are following types available: nodal, volumetric.
+
+```xml
+<source_term>
+ <geometrical_set>geometry</geometrical_set>
+ <geometry>inner</geometry>
+ <type>Nodal</type>
+ <parameter>pressure_source_term</parameter>
+</source_term>
+```
+
+### Source as boundary condition
+
+Defining it as boundary condition can be done in the same way as it was described in the paragraph above.
+
+### Scaling a source
+
+Neumann boundary condition should be scaled by the surface of the source:
+
+$$ Q_{scaled} = Q_{term} / a $$
+
+where $Q$ is source term, $a$ and resulting unit is power over scaling surface area or length depending on dimension ($[W / L^{dim-1}]$).
+For example if the source is 2D, the scaling factor $a$ will be the length of it's circumference (or the relevant part of it if the source is at the boundary of the domain) and similarly in 3D case, the relevant area.
+If the mesh is axially symmetric, it has to be considered that it is fully symmetric.
+The 2D source will be rotated by $360°$.
+For example a rectangular source at the axis of symmetry, will have to be considered as a cylinder.
+For scaling the surface of the cylinder has to be used,not the relevant part of the circumference of the rectangle.
+
+If source is placed on the axially symmetrical boundary and has radius equal to 0, it has to be defined as boundary condition not as source term.
+If radius is non zero, it can be defined using source term.
+
+For more detailed description see [scaling a source term](/docs/userguide/blocks/misc/scaling_source_term/).
diff --git a/web/content/docs/userguide/blocks/processes.md b/web/content/docs/userguide/blocks/processes.md
new file mode 100644
index 0000000000000000000000000000000000000000..a1d2bbbc9158a504485bad0adf306f226902bbf7
--- /dev/null
+++ b/web/content/docs/userguide/blocks/processes.md
@@ -0,0 +1,163 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Processes"
+author = "Feliks Kiszkurno"
+weight = 3
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+Process block is defined with `<process> </process>` tags.
+
+This section defines the process, that is modelled in the project.
+It has to contain 'name' and 'type' tags:
+
+```xml
+<name>THM</name>
+<type>THERMO_HYDRO_MECHANICS</type>
+```
+
+Name can be defined freely, type has to contain one of following strings [list of available processes](https://doxygen.opengeosys.org/d5/d98/ogs_file_param__prj__processes__process.html). More details about some of them can be found in the [Process-dependent configuration](/docs/processes/heat-transport/heat_transport_bhe/) section.
+
+## Integration order
+
+Tag `<integration_order> </integration_order>` is mandatory and defines the integration order of the Gauss-Legendre integration over an element.
+
+## Process variables
+
+An important part of this section is defined in "process\_variables" tag. It is important, because in later parts of the project files (e.g.: in definition of errors). Those variables and their order are specific to each type of process. The order in which those variables have been defined in each process plays an important role.
+For more details see [time loop](/docs/userguide/blocks/time_loop/) and [linear solvers](/docs/userguide/blocks/linear_solvers/).
+Information of which variables are required for which process can be found in appropriate sections of the Doxygen documentation.
+For example, for THM process following parameters are required:
+
+```xml
+<process_variables>
+ <temperature>temperature</temperature>
+ <pressure>pressure</pressure>
+ <displacement>displacement</displacement>
+</process_variables>
+```
+
+## Secondary variables
+
+This tag is optional.
+It allows to define which secondary variables will be computed and saved in the output files.
+Which secondary variables are available is dependent on a specific process.
+They can be defined as follows:
+
+```xml
+<secondary_variables>
+ <secondary_variable internal_name="internal_name" output_name="output_name"/>
+</secondary_variables>
+```
+
+where internal name has to match the name of one of available secondary variables and output name can be defined by the user.
+Output name will be used as the name of the field into which specific variable will be written into in output files.
+
+## Error tolerances
+
+In this section, within `<convergence\_criterion>` tag, relative tolerances for error have to be defined - with tag `<reltols>`.
+Each value in this tag defines the tolerance for errors with respect to one process variables.
+The order of variables is process specific.
+For the process variables listed above, relative error tolerances can be defined as follows:
+
+```xml
+<reltols>
+ reltol_temp
+ reltol_press
+ reltol_disp_0
+ reltol_disp_1
+</reltols>
+```
+
+The order can differ based on the order in which they are defined in a process and on dimensionality of the process (*e.g.* number of components in displacement, or number of chemical constituents).
+Keep in mind, that some process variables have more than one values, as displacement in the example above.
+In such a case, a matching number of reltols has to be defined.
+
+## Constitutive relations
+
+Constitutive relation can be one of the [existing relations](/docs/userguide/blocks/misc/constitutive_relations/) implemented in OpenGeoSys or it can be defined by user using [MFront](/docs/userguide/features/mfront/).
+They are used with one of the following mechanical processes:
+
+* Hydro Mechanics
+* Phase Field
+* Richards Mechanics
+* Small Deformation
+* Thermo Mechanics
+* Thermo Hydro Mechanics
+* Thermo Richards Mechanics
+* TH2M
+
+To define constitutive relation, tags `<constitutive_relation> </constitutive_relation>` are used.
+The fixed, minimum requirement is presence of `<type> </type>` tag. Other tags depend on the chosen relation.
+
+There can be more than one constitutive relation used in one project file but only one for each material id, similar to how each medium is defined in [media block](/docs/userguide/blocks/media/).
+OpenGeoSys selects constitutive relation for a material id based on the content of the attribute id in tags `<constitutive_relation> </constitutive_relation>` and `<medium> </medium>`.
+
+## Source terms
+
+There are four available types of source terms:
+
+* Line
+* Nodal
+* Volumetric
+* Python
+
+ The source term has to be scaled by the volume.
+
+## Specific body force
+
+ The tag `<specific_body_force>` can be used to define gravitational force.
+ This tag is optional.
+ By default it is not considered in the simulation, it has to be be explicitly enabled by setting an appropriate value in project file.
+ Presence of this tag, should be reflected in initial stress conditions.
+ It can improve the convergence in the first time step, if the correct stress field is defined.
+
+```xml
+<process>
+ ...
+ <specific_body_force>in_X_direction in_Y_direction in_Z_direction
+ </specific_body_force>
+ ...
+</process>
+```
+
+In 3D case it has to be defined on Z-axis as negative value: $-9.81$.
+So the code in project file would look like this:
+
+```xml
+<process>
+ ...
+ <specific_body_force>0 0 -9.81</specific_body_force>
+ ...
+</process>
+```
+
+**Warning!** If specific body force is added, it can be reflected with the initial state of stress.
+
+Stress is a a bit unique, as initial condition for stress are not defined in block "Process variables", but in "Process".
+It requires setting up a constant or function definition in "Parameters" block where initial stress is defined.
+It has to match the dimension of experiment.
+OGS expects it to be effective stress (total stress with pore pressure subtracted), this is in contrast to total stress that is expected to be provided in boundary condition.
+If meshes are defined as axially symmetrical, the stress has to be provided in polar or cylindrical coordinates.
+
+## Jacobian Assembler
+
+TODO: Explanations for each type.
+
+The global non-linear equation system can be solved either with Picard fix-point iterations or a Newton scheme. (TODO: Reference NLS scheme)
+For the latter the process has to provide an analytical Jacobian.
+If the analytical Jacobian was not implemented, one can use a quasi-Newton scheme where the Jacobian is approximated by a central differences or forward differences scheme.
+
+For the Picard fix-point iterations this section is not used.
diff --git a/web/content/docs/userguide/blocks/test_definitions.md b/web/content/docs/userguide/blocks/test_definitions.md
new file mode 100644
index 0000000000000000000000000000000000000000..961157ec872c781c0af7888ae54fff84c5e88123
--- /dev/null
+++ b/web/content/docs/userguide/blocks/test_definitions.md
@@ -0,0 +1,8 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Test definitions"
+author = "Feliks Kiszkurno"
+weight = 11
++++
+
+TODO: describe usage of test definitions, reference the `-o` and `-r` command line arguments, `vtkdiff`.
\ No newline at end of file
diff --git a/web/content/docs/userguide/blocks/time_loop.md b/web/content/docs/userguide/blocks/time_loop.md
new file mode 100644
index 0000000000000000000000000000000000000000..2a9b3ea38ca6024127388dbee08ca7ddc0bd0e44
--- /dev/null
+++ b/web/content/docs/userguide/blocks/time_loop.md
@@ -0,0 +1,314 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Time loop"
+author = "Feliks Kiszkurno"
+weight = 6
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+This block defines all aspects related to the progress of time in the simulation and controls when the output files will be written, their naming pattern and content.
+
+## Process
+
+First section of this block, the one controlling time progress has to be set up separately for each process defined in [processes block](/docs/userguide/blocks/processes/#process-variables) separately.
+There can be more than one process defined.
+They are distinguished with the parameter "ref" in the `<process>` tag:
+
+```xml
+<process ref="Process_name">
+ ...
+</process>
+```
+
+### Time stepping
+
+Numerical simulations proceed in time steps.
+Their size is important factor impacting if a stable solution will be found.
+
+In OpenGeoSys the following time step definitions are available:
+
+- FixedTimeStepping
+- SingleStep
+- IterationNumberBasedTimeStepping
+- EvolutionaryPIDcontroller
+
+#### Single time step
+
+This is the simplest type of time steppings used for solution of elliptic pdes as in the `SteadyStateDiffusion` process.
+It only requires its type to be given:
+
+```xml
+<time_stepping>
+ <type>SingleStep</type>
+</time_stepping>
+```
+
+#### Fixed time stepping
+
+This type of time stepping will run the simulation with predetermined number of steps from start to end of the simulation.
+The steps are defined with parameter pair of number of repetitions and length. It is allowed to define multiple pairs. This way, the time step can vary throughout the experiment.
+
+In the example below, a duration of $1$ time unit is simulated, with first 5 time steps being $0.1$ time unit long and next 10 being $0.05$ time unit long.
+
+```xml
+<time_stepping>
+ <type>FixedTimeStepping</type>
+ <t_initial>0</t_initial>
+ <t_end>1</t_end>
+ <timesteps>
+ <pair>
+ <repeat> 5 </repeat>
+ <delta_t> 0.1 </delta_t>
+ </pair>
+ <pair>
+ <repeat> 10 </repeat>
+ <delta_t> 0.05 </delta_t>
+ </pair>
+ </timesteps>
+</time_stepping>
+```
+
+An arbitrary number of repeat-delta_t pairs can be provided (though at least one has to be defined).
+It is not required that sum of duration of all time steps perfectly matches the value of end time.
+If this is not the case, a time step at t_end will be added.
+The first time step of the simulation is always at t_initial.
+
+The unit for time has to be consistent with the rest of the units used in the experiment.
+Following SI system, second is a common choice.
+This is how to define experiment simulating a year of time in daily time step using second as time unit:
+
+```xml
+<time_stepping>
+ <type>FixedTimeStepping</type>
+ <t_initial>0</t_initial>
+ <!--t_end>365*24*60*60</t_end-->
+ <t_end>31536000</t_end>
+ <timesteps>
+ <pair>
+ <repeat>365</repeat>
+ <!--delta_t>24*60*60</delta_t-->
+ <delta_t>86400</delta_t>
+ </pair>
+ </timesteps>
+</time_stepping>
+```
+
+The fixed time stepping is the most commonly used type.
+As it is one of the simplest available, it makes a good starting point.
+
+#### Iteration number based time stepping
+
+[See doxygen](https://doxygen.opengeosys.org/df/df4/ogs_file_param__prj__time_loop__processes__process__time_stepping__iterationnumberbasedtimestepping)
+The examples discussed above, would be defined in the project file as follows:
+
+```xml
+<time_stepping>
+ <type>IterationNumberBasedTimeStepping</type>
+ <t_initial>0</t_initial>
+ <t_end>1e16</t_end>
+ <initial_dt>1</initial_dt>
+ <minimum_dt>1</minimum_dt>
+ <maximum_dt>9</maximum_dt>
+ <number_iterations>2 6 8 9</number_iterations>
+ <multiplier>1.6 1.0 0.5 0.25</multiplier>
+</time_stepping>
+```
+
+#### Evolutionary PID controller
+
+[See doxygen](https://doxygen.opengeosys.org/d3/d86/ogs_file_param__prj__time_loop__processes__process__time_stepping__evolutionarypidcontroller)
+
+### Error tolerances
+
+Error tolerances will be applied to the solution vector
+There are two two ways of defining error tolerances:
+
+- relative `<reltosl> </reltols>`
+- absolute `<abstols> </abstols>`
+
+Both of them can be defined as single value, that will be applied to all process variables, or with multiple ones applied to them individually.
+
+If tolerances per process variable are provided, the order of values defined inside of the tags `<abstols> </abstols>` and `<reltosl> </reltols>` has to match order of process variables defined in [processes](/docs/userguide/blocks/processes/).
+If process variable is directional, XYZ pattern is followed.
+For example for a 3D THM problem with directional displacement $\mathbf{u}$ following order has to be used: $T$, $p$, $u_x$, $u_y$, $u_z$.
+The order of $T$, $p$ and $u$ is prescribed by the THM process.
+
+Depending on process and simulation setup, the number of variables in the solution vector can vary.
+In the following example, there are four tolerances given in "abstol": one for T, one for p and two for $\mathbf{u}$ ($u_x$ and $u_y$ as this is a 2D problem):
+
+```xml
+<process_variables>
+ <displacement>displacement</displacement>
+ <pressure>pressure</pressure>
+ <temperature>temperature</temperature>
+</process_variables>
+```
+
+The same order is preserved for [output variables](/docs/userguide/blocks/time_loop/#output).
+
+### Convergence criteria
+
+In this part convergence criterion has to be selected. Following options are available:
+
+- [DeltaX and PerComponentDeltaX](/docs/userguide/blocks/time_loop/#deltax-and-percomponentdeltax)
+- [Residual and PerComponentResidual](/docs/userguide/blocks/time_loop/#residual-and-percomponentresidual)
+
+All of the criterions mentioned above compare value quantifying error with user defined tolerances.
+
+There are three way how error tolerances can be set up:
+
+- only relative tolerances $e_{\mathrm{rel}} \le \epsilon_{\mathrm{rel}}$
+- only absolute tolerances $e_{\mathrm{abs}} \le \epsilon_{\mathrm{abs}}$
+- relative and absolute tolerances $e_{\mathrm{abs}} \le \epsilon_{\mathrm{abs}} \vee e_{\mathrm{rel}} \le \epsilon_{\mathrm{rel}} $
+
+where $e$ indicates error and $\epsilon$ indicates tolerance.
+
+In the last case convergence criterion will be satisfied with **at least one** of the tolerances being met.
+
+Both relative and absolute tolerances can be defined as single value or with separate values for each component, see [error tolerances](/docs/userguide/blocks/time_loop/#error-tolerances) for more details.
+
+#### DeltaX and PerComponentDeltaX
+
+DeltaX criteria are based on the norm value of the update (difference) of the solution between two consecutive iterations and is applied to each process variable.
+If process variable is vectorial, criteria will be applied to each component of the vector.
+
+In this criteria, the error is defined as difference between results vector obtained from two consecutive iterations.
+If this difference drops below tolerance, the criteria is fulfilled and solver will proceed to the next time step.
+
+The DeltaX criterion usually uses the [euclidean norm](/docs/userguide/blocks/time_loop/#euclidan-norm) as indicated by the `<norm_type>` tag value `NORM2`.
+Other possible values are `NORM1` and `INFINITY_N`.
+
+The norm value of the solution vector is compared with the error tolerances.
+They can be provided as absolute, relative or both.
+
+#### Residual and PerComponentResidual
+
+Differently than [DeltaX](/docs/userguide/blocks/time_loop/#deltax-and-percomponentdeltax), the residual based convergence criteria use the residuum values for evaluation, not the increment values.
+
+The residual value is the difference between two sides of modeled equation.
+In analytical solution, they would be perfectly equal, but in numerical solution, this will usually not be the case.
+The lower the residuals are, the closer numerical solution is to fulfilling the equation that is being solved.
+
+In this criteria, error is defined as imbalance between left and right hand sides of the equation.
+Once the residual values drop below user defined tolerances, solution is accepted and solver can proceed to the next time step.
+
+The normal of the residuum vector is compared with the error tolerances.
+They can be provided as absolute, relative or both.
+
+### Time discretizationn
+
+TODO: describe different options for time discretization
+
+For the time being only backward Euler time stepping scheme is available.
+
+## Output
+
+In this section all parameters controlling the output of the data from the simulation are defined.
+
+Currently OpenGeoSys supports two output file formats: VTK and XDMF.
+The desired format for output files can be declared as follows:
+
+```xml
+<type>VTK</type>
+```
+
+The number of time steps at which the output files are written doesn't need to match the simulation time steps.
+They can be defined in the same way as in [fixed time step time stepping](/docs/userguide/blocks/time_loop/#fixed-time-stepping).
+
+If specific times of the simulation are of a special interest to the user, OpenGeoSys can write the output files at times provided in a list in `<fixed_output_times> </fixed_output_times>` tag:
+
+```xml
+<fixed_output_times>
+ 0
+ 10
+ 20
+ 40
+ 80
+ 160
+ 320
+</fixed_output_times>
+```
+
+The naming of output files written at different time steps is handled automatically by OpenGeoSys.
+User can use two tags that allow control over how the file names are structured and what they contain: tags `<suffix> </suffix>` and `<prefix> </prefix>`.
+The rules regarding their content are the same.
+They should contain text string.
+Variables can be used to allow those strings to vary between files.
+Following variables can be called:
+
+- meshname
+- timestep
+- time
+- iteration
+
+They can be used in the file name with syntax illustrated by following example:
+
+```xml
+<suffix>Experiment_name</suffix>
+<prefix>_at_time_step_{:timestep}_time_{:time}_iteration_{:iteration}</prefix>
+```
+
+Name of each file will be automatically appended by a file extension appropriate to the content of `<type> </type>` tag.
+No user action is needed in this regard.
+
+Block `<variables> </variables>` allows user to control what process variables are included in the output files.
+If only some of them are of interest, it may be convenient to reduce size of the output files by only writing the necessary ones.
+If only temperature and pressure are important, this block can be defined as follows:
+
+```xml
+<variables>
+ <variable>temperature</variable>
+ <variable>pressure</variable>
+</variables>
+```
+
+The list of available variables differs between processes.
+TODO: Create list of variables available in different processes
+
+In order to save space, the compression of output files can be enabled with:
+
+```xml
+<compress_output>true</compress_output>
+```
+
+Compression will be performed with zlib.
+
+## Norms
+
+In following section $x$ denotes solution vector.
+
+### Manhattan norm
+
+Norm1 is defined as Manhattan norm in [LinAlg library](https://doxygen.opengeosys.org/d6/dcd/namespacemathlib_1_1linalg#ac7415e1254b70c4015ccd3b6f2873338).
+
+Defined with following equation:
+$$
+x_{norm}=\sum_{i=0}^{n}{|x_i|}
+$$
+
+### Euclidan norm
+
+Norm2 in OpenGeoSys implementation in the [LinAlg library](https://doxygen.opengeosys.org/d6/dcd/namespacemathlib_1_1linalg#af298d1ddc92d7ce52046adc669e9904f).
+
+Defined with following equation:
+$$
+x_{norm} = \sqrt{\sum_{i=0}^{n}{x_i}}
+$$
+
+### Max norm
+
+$$
+\mathrm{max}_i |x_i|
+$$
diff --git a/web/content/docs/userguide/features/_index.md b/web/content/docs/userguide/features/_index.md
new file mode 100644
index 0000000000000000000000000000000000000000..710363f6c7c9c1662a92b9a0f4fc87bf73d35e13
--- /dev/null
+++ b/web/content/docs/userguide/features/_index.md
@@ -0,0 +1,4 @@
++++
+title = "OpenGeoSys Features"
+weight = 3
++++
\ No newline at end of file
diff --git a/web/content/docs/userguide/features/main.md b/web/content/docs/userguide/features/main.md
new file mode 100644
index 0000000000000000000000000000000000000000..b1449041289d78c9a631ae049469a2a114dc6ddf
--- /dev/null
+++ b/web/content/docs/userguide/features/main.md
@@ -0,0 +1,13 @@
++++
+title = " Features overview"
+author = "Feliks Kiszkurno"
+weight = 1
++++
+
+This section will address useful features of OpenGeoSys, for which it takes more to use then than adding appropriate tag / block to the project file. Some of them require additional software install, special compilation flags used or separate file to be provided path to inside the project file.
+
+Following features are available:
+
+* [MFront](/docs/userguide/features/mfront/)
+* [Python boundary condition](/docs/userguide/features/python_bc/)
+* [Running OpenGeoSys with MPI](/docs/userguide/features/parallel_computing_mpi/)
diff --git a/web/content/docs/userguide/features/mfront.md b/web/content/docs/userguide/features/mfront.md
new file mode 100644
index 0000000000000000000000000000000000000000..e5a22c4bfca453fb182a870655f40a8d25f0c19c
--- /dev/null
+++ b/web/content/docs/userguide/features/mfront.md
@@ -0,0 +1,110 @@
++++
+title = "Using MFront with OpenGeoSys"
+author = "Feliks Kiszkurno"
+weight = 2
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+## Goal
+
+[MFront](https://tfel.sourceforge.net/) can be used to run simulation with constitutive model not available in OpenGeoSys or with a modification of one of available ones.
+
+## Prerequisites
+
+OpenGeoSys has to be compiled with flag `-DOGS_USE_MFRONT`. It will enable MFront support and download necessary libraries.
+For more details about compiling OpenGeoSys, see [developer guide - build configuration](/docs/devguide/getting-started/build-configuration/) and [developer guide - MFront installation](/docs/devguide/packages/mfront/).
+
+## Preparing MFront file
+
+TODO: add content
+
+The details of preparing MFront file will not be discussed here. Only the necessary details will be stated.
+
+### Name of the model
+
+At the beginning of the file, name of the model has to be provided as follows:
+
+```c++
+@Behaviour ModelName
+```
+
+The MFront file has to be the same as name provided in the line above:
+
+```c++
+ModelName.mfront
+```
+
+### Material properties
+
+The material properties, that should be read from project file and be used in the MFront model have to be defined using following syntax:
+
+```c++
+@MaterialProperty type MatPropName
+```
+
+The project file has to contain references pointing from one of the parameters to material properties used by the MFront model.
+For details, see next section.
+
+## Preparing project file
+
+Details on how to use a constitutive relation defined with MFront is described [here](/docs/userguide/blocks/misc/constitutive_relations/#mfront).
+
+## Preparing OpenGeoSys to use new MFront model
+
+After the MFront file has been prepared, it has to be placed in the folder containing OpenGeoSys source code at following path:
+
+```c++
+ogs-source-code/MaterialLib/SolidModels/MFront
+```
+
+in the same folder there is `CMakeLists.txt`.
+In that file, there is a list containing names of all MFront models stored in the folder.
+Name of the newly added model has to be added to that list:
+
+```c++
+mfront_behaviours_check_library(
+ ...
+ ModelName
+ ...
+)
+```
+
+To make the new "ModelName" available rerun CMake's "configure" and "generate" steps, and recompile OpenGeoSys.
+(This process should take less time than the first time, as only new code will be compiled.)
+
+<div class='note'>
+
+### Warning
+
+If a compilation error is encountered, it can be caused by inconsistent use of name of the model.
+It is case sensitive and it has to be written in exactly the same way everywhere, where it is used.
+
+</div>
+
+## References
+
+TODO: add content
+
+### Benchmarks using MFront
+
+TODO: add content
+
+### Available MFront models
+
+TODO: add content
+
+## Testing MFront model with MTest
+
+TODO: add content
diff --git a/web/content/docs/userguide/parallel_computing/mpi/index.md b/web/content/docs/userguide/features/parallel_computing_mpi.md
similarity index 99%
rename from web/content/docs/userguide/parallel_computing/mpi/index.md
rename to web/content/docs/userguide/features/parallel_computing_mpi.md
index 4d411f3bd0baea947840f722130198f924b654b4..cedb8f5e5ad02abe89840feb00093ef76f0c77b4 100644
--- a/web/content/docs/userguide/parallel_computing/mpi/index.md
+++ b/web/content/docs/userguide/features/parallel_computing_mpi.md
@@ -2,7 +2,7 @@
title = "Running OGS with MPI"
date = "2022-05-06T11:20:34+02:00"
author = "Wenqing Wang"
-weight = 1
+weight = 4
+++
<!-- vale off -->
diff --git a/web/content/docs/userguide/features/python_bc.md b/web/content/docs/userguide/features/python_bc.md
new file mode 100644
index 0000000000000000000000000000000000000000..9e5dad207af8e6990f6a932810f56b901224f3dc
--- /dev/null
+++ b/web/content/docs/userguide/features/python_bc.md
@@ -0,0 +1,143 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Defining boundary conditions with Python"
+author = "Feliks Kiszkurno"
+weight = 3
++++
+<div class="note">
+
+### Work in progress
+
+This page is a work in progress.
+
+It was published in this state to make existing content available to users and highlight missing parts to contributors.
+
+**Contributors:** please see Documentation Contribution Guide to contribute to the documentation.
+
+**Users:** the content of this page has been verified and is correct. Please return later for more content!
+
+</div>
+
+## Goal
+
+Defining boundary condition with Python script allows more flexible approach.
+For example it can be used to insert time series data or measurements as boundary conditions.
+
+## Prerequisites
+
+OpenGeoSys has to be compiled with `-DOGS_USE_PYTHON` enabled. For more details about compiling OpenGeoSys, see [developer guide - build configuration](/docs/devguide/getting-started/build-configuration/).
+This feature requires basic understanding of classes in Python. Information about them and their syntax can be found in [official Python documentation](https://docs.python.org/3/tutorial/classes.html).
+
+## Using python boundary condition in project file
+
+TODO: add description of how to call python bc from the boundary condition tag
+
+In order to define a boundary condition with python the path `*.py` file, containing the boundary condition script, has to be provided.
+It can be done with tag `<python_script> </python_script>`.
+It is commonly placed in the beginning of the project file between sections "Meshes" and "Processes".
+The path to the file can be defined relatively or absolutely. For example:
+
+```xml
+<python_script>Other_files/Boundary_conditions/BC_North.py</python_script>
+```
+
+## Prepare definition of boundary condition in python script
+
+First, OpenGeoSys module has to be imported:
+
+```python
+import OpenGeoSys
+```
+
+This module doesn't have to be installed, it is part of the python environment created when OpenGeoSys is compiled with Python support.
+For testing or debugging of the Python script outside of OpenGeoSys run environment, it is necessary to comment this line out.
+
+OpenGeoSys will expect a child class of "OpenGeoSys.BoundaryCondition" in the python script:
+
+```python
+class SomeBoundaryCondition(OpenGeoSys.BoundaryCondition)
+```
+
+The two types of boundary conditions that can be defined in Python script are Dirichlet and Neumann.
+
+### Dirichlet boundary condition
+
+OpenGeoSys will obtain values for Dirichlet boundary condition by calling method "getDirichletBCValue".
+
+#### Input
+
+Following variables are always passed as an input to Dirichlet boundary condition method (in bracket default variable name used in examples):
+
+- time (t),
+- spatial coordinates (coords),
+- node id (node_id),
+- primary variables (primary_vars).
+
+#### Output
+
+Dirichlet boundary condition method has to return two values:
+
+- Boolean (True)
+- Value at point for which it was called
+
+The order in which those variables are provided is important.
+
+#### Example
+
+### Neumann boundary condition
+
+OpenGeoSys will obtain values for Neumann boundary condition by calling method "getFlux".
+
+#### Input
+
+Following variables are always passed as an input to Dirichlet boundary condition method (in bracket default variable name used in examples):
+
+- time (t),
+- spatial coordinates (coords),
+- primary variables (primary_vars).
+
+The order in which those variables are provided is important.
+
+#### Output
+
+The expected output of Neumann boundary condition method is similar to the one for Dirichlet but is expanded by value of the Jacobian at specific point at the boundary:
+
+- Boolean (True)
+- Value at point for which it was called
+- Jacobian
+
+## Last step initialize boundary condition object
+
+Within the script, an object has to be created by which OpenGeoSys will access the values provided by the Python script.
+There can be an arbitrary number of boundary condition objects defined in the Python script.
+Each of them can be used for one or multiple instance of boundary condition defined in the project file.
+
+The name of this object will be included in project file in tag `<boundary_condition> <boundary_condition>`
+
+## Benchmarks
+
+For examples of the application of Python boundary conditions can be found in [this group of benchmarks](/docs/benchmarks/python-bc/).
+
+## Full example of python boundary condition
+
+```python
+import OpenGeoSys
+
+class BoundaryCondition(OpenGeoSys):
+
+ def __init__(self):
+ super(OpenGeoSys, BoundaryCondition)
+ # Do here all steps, that should be done only once, e.g.: read and preprocess the data from csv file
+
+ def getFlux(self, coords, t, primary_vars):
+ # For Neumann BC
+
+ return True, BC_value, BC_jacobian
+
+ def getDirichletBCValue(self, t, coords, node_id, primary_vars):
+
+ return True, BC_value
+
+# Initialize boundary condition object
+BC_class = BoundaryCondition()
+```
diff --git a/web/content/docs/userguide/parallel_computing/_index.md b/web/content/docs/userguide/parallel_computing/_index.md
deleted file mode 100644
index 0358e630a1684dbd4eedac9044cf12d40c6c743c..0000000000000000000000000000000000000000
--- a/web/content/docs/userguide/parallel_computing/_index.md
+++ /dev/null
@@ -1,4 +0,0 @@
-+++
-title = "Parallel computing"
-weight = 2
-+++
diff --git a/web/content/docs/userguide/troubleshooting/_index.md b/web/content/docs/userguide/troubleshooting/_index.md
index 7cbf1e43b736336053b8f7373777da290642dd8f..7c6c05b4896dd9d5d3bef580b5092397febfc7ee 100644
--- a/web/content/docs/userguide/troubleshooting/_index.md
+++ b/web/content/docs/userguide/troubleshooting/_index.md
@@ -1,4 +1,4 @@
+++
title = "Troubleshooting"
-weight = 2
+weight = 4
+++
diff --git a/web/content/docs/userguide/troubleshooting/faq.md b/web/content/docs/userguide/troubleshooting/faq.md
new file mode 100644
index 0000000000000000000000000000000000000000..5f2e907da050b07d21f8b3b9dfa73e21b6ea0d3d
--- /dev/null
+++ b/web/content/docs/userguide/troubleshooting/faq.md
@@ -0,0 +1,51 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = " Frequently asked questions"
+author = "Lars Bilke and Feliks Kiszkurno"
+weight = 1
++++
+
+## "XSDError: Loaded schema file is invalid" error encountered when running DataExplorer
+
+You may encountering the following error (or similar) on opening `.gml`, `.cnd`, `std` or `.prj` files in the Data Explorer or file conversion tools (e.g. `OGSFileConverter`):
+
+<i class="far fa-exclamation-triangle"></i> Error message:
+
+```bash
+Error XSDError in http://www.opengeosys.org/images/xsd/OpenGeoSysCND.xsd, at line 1, column 1: Start tag expected.
+Error XSDError in file:///../bc/well.cnd, at line 5, column 195: Loaded schema file is invalid.
+XMLInterface::isValid() - XML File is invalid (in reference to schema ./OpenGeoSysCND.xsd).
+Error XSDError in http://www.opengeosys.org/images/xsd/OpenGeoSysCND.xsd, at line 1, column 1: Start tag expected.
+```
+
+<i class="far fa-arrow-right"></i> Solution:
+
+Open the affected file (e.g. `well.cnd` in this case) in a text editor and remove the following parameter of the XML root element (the first element in `< >`-brackets in the element, e.g. `<OpenGeoSysCND>`):
+
+```xml
+xsi:noNamespaceSchemaLocation="http://www.opengeosys.org/images/xsd/OpenGeoSysXXX.xsd"
+```
+
+where `XXX` can be `CND`, `GLI`, `PRJ` or `STN` depending on the file type.
+
+Now the save the modified file and try to load it again.
+
+<!-- vale off -->
+
+<details>
+ <summary>Background info:</summary>
+ The XSD files may be downloaded from a web location. We changed the protocol of our web site to `https://` but due to some weird behavior of the Qt XML validation code it tries to download the file (even if it is available locally) and does not respect the URL redirection to `https://` of the web server. Simply removing the part solves the problem. The XML is still validated! Newer OGS versions do not write that parameter into files anymore, see [!2198](https://github.com/ufz/ogs/pull/2198).
+</details>
+
+## Oh, no! It diverges
+
+OpenGeoSys will sometimes crash with an error message stating, that it couldn't reduce the time step any more. There are several things that can be done to solve this:
+
+- In [Time loop](/docs/userguide/blocks/time_loop/) adjust time stepping allowing smaller time steps to be taken.
+- In [Time loop](/docs/userguide/blocks/time_loop/) adjust the [error tolerance](/docs/userguide/blocks/time_loop/#error-tolerances)
+- Check if [mesh quality](/docs/userguide/blocks/meshes/#mesh-quality) is sufficient
+- Verify if all [parameters](/docs/userguide/blocks/parameters/), especially those that vary during the simulation, make physical sense through out the whole experiment and combined with other parameters.
+
+## Oh, no! There are NaNs everywhere
+
+If in the output log all values are [NaN](/docs/userguide/troubleshooting/glossary/#nan) and one or more parameters were defined as functions, there is a good chance that division by zero, or other undefined operation happened.
diff --git a/web/content/docs/userguide/troubleshooting/glossary.md b/web/content/docs/userguide/troubleshooting/glossary.md
new file mode 100644
index 0000000000000000000000000000000000000000..0f968d4eff6976ceba991c35831529c1ab0aa02f
--- /dev/null
+++ b/web/content/docs/userguide/troubleshooting/glossary.md
@@ -0,0 +1,114 @@
++++
+date = "2018-02-27T11:00:13+01:00"
+title = "Glossary"
+author = "Feliks Kiszkurno"
+weight = 1
++++
+
+This file will list in alphabetical order some most important terms, that may not be know to wider audience or are used in non standard way in the OpeGeoSys project.
+
+The terms explained in this section are relevant for the "Beginners Guide" in other sections (for example in process descriptions), the meaning of some terms used here may vary.
+
+## A
+
+### Aqueous phase
+
+Liquid phase in porous media. Can be used in THM process....
+
+## B
+
+## C
+
+### Constitutive relation
+
+Known also as constitutive equation. It is an equation defining a relation between physical quantities that is specific to material for which the equation is valid and describes how it responds to external stimulation. For more information click [here](https://en.wikipedia.org/wiki/Constitutive_equation) and for more information on how they are used in OpenGeoSys click [here](/docs/userguide/blocks/processes/#constitutive-relations), for the list of relations available in OpenGeoSys and details on them click [here](/docs//ConstitutiveRelations/ConstitutiveRelationsOverview.md).
+
+### Constitutive equation
+
+See [constitutive relation](/docs/userguide/troubleshooting/glossary/#constitutive-relation).
+
+## D
+
+## E
+
+## F
+
+## G
+
+## H
+
+## I
+
+### Interface
+
+Boundary between two media (geological layers, construction elements, etc.) defined entirely within the simulation domain.
+
+## J
+
+## K
+
+## L
+
+## M
+
+### Medium
+
+Part of the simulation domain characterized by the same physical properties and phase composition. One medium can consists of multiple phases.
+
+## N
+
+### NaN
+
+NaN is an acronym for not-a-number. This value is a result of:
+
+- dividing over 0
+- taking a square root of negative value
+
+### Native installation
+
+Setup in which program (e.g. OpenGeoSys platform) is installed directly in the system running on a specific machine without containers or other intermediary.
+
+## O
+
+## P
+
+### Primary variable
+
+### Process variable
+
+### Project file
+
+Input file provided to OGS executable as the required input argument. It defines all aspects of the simulation that is to be executed.
+
+## Q
+
+## R
+
+### Residuals
+
+Residuals is the difference between left and right hand side of the modeled equation. In theory, if a perfect solution was available, both sides would be equal. Due to numerical errors, it is usually not the case.
+
+## S
+
+### Solution vector
+
+### Secondary variable
+
+## T
+
+## U
+
+## V
+
+### Vectorial process variable
+
+Is a subtype of [process variable](/docs/userguide/troubleshooting/glossary/#process-variable) which is defined as vector. It is mostly directional. An example of vector process variable is displacement which can have a different value in each direction:
+$$
+\mathbf{u} = [u_x u_y u_z]
+$$
+
+## X
+
+## Y
+
+## Z