From 3780e9f240a939b2f2f977c86032fb5a65ff75fd Mon Sep 17 00:00:00 2001
From: Lars Bilke <lars.bilke@ufz.de>
Date: Fri, 6 Jan 2023 15:38:03 +0100
Subject: [PATCH] [web] Moved process dependent configuration to own section.
---
.../_index.md | 5 +-
.../processes/component-transport/_index.md | 4 +
.../hydro-component/index.md} | 60 +++++-----
.../HEAT_TRANSPORT_BHE}/coaxial.png | Bin
.../HEAT_TRANSPORT_BHE}/index.md | 112 +++++++++---------
.../HEAT_TRANSPORT_BHE}/u_type.png | Bin
.../BHE_PipeNetwork_feature_workflow.png | Bin
.../BHE_network.png | Bin
.../index.md | 62 +++++-----
.../docs/processes/heat-transport/_index.md | 4 +
.../Multiphase_Flow_Overview/index.md | 27 +++++
.../docs/processes/multiphase/_index.md | 4 +
.../Multiphase_Flow_Overview/index.md | 29 -----
13 files changed, 161 insertions(+), 146 deletions(-)
rename web/content/docs/{userguide/process-dependent-configuration => processes}/_index.md (50%)
create mode 100644 web/content/docs/processes/component-transport/_index.md
rename web/content/docs/{userguide/process-dependent-configuration/Hydro_Component.md => processes/component-transport/hydro-component/index.md} (77%)
rename web/content/docs/{userguide/process-dependent-configuration/Heat_Transport_BHE => processes/heat-transport/HEAT_TRANSPORT_BHE}/coaxial.png (100%)
rename web/content/docs/{userguide/process-dependent-configuration/Heat_Transport_BHE => processes/heat-transport/HEAT_TRANSPORT_BHE}/index.md (65%)
rename web/content/docs/{userguide/process-dependent-configuration/Heat_Transport_BHE => processes/heat-transport/HEAT_TRANSPORT_BHE}/u_type.png (100%)
rename web/content/docs/{userguide/process-dependent-configuration => processes/heat-transport}/Heat_Transport_BHE_PipelineNetwork/BHE_PipeNetwork_feature_workflow.png (100%)
rename web/content/docs/{userguide/process-dependent-configuration => processes/heat-transport}/Heat_Transport_BHE_PipelineNetwork/BHE_network.png (100%)
rename web/content/docs/{userguide/process-dependent-configuration => processes/heat-transport}/Heat_Transport_BHE_PipelineNetwork/index.md (94%)
create mode 100644 web/content/docs/processes/heat-transport/_index.md
create mode 100644 web/content/docs/processes/multiphase/Multiphase_Flow_Overview/index.md
create mode 100644 web/content/docs/processes/multiphase/_index.md
delete mode 100644 web/content/docs/userguide/process-dependent-configuration/Multiphase_Flow_Overview/index.md
diff --git a/web/content/docs/userguide/process-dependent-configuration/_index.md b/web/content/docs/processes/_index.md
similarity index 50%
rename from web/content/docs/userguide/process-dependent-configuration/_index.md
rename to web/content/docs/processes/_index.md
index 8bb79a4e684..3841b0c8881 100644
--- a/web/content/docs/userguide/process-dependent-configuration/_index.md
+++ b/web/content/docs/processes/_index.md
@@ -1,4 +1,7 @@
+++
title = "Process-dependent configuration"
-weight = 4
+os_selector = false
+
+[cascade]
+breadcumbs = false
+++
diff --git a/web/content/docs/processes/component-transport/_index.md b/web/content/docs/processes/component-transport/_index.md
new file mode 100644
index 00000000000..eaf72d661d2
--- /dev/null
+++ b/web/content/docs/processes/component-transport/_index.md
@@ -0,0 +1,4 @@
++++
+title = "Component Transport"
+weight = 3
++++
diff --git a/web/content/docs/userguide/process-dependent-configuration/Hydro_Component.md b/web/content/docs/processes/component-transport/hydro-component/index.md
similarity index 77%
rename from web/content/docs/userguide/process-dependent-configuration/Hydro_Component.md
rename to web/content/docs/processes/component-transport/hydro-component/index.md
index fbd09457f06..6ef881c4e6c 100644
--- a/web/content/docs/userguide/process-dependent-configuration/Hydro_Component.md
+++ b/web/content/docs/processes/component-transport/hydro-component/index.md
@@ -1,21 +1,21 @@
+++
date = "2022-03-21T12:00:13+01:00"
-title = "Component Transport Process"
+title = "ComponentTransport"
author = "Haibing Shao, Renchao Lu"
-weight = 44
+weight = 4
[menu]
[menu.userguide]
parent = "process-dependent-configuration"
+++
-## Description of the ComponentTransport process
+## Introduction
-ComponentTransport process is widely used to predict the distribution of chemical components in the subsurface, which is controlled by the groundwater flow (advection), the hydrodynamic dispersion and diffusion, the sorption on the solid phase, as well as the decay of component.
+`ComponentTransport` process is widely used to predict the distribution of chemical components in the subsurface, which is controlled by the groundwater flow (advection), the hydrodynamic dispersion and diffusion, the sorption on the solid phase, as well as the decay of component.
## Mathematical framework
-The governing equation implemented in OGS-6 is the so-called advective and diffusion equation (`ADE`), with the consideration of sorption and decay process. ADE is widely used to describe the concentration of chemical components in groundwater aquifer and porous media. The equations can be solved analytically in (simplified) 1D cases. For more complex geometry, especially with heterogeneous material properties, numerical solution is often preferred. The ComponentTransport process has the following assumptions.
+The governing equation implemented in OGS-6 is the so-called advective and diffusion equation (`ADE`), with the consideration of sorption and decay process. ADE is widely used to describe the concentration of chemical components in groundwater aquifer and porous media. The equations can be solved analytically in (simplified) 1D cases. For more complex geometry, especially with heterogeneous material properties, numerical solution is often preferred. The `ComponentTransport` process has the following assumptions.
* The model domain is a porous media and it is fully saturated with water.
* The fluid velocity in the porous media is assumed to be slow, and the flow process is regulated by Darcy's law.
@@ -73,11 +73,11 @@ The following table shows an overview of all input parameters available in the C
In the `ComponentTransport` process, the configuration is as follows.
* `<name>`: name of the chemical component.
-* `<type>`: must be ComponentTransport.
-* `<integration_order>`: This is the order of the integration method for element-wise integration. In common cases set to 2.
-* `<process_variables>`: The primary variables of the ComponentTransport process are either `<concentration>` or `<pressure>`. For the variable concentration, the name of the chemical component is given. Like in the following example, there are 3 chemical components, i.e. Si, Al and Cl. The `<pressure>` process' variable is also named 'pressure', see `<process_variables>` section outside of process' definition.
+* `<type>`: must be `ComponentTransport`.
+* `<integration_order>`: This is the order of the integration method for element-wise integration. In common cases set to `2`.
+* `<process_variables>`: The primary variables of the `ComponentTransport` process are either `<concentration>` or `<pressure>`. For the variable concentration, the name of the chemical component is given. Like in the following example, there are 3 chemical components, i.e. Si, Al and Cl. The `<pressure>` process' variable is also named 'pressure', see `<process_variables>` section outside of process' definition.
-```bash
+```xml
<processes>
<process>
<name>hc</name>
@@ -101,27 +101,27 @@ In the `ComponentTransport` process, the configuration is as follows.
Under the keyword `<component>`, the properties of the transported chemical component are defined. The parameters here are the pore diffusion coefficient, the retardation factor, and the decay rate. Below is an example of the Si component with the corresponding transport parameters.
-```bash
- <component>
- <name>Si</name>
- <properties>
- <property>
- <name>pore_diffusion</name>
- <type>Constant</type>
- <value>1</value>
- </property>
- <property>
- <name>retardation_factor</name>
- <type>Constant</type>
- <value>0</value>
- </property>
- <property>
- <name>decay_rate</name>
- <type>Parameter</type>
- <parameter_name>decay</parameter_name>
- </property>
- </properties>
- </component>
+```xml
+<component>
+ <name>Si</name>
+ <properties>
+ <property>
+ <name>pore_diffusion</name>
+ <type>Constant</type>
+ <value>1</value>
+ </property>
+ <property>
+ <name>retardation_factor</name>
+ <type>Constant</type>
+ <value>0</value>
+ </property>
+ <property>
+ <name>decay_rate</name>
+ <type>Parameter</type>
+ <parameter_name>decay</parameter_name>
+ </property>
+ </properties>
+</component>
```
## Available benchmarks
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/coaxial.png b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/coaxial.png
similarity index 100%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/coaxial.png
rename to web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/coaxial.png
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/index.md b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md
similarity index 65%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/index.md
rename to web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md
index a59d8b6da83..899d83b3932 100644
--- a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/index.md
+++ b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md
@@ -1,18 +1,24 @@
+++
date = "2019-11-21T12:00:13+01:00"
-title = "Heat_Transport_BHE"
+title = "HEAT_TRANSPORT_BHE"
author = "Wanlong Cai, Haibing Shao"
weight = 1
+
+[menu.docs]
+name = "Process-dependent configuration"
+identifier = "processes"
+weight = 5
+post = "Get more insight into process-specific configurations."
+++
-## Description of process Heat_Transport_BHE
+## Description
Borehole heat exchangers (BHE) are widely applied in Ground Source Heat Pump (GSHP) systems to explore geothermal energy for building heating and cooling purposes. There are more and more engineering companies starting to use simulation tools for the performance evaluation and design of GSHP projects.\
For OGS-6, it allows the users to simulate the subsurface and soil temperature evolution induced by BHE and operation performance of BHE coupled heat pump.
## Mathematical framework
-This part aims to give an explanation of the mathematical framework in configuring the Heat_Transport_BHE process provided in OpenGeoSys. The numerical method implemented in OGS-6 is the so-called double-continuum finite element method (`DC-FEM`). This approach was originally proposed by Al-Khoury et al. (2010) and extended by Diersch et al. (2011a; 2011b). It was then implemented in OpenGeoSys by Shao et al. (2016). This modelling approach has the following assumptions.
+This part aims to give an explanation of the mathematical framework in configuring the `HEAT_TRANSPORT_BHE` process provided in OpenGeoSys. The numerical method implemented in OGS-6 is the so-called double-continuum finite element method (`DC-FEM`). This approach was originally proposed by Al-Khoury et al. (2010) and extended by Diersch et al. (2011a; 2011b). It was then implemented in OpenGeoSys by Shao et al. (2016). This modelling approach has the following assumptions.
* The subsurface is considered to be a 3D continuum, while the BHE is represented by 1D line elements as the second continuum.
* The heat transfer between different BHE components is simulated by the Capacity-Resistance-Model (CaRM) in analogy to the electrical circuits.
@@ -27,14 +33,14 @@ Here, $\Lambda_s$ denotes the tensor of thermal hydrodynamic dispersion and $H_s
## Input parameters
-In the configuration of `Heat_Transport_BHE` process, it is generally configured as follows.
+In the configuration of `HEAT_TRANSPORT_BHE` process, it is generally configured as follows.
-* < name >: should be HeatTransportBHE.
-* < type >: should be HEAT_TRANSPORT_BHE.
+* < name >: should be `HeatTransportBHE`.
+* < type >: should be `HEAT_TRANSPORT_BHE`.
* < integration_order >: It is the order of the integration method for element-wise integration, normally set to 2.
-* < process_variables >: The primary variables of the HEAT_TRANSPORT_BHE process are `temperature_soil` and `temperature_BHE1`. For multiple boreholes, the name `temperature_BHE2`, `temperature_BHE3` etc can be added.
+* < process_variables >: The primary variables of the `HEAT_TRANSPORT_BHE` process are `temperature_soil` and `temperature_BHE1`. For multiple boreholes, the name `temperature_BHE2`, `temperature_BHE3` etc can be added.
-```bash
+```xml
<name>HeatTransportBHE</name>
<type>HEAT_TRANSPORT_BHE</type>
<integration_order>2</integration_order>
@@ -44,29 +50,29 @@ In the configuration of `Heat_Transport_BHE` process, it is generally configured
</process_variables>
```
-### < borehole >
+### `<borehole>`
-The borehole < length > and < diameter > are defined here. The unit of these parameters are in $\mathrm{m}$. Here is an example of a borehole with 18 m in length and 0.13 m in diameter.
+The borehole `<length>` and `<diameter>` are defined here. The unit of these parameters are in $\mathrm{m}$. Here is an example of a borehole with 18 m in length and 0.13 m in diameter.
-```bash
+```xml
<borehole>
<length>18.0</length>
<diameter>0.13</diameter>
</borehole>
```
-### < type >
+### `<type>`
Currently there are 4 types of BHE available. Following the convention in Diersch et al. (2011a), they are named as 1U，2U，CXA and CXC types. In the OGS .prj file, it is defined as:
-```bash
+```xml
<type>2U</type>
```
-* 1U: means there is only one single U-tube installed in the borehole;
-* 2U: double U-tubes installed in the borehole;
-* CXA: coaxial pipe with annular space as the inlet downwards flow and the centre part as outlet upwards flow;
-* CXC: coaxial pipe with a reversed flow direction to CXA type.
+* `1U`: means there is only one single U-tube installed in the borehole;
+* `2U`: double U-tubes installed in the borehole;
+* `CXA`: coaxial pipe with annular space as the inlet downwards flow and the centre part as outlet upwards flow;
+* `CXC`: coaxial pipe with a reversed flow direction to CXA type.
Especially in CXA and CXC type, the direction of the borehole itself could be deviated by any angle, which is defined by mesh. The inflow direction will be in accordance with the direction of the line element (represents the BHE borehole) in the mesh. And the outlet direction is the opposite of the inflow direction.
@@ -76,16 +82,16 @@ The cross-sections of these 4 types of BHEs are illustrated in the following fig
{{< img src="coaxial.png" width="50">}}
-### < pipes >
+### `<pipes>`
The properties of the pipes are defined in this section. For different types of BHE, the pipes are also configured differently.
-* For coaxial pipes (CXA or CXC), < longitudinal_dispersion_length > should be given.
-* For 1U and 2U type pipe, the < distance_between_pipes > must be given, along side with the < longitudinal_dispersion_length >;
+* For coaxial pipes (`CXA` or `CXC`), `<longitudinal_dispersion_length>` should be given.
+* For `1U` and `2U` type pipe, the `<distance_between_pipes>` must be given, along side with the `<longitudinal_dispersion_length>`.
-The units of these parameters are all in $\mathrm{m}$. Here is an example of a 2U type BHE. The inlet and outlet pipe are all made of high-density polyethylene(HDPE).
+The units of these parameters are all in $\mathrm{m}$. Here is an example of a 2U type BHE. The inlet and outlet pipe are all made of high-density polyethylene (HDPE).
-```bash
+```xml
<pipes>
<inlet>
<diameter> 0.0378</diameter>
@@ -102,37 +108,37 @@ The units of these parameters are all in $\mathrm{m}$. Here is an example of a 2
</pipes>
```
-### < flow_and_temperature_control >
+### `<flow_and_temperature_control>`
Four type of flow and temperature control patterns are provided in OGS.
-* FixedPowerConstantFlow:\
+* `FixedPowerConstantFlow`:\
It means the BHE has a fixed thermal load and the refrigerant flow rate in the borehole is kept as a constant.
- The fixed heating load value was defined by the key word < power > , and the flow rate is given by < flow_rate >.
-* FixedPowerFlowCurve:\
+ The fixed heating load value was defined by the key word `<power>` , and the flow rate is given by `<flow_rate>`.
+* `FixedPowerFlowCurve`:\
It means the BHE has a fixed thermal load and the flow rate is following a time dependent curve.
- The key word < power > is kept the same, while the flow rate is defined by a curve in the < curves >.
-* PowerCurveConstantFlow:\
+ The key word `<power>` is kept the same, while the flow rate is defined by a curve in the `<curves>`.
+* `PowerCurveConstantFlow`:\
It means BHE has a constant flow rate while the power is various following a curve.
- The key word < flow_rate > applies here, along with the curve defined in the < curves >.
-* TemperatureCurveConstantFlow:\
- It means BHE has a constant < flow_rate > while the inflow temperature following the values defined in the < curves >.
-* TemperatureCurveFlowCurve:\
+ The key word `<flow_rate>` applies here, along with the curve defined in the `<curves>`.
+* `TemperatureCurveConstantFlow`:\
+ It means BHE has a constant `<flow_rate>` while the inflow temperature following the values defined in the `<curves>`.
+* `TemperatureCurveFlowCurve`:\
It means both the BHE inflow rate and temperature values are following the corresponding curves.
-* PowerCurveFlowCurve:\
+* `PowerCurveFlowCurve`:\
It means both the BHE thermal load and flow rate values are following the corresponding curves.
-* BuildingPowerCurveConstantFlow:\
+* `BuildingPowerCurveConstantFlow`:\
It means the BHE thermal load is following a building heat load depending on a COP curve while the flow rate is kept as a constant.
-The unit of < power > is in $\mathrm{W}$ and < flow_rate > is in $\mathrm{m^{3}/s}$. For heating applications, thermal energy is extracted from the subsurface, then a negative power value should be given. It is vice versa for cooling applications.
+The unit of `<power>` is in $\mathrm{W}$ and `<flow_rate>` is in $\mathrm{m^{3}/s}$. For heating applications, thermal energy is extracted from the subsurface, then a negative power value should be given. It is vice versa for cooling applications.
<i class="far fa-arrow-right"></i> Further info:
-For all the flow and temperature control options, OpenGeoSys calculates the inlet temperature of each BHE internally. For each BHE, temperature on its inlet pipe is always set as a Dirichlet type boundary condition. Depending on the choice of < flow_and_temperature_control >, the inflow temperature will be calculated dynamically in each time step and iteration to satisfy the given constrains.
+For all the flow and temperature control options, OpenGeoSys calculates the inlet temperature of each BHE internally. For each BHE, temperature on its inlet pipe is always set as a Dirichlet type boundary condition. Depending on the choice of `<flow_and_temperature_control>`, the inflow temperature will be calculated dynamically in each time step and iteration to satisfy the given constrains.
Here is an example using `TemperatureCurveConstantFlow`.
-```bash
+```xml
<flow_and_temperature_control>
<type>TemperatureCurveConstantFlow</type>
<flow_rate>2.0e-4</flow_rate>
@@ -140,21 +146,21 @@ Here is an example using `TemperatureCurveConstantFlow`.
</flow_and_temperature_control>
```
-For 2U-type BHE configuration, the flow rate in < flow_and_temperature_control > indicates the flow rate within each U-pipe.
-When a fixed power or power curve is imposed on a 2U-type BHE, the given value in < flow_and_temperature_control > or in the related power curve should be specified with half of the user's presumed entire borehole exchanger power.
+For `2U`-type BHE configuration, the flow rate in `<flow_and_temperature_control>` indicates the flow rate within each U-pipe.
+When a fixed power or power curve is imposed on a `2U`-type BHE, the given value in `<flow_and_temperature_control>` or in the related power curve should be specified with half of the user's presumed entire borehole exchanger power.
-### < grout >
+### `<grout>`
The thermal properties of the grout material is defined here.
-* /density/: density of grout which has the unit of $\mathrm{kg/m^{3}}$;
-* /porosity/: porosity of grout which is dimensionless;
-* /specific_heat_capacity/: specific heat capacity of grout which has the unit of $\mathrm{J·kg^{-1} K^{-1}}$;
-* /thermal_conductivity/: thermal conductivity of grout which has the unit of $\mathrm{W·m^{-1} K^{-1}}$.
+* `density`: density of grout which has the unit of $\mathrm{kg/m^{3}}$;
+* `porosity`: porosity of grout which is dimensionless;
+* `specific_heat_capacity`: specific heat capacity of grout which has the unit of $\mathrm{J·kg^{-1} K^{-1}}$;
+* `thermal_conductivity`: thermal conductivity of grout which has the unit of $\mathrm{W·m^{-1} K^{-1}}$.
Here is an example how the typical parameters of borehole grout looks like.
-```bash
+```xml
<grout>
<density>2190.0</density>
<porosity>0.0</porosity>
@@ -163,26 +169,26 @@ Here is an example how the typical parameters of borehole grout looks like.
</grout>
```
-### < refrigerant >
+### `<refrigerant>`
The thermal properties of the circulating fluid is defined here. The parameters and their units are listed below.
-* /density/: density of circulating fluid, in the unit of $\mathrm{kg/m^{3}}$;
-* /viscosity/: dynamic viscosity of circulating media which has the unit of $\mathrm{kg·m^{-1} s^{-1}}$;
-* /specific_heat_capacity/: specific heat capacity of circulating fluid, which has the unit of $\mathrm{J·kg^{-1} K^{-1}}$;
-* /thermal_conductivity/: thermal conductivity of the circulating fluid, which has the unit of $\mathrm{W·m^{-1} K^{-1}}$;
-* /reference_temperature/: When the < flow_and_temperature_control > was not set to TemperatureCurveConstantFlow, OGS needs to have an initial outlet temperature value in the first time step to start the simulation. A reference temperature has to be defined for the calculation of initial inflow temperature. The unit of reference temperature is in $^{\circ}$C.
+* `density`: density of circulating fluid, in the unit of $\mathrm{kg/m^{3}}$;
+* `viscosity`: dynamic viscosity of circulating media which has the unit of $\mathrm{kg·m^{-1} s^{-1}}$;
+* `specific_heat_capacity`: specific heat capacity of circulating fluid, which has the unit of $\mathrm{J·kg^{-1} K^{-1}}$;
+* `thermal_conductivity`: thermal conductivity of the circulating fluid, which has the unit of $\mathrm{W·m^{-1} K^{-1}}$;
+* `reference_temperature`: When the `<flow_and_temperature_control>` was not set to `TemperatureCurveConstantFlow`, OGS needs to have an initial outlet temperature value in the first time step to start the simulation. A reference temperature has to be defined for the calculation of initial inflow temperature. The unit of reference temperature is in $^{\circ}$C.
Here is an example in which the circulating fluid is water at about 15 $^{\circ}$C.
-```bash
+```xml
<refrigerant>
<density>998</density>
<viscosity>0.0011375 </viscosity>
<specific_heat_capacity>4190</specific_heat_capacity>
<thermal_conductivity>0.6</thermal_conductivity>
<reference_temperature>22</reference_temperature>
-/refrigerant>
+</refrigerant>
```
## References
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/u_type.png b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/u_type.png
similarity index 100%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE/u_type.png
rename to web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/u_type.png
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/BHE_PipeNetwork_feature_workflow.png b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/BHE_PipeNetwork_feature_workflow.png
similarity index 100%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/BHE_PipeNetwork_feature_workflow.png
rename to web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/BHE_PipeNetwork_feature_workflow.png
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/BHE_network.png b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/BHE_network.png
similarity index 100%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/BHE_network.png
rename to web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/BHE_network.png
diff --git a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/index.md b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md
similarity index 94%
rename from web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/index.md
rename to web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md
index 5016e9e09a4..2547d625465 100644
--- a/web/content/docs/userguide/process-dependent-configuration/Heat_Transport_BHE_PipelineNetwork/index.md
+++ b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md
@@ -1,26 +1,24 @@
+++
date = "2020-02-03T12:00:13+01:00"
-title = "Heat_Transport_BHE PipeNetwork Feature"
+title = "HEAT_TRANSPORT_BHE PipeNetwork Feature"
author = "Shuang Chen, Haibing Shao, Francesco Witte"
weight = 2
project = ["Parabolic/T/3D_3BHEs_array/3bhes_1U.prj"]
+++
-{{< data-link >}}
-
-## Introduction of the Pipe Network feature for the process Heat_Transport_BHE
+## Introduction
-In a large borehole heat exchanger (BHE) array, all BHEs are connected with each other through a pipeline network. As the circulating fluid temperatures within each BHE are controlled by the network, the array itself has an intrinsic feature of balancing thermal extraction rates among different BHEs. This leads to the BHE thermal load shifting phenomena in the long-term operation. In OGS-6, this process can be simulated by using the PipeNetwork feature in the `Heat_Transport_BHE` process.
+In a large borehole heat exchanger (BHE) array, all BHEs are connected with each other through a pipeline network. As the circulating fluid temperatures within each BHE are controlled by the network, the array itself has an intrinsic feature of balancing thermal extraction rates among different BHEs. This leads to the BHE thermal load shifting phenomena in the long-term operation. In OGS-6, this process can be simulated by using the PipeNetwork feature in the `HEAT_TRANSPORT_BHE` process.
-This short tutorial aims to give the user a guide to the PipeNetwork feature. It includes the following main parts:\
+This short tutorial aims to give the user a guide to the PipeNetwork feature. It includes the following main parts:
-* The basic requirements for the PipeNetwork feature.\
-* The workflow of creating a pipeline network model using the software TESPy.\
-* The workflow of connecting the TESPy pipeline network model with the OGS model.\
+* The basic requirements for the PipeNetwork feature.
+* The workflow of creating a pipeline network model using the software TESPy.
+* The workflow of connecting the TESPy pipeline network model with the OGS model.
## Requirements on the computer
-In order to use the PipeNetwork feature, the computer running the `Heat_Transport_BHE` process of OpenGeoSys is required to have a Python 3 environment with the TESPy program installed. For the Python 3 environmental installation, there are various tutorial available on the Internet. For the TESPy package, one can install it with the following command line in the Python3 environment:
+In order to use the PipeNetwork feature, the computer running the `HEAT_TRANSPORT_BHE` process of OpenGeoSys is required to have a Python 3 environment with the TESPy program installed. For the Python 3 environmental installation, there are various tutorial available on the Internet. For the TESPy package, one can install it with the following command line in the Python3 environment:
```bash
pip3 install tespy
@@ -32,15 +30,13 @@ Thermal Engineering Systems in Python (software paper: <https://doi.org/10.21105
The coupled model that is going to be built is demonstrated in Figure 1. It consists of a pipeline network connected with 3 BHEs, a water pump, a virtual heat pump as the consumer, a splitter to split up the feeding fluid flow and a merge to returned flow. These devices are all defined as `components` in TESPy. A full list of available components can be found in the TESPy components module. In the pipeline network, these components are connected with each other through `connections` parts, which are illustrated by the black lines in the figure. With these two main parts, a completely TESPy pipeline network model can be set up.
-{{< img src="BHE_network.png" width="200">}}
-
-Figure 1: Pipeline network model in TESPy
+{{< img src="BHE_network.png" width="200" caption="Pipeline network model in TESPy" >}}
### < Network >
-Firstly a network needs to be created. It is the main container for the model. Several parameters will be set here. For example the required fluids in the network and the unit systems for the networks variables are specified as follows.\
+Firstly a network needs to be created. It is the main container for the model. Several parameters will be set here. For example the required fluids in the network and the unit systems for the networks variables are specified as follows.
-```bash
+```python
from tespy.networks import network
from tespy.connections import connection, ref
from tespy.components import source, sink, pump, splitter, merge, heat_exchanger_simple, cycle_closer
@@ -51,11 +47,11 @@ import numpy as np
btes = network(fluids=['water'], T_unit='K', p_unit='bar', h_unit='kJ / kg')
```
-### < Components >
+### `<Components>`
In the next step different components in the network needed to be configured. In TESPy model the fluid usually emerges from a `source` and drains in a `sink` term. However, using a virtual loop system can is created by using the component `cycle_closer`. This component ensures, that enthalpy and pressure at the `source` and the `sink` are identical. In our model, TESPy components of type `cycle_closer`, `pump`, `splitter`, `merge` and `heat_exchanger_simple` are created with locally defined names surrounded by quotes. To simplify the model the heat pump is specified as a pure heat exchanger to consume the heat.
-```bash
+```python
# %% components
fc = cycle_closer('cycle closer')
pu = pump('pump')
@@ -72,7 +68,7 @@ cons = heat_exchanger_simple('consumer')
When all components are set up, it is needed to specify parameters for them. One can find the full list of parameters for a specific component in the respective TESPy class documentation. In this model, a pump curve for the water pump, physical properties (length, diameter, roughness) for the BHE pipes, the imposed thermal load on the virtual heat pump are specified as follows.
-```bash
+```python
## components paramerization
# pump
# flow_char
@@ -111,11 +107,11 @@ cons.set_attr(D=0.2, L=20, ks=0.00001)
cons.set_attr(Q=-3000) # W
```
-### < Connections >
+### Connections
Connections are used to link two components. It starts from the outlet of the component 1 to the inlet of component 2. In order to connect all components with each other a system workflow sequence needs to be determined. In this case the fluid flowing from the inlet source term will be firstly lifted by the pump. Then the inflow will be divided into 3 branches by the splitter and then flow into each BHEs. After that the outflow from the BHEs will be mixed together at the merging point and then feed into the heat pump for heat extraction. The total sequence ends up when the flow reaches the outlet sink term. In the last step, all connections have to be added into the network container to form a complete network.
-```bash
+```python
# connections
fc_pu = connection(fc, 'out1', pu, 'in1')
pu_sp = connection(pu, 'out1', sp, 'in1')
@@ -137,7 +133,7 @@ btes.add_conns(fc_pu, pu_sp, sp_bhe1, sp_bhe2, sp_bhe3, bhe1_mg, bhe2_mg,
Here the fluid properties within the connection is set to be identical. It means when two components are connected with each other, the fluid properties for instance the mass flow rate, the pressure, the temperature at the outlet of component 1 will be equal to the values at the inlet of component 2. In order to complete the calculation, several boundary conditions are required to be imposed on the connections. First, the inflow pressure is fixed. A temporary outflow temperature on each BHEs is specified to make sure the network is computable. In this case the consumed heat on the virtual heat pump is assumed to be totally supplied by the 3 BHEs. The cycle closer ensures, that pressure and enthalpy at the consumer's outlet are identical to those at the pump's inlet.
-```bash
+```python
## connection parametrization
# system inlet
fc_pu.set_attr(p=2, fluid={'water': 1})
@@ -149,7 +145,7 @@ bhe2_mg.set_attr(T=303.15)
bhe3_mg.set_attr(T=303.15)
```
-### < Solve >
+### Solve
After the network, components and connections are completely set up, the system can be solved to get its steady states results. One can use the `print_results` to find the details parameters during the calculation.
@@ -159,7 +155,7 @@ btes.solve('design')
#btes.print_results()
```
-### < Save the network >
+### Save the network
At last, the built BHE pipe network model needs to be saved into the project working folder.
@@ -172,11 +168,9 @@ btes.save('tespy_nw')
The work flow of the PipeNetwork feature is illustrated in Figure 2. To explicitly simulate both the BHE and the pipe network, OGS is coupled with the TESPy through a Python interface. Within every time step and each iteration, the outflow temperature `Tout` from each BHE is computed by OGS and transferred to TESPy via the interface. Then TESPy will use these `Tout` temperature and the current hydraulic state as the boundary condition imposed on the pipeline network to calculate the current inflow temperature `Tin` of each BHE and the currently flow rate, which satisfies the overall thermal load of the building. After the calculation, all data will be transferred back to OGS and update the inlet temperature and flow rate of each BHE for the next iteration. The convergence is set to be satisfied when the difference from the last two iteration results is smaller than a preset tolerance value. Additionally, OGS will transfer the currently time step 't' to TESPy within each iteration, which makes TESPy able to adjust its time dependent network boundary conditions according to the user's configuration.
-{{< img src="BHE_PipeNetwork_feature_workflow.png" width="100">}}
-
-Figure 2: Work flow of the model with BHEs coupled with a pipe network
+{{< img src="BHE_PipeNetwork_feature_workflow.png" width="100" caption="Work flow of the model with BHEs coupled with a pipe network" >}}
-### < BHE data container >
+### BHE data container
In order to use the PipeNetwork feature, the pre-built and saved TESPy network model in the above section is required. A CSV file `bhe_network.csv` which containing all the OGS-TESPy transferred BHE's information needs to be created. The PipeNetwork feature will access this CSV file to initialize the exchange data container between OGS and TESPy during the simulation. All BHEs have to be included in this CSV file. Please take notice that all BHE names located in the data_index column have to be identical with the BHE names defined in the corresponding TESPy network model.
@@ -187,7 +181,7 @@ BHE2;2;283.15;283.15;0;0
BHE3;3;283.15;283.15;0;0
```
-### < PipeNetwork feature interface >
+### PipeNetwork feature interface
The python script `bcs_tespy.py` is the data exchange interface for running the PipeNetwork feature.
It contains the main procedure of data exchange during the simulation.
@@ -196,7 +190,7 @@ The function `network_status` receives the current time step information from OG
When the switch for dynamic thermal load `switch_dyn_demand` and dynamic flow rate `switch_dyn_frate` are `off`, the thermal and hydraulic boundary conditions, which were defined in the pre-constructed TESPy model, will be used throughout the simulation.
When the switches are `on`, a user defined system thermal load curve and inlet flow rate curve can be specified according to the current time step from OGS.
-```bash
+```python
# User setting ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
# parameters
# refrigerant density
@@ -256,25 +250,27 @@ def dyn_frate(t):
# End User setting+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
```
-### < Configuration in OGS >
+### Configuration in OGS
To use the PipeNetwork feature, several input parameters need to be adjusted in comparison to the standard settings in the OGS project file. The python script interface `bcs_tespy.py` is required to be added in the `prj` file. Besides, within the configuration of each BHE, an input parameter `use_bhe_pipe_network` needs to be added to determine whether the related BHE is included in the pipeline network or not.
-```bash
+```xml
<OpenGeoSysProject>
<mesh>3bhes_1U.vtu</mesh>
<geometry>3bhes_1U.gml</geometry>
<python_script>bcs_tespy.py</python_script>
```
-```bash
+```xml
<borehole_heat_exchangers>
<borehole_heat_exchanger>
<type>1U</type>
<use_bhe_pipe_network>true</use_bhe_pipe_network>
```
-After the configuration of the OGS project file, all the required files for using the PipeNetwork feature are prepared. The process explicitly couple the BHE and the pipe network can be simulated in the `Heat_Transport_BHE` process by OGS.
+After the configuration of the OGS project file, all the required files for using the PipeNetwork feature are prepared. The process explicitly couple the BHE and the pipe network can be simulated in the `HEAT_TRANSPORT_BHE` process by OGS.
+
+{{< data-link >}}
## References
diff --git a/web/content/docs/processes/heat-transport/_index.md b/web/content/docs/processes/heat-transport/_index.md
new file mode 100644
index 00000000000..c2b9d5a1c57
--- /dev/null
+++ b/web/content/docs/processes/heat-transport/_index.md
@@ -0,0 +1,4 @@
++++
+title = "Heat Transport"
+weight = 1
++++
diff --git a/web/content/docs/processes/multiphase/Multiphase_Flow_Overview/index.md b/web/content/docs/processes/multiphase/Multiphase_Flow_Overview/index.md
new file mode 100644
index 00000000000..2cb070270f5
--- /dev/null
+++ b/web/content/docs/processes/multiphase/Multiphase_Flow_Overview/index.md
@@ -0,0 +1,27 @@
++++
+author = "Boyan Meng and Haibing Shao"
+date = "2021-11-2T18:52:00+01:00"
+title = "Overview of Multiphase Flow Processes (without mechanics)"
+weight = 3
++++
+
+
+This documentation gives an overview of the multiphase flow processes (except `TH2M`) in OGS. Currently all processes assume two-phase flow (The `RICHARDS_FLOW` process is not considered as a "two-phase flow" process since the gas phase is assumed static). A comparison of the process-specific features is listed in the following table.
+
+| Feature | `TwoPhaseFlowWithPP` | `TwoPhaseFlowWithPrho` | `ThermalTwoPhaseFlowWithPP` |
+|---|---|---|---|
+| \# of phases | 2 | 2 | 2 |
+| \# of components | 2 | 2 | 2 |
+| Phase composition | Pure | Compositional (only liquid phase) | Compositional (only gas phase) |
+| Primary Variables | $P_g, P_c$ | $P_g, \rho^h_{tot}$ | $P_g, P_c, T$ |
+| Temperature effect | Isothermal | Isothermal | Non-isothermal |
+| Phase change | N.A. | Gas dissolution/degassing | Evaporation/condensation |
+| Phase appearance/disappearance | N.A. | Yes, only gas phase | Yes, only liquid phase |
+
+Nomenclature: $P_g$: gas pressure; $P_c$: capillary pressure; $T$: temperature; $\rho^h_{tot}$: total density of the light component.
+
+Some remarks:
+
+1. The `TwoPhaseFlowWithPP` process assumes that the two fluid phases are immiscible. Thus, it is most suitable for simulating two-phase flow under capillary effects (e.g. replacement of one phase by another due to gravity). Note that the wetting and non-wetting phases are not limited to water and gas, see the [McWhorter benchmark]({{< ref "docs/benchmarks/two-phase-flow/two-phase-flow-pp-mcwhorter" >}}) for example.
+2. The `TwoPhaseFlowWithPrho` process assumes that the main component of the gas phase can be dissolved in the liquid phase. Water evaporation is neglected here. The appearance/disappearance of the gas phase is controlled by the solubility (given by the Henry's Law) of the gaseous component, e.g. H2. It is therefore most suitable for nuclear waste repository (see the [MoMaS benchmark](https://www.opengeosys.org/docs/benchmarks/two-phase-flow/momas/)) or CO2 storage problems.
+3. The `ThermalTwoPhaseFlowWithPP` process simulates the temperature-dependent two-phase flow and moisture transport. Water evaporation and recondensation can be modeled thanks to that the gas phase is compositional. This process is most favorably used for shallow geothermal applications (e.g. borehole thermal energy storage), especially in unsaturated soils (see the [heat pipe benchmark](https://www.opengeosys.org/docs/benchmarks/thermal-two-phase-flow/heatpipe/)).
diff --git a/web/content/docs/processes/multiphase/_index.md b/web/content/docs/processes/multiphase/_index.md
new file mode 100644
index 00000000000..56704bd29f5
--- /dev/null
+++ b/web/content/docs/processes/multiphase/_index.md
@@ -0,0 +1,4 @@
++++
+title = "Multiphase"
+weight = 2
++++
diff --git a/web/content/docs/userguide/process-dependent-configuration/Multiphase_Flow_Overview/index.md b/web/content/docs/userguide/process-dependent-configuration/Multiphase_Flow_Overview/index.md
deleted file mode 100644
index 4993fabd192..00000000000
--- a/web/content/docs/userguide/process-dependent-configuration/Multiphase_Flow_Overview/index.md
+++ /dev/null
@@ -1,29 +0,0 @@
-+++
-author = "Boyan Meng and Haibing Shao"
-date = "2021-11-2T18:52:00+01:00"
-title = "Overview of Multiphase Flow Processes (without mechanics)"
-weight = 3
-+++
-
-
-This documentation gives an overview of the multiphase flow processes (except `TH2M`) in OGS. Currently all processes assume two-phase flow (The `Richards Flow` process is not considered as a "two-phase flow" process since the gas phase is assumed static). A comparison of the process-specific features is listed in the following table.
-
-| Feature | `TwoPhaseFlowWithPP` | `TwoPhaseFlowWithPrho` | `ThermalTwoPhaseFlowWithPP` |
-|---|---|---|---|
-| \# of phases | 2 | 2 | 2 |
-| \# of components | 2 | 2 | 2 |
-| Phase composition | Pure | Compositional (only liquid phase) | Compositional (only gas phase) |
-| Primary Variables | $P_g, P_c$ | $P_g, \rho^h_{tot}$ | $P_g, P_c, T$ |
-| Temperature effect | Isothermal | Isothermal | Non-isothermal |
-| Phase change | N.A. | Gas dissolution/degassing | Evaporation/condensation |
-| Phase appearance/disappearance | N.A. | Yes, only gas phase | Yes, only liquid phase |
-
-Nomenclature: $P_g$: gas pressure; $P_c$: capillary pressure; $T$: temperature; $\rho^h_{tot}$: total density of the light component.
-
-Some remarks:
-
-1\. The `TwoPhaseFlowWithPP` process assumes that the two fluid phases are immiscible. Thus, it is most suitable for simulating two-phase flow under capillary effects (e.g. replacement of one phase by another due to gravity). Note that the wetting and non-wetting phases are not limited to water and gas, see the [McWhorter benchmark]({{< ref "docs/benchmarks/two-phase-flow/two-phase-flow-pp-mcwhorter" >}}) for example.
-
-2\. The `TwoPhaseFlowWithPrho` process assumes that the main component of the gas phase can be dissolved in the liquid phase. Water evaporation is neglected here. The appearance/disappearance of the gas phase is controlled by the solubility (given by the Henry's Law) of the gaseous component, e.g. H2. It is therefore most suitable for nuclear waste repository (see the [MoMaS benchmark](https://www.opengeosys.org/docs/benchmarks/two-phase-flow/momas/)) or CO2 storage problems.
-
-3\. The `ThermalTwoPhaseFlowWithPP` process simulates the temperature-dependent two-phase flow and moisture transport. Water evaporation and recondensation can be modeled thanks to that the gas phase is compositional. This process is most favorably used for shallow geothermal applications (e.g. borehole thermal energy storage), especially in unsaturated soils (see the [heat pipe benchmark](https://www.opengeosys.org/docs/benchmarks/thermal-two-phase-flow/heatpipe/)).
--
GitLab