We publish a series of books and tutorials on OpenGeoSys. The books contain comprehensive benchmark descriptions and can be seen as a reference to what is possible with OGS. The tutorials focus on specific topics such as [Groundwater Flow Modeling]({{< relref "computational-hydrology-i-groundwater-flow-modeling">}}) or [Models of Thermochemical Heat Storage]({{< relref "models-of-thermochemical-heat-storage" >}}) with step-by-step instructions giving the user a good introduction into modeling and simulation with OGS. Most of the tutorials can be downloaded as PDF! See the detail page on each tutorial.

We publish a series of books and tutorials on OpenGeoSys. The books contain comprehensive benchmark descriptions and can be seen as a reference to what is possible with OGS. The tutorials focus on specific topics such as [Groundwater Flow Modeling]({{< ref "computational-hydrology-i-groundwater-flow-modeling" >}}) or [Models of Thermochemical Heat Storage]({{< ref "models-of-thermochemical-heat-storage" >}}) with step-by-step instructions giving the user a good introduction into modeling and simulation with OGS. Most of the tutorials can be downloaded as PDF! See the detail page on each tutorial.

- Additional checks regarding code formatting and documentation help in maintaining a good software quality and structure

After the system is done with all these tasks the developer can view build reports highlighting occurred errors and problems. We are using [Jenkins]({{< relref "jenkins.pandoc" >}}) as our CI system.

After the system is done with all these tasks the developer can view build reports highlighting occurred errors and problems. We are using [Jenkins]({{< ref "jenkins.pandoc" >}}) as our CI system.

## CI on OGS

@@ -31,5 +31,5 @@ Click on the *Details* link to find out the reason for a failed check. If you ad

# Enable CI on your fork

You can have the CI system testing all your branches in your fork of OGS even before creating a pull request. See the page on [Jenkins]({{< relref "jenkins.pandoc#automatic-testing-for-own-repository" >}}) for further information.

You can have the CI system testing all your branches in your fork of OGS even before creating a pull request. See the page on [Jenkins]({{< ref "jenkins.pandoc#automatic-testing-for-own-repository" >}}) for further information.

It is preferred to use Conan package manager to install required third-party libraries. To use Conan add the CMake option `OGS_USE_CONAN=ON` to the CMake run (see below). This will run Conan automatically downloading either prebuilt binaries of required libraries or building them locally if a binary for your setup (operating system, compiler, ..) is not available. [Check this]({{< ref "conan-package-manager.pandoc" >}}) for advanced Conan usage.

*Note:* Instead of using Conan you can optionally [install the required libraries manually]({{< relref "third-party-libraries.pandoc" >}}).

*Note:* Instead of using Conan you can optionally [install the required libraries manually]({{< ref "third-party-libraries.pandoc" >}}).

For adding new data files make sure you have [setup git lfs](../../getting-started/prerequisites) already. Then simply commit the new files as usual. For pushing you need to have [setup an account]({{< relref "gitlab.pandoc" >}}) on our own GitLab server as the lfs files are stored there (due to bandwidth limitations on GitHub). When asked for GitLab credentials on pushing use your GitLab account name (should be the same as the GitHub account name) and your created GitLab personal access token ([see the GitLab Setup page]({{< relref "gitlab.pandoc" >}})).

For adding new data files make sure you have [setup git lfs](../../getting-started/prerequisites) already. Then simply commit the new files as usual. For pushing you need to have [setup an account]({{< ref "gitlab.pandoc" >}}) on our own GitLab server as the lfs files are stored there (due to bandwidth limitations on GitHub). When asked for GitLab credentials on pushing use your GitLab account name (should be the same as the GitHub account name) and your created GitLab personal access token ([see the GitLab Setup page]({{< ref "gitlab.pandoc" >}})).

Check this [in-depth tutorial](https://www.atlassian.com/git/tutorials/git-lfs) to learn more about git lfs.

The normal of the surface that should be extracted is given by the arguments `-x`, `-y` and `-z`. The default normal is (0,0,-1). The command line option `-a` can be used to specify the allowed deviation of the normal of the surface element from the given normal. The data arrays added to the surface mesh by using the options `--face-property-name` (default value 'OriginalFaceIDs'), `--element-property-name` (default value 'OriginalSubsurfaceElementIDs'), and `--node-property-name` (default value 'OriginalSubsurfaceNodeIDs') are used in other tools (for instance in [ComputeNodeAreasFromSurfaceMesh]({{< relref "compute-node-areas-from-surface-mesh" >}})) and is required for flux calculations during a simulation run of OpenGeoSys.

The normal of the surface that should be extracted is given by the arguments `-x`, `-y` and `-z`. The default normal is (0,0,-1). The command line option `-a` can be used to specify the allowed deviation of the normal of the surface element from the given normal. The data arrays added to the surface mesh by using the options `--face-property-name` (default value 'OriginalFaceIDs'), `--element-property-name` (default value 'OriginalSubsurfaceElementIDs'), and `--node-property-name` (default value 'OriginalSubsurfaceNodeIDs') are used in other tools (for instance in [ComputeNodeAreasFromSurfaceMesh]({{< ref "compute-node-areas-from-surface-mesh" >}})) and is required for flux calculations during a simulation run of OpenGeoSys.

@@ -16,9 +16,9 @@ The tool `removeMeshElements` removes those elements from a given input mesh tha

3. Remove elements that have zero volume.

4. Remove elements by axis aligned bounding box criterion.

One possible application is to cut out a smaller mesh out of a bigger one by marking the inner/outer region using the tool [SetPropertiesInPolygonalRegion]({{< relref "set-properties-in-polygonal-region" >}}).

One possible application is to cut out a smaller mesh out of a bigger one by marking the inner/outer region using the tool [SetPropertiesInPolygonalRegion]({{< ref "set-properties-in-polygonal-region" >}}).

Another application is to cut out patches of a (top) surface (tool [ExtractSurface]({{< relref "extract-surface" >}})) for assigning boundary conditions.

Another application is to cut out patches of a (top) surface (tool [ExtractSurface]({{< ref "extract-surface" >}})) for assigning boundary conditions.

## Usage

@@ -36,7 +36,7 @@ Each particular line with optional arguments refere to one of the different remo

![](ExampleRemoveElements-Input.png)

![](ExampleRemoveElements-Output.png)

The left figure above is the result of the repeated application of [SetPropertiesInPolygonalRegion]({{< relref "set-properties-in-polygonal-region" >}}). It contains material ids 0 (red), 1 (yellow), 2 (turquoise) and 3 (blue). On the right figure the result of the following command line input is depicted:

The left figure above is the result of the repeated application of [SetPropertiesInPolygonalRegion]({{< ref "set-properties-in-polygonal-region" >}}). It contains material ids 0 (red), 1 (yellow), 2 (turquoise) and 3 (blue). On the right figure the result of the following command line input is depicted:

In the process of incorporating boundary conditions of second type (or Neumann boundary conditions) into the simulation model, the area associated to each surface node is needed for the local assembly. This tool reads a surface mesh (see also [ExtractSurface]({{< relref "extract-surface" >}})), computes the associated area for each node and writes the information as txt and csv data.

In the process of incorporating boundary conditions of second type (or Neumann boundary conditions) into the simulation model, the area associated to each surface node is needed for the local assembly. This tool reads a surface mesh (see also [ExtractSurface]({{< ref "extract-surface" >}})), computes the associated area for each node and writes the information as txt and csv data.

If the option `-p` is not given the output path is extracted from the input path. The default value for the `--id-prop-name` argument is "OriginalSubsurfaceNodeIDs". This name is also used by [ExtractSurface]({{< relref "extract-surface" >}}) for storing the subsurface node ids.

If the option `-p` is not given the output path is extracted from the input path. The default value for the `--id-prop-name` argument is "OriginalSubsurfaceNodeIDs". This name is also used by [ExtractSurface]({{< ref "extract-surface" >}}) for storing the subsurface node ids.

The generated surface mesh contains a property "OriginalSubsurfaceNodeIDs" assigned to the mesh nodes that contains the original subsurface mesh node ids.

3. Finally `ComputeNodeAreasFromSurfaceMesh -i hex_6x7x3_surface.vtu` generates two text files (`hex_6x7x3_surface.txt` and `hex_6x7x3_surface.csv`). The txt file is usable as boundary condition input file for OGS-5 simulation. The first column of the text file contains the original mesh node id (see image above), the second column the associated area. For example to the corner node 168 an area of 0.25 is associated. The edge node 169 has an area value of 0.5 and the interior node 176 has an area value of 1.

@@ -16,7 +16,7 @@ The user has to provide the input mesh `mesh` and the geometry `geometry` that m

The tool will output a OGS-5 boundary condition file (.bc) and a geometry file (.gli) containing the points the boundary conditions refer to. The original geometry will not be altered. Additional, it is possible to write the geometry in the gml format by setting the switch `gml` to 1.

The polylines should be in the vicinity of the mesh nodes, where the user wants to set the boundary conditions. The tool will generate boundary conditions at every node which lies within the search radius `search_radius`. Idealy, the geometry should be mapped as close as possible to the area the user wants to set boundary conditions (for this, also see tool [MapGeometryToSurface]({{< relref "map-geometric-object-to-the-surface-of-a-mesh" >}})).

The polylines should be in the vicinity of the mesh nodes, where the user wants to set the boundary conditions. The tool will generate boundary conditions at every node which lies within the search radius `search_radius`. Idealy, the geometry should be mapped as close as possible to the area the user wants to set boundary conditions (for this, also see tool [MapGeometryToSurface]({{< ref "map-geometric-object-to-the-surface-of-a-mesh" >}})).

@@ -16,7 +16,7 @@ The new value must be of one of the data types, either [integer](https://en.wiki

The polygon must be located within a plane. A node is located in the cylindrical volume iff (ie. if and only if) the node's orthogonal projection to the plane of the polygon lies in the polygon, ie. the plane can be defined in any arbitrary direction in 3d space.

In combination with a threshold filter the tool can also be used to cut out some region of the mesh. The tool can be also used in combination with the tool [removeMeshElements]({{< relref "remove-mesh-elements" >}}).

In combination with a threshold filter the tool can also be used to cut out some region of the mesh. The tool can be also used in combination with the tool [removeMeshElements]({{< ref "remove-mesh-elements" >}}).