diff --git a/.vale.ini b/.vale.ini index e7bc628f259..3fca8448f98 100644 --- a/.vale.ini +++ b/.vale.ini @@ -9,7 +9,7 @@ Packages = Hugo [*.md] BasedOnStyles = Vale, write-good, ogs Vale.Spelling = None -write-good.ThereIs = suggestion +write-good.ThereIs = None write-good.Passive = None write-good.TooWordy = None write-good.Weasel = None @@ -21,7 +21,10 @@ TokenIgnores = \ ; (\\ref\s\S+(\s"\S*")?), \ ; (\\subpage\s\S*), \ ; (\\copydoc\s\S*), \ -(\$+[^\n$]+\$+), \ (\$[^\n$]+\$), \ (\\\S*|\{\S*\}), \ -(\w*\set\sal) +(\w*\set\sal), \ +({{<\s?(rel)?ref (.*)>}}) + +# https://regex101.com/r/QWLhgT/1 helped me generating this one: +BlockIgnores = (?s) *(\$\$.*?\$\$) diff --git a/Documentation/.vale/.vale-config/0-Hugo.ini b/Documentation/.vale/.vale-config/0-Hugo.ini new file mode 100644 index 00000000000..3b014081dff --- /dev/null +++ b/Documentation/.vale/.vale-config/0-Hugo.ini @@ -0,0 +1,8 @@ +[*.md] +# Exclude `{{< ... >}}`, `{{% ... %}}`, [Who]({{< ... >}}) +TokenIgnores = ({{[%<] .* [%>]}}.*?{{[%<] ?/.* [%>]}}), \ +(\[.+\]\({{< .+ >}}\)) + +# Exclude `{{< myshortcode `This is some HTML, ... >}}` +BlockIgnores = (?sm)^({{[%<] [^{]*? [%>]}})\n$, \ +(?s) *({{< highlight [^>]* ?>}}.*?{{< ?/ ?highlight >}}) diff --git a/Documentation/.vale/Vocab/ogs/accept.txt b/Documentation/.vale/Vocab/ogs/accept.txt index 43df39539ea..4742e37cda0 100644 --- a/Documentation/.vale/Vocab/ogs/accept.txt +++ b/Documentation/.vale/Vocab/ogs/accept.txt @@ -1,9 +1,13 @@ +Alcolea Algolia Aluminol Alves Atteia Autolinks +BC[s?] Beier +BGR[a?] +BHE[s?] Bincrafters biokinetic Biot @@ -14,6 +18,7 @@ Bruns CLion Dalen Degener +DEM[s?] devguide Diao Diersch @@ -29,25 +34,26 @@ Eskilson Everton Fancybox FancyBox +FEFLOW Feldspars fmt Forchheimer Fortran Francesco frontmatter +Galerkin Genuchten Geoenergy -Galerkin Giraldo gml GML Gmsh +Gnielinski Goswami Guo Heidemann Homebrew Horner -HTTPS IPhreeqc ipynb ipyvtklink @@ -55,8 +61,10 @@ Jacobian Johannsen Jong Jupyter +Jupytext Juwels Kinzelbach +Kitware Kolditz Laloui Langergraber @@ -68,9 +76,11 @@ Massmann Matplotlib meshio METIS +MFront Mikelic Mises MODFLOW +MTest nbconvert nbdime Netbeans @@ -87,7 +97,9 @@ parameteri[zs]ation ParaView Parisio partmesh +PDE[s?] Péclet +PETSc PHREEQC Pinheiro Prandtl @@ -98,6 +110,7 @@ pvpython PVTU Quadro Quirijn +Ramey recondensation relref Revista @@ -107,13 +120,16 @@ Rossendorf Ruehaak Scheidegger semianalytical +SGrid Shao shortcode Snakemake Srivastava +ST[s?] Stauffer Stauffer stdout +stepping[s?] storativity Tarok Taucha @@ -122,16 +138,19 @@ TESPy Theis Thuringia Thuringian +TODO[s?] Ucar Unlicense Unstrut Vogel Vogels vtkdiff -VTU +VTK[s?] +VTUinterface Witte Xcode Xeon XPath Youngs Zenodo +zlib diff --git a/Documentation/.vale/Vocab/ogs/ignore.txt b/Documentation/.vale/Vocab/ogs/ignore.txt index d8d2d6dbf00..9c0a6759e6b 100644 --- a/Documentation/.vale/Vocab/ogs/ignore.txt +++ b/Documentation/.vale/Vocab/ogs/ignore.txt @@ -54,3 +54,9 @@ thermomechanics undeformed voxel wellbore +expansivity +simplices +orthotropic +tetrahedralization +cmake +ctest diff --git a/scripts/ci/jobs/build-docs.yml b/scripts/ci/jobs/build-docs.yml index ff796f72873..9ce2be9f4d6 100644 --- a/scripts/ci/jobs/build-docs.yml +++ b/scripts/ci/jobs/build-docs.yml @@ -99,7 +99,7 @@ check docs links: build/docs spell check docs: - image: registry.gitlab.com/gitlab-org/gitlab-docs/lint-markdown:alpine-3.15-vale-2.16.1-markdownlint-0.31.1 + image: registry.gitlab.com/gitlab-org/gitlab-docs/lint-markdown:alpine-3.18-vale-2.27.0-markdownlint-0.35.0-markdownlint2-0.8.1 stage: check needs: [] variables: diff --git a/scripts/ci/jobs/code-quality.yml b/scripts/ci/jobs/code-quality.yml index 34aa669c244..5528fc9014e 100644 --- a/scripts/ci/jobs/code-quality.yml +++ b/scripts/ci/jobs/code-quality.yml @@ -7,8 +7,7 @@ cppcheck: - cd build script: - > - cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DOGS_USE_CONAN=OFF - -DOGS_BUILD_UTILS=OFF + cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DOGS_BUILD_UTILS=OFF -DOGS_USE_UNITY_BUILDS=OFF -DCMAKE_EXPORT_COMPILE_COMMANDS=ON - bash cppcheck.sh artifacts: diff --git a/scripts/cmake/CppCheck.cmake b/scripts/cmake/CppCheck.cmake index 5ce9cf0c539..fe03718a776 100644 --- a/scripts/cmake/CppCheck.cmake +++ b/scripts/cmake/CppCheck.cmake @@ -9,10 +9,13 @@ elseif(DEFINED CMAKE_BUILD_PARALLEL_LEVEL) set(CPPCHECK_PARALLEL ${CMAKE_BUILD_PARALLEL_LEVEL}) endif() if(DEFINED CPM_SOURCE_CACHE) - set(_cpp_check_ingore "-i${CPM_SOURCE_CACHE}") + set(_cpm_dir ${CPM_SOURCE_CACHE}) +elseif(DEFINED ENV{CPM_SOURCE_CACHE}) + set(_cpm_dir $ENV{CPM_SOURCE_CACHE}) else() - set(_cpp_check_ingore "-i${PROJECT_BINARY_DIR}/_deps") + set(_cpm_dir ${PROJECT_BINARY_DIR}/_deps) endif() +set(_last_sed_expression [['x;${s/,$//;p;x;};1d']]) configure_file( ${PROJECT_SOURCE_DIR}/scripts/test/cppcheck.in.sh @@ -25,13 +28,6 @@ endif() add_custom_target( cppcheck - COMMAND - ${CPPCHECK_TOOL_PATH} - --project=${PROJECT_BINARY_DIR}/compile_commands.json --language=c++ - --std=c++20 --enable=all --inconclusive ${CPPCHECK_THREADS} -i - ${PROJECT_BINARY_DIR}/CMakeFiles -i ${PROJECT_BINARY_DIR}/_deps -i - ${PROJECT_SOURCE_DIR}/ThirdParty -i - ${PROJECT_SOURCE_DIR}/Applications/DataExplorer -i - ${PROJECT_SOURCE_DIR}/Tests --xml --xml-version=2 - --output-file=${PROJECT_BINARY_DIR}/cppcheck.log ${PROJECT_SOURCE_DIR} + COMMAND ${BASH_TOOL_PATH} cppcheck.sh + WORKING_DIRECTORY ${PROJECT_BINARY_DIR} ) diff --git a/scripts/test/cppcheck.in.sh b/scripts/test/cppcheck.in.sh index 79b1819cfdb..ecc33278bc8 100644 --- a/scripts/test/cppcheck.in.sh +++ b/scripts/test/cppcheck.in.sh @@ -5,15 +5,15 @@ OUTPUT_FILE=${PROJECT_BINARY_DIR}/cppcheck.json ${CPPCHECK_TOOL_PATH} \ --project=${PROJECT_BINARY_DIR}/compile_commands.json \ --language=c++ \ - --std=c++20 \ + --std=c++${CMAKE_CXX_STANDARD} \ --enable=all \ --inconclusive \ -j ${CPPCHECK_PARALLEL} \ - ${_cpp_check_ingore} \ --inline-suppr \ - --suppress=*:*/usr/local\* \ - --suppress=*:*cpm\* \ - --suppress=*:*Tests\* \ + -i ${_cpm_dir} --suppress=*:${_cpm_dir}/* \ + -i ${PROJECT_SOURCE_DIR}/ThirdParty --suppress=*:${PROJECT_SOURCE_DIR}/ThirdParty* \ + -i ${PROJECT_SOURCE_DIR}/Tests --suppress=*:*Tests/* \ + --suppress=missingIncludeSystem \ --template='{\n "description": "{message}",\n "severity": "info",\n "location": {\n "path": "{file}",\n "lines": {\n "begin": {line}\n }\n }\n},' \ --output-file="$OUTPUT_FILE.tmp" @@ -24,15 +24,21 @@ $( `: strip source code absolute path` \ sed 's|${PROJECT_SOURCE_DIR}/||' | \ `: escape strings` \ - sed 's/string literal "\(.*\)" to/string literal \\"\1\\" to/g' | \ - `: remove last comma` \ - sed '$s/,$//' + sed 's/string literal "\(.*\)" to/string literal \\"\1\\" to/g' ) ] EOF +cat <"$OUTPUT_FILE" +$( + cat "$OUTPUT_FILE" | \ + `: remove last comma` \ + sed ${_last_sed_expression} +) +EOF + rm "$OUTPUT_FILE.tmp" if [ -f ${Python_EXECUTABLE} ]; then - ${Python_EXECUTABLE} ${PROJECT_SOURCE_DIR}/scripts/test/cppcheck_gen_hashes.py "$OUTPUT_FILE" + ${Python_EXECUTABLE} ${PROJECT_SOURCE_DIR}/scripts/test/cppcheck_gen_hashes.py "$OUTPUT_FILE" fi diff --git a/web/content/docs/benchmarks/elliptic/elliptic-neumann/index.md b/web/content/docs/benchmarks/elliptic/elliptic-neumann/index.md index 1db94daac1f..ed4c81d2650 100644 --- a/web/content/docs/benchmarks/elliptic/elliptic-neumann/index.md +++ b/web/content/docs/benchmarks/elliptic/elliptic-neumann/index.md @@ -35,12 +35,22 @@ k\\;{\partial h(x,y) \over \partial n} = 0 &\quad \text{on } (x,y=1) \subset \Ga }$$ The solution of this problem is + $$ -\begin{equation} h(x,y) = 1 + \sum_{k=1}^\infty A_k \sin\bigg(C_k y\bigg) \sinh\bigg(C_k x\bigg), -\end{equation} $$ -where $C_k = \frac{2k-1}{2} \pi$ and $A_k = 2 \Big/ \Big(C_k^2 \cosh\big(C_k\big)\Big)$. + +where + +$$ +C_k = \frac{2k-1}{2} \pi +$$ + +and + +$$ +A_k = 2 \Big/ \Big(C_k^2 \cosh\big(C_k\big)\Big). +$$ ## Input files diff --git a/web/content/docs/benchmarks/heat-transport-bhe/pipe_flow_EBHE/index.md b/web/content/docs/benchmarks/heat-transport-bhe/pipe_flow_EBHE/index.md index 6bb1a369d8a..730bdca2367 100644 --- a/web/content/docs/benchmarks/heat-transport-bhe/pipe_flow_EBHE/index.md +++ b/web/content/docs/benchmarks/heat-transport-bhe/pipe_flow_EBHE/index.md @@ -25,60 +25,73 @@ Figure 1: Single pipe flow model In Ramey's analytical solution (Ramey et al. (1962)), the outlet temperature of the pipe inside the wellbore can be calculated by, -\begin{equation} +$$ T_o(t) = T_{s} + (T_i(t) - T_{s})\exp(-\Delta z/X) -\end{equation} +$$ \noindent where, $q$ is the flow rate of the fluid in the wellbore and coefficient $X$ is determined by, -\begin{equation} +$$ X = \frac{q\rho_fc_{p,f}(\lambda_{s}+r_pUf(t))}{2\pi r_pU \lambda_{s}} -\end{equation} +$$ with dimensionless time $t_D = \frac{\lambda_{s}t}{(\rho_{s}c_{p,s}r_b)}$, the time function $f(t)$ can be calculated by, -\begin{align} - &f(t) = [0.4063+0.5\ln(t_D)][1+\frac{0.6}{t_D}], & t_D > 1.5 - \\ - &f(t) = 1.1281\sqrt{t_D}(1-0.3\sqrt{t_D}), & t_D \leqslant 1.5 -\end{align} + -\noindent and the overall heat transfer coefficient $U$ is written as follows, +$$ + f(t) = [0.4063+0.5\ln(t_D)][1+\frac{0.6}{t_D}], t_D > 1.5 +$$ -\begin{equation} + + +$$ + f(t) = 1.1281\sqrt{t_D}(1-0.3\sqrt{t_D}), t_D \leqslant 1.5 +$$ + +and the overall heat transfer coefficient $U$ is written as follows, + +$$ U = [\frac{r_{pi}+t_{pi}}{r_{pi}h}+(r_{pi}+t_{pi})(\frac{\ln{\frac{r_{pi}+t_{pi}}{r_{pi}}}}{\lambda_{pi}}+\frac{\ln{\frac{r_b}{r_{pi}+t_{pi}}}}{\lambda_{grout}})]^{-1} -\end{equation} +$$ -\begin{equation} +$$ h = \frac{\lambda_f Nu}{2r_{pi}} -\end{equation} +$$ The Nusselt number can be determined according to the Gnielinski's equation (Gnielinski et al. (1975)), -\begin{align} - & Nu = 4.364, & Re < 2300 \\ - & Nu = \frac{\frac{f}{8}(Re - 1000)Pr}{1+12.7\sqrt{\frac{f}{8}}(Pr^{\frac{2}{3}}-1)}, & 2300\leqslant Re < 5 \times 10^6 -\end{align} +$$ + Nu = 4.364, Re < 2300 +$$ + +$$ + Nu = \frac{\frac{f}{8}(Re - 1000)Pr}{1+12.7\sqrt{\frac{f}{8}}(Pr^{\frac{2}{3}}-1)}, 2300\leqslant Re < 5 \times 10^6 +$$ Pr is the Prandtl number, and the friction factor $f$, is evaluated by Churchill correlation (Churchill et al. (1977)), -\begin{equation} +$$ f = \frac{1}{(\frac{1}{[((\frac{8}{Re})^{10}+(\frac{Re}{36500})^{20})]^{1/2}}+[2.21(\ln{\frac{Re}{7}})]^{10})^{1/5}} -\end{equation} +$$ The Prandtl and Reynolds number can be calculated as follows, -\begin{align} - & Pr = \frac{\mu_f c_{p,f}}{\lambda_f} - & Re = \frac{\rho_f v d_{pi}}{\mu_f} -\end{align} -\noindent where, $\mu_f, \rho_f$ and $\lambda_f$ is the fluid viscosity, density and thermal conductivity. +$$ + Pr = \frac{\mu_f c_{p,f}}{\lambda_f} +$$ + +$$ + Re = \frac{\rho_f v d_{pi}}{\mu_f} +$$ + +where, $\mu_f, \rho_f$ and $\lambda_f$ is the fluid viscosity, density and thermal conductivity. ## Results and discussion -The outlet temperature change over time was compared against analytical solution and presented in Figure 2. After 30 days, the fluid temperature distribution in the wellbore is shown in Figure 3. The maximum relative error between the numerical model and Ramey's analytical solution is less than 0.15 \%. +The outlet temperature change over time was compared against analytical solution and presented in Figure 2. After 30 days, the fluid temperature distribution in the wellbore is shown in Figure 3. The maximum relative error between the numerical model and Ramey's analytical solution is less than $0.15\ \\%$. -In numerical model, the outlet temperature at beginning stage is affected by the initial temperature in the pipe inside the wellbore. The initial fluid temperature set in the benchmark means there is water with 20 $^{\circ}$C filled in the wellbore already before injecting water into the wellbore. But in the analytical solution, no initial temperature is set and the temperature keeps equilibrium state at every moment. The impact of initial temperature condition in numerical model is decreasing with the increasing of the operational time as shown in Figure 2. +In numerical model, the outlet temperature at beginning stage is affected by the initial temperature in the pipe inside the wellbore. The initial fluid temperature set in the benchmark means there is water with $20\ ^{\circ}$C filled in the wellbore already before injecting water into the wellbore. But in the analytical solution, no initial temperature is set and the temperature keeps equilibrium state at every moment. The impact of initial temperature condition in numerical model is decreasing with the increasing of the operational time as shown in Figure 2. {{< img src="T_out_comparison.png" width="120">}} diff --git a/web/content/docs/benchmarks/heatconduction/heatconduction-soil-freezing/index.md b/web/content/docs/benchmarks/heatconduction/heatconduction-soil-freezing/index.md index 7e0e1616c4f..e53f1aafbe1 100644 --- a/web/content/docs/benchmarks/heatconduction/heatconduction-soil-freezing/index.md +++ b/web/content/docs/benchmarks/heatconduction/heatconduction-soil-freezing/index.md @@ -21,17 +21,25 @@ Simulations are performed using both our OpenGeoSys platform and the [FreeFem++] The detailed IBVP problem description for the T+freezing equation, geometric setup, material and model parameters used in the implementation can be found in this document [this PDF document](Heat_conduction_phase_change_(soil_freezing_around_BHE).pdf). The figures below are taken from this documentation and serve for illustrative purposes to give a hint about the modeled process and simulations outcome. 1. We assume the problem to be 3d-axisymmetric and hence opt for reducing it to 2-dimensional setting, as depicted in the figure below. A quarter of a cylindrical soil specimen around a BHE (a quarter of a 3-dimensional domain $\Omega$) and reduction to 2d computational domain $S$: + {{< img src="Soil_block.png" >}} + Note that $(r,z)\in S$ are denoted as $(x,y)$ which are assumed to be unrelated to the coordinate notations in the original 3d formulation. 2. The initial condition for $T$ in $S$ is assumed to be a positive function which decays linearly from surface to bottom. For modeling the (time-dependent) boundary conditions on $\Gamma_D$ of $S$, it is assumed that within the first $\widehat{t}$ hours, the temperature on $\Gamma_D$ drops continuously from the initial state to the values prescribed by some continuous piecewise linear function of $y$ and such that at the last depth segment it becomes negative. (The latter mimics the impact of the BHE refrigerant with sub-zero temperature.) The figure sketches the situation: + {{< img src="T1_soil_block.png" >}} + Temperature is given in degrees Celsius. For $t>\widehat{t}$, the prescribed temperature on $\Gamma_D$ and, thus, the heat conduction in the modelled case is triggered by a significant difference between the temperature on $\Gamma_D$ and the initial one within $S$. 3. The results of modelling are depicted in the following two figures, where we plot the temperature distribution in the soil block after 720 hours (30 days) of cooling, and also compare the outcomes of the two corresponding packages: -{{< img src="T-distribution_(OGS_vs_FF++_2d).png" >}} -{{< img src="T-distribution_(OGS_vs_FF++_3d).png" >}} + +{{< img src="T-distribution_(OGS_vs_FF++*2d).png" >}} +{{< img src="T-distribution*(OGS_vs_FF++*3d).png" >}} + Temperature is given in kelvins. The color legend of $T$ in the corresponding ParaView plots is tuned such that the amount of ice formed around BHEs can be identified. As expected, ice formation occurs in the vicinity of $\Gamma_D$, more specifically, near the segment of $\Gamma_D$ in which the negative temperature has been prescribed. In the rest of the domain, temperature distribution remains almost identical to the initial state, as could also be expected. 4. Finally, the corresponding results from the previous figure are plotted over the three different directed lines within the domain $S$: -{{< img src="T-over_lines_(OGS_vs_FF++).png" >}} + +{{< img src="T-over_lines*(OGS_vs_FF++).png" >}} + Here, origin of the horizontal axis on the right plot corresponds to line's origin. For the selected lines, the compared data seems identical point-wise, thus supporting the quantitative similarity of the OGS and FF++ results observed earlier. ### *Remark* diff --git a/web/content/docs/benchmarks/hydro-component/contracer/index.md b/web/content/docs/benchmarks/hydro-component/contracer/index.md index f452b05b818..6c175213010 100644 --- a/web/content/docs/benchmarks/hydro-component/contracer/index.md +++ b/web/content/docs/benchmarks/hydro-component/contracer/index.md @@ -93,9 +93,9 @@ Both models (1D and 2D) fit the experimental tracer breakthrough curves quite we The deviance at the peak and tail can be related to the fact that the simulations only consider conservative equilibrium transport (processes that may have occurred in the experimental system such as tracer sorption, non--equilibrium flow and evapotranspiration were not considered in the model). The differences between the OGS-6 and OGS-5 simulation were very low (RMSQE$=$1.37e-07). -![Measured (tracer_exp) and simulated tracer breakthrough curves at the outlet (1D scenario)](ConTracer1d_results.png) +![Measured and simulated tracer breakthrough curves at the outlet (1D scenario)](ConTracer1d_results.png) -![Measured (tracer_exp} and simulated tracer breakthrough curves at the outlet (2D scenario)](ConTracer2d_results.png) +![Measured and simulated tracer breakthrough curves at the outlet (2D scenario)](ConTracer2d_results.png) ## References diff --git a/web/content/docs/benchmarks/hydro-component/theis/HC_Theis/index.md b/web/content/docs/benchmarks/hydro-component/theis/HC_Theis/index.md index bae09404234..9d2005053b6 100644 --- a/web/content/docs/benchmarks/hydro-component/theis/HC_Theis/index.md +++ b/web/content/docs/benchmarks/hydro-component/theis/HC_Theis/index.md @@ -30,7 +30,7 @@ The setup comprises a 1/8th slice of a full circle (see figure 1). The outer boundary condition is set as Dirichlet with a hydrostatic pressure along the shell surface of the slice equivalent to a head of $h = 0 m$ (i.e. water level equals top of domain). For mass transport, a Dirichlet boundary conditions with concentration $c = 0$ is set at the outer shell. The inner boundary condition is equivalent to the eighth of a total abstraction rate of $Q_t = 15 m^3/d$ for a full cylinder. *NB: In the `ComponentTransport` process, the Neumann BC is given as mass flux and has to be calculated per area, such that the value for the project file is $Q = Q_t / 8 / A \cdot \rho_0 = 2.83542E-03 m^3/s/m^2 \cdot kg/m^3$ (units equal $\frac{kg}{s m^2}$) with fluid reference density $\rho_0 = 1000 kg/m^3$ and abstraction area $A = 7.65 m^2$.* -The homogeneous, isotropic domain is defined for the radius $1 < r < 100 m$ and a thickness $b = 10 m$. Saturated intrinsic permeability is $\kappa = 7.6453E-13 m^2$ yielding a transmissivity of $T = 7.5E-05 m^2/s$; porosity is $\phi = 0.2$; specific storage is $S_s = 1.0E-03$ and defined through compressibility $\gamma = 5.0968E-08 s^2/m/kg$ (input tag fluid_density_pressure_difference_ratio is $\gamma = \frac{1}{\rho_0} \frac{\partial \rho}{\partial p}$, which can be used to incorporate $S_s$ with $\gamma = \frac{S_s}{b \phi g \rho_0}$ with gravitational acceleration $g = 9.81 m^2/s$). +The homogeneous, isotropic domain is defined for the radius $1 < r < 100 m$ and a thickness $b = 10 m$. Saturated intrinsic permeability is $\kappa = 7.6453E-13 m^2$ yielding a transmissivity of $T = 7.5E-05 m^2/s$; porosity is $\phi = 0.2$; specific storage is $S_s = 1.0E-03$ and defined through compressibility $\gamma = 5.0968E-08 s^2/m/kg$ (input tag `fluid_density_pressure_difference_ratio` is $\gamma = \frac{1}{\rho_0} \frac{\partial \rho}{\partial p}$, which can be used to incorporate $S_s$ with $\gamma = \frac{S_s}{b \phi g \rho_0}$ with gravitational acceleration $g = 9.81 m^2/s$). Mass transport properties are irrelevant as no transport processes are calculated. diff --git a/web/content/docs/benchmarks/hydro-thermal/constant-viscosity/index.md b/web/content/docs/benchmarks/hydro-thermal/constant-viscosity/index.md index 6652093921c..3d87579bf75 100644 --- a/web/content/docs/benchmarks/hydro-thermal/constant-viscosity/index.md +++ b/web/content/docs/benchmarks/hydro-thermal/constant-viscosity/index.md @@ -17,7 +17,7 @@ See [this PDF](HT-Process.pdf). This is a 2d benchmark of large-scale thermal convection that tests the temperature dependent fluid density in the hydro-thermal process monolithic approach implementation. It is defined on the domain $\Omega = [0,5500]^2.$ -- The initial conditions for the pressure is a gradient starting from zero at the top surface to a pressure of circa 54 mega pascal at the bottom given in the data array 'initial_pressure' in the VTU file. The initial temperature is also almost a gradient from top (293 K) to bottom (443 K) of the domain, except there is a small perturbation given by adding $\sin \left( \pi \frac{y}{5500}\right) \cdot \cos \left( \pi \frac{x}{5500}\right).$ See the following images. +- The initial conditions for the pressure is a gradient starting from zero at the top surface to a pressure of circa 54 mega pascal at the bottom given in the data array `initial_pressure` in the VTU file. The initial temperature is also almost a gradient from top (293 K) to bottom (443 K) of the domain, except there is a small perturbation given by adding $\sin \left( \pi \frac{y}{5500}\right) \cdot \cos \left( \pi \frac{x}{5500}\right).$ See the following images. TODO 3 images @@ -25,6 +25,6 @@ TODO 3 images - The further parameter specification can be found in the project file linked at the top of this page. - The steady state temperature is shown in the following on the right figure. The left figure shows the resulting temperature minus the initial gradient. The resulting temperatures are in good accordance with the FEFLOW results and with results from the OGS version < 6. -## Comparison with FEFlow solution +## Comparison with FEFLOW solution {{< img src="compare.png" >}} diff --git a/web/content/docs/benchmarks/hydro-thermal/decovalex-TH/index.md b/web/content/docs/benchmarks/hydro-thermal/decovalex-TH/index.md index e2215e0993a..ff8bddbe999 100644 --- a/web/content/docs/benchmarks/hydro-thermal/decovalex-TH/index.md +++ b/web/content/docs/benchmarks/hydro-thermal/decovalex-TH/index.md @@ -21,27 +21,27 @@ The TASK D_THM1 of the DECOVALEX-THMC project studies the coupled thermal hydrau about the FEBEX type repository \cite BirEtAl:2008. In this example, TASK D_THM1 is simplified in order to test the staggered scheme for TH process in OGS. The simplifications are -
    -
  1. resizing the domain to an area that can represent the near field of an - installed nuclear water canister,

  2. -
  3. assuming the bentonite is fully saturated from the beginning,

  4. -
  5. ignoring the mechanical process.

  6. -
-

With such simplifications, the geometry of the present example is illustrated - in the following figure:

+ +1. resizing the domain to an area that can represent the near field of an + installed nuclear water canister, +2. assuming the bentonite is fully saturated from the beginning, +3. ignoring the mechanical process. + +With such simplifications, the geometry of the present example is illustrated +in the following figure: + {{< img src="decovalex_TH_domain.png" >}} -

In the above figure, the domain in the annulus sector represents the sealing + +In the above figure, the domain in the annulus sector represents the sealing material, bentonite. A heat power, which is generated by the nuclear waste with one million year variation, is applied onto the inner arc of the annulus sector. On the top boundary, the boundary conditions are - p = 4.3 ⋅ 106 Pa, - T = 294 K. + $p=4.3 ⋅ 10^6\ \mathrm{Pa}, T=294\ \mathrm{K}$. While on the bottom boundary, the boundary conditions are set as - p = 4.7 ⋅ 106 Pa, - T = 310 K. + $p=4.7 ⋅ 10^6\ \mathrm{Pa}, T=319\ \mathrm{K}$. The initial conditions are given as - p = 4.7 ⋅ 106 Pa, - T = 298 K.

+ $p=4.7 ⋅ 10^6\ \mathrm{Pa}, T=298\ \mathrm{K}$. +

The material properties are shown in the following table:

@@ -118,9 +118,9 @@ The TASK D_THM1 of the DECOVALEX-THMC project studies the coupled thermal hydrau ## Solution -

As the reference results, the temperature and pressure distributions in the +As the reference results, the temperature and pressure distributions in the domain at the time of 18 years are shown in the following figure, in which the - thermal convection effective can be seen clearly.

+ thermal convection effective can be seen clearly. {{< img src="decovalex_TH_domain_pT.png" >}} diff --git a/web/content/docs/benchmarks/small-deformations/ModifiedCamClay/index.md b/web/content/docs/benchmarks/small-deformations/ModifiedCamClay/index.md index 1101656ecc9..c2b939723f1 100644 --- a/web/content/docs/benchmarks/small-deformations/ModifiedCamClay/index.md +++ b/web/content/docs/benchmarks/small-deformations/ModifiedCamClay/index.md @@ -17,7 +17,7 @@ Five tests are presented: {{< data-link >}} of which the last three have the same test program but use different implementations of the modified Cam clay model. -The mfront-files can be found at [here](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/MaterialLib/SolidModels/MFront). +The MFront-files can be found at [here](https://gitlab.opengeosys.org/ogs/ogs/-/tree/master/MaterialLib/SolidModels/MFront). ## Problem description diff --git a/web/content/docs/benchmarks/th2m/th2m_strain_dependent_permeability/index.md b/web/content/docs/benchmarks/th2m/th2m_strain_dependent_permeability/index.md index 208d3122c77..d67964cf319 100644 --- a/web/content/docs/benchmarks/th2m/th2m_strain_dependent_permeability/index.md +++ b/web/content/docs/benchmarks/th2m/th2m_strain_dependent_permeability/index.md @@ -12,6 +12,6 @@ draft = true ## Problem description -Todo +TODO ## Results and evaluation diff --git a/web/content/docs/benchmarks/thermal-two-phase-flow/TCE-diffusion/index.md b/web/content/docs/benchmarks/thermal-two-phase-flow/TCE-diffusion/index.md index f74a3cb3cdd..34b20097eae 100644 --- a/web/content/docs/benchmarks/thermal-two-phase-flow/TCE-diffusion/index.md +++ b/web/content/docs/benchmarks/thermal-two-phase-flow/TCE-diffusion/index.md @@ -27,9 +27,11 @@ Table 1: Parameters used in the numerical model. | van Genuchten parameter | $m_{\mathrm{vG}}$ | 0.8 | - | Atteia and Höhener [[1]](#1) developed a semianalytical solution for the TCE concentration profile at steady state. In their original solution, the effect of hydrodynamic dispersion is also considered. Here, we briefly derive a simplified semianalytical solution for the case without groundwater flow. By using the classical Millington [[2]](#2) formulation for tortuosity, the diffusive flux in either phase $\alpha$ ($\alpha\in \{a, w\}$) can be written as -\begin{equation} + +$$ J_{\alpha}=-nS_{\alpha}\tau_{\alpha}D_{0\alpha}\frac{dx^c_{\alpha}}{dz}=-n^{4/3}S_{\alpha}^{10/3}D_{0\alpha}\frac{dx^c_{\alpha}}{dz} -\end{equation} +$$ + in which $\tau_{\alpha}$ is the tortuosity of phase $\alpha$ and $x^c_{\alpha}$ is molar fraction of TCE in phase $\alpha$. Assuming equilibrium of contaminant concentrations between the liquid and gas phases, we have \begin{equation} \frac{N_wx^c_w}{P_gx^c_a}=H diff --git a/web/content/docs/benchmarks/thermo-hydro-mechanics/massbalance_with_freezing/index.md b/web/content/docs/benchmarks/thermo-hydro-mechanics/massbalance_with_freezing/index.md index af74d920c82..dddb8f9331a 100644 --- a/web/content/docs/benchmarks/thermo-hydro-mechanics/massbalance_with_freezing/index.md +++ b/web/content/docs/benchmarks/thermo-hydro-mechanics/massbalance_with_freezing/index.md @@ -1,7 +1,7 @@ +++ author = "Tymofiy Gerasimov, Dmitri Naumov" date = "2023-16-6" -title = "Fully_saturated_column_deformation_and_freezing" +title = "Fully saturated column deformation and freezing" project = ["ThermoHydroMechanics/ColumnDeformationFreezing/TM.prj"] image = "Column_setup.png" +++ @@ -44,7 +44,7 @@ To assess and analyse our simulation results, we calculate and record at each time step the vertical component $F_y$ of reaction force on the top boundary $\Gamma_\mathrm{top}$, namely, -\begin{equation} +$$ \boldsymbol F^n=(F^n_x,F^n_y):=\int_{\Gamma_\mathrm{top}} \boldsymbol\sigma(\boldsymbol u^n)\cdot\boldsymbol n\\, \mathrm{d}s \quad\text{for $\boldsymbol\sigma \in @@ -52,7 +52,7 @@ $\Gamma_\mathrm{top}$, namely, \boldsymbol\sigma_\mathrm{I}, \boldsymbol\sigma_\mathrm{SI} \\\}$}, -\end{equation} +$$ where $\boldsymbol u^n:\Omega\rightarrow\mathbb{R}^2$ is the computed displacement solution vector, and $\boldsymbol n$ is an outward normal on diff --git a/web/content/docs/devguide/documentation/jupyter-docs/index.md b/web/content/docs/devguide/documentation/jupyter-docs/index.md index 82ae9b05266..8deecdb3839 100644 --- a/web/content/docs/devguide/documentation/jupyter-docs/index.md +++ b/web/content/docs/devguide/documentation/jupyter-docs/index.md @@ -14,10 +14,10 @@ parent = "development-workflows" ## Create a new notebook -Create a new notebook file in `Tests/Data` (either as regular `.ipynb`-files or as Markdown-based notebooks via [jupytext](https://jupytext.readthedocs.io/en/latest)). See examples: +Create a new notebook file in `Tests/Data` (either as regular `.ipynb`-files or as Markdown-based notebooks via [Jupytext](https://jupytext.readthedocs.io/en/latest)). See examples: - [SimpleMechanics.ipynb](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Mechanics/Linear/SimpleMechanics.ipynb) (regular `.ipynb`-notebook) -- [Linear_Disc_with_hole.md](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Mechanics/Linear/DiscWithHole/Linear_Disc_with_hole.md) (jupytext-based notebook in Markdown) +- [Linear_Disc_with_hole.md](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/Mechanics/Linear/DiscWithHole/Linear_Disc_with_hole.md) (Jupytext-based notebook in Markdown) ## Add web meta information @@ -38,7 +38,7 @@ If the notebook result should appear as a page on the web documentation a frontm
-In jupytext-based notebooks you can add the frontmatter within the ``- and ``-markers: +In Jupytext-based notebooks you can add the frontmatter within the ``- and ``-markers: ```md @@ -125,9 +125,9 @@ ctest -R nb -j 4 --output-on-failure ## Advanced topics -### jupytext usage +### Jupytext usage -If you use the [execution environment](#execution-environment) [jupytext](https://jupytext.readthedocs.io/en/latest) as already configured and its usage is transparent: +If you use the [execution environment](#execution-environment) [Jupytext](https://jupytext.readthedocs.io/en/latest) is already configured and its usage is transparent: - Double-click on a markdown file will open it as a Notebook - Upon saving or executing a linked `.ipynb`-file is created in the background which stores outputs @@ -140,8 +140,8 @@ On the web site or MR web previews on pages generated by a notebook there is a n ![Notebook web banner with BinderHub launch button](binderhub-button.png) - Click the button to launch the notebook in BinderHub. -- The environment running in BinderHub is defined in [bilke/binder-ogs-requirements at GitHub](https://github.com/bilke/binder-ogs-requirements) -- When clicking the link it launches a Jupyter Lab instance pre-configured with ogs [via wheel](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/requirements-ogs.txt#L2), clones the current ogs repo in it and opens the respective notebook ready to run. Please note that startup times may be several minutes and the computing resources are limited (1 core, 2GB RAM). For improved performance we would need to setup own infrastructure. Also currently only works for serial ogs configs. +- The environment running in BinderHub is defined in [`bilke/binder-ogs-requirements` at GitHub](https://github.com/bilke/binder-ogs-requirements) +- When clicking the link it launches a Jupyter Lab instance pre-configured with ogs [via wheel](https://gitlab.opengeosys.org/ogs/ogs/-/blob/master/Tests/Data/requirements-ogs.txt#L2), clones the current ogs repo in it and opens the respective notebook ready to run. Please note that startup times may be several minutes and the computing resources are limited (1 core, 2GB RAM). For improved performance we would need to setup own infrastructure. Also currently only works for serial ogs configurations. ### PyVista notebooks on headless Linux systems diff --git a/web/content/docs/devguide/documentation/todo/index.md b/web/content/docs/devguide/documentation/todo/index.md index 38d5ab1ba51..a03619af523 100644 --- a/web/content/docs/devguide/documentation/todo/index.md +++ b/web/content/docs/devguide/documentation/todo/index.md @@ -8,12 +8,13 @@ weight = 1027 This list was obtained using grep and added here to provide an overview of what sections are missing the documentation. In the future it should be generated automatically. -It can be obtained by running script ```todo-check.sh``` from ```/web/content/docs/userguide``` folder. +It can be obtained by running script `todo-check.sh` from `web/content/docs/userguide` folder. -## TODOs in userguide/basics +## TODOs in `userguide/basics` -## TODOs in userguide/blocks -``` +## TODOs in `userguide/blocks` + +```bash blocks/curves.md-19-
blocks/curves.md-20- blocks/curves.md:21:TODO: Add general description @@ -95,8 +96,9 @@ blocks/processes.md-158- blocks/processes.md:159:The global non-linear equation system can be solved either with Picard fix-point iterations or a Newton scheme. (TODO: Reference NLS scheme) ``` -## TODOs in userguide/features -``` +## TODOs in `userguide/features` + +```bash features/python_bc.md-31-## Using python boundary condition in project file features/python_bc.md-32- features/python_bc.md:33:TODO: add description of how to call python bc from the boundary condition tag @@ -122,5 +124,4 @@ features/mfront.md-109- features/mfront.md:110:TODO: add content ``` -## TODOs in userguide/troubleshooting - +## TODOs in `userguide/troubleshooting` diff --git a/web/content/docs/devguide/documentation/web-docs/index.md b/web/content/docs/devguide/documentation/web-docs/index.md index 1cf45a36a05..8f26d079b7d 100644 --- a/web/content/docs/devguide/documentation/web-docs/index.md +++ b/web/content/docs/devguide/documentation/web-docs/index.md @@ -88,7 +88,7 @@ We use [Markdown](https://commonmark.org/help/) for the actual content. Hugo use Use regular Markdown syntax: -```md +```markdown ![Alt text](square_1e2_neumann_gradients.png "Caption text") ``` @@ -96,7 +96,7 @@ The path to the image is the relative path to the current [page bundle](https:// You can add size attributes to the filename with a `#`-character: -```md +```markdown ![Alt text](square_1e2_neumann_gradients.png#two-third "Caption text") ``` diff --git a/web/content/docs/devguide/getting-started/build-configuration/index.md b/web/content/docs/devguide/getting-started/build-configuration/index.md index 57fccab4fb3..f0dda1acd38 100644 --- a/web/content/docs/devguide/getting-started/build-configuration/index.md +++ b/web/content/docs/devguide/getting-started/build-configuration/index.md @@ -146,7 +146,7 @@ CC=mpicc CXX=mpic++ cmake ../ogs -G Ninja -DCMAKE_BUILD_TYPE=Release -DOGS_USE_P
-CMake comes with a graphical tool called **cmake-gui**. You can find it in the **Windows Start Menu**. First you need to set the source and build directory. Then click **Configure**. Now choose the generator to be used (e.g. **Visual Studio {{< dataFile "versions.minimum_version.msvc.number" >}} {{< dataFile "versions.minimum_version.msvc.year" >}}** for Visual Studio {{< dataFile "versions.minimum_version.msvc.year" >}}). Now choose your desired configuration options by toggling the corresponding checkboxes. Click **Configure** again. Click **Configure** often enough until the **Generate**-button becomes visible. Pressing **Generate** will finally generate the project files inside the chosen build directory. +CMake comes with a graphical tool called `cmake-gui`. You can find it in the **Windows Start Menu**. First you need to set the source and build directory. Then click **Configure**. Now choose the generator to be used (e.g. **Visual Studio {{< dataFile "versions.minimum_version.msvc.number" >}} {{< dataFile "versions.minimum_version.msvc.year" >}}** for Visual Studio {{< dataFile "versions.minimum_version.msvc.year" >}}). Now choose your desired configuration options by toggling the corresponding checkboxes. Click **Configure** again. Click **Configure** often enough until the **Generate**-button becomes visible. Pressing **Generate** will finally generate the project files inside the chosen build directory.
diff --git a/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md b/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md index 5774336d10b..13a13c06461 100644 --- a/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md +++ b/web/content/docs/devguide/getting-started/build-configuration_for_MPI_PETSc/configure_for_mpi_and_petsc.md @@ -21,7 +21,7 @@ has many derivatives, e.g intelMPI) has to be installed as prerequisite. PETSc is not supported on Windows system. As an alternative you can follow the instructions in Section [Install PETSc manually](#install-petsc-manually) and run PETSc using Cygwin or use Windows Subsystem For Linux (WSL). The latter option is recommended - using WSL. -The manual of setting up OpenGeoSys in WSL can be found in our [Windows Subsystem For Linux]({{}}) guide. +The manual of setting up OpenGeoSys in WSL can be found in our [Windows Subsystem For Linux]({{< ref "wsl" >}}) guide. After setting up WSL, please follow the Linux tab in this guide. @@ -30,7 +30,7 @@ After setting up WSL, please follow the Linux tab in this guide. ## Set up prerequisites -Before continuing with this guide, please follow all steps from the "Developer guide" articles: [Set Up Prerequisites]({{}}) and [Get the source code]({{}}). +Before continuing with this guide, please follow all steps from the "Developer guide" articles: [Set Up Prerequisites]({{< ref "prerequisites" >}}) and [Get the source code]({{< ref "get-the-source-code" >}}). ### Install MPI @@ -88,7 +88,7 @@ cmake --build --preset release-petsc ``` The ```release-petsc``` preset is based on the ```release``` preset. -It can be customized by passing additional variable with ```-D``` flags to cmake command. +It can be customized by passing additional variable with ```-D``` flags to `cmake` command. If you want to install PETSc yourself, please see Section [Install PETSc](#install-petsc-manually). @@ -134,7 +134,7 @@ Please note, that the PETSc package is usually build in release mode independent
-PESTSc is recommended to use on Linux. +PETSc is recommended to use on Linux. On Windows, it only runs on UNIX emulator Cygwin. A detailed description about how to use PETSc on Windows is available on this PETSc site: . diff --git a/web/content/docs/devguide/getting-started/build/index.md b/web/content/docs/devguide/getting-started/build/index.md index eef1ee3a256..efd53c2c2a5 100644 --- a/web/content/docs/devguide/getting-started/build/index.md +++ b/web/content/docs/devguide/getting-started/build/index.md @@ -38,7 +38,7 @@ cd build-directory cmake --build . --config Release ``` -Please that with Visual Studio you have to provide the `--config`-paramter as Visual Studio is a [multi-configuration generator](https://cmake.org/cmake/help/latest/prop_gbl/GENERATOR_IS_MULTI_CONFIG.html) in CMake. +Please that with Visual Studio you have to provide the `--config`-parameter as Visual Studio is a [multi-configuration generator](https://cmake.org/cmake/help/latest/prop_gbl/GENERATOR_IS_MULTI_CONFIG.html) in CMake. If you build with the help of a [CMake preset]({{< ref "build-configuration#available-cmake-presets" >}}) then you can omit the `--config`-parameter, e.g.: diff --git a/web/content/docs/devguide/packages/python-env/index.md b/web/content/docs/devguide/packages/python-env/index.md index 887d241a9f0..e703e3c6d19 100644 --- a/web/content/docs/devguide/packages/python-env/index.md +++ b/web/content/docs/devguide/packages/python-env/index.md @@ -31,7 +31,7 @@ To manually add Python packages run the following inside your build-directory: .venv/bin/pip install python-package-name ``` -To activate the environment run `source .venv/bin/activate` inside your build directory. If you have the [direnv](https://direnv.net)-tool installed and setup the virtual environment will be activated automatically upon changing into the build directory. +To activate the environment run `source .venv/bin/activate` inside your build directory. If you have the [`direnv`](https://direnv.net)-tool installed and setup the virtual environment will be activated automatically upon changing into the build directory. ### Pip & Benchmarks diff --git a/web/content/docs/devguide/testing/gitlab-ci/index.md b/web/content/docs/devguide/testing/gitlab-ci/index.md index e7fce01fba5..3c53257279a 100644 --- a/web/content/docs/devguide/testing/gitlab-ci/index.md +++ b/web/content/docs/devguide/testing/gitlab-ci/index.md @@ -68,7 +68,7 @@ You can change the pipeline by editing the `.gitlab-ci.yml` and `scripts/ci/jobs These variables in `.gitlab-ci.yml` modify the pipeline: - `BUILD_TESTS`: Set this to `false` to disable unit tests. -- `BUILD_CTEST`: Set this to `false` to disable ctest (benchmark) tests. +- `BUILD_CTEST`: Set this to `false` to disable CTest (benchmark) tests. - `CTEST_ARGS`: Supply additional arguments to the `ctest`-command to select which benchmarks are run, e.g.: - `-R nb` would select all notebook-based tests and would disable all other benchmarks - `-LE large` would exclude all tests with label `large` diff --git a/web/content/docs/processes/component-transport/hydro-component/index.md b/web/content/docs/processes/component-transport/hydro-component/index.md index 6ef881c4e6c..8923bd97715 100644 --- a/web/content/docs/processes/component-transport/hydro-component/index.md +++ b/web/content/docs/processes/component-transport/hydro-component/index.md @@ -39,9 +39,11 @@ $$ \end{equation} $$ with the concentration $c_{\alpha}$ of the chemical component as the primary variable. $D$ [m$^2$/s] denotes the hydrodynamic dispersion tensor with the following relation -\begin{equation} + +$$ D = (\phi D_{p} + \beta_T \lVert \textbf{q} \rVert) \textbf{I} + ( \beta_L - \beta_T ) \frac{\textbf{q} \textbf{q}^{T}}{\lVert \textbf{q} \rVert} -\end{equation} +$$ + implemented, where $D_p$ [m$^2$/s] is the pore diffusion coefficient, $\beta_L$ and $\beta_T$ [m] are the longitudinal and transversal dispersion coefficients. $R$ [-] is the retardation factor defined as $$ R = 1 + \rho_{b} K_{D} / \phi diff --git a/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md index 2b0da050510..c09af614b4f 100644 --- a/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md +++ b/web/content/docs/processes/heat-transport/HEAT_TRANSPORT_BHE/index.md @@ -37,10 +37,10 @@ Here, $\Lambda_s$ denotes the tensor of thermal hydrodynamic dispersion and $H_s In the configuration of `HEAT_TRANSPORT_BHE` process, it is generally configured as follows. -* < 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. +* ``: should be `HeatTransportBHE`. +* ``: should be `HEAT_TRANSPORT_BHE`. +* ``: It is the order of the integration method for element-wise integration, normally set to 2. +* ``: 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. ```xml HeatTransportBHE diff --git a/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md index 2547d625465..892c825e854 100644 --- a/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md +++ b/web/content/docs/processes/heat-transport/Heat_Transport_BHE_PipelineNetwork/index.md @@ -172,7 +172,7 @@ The work flow of the PipeNetwork feature is illustrated in Figure 2. To explicit ### 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. +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 contains all the OGS-TESPy transferred BHE 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. ```bash data_index;BHE_id;Tin_val;Tout_val;Tout_node_id;flowrate diff --git a/web/content/docs/processes/thermal-processes/THM/index.md b/web/content/docs/processes/thermal-processes/THM/index.md index e5d3e34d144..106395da94d 100644 --- a/web/content/docs/processes/thermal-processes/THM/index.md +++ b/web/content/docs/processes/thermal-processes/THM/index.md @@ -59,9 +59,9 @@ THM process has to be declared in project file in the processes block. For examp Following process variables are available in THM process: -- temperature -- pressure -- displacement +- `temperature` +- `pressure` +- `displacement` For more details, see [Process variables]({{< ref "process_variables" >}}). diff --git a/web/content/docs/processes/thermal-processes/TRM/index.md b/web/content/docs/processes/thermal-processes/TRM/index.md index da4da584cb4..70af681b264 100644 --- a/web/content/docs/processes/thermal-processes/TRM/index.md +++ b/web/content/docs/processes/thermal-processes/TRM/index.md @@ -1,7 +1,7 @@ +++ author = "Feliks Kiszkurno, Wenqing Wang" date = "2023-01-10" -title = "Thermo Richards Mechanics Process" +title = "Thermo-Richards-Mechanics Process" weight = 2 +++ @@ -74,7 +74,7 @@ $$ $$ with $\mathbf{\sigma}$ the effective stress tensor, $b(S)$ the Bishop model, $\mathbf f$ the body force, and $\mathbf I$ the identity. - The primary unknowns of the momentum balance equation are the displacement $\mathbf u$, which is associated with the stress by the the generalized Hook's law as + The primary unknowns of the momentum balance equation are the displacement $\mathbf u$, which is associated with the stress by the generalized Hook's law as $$ {\dot {\mathbf {\sigma}}} = C {\dot {\mathbf \epsilon}}^e = C ( {\dot {\mathbf \epsilon}} - {\dot {\mathbf \epsilon}}^T @@ -124,7 +124,7 @@ Those properties are defined on the phase level for each medium. See [phase prop | Vapour density | Yes | No | No | No | No | WaterVapourDensity | | Vapour diffusion | Yes | No | No | No | No | VapourDiffusionFEBEX | | Thermal expansivity | No | Yes | No | No | Yes | - | -| Thermo osmosis coefficient | No | Yes | No | No | No | - | +| Thermo-osmosis coefficient | No | Yes | No | No | No | - | ### Medium properties @@ -158,9 +158,9 @@ TRM process has to be declared in the project file in the processes block. For e Following process variables are available in TRM process: -- temperature -- pressure -- displacement +- `temperature` +- `pressure` +- `displacement` For more details, see [Process variables]({{< ref "process_variables" >}}). diff --git a/web/content/docs/tools/fileio/GocadTSurfaceReader/index.md b/web/content/docs/tools/fileio/GocadTSurfaceReader/index.md index d9541bab6d9..e5c79778bb3 100644 --- a/web/content/docs/tools/fileio/GocadTSurfaceReader/index.md +++ b/web/content/docs/tools/fileio/GocadTSurfaceReader/index.md @@ -16,7 +16,7 @@ At the moment, this utility can read: Expected file extensions for these data types include *.vs,*.pl, *.ts, and*.mx (the last one for **m**i**x**ed data). -Another data type, SGRID (Structured Grid, usually saved to `.sg` files) can be converted via the [GoCadSGridReader](../../meshing/gocadsgridreader). +Another data type, SGrid (Structured Grid, usually saved to `.sg` files) can be converted via the [GoCadSGridReader](../../meshing/gocadsgridreader). Parsers for additional GOCAD-datasets may be added in the future. diff --git a/web/content/docs/tools/fileio/OGS2VTK/index.md b/web/content/docs/tools/fileio/OGS2VTK/index.md index f80574ec006..0bb3517450f 100644 --- a/web/content/docs/tools/fileio/OGS2VTK/index.md +++ b/web/content/docs/tools/fileio/OGS2VTK/index.md @@ -5,14 +5,17 @@ author = "Julian Heinze" +++ ## Description -OGS2VTK is a tool to convert OGS-mesh-files to VTK-files. + +OGS2VTK is a tool to convert OGS-mesh-files to VTK-files. It can be applied to format OGS-5 legacy mesh files or visualize them in ParaView. + ## Usage + ```bash -USAGE: +USAGE: OGS2VTK [--ascii_output] -o -i [--] [--version] [-h] -Where: +Where: --ascii_output Write VTU output in ASCII format. Due to possible rounding the ascii @@ -33,8 +36,11 @@ Where: -h, --help Displays usage information and exits. ``` -## Example: -Converting a .msh-file to a .vtu-file. + +## Example + +Converting a `.msh`-file to a `.vtu`-file. + ```bash OGS2VTK -i example.msh -o example.vtu -``` \ No newline at end of file +``` diff --git a/web/content/docs/tools/fileio/TIN2VTK/index.md b/web/content/docs/tools/fileio/TIN2VTK/index.md index 51dc44ef59b..f9bc6c50a1f 100644 --- a/web/content/docs/tools/fileio/TIN2VTK/index.md +++ b/web/content/docs/tools/fileio/TIN2VTK/index.md @@ -5,17 +5,19 @@ author = "Julian Heinze" +++ ## Description + This tool converts datasets in TIN-format, usually used in geographic information systems (GIS), into VTK-format. The TIN-format stores triangular irregular networks which can be considered a subclass of triangulated 2D meshes. -VTK stores such irregular networks as unstructured grids in *.vtu-files. +VTK stores such irregular networks as unstructured grids in `*.vtu`-files. ## Usage + ```bash -USAGE: +USAGE: TIN2VTK -o -i [--] [--version] [-h] -Where: +Where: -o , --output-vtu-file (required) the name of the file the mesh will be written to @@ -32,8 +34,8 @@ Where: Displays usage information and exits. ``` -## Example: +## Example ```bash TIN2VTK -i input.tin -o output.vtu -``` \ No newline at end of file +``` diff --git a/web/content/docs/tools/fileio/VTK2TIN/index.md b/web/content/docs/tools/fileio/VTK2TIN/index.md index 8f3c657f0bc..e12739c10f3 100644 --- a/web/content/docs/tools/fileio/VTK2TIN/index.md +++ b/web/content/docs/tools/fileio/VTK2TIN/index.md @@ -5,16 +5,19 @@ author = "Julian Heinze" +++ ## Description -This tool converts VTK unstructured grids (*.vtu) into TIN-format usable in geographic information systems (GIS). -The TIN-format stores triangular irregular networks which can be considered a subclass of triangulated 2D meshes. -The vtu-format can store a large variety of unstructured mesh types, but only 2D triangle meshes can be converted using this tool. + +This tool converts VTK unstructured grids (`*.vtu`) into TIN-format usable in geographic information systems (GIS). +The TIN-format stores triangular irregular networks which can be considered a subclass of triangulated 2D meshes. +The VTU-format can store a large variety of unstructured mesh types, but only 2D triangle meshes can be converted using this tool. + ## Usage + ```bash -USAGE: +USAGE: TIN2VTK -o -i [--] [--version] [-h] -Where: +Where: -o , --output-vtu-file (required) the name of the file the mesh will be written to @@ -31,8 +34,8 @@ Where: Displays usage information and exits. ``` -## Example: +## Example ```bash VTK2TIN -i input.vtu -o output.tin -``` \ No newline at end of file +``` diff --git a/web/content/docs/tools/geometries/generateGeometry/index.md b/web/content/docs/tools/geometries/generateGeometry/index.md index 7a509c9407f..63e4a2102f3 100644 --- a/web/content/docs/tools/geometries/generateGeometry/index.md +++ b/web/content/docs/tools/geometries/generateGeometry/index.md @@ -6,28 +6,31 @@ weight = 1 +++ ## Description -This tool is used to generate either a quad/rectangle or a line. + +This tool is used to generate either a quad/rectangle or a line. For this purpose, two points are used to define the geometry. -To create a quad, the defining points need to be in a plane parallel to the xy-, xz- or yz-plane. -To create a line, they must define a line parallel to the standard basis vectors of 3D space. +To create a quad, the defining points need to be in a plane parallel to the XY-, YZ- or YZ-plane. +To create a line, they must define a line parallel to the standard basis vectors of 3D space. Quads and lines then can be combined to create more complex geometries. -This tool is mainly used to create simple geometries for benchmarking or testing purposes. +This tool is mainly used to create simple geometries for benchmarking or testing purposes. + ## Usage + ```bash -USAGE: - generateGeometry -o +USAGE: + generateGeometry -o [--polyline_name ] - [--geometry_name ] - [--nz1 ] - [--nz ] - [--ny1 ] - [--ny ] - [--nx1 ] - [--nx ] - --x1 --y1 --z1 --x0 --y0 --z0 + [--geometry_name ] + [--nz1 ] + [--nz ] + [--ny1 ] + [--ny ] + [--nx1 ] + [--nx ] + --x1 --y1 --z1 --x0 --y0 --z0 [--] [--version] [-h] -Where: +Where: -o , --output (required) output geometry file (*.gml) @@ -83,21 +86,26 @@ Where: -h, --help Displays usage information and exits. ``` -Subdivisions can be made along all 4 edges of a quad. -The input is a number that defines the amount of equidistant points that are created on the corresponding edge/line. + +Subdivisions can be made along all 4 edges of a quad. +The input is a number that defines the amount of equidistant points that are created on the corresponding edge/line. When a mesh is generated using this geometry, these points are also integrated into the mesh. -Generating subdivisions along a line is done by --nx,--ny,--nz, depending on the axis the line is parallel to. +Generating subdivisions along a line is done by `--nx`, `--ny` or `--nz` depending on the axis the line is parallel to. + +## Example + +In this example we generate a line by defining two points p0 = (-4,-2,3) and p1= (15,-2,3). +Here, a line is generated because y0 = y1 = -2 and z0 = z1 = 3 for the two points. +This means the defined points are in a line parallel to the x-axis. -## Example: -In this example we generate a line by defining two points p0 = (-4,-2,3) and p1= (15,-2,3). -Here, a line is generated because y0 = y1 = -2 and z0 = z1 = 3 for the two points. -This means the defined points are in a line parallel to the x-axis. ```bash generateGeometry -o line.gml --x0 -4 --x1 15 --y0 -2 --y1 -2 --z0 3 --z1 3 ``` + In this example we generate a quad by defining two points p0 = (1,2,3) and p1= (10,20,3). Here, a plane is generated because z0 = z1 = 3 for the two points. This means the defined points are in a plane parallel to x-y-plane. + ```bash generateGeometry -o quad.gml --x0 1 --x1 10 --y0 2 --y1 20 --z0 3 --z1 3 ``` @@ -108,4 +116,3 @@ This means the defined points are in a plane parallel to x-y-plane.

Fig.1 Visualization of the generated quad and the line viewed along the z-axis.

- diff --git a/web/content/docs/tools/getting-started/first_steps/index.md b/web/content/docs/tools/getting-started/first_steps/index.md index f59ea407400..978a4b63fb9 100644 --- a/web/content/docs/tools/getting-started/first_steps/index.md +++ b/web/content/docs/tools/getting-started/first_steps/index.md @@ -11,7 +11,7 @@ This section describes a possible general pre-processing workflow using some of To set up a model domain, the project file `*.prj` requires additional files for the mesh and geometry to apply the boundary conditions accordingly. -The bulk mesh must be provided in VTK's `*.vtu` format, whereas the boundary and source term domains can be provided either in OGS' internal geometry file format (filename extension: `*.gml`, not to be confused with the Geography Markup Language) or as a `*.vtu` file as well, containing a subdomain of the bulk mesh. Multiple `*.vtu` files can be provided in the project file using the `` tag. We recommend the usage of the first method for simple 2D meshes with constant boundary conditions, whereas more complicated geometries and conditions might require the latter method. One general advantage in the utilization of `*.vtu` files is that they allow a definition of additional field variables at each mesh node/element in order to implement spatially varying boundary conditions in a similar manner as, e.g., defining inhomogeneous material properties in the bulk mesh. +The bulk mesh must be provided in VTKs `*.vtu` format, whereas the boundary and source term domains can be provided either in OGS' internal geometry file format (filename extension: `*.gml`, not to be confused with the Geography Markup Language) or as a `*.vtu` file as well, containing a subdomain of the bulk mesh. Multiple `*.vtu` files can be provided in the project file using the `` tag. We recommend the usage of the first method for simple 2D meshes with constant boundary conditions, whereas more complicated geometries and conditions might require the latter method. One general advantage in the utilization of `*.vtu` files is that they allow a definition of additional field variables at each mesh node/element in order to implement spatially varying boundary conditions in a similar manner as, e.g., defining inhomogeneous material properties in the bulk mesh. The finite-element mesh must be created using external mesh generators. Simple meshes can be created using the OGS utility [generateStructuredMesh]({{< ref "structured-mesh-generation" >}}) or [PyVista](https://docs.pyvista.org). More complicated geometries can be generated and meshed using, e.g., [SALOME Platform](https://www.salome-platform.org) or [Gmsh](http://gmsh.info). diff --git a/web/content/docs/tools/meshing/Layers2Grid/index.md b/web/content/docs/tools/meshing/Layers2Grid/index.md index 1b031e6f39b..949a0f99929 100644 --- a/web/content/docs/tools/meshing/Layers2Grid/index.md +++ b/web/content/docs/tools/meshing/Layers2Grid/index.md @@ -5,21 +5,22 @@ author = "Julian Heinze" +++ ## Description -Reads a list of 2D unstructured mesh layers and samples them onto a structured grid of the same extent. -The resulting mesh is referred to as voxelgrid. -Voxel sizes are defines by x/y/z-parameters. + +Reads a list of 2D unstructured mesh layers and samples them onto a structured grid of the same extent. +The resulting mesh is referred to as voxel grid. +Voxel sizes are defines by x/y/z-parameters. Note that a large cube size may result in an undersampling of the original structure. For equilateral cubes, only the x-parameter needs to be set. - ## Usage + ```bash -Layers2Grid -i -o -x +Layers2Grid -i -o -x [-y ] [-z ] [-d] [--] [--version] [-h] -Where: +Where: -i , --input (required) name of the input file list containing the paths the all @@ -52,15 +53,19 @@ Where: Displays usage information and exits. ``` -## Example: -In this example we will present how to create a voxel grid (output) from a list of layers in VTK-format (input). +## Example + +In this example we will present how to create a voxel grid (output) from a list of layers in VTK-format (input). + ```bash Layers2Grid -i layers.txt -o layers2grid.vtu -x 100 -y 200 -z 50 ``` + The list must contain the paths of the input layers as well as their names. -The voxelgrid is build in the same order as the names are listed from top to bottom. +The voxel grid is build in the same order as the names are listed from top to bottom. Example list of 10 layers: + ```bash path/to/layers/00_layer.vtu path/to/layers/01_layer.vtu @@ -79,6 +84,5 @@ path/to/layers/10_layer.vtu

-Fig.1 Voxelgrid composed of elements of size x=100, y=200 and z=50. +Fig.1 The voxel grid composed of elements of size x=100, y=200 and z=50.

- diff --git a/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.md b/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.md index 3020e562478..94b6b16978b 100644 --- a/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.md +++ b/web/content/docs/tools/model-preparation/compute-node-areas-from-surface-mesh/index.md @@ -16,7 +16,7 @@ ComputeNodeAreasFromSurfaceMesh -i [--id-prop-name ] ``` -If the option `-p` is not given the output path is extracted from the input path. The default value for the `--id-prop-name` argument is "bulk_node_ids". This name is also used by [ExtractSurface]({{< ref "extract-surface" >}}) for storing the subsurface node ids. +If the option `-p` is not given the output path is extracted from the input path. The default value for the `--id-prop-name` argument is `bulk_node_ids`. This name is also used by [ExtractSurface]({{< ref "extract-surface" >}}) for storing the subsurface node ids. ## Example @@ -27,7 +27,7 @@ The following steps were performed to obtain the example data: 1. The hexahedral example domain was created by [generateStructuredMesh]({{< ref "structured-mesh-generation">}}) `generateStructuredMesh -o hex_6x7x3.vtu -e hex --lx 6 --ly 7 --lz 3`. 2. The tool [ExtractSurface]({{< ref "extract-surface" >}}) was applied: `ExtractSurface -i hex_6x7x3.vtu -o hex_6x7x3_surface.vtu` - The generated surface mesh contains a property "bulk_node_ids" assigned to the mesh nodes that contains the original subsurface mesh node ids. + The generated surface mesh contains a property `bulk_node_ids` 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. ![Result data](ExampleComputeSurfaceNodeAreasFromSurfaceMesh-Result.png) diff --git a/web/content/docs/tools/preprocessing/AddFaultToVoxelGrid/index.md b/web/content/docs/tools/preprocessing/AddFaultToVoxelGrid/index.md index ca1f64759b2..914b39d9fa9 100644 --- a/web/content/docs/tools/preprocessing/AddFaultToVoxelGrid/index.md +++ b/web/content/docs/tools/preprocessing/AddFaultToVoxelGrid/index.md @@ -1,12 +1,12 @@ +++ -date = "" +date = "2023-02-23" title = "AddFaultToVoxelGrid" author = "Julian Heinze" +++ ## Description -This tool marks all elements in a voxel-grid (i.e. a structured hex grid, for instance created with [Layers2Grid]({{< ref "Layers2Grid.md" >}}) or [Vtu2Grid]({{< ref "vtu2grid.md" >}})) that are intersected by a triangulated 2D mesh representing a fault or some other significant structure. +This tool marks all elements in a voxel grid (i.e. a structured hex grid, for instance created with [Layers2Grid]({{< ref "Layers2Grid.md" >}}) or [Vtu2Grid]({{< ref "vtu2grid.md" >}})) that are intersected by a triangulated 2D mesh representing a fault or some other significant structure. The material group for those intersected elements can be explicitly specified. Otherwise the largest existing MaterialID will be increased by one and defined as MaterialID for those elements. @@ -52,5 +52,5 @@ AddFaultToVoxelGrid -i grid.vtu -f fault.vtu -o grid_fault.vtu

-Fig.1 The left figure shows the input grid with the intersecting triangulated 2D mesh, which is highlighted in red. The center and right figure show the output voxelgrid. +Fig. 1 The left figure shows the input grid with the intersecting triangulated 2D mesh, which is highlighted in red. The center and right figure show the output voxel grid.

diff --git a/web/content/docs/tools/preprocessing/MeshMapping/index.md b/web/content/docs/tools/preprocessing/MeshMapping/index.md index 606548a95bd..0180f4f0c67 100644 --- a/web/content/docs/tools/preprocessing/MeshMapping/index.md +++ b/web/content/docs/tools/preprocessing/MeshMapping/index.md @@ -1,19 +1,21 @@ +++ -date = "" +date = "2023-14-02" title = "MeshMapping" author = "Julian Heinze" +++ ## Description -MeshMapping is a tool to change the elevation of the nodes of a 2D mesh according to a raster file (*.asc, *.grd, *.xyz) or another 2D mesh. + +MeshMapping is a tool to change the elevation of the nodes of a 2D mesh according to a raster file (`*.asc`, `*.grd`, `*.xyz`) or another 2D mesh. The x-y coordinates remain unchanged, while the z-coordinates of the input mesh are adjusted according to the raster used for mapping. ## Usage + ```bash - MeshMapping -i -o [-r ] [-m ] + MeshMapping -i -o [-r ] [-m ] [-d ] [-s ] [--lowpass] [--] [--version] [-h] -Where: +Where: (required) Input mesh file (*.vtu, *.msh) -o , --output @@ -48,25 +50,27 @@ Where: Displays usage information and exits. ``` -## Example: -Mapping the input mesh to a digital elevation model (DEM). +## Example + +Mapping the input mesh to a digital elevation model (DEM).

-Fig.1 Both images show the INPUT mesh from two different point of views. The upper image shows the view along the z-axis. The lower image shows the view along the x-axis. +Fig. 1 Both images show the INPUT mesh from two different point of views. The upper image shows the view along the z-axis. The lower image shows the view along the x-axis.

```bash -MeshMapping -i Berlin.vtu -o Berlin_mapped.vtu -r DEM.asc +MeshMapping -i Berlin.vtu -o Berlin_mapped.vtu -r DEM.asc ``` -The command above maps the mesh 'Berlin.vtu' to the mesh 'Berlin_mapped.vtu' according to the elevation given in 'DEM.asc'. -Differences can be seen comparing Fig.1 and Fig.2, especially comparing the lower images. + +The command above maps the mesh `Berlin.vtu` to the mesh `Berlin_mapped.vtu` according to the elevation given in `DEM.asc`. +Differences can be seen comparing Fig.1 and Fig.2, especially comparing the lower images.

- +

-Fig.2 Both images show the OUTPUT mesh from two different point of views. The upper image shows it viewing along the z-axis. The right image shows it viewing along the x-axis. To increase the visibility of the elevation, z-values are scaled by factor of 10. +Fig. 2 Both images show the OUTPUT mesh from two different point of views. The upper image shows it viewing along the z-axis. The right image shows it viewing along the x-axis. To increase the visibility of the elevation, z-values are scaled by factor of 10.

diff --git a/web/content/docs/tools/preprocessing/NodeReordering/index.md b/web/content/docs/tools/preprocessing/NodeReordering/index.md index e074ec2b84e..2fa7db690ad 100644 --- a/web/content/docs/tools/preprocessing/NodeReordering/index.md +++ b/web/content/docs/tools/preprocessing/NodeReordering/index.md @@ -1,28 +1,29 @@ +++ -date = "" +date = "2023-02-23" title = "NodeReordering" author = "Julian Heinze" +++ ## Description + This tool is to reorder nodes of a given mesh. Mostly it is applied to reorder the nodes of a mesh from an older OGS version to have a mesh compatible with the current OGS version. There are four different methods available, which define the reordering process: - Method 0: Reversing order of nodes for all elements. -- Method 1: Reversing order of nodes unless it's perceived correct by OGS6 standards. +- Method 1: Reversing order of nodes unless it's perceived correct by OGS-6 standards. This is the default selection. -- Method 2: Fixing node ordering issues between VTK and OGS6 (only applies to prism-elements). +- Method 2: Fixing node ordering issues between VTK and OGS-6 (only applies to prism-elements). - Method 3: Re-ordering of mesh node vector such that all base nodes are sorted before all nonlinear.nodes. - ## Usage + ```bash -USAGE: +USAGE: NodeReordering -i -o [-m <0|1|2|3>] [--] [--version] [-h] -Where: +Where: -i , --input_mesh (required) the name of the input mesh file @@ -42,8 +43,10 @@ Where: Displays usage information and exits. ``` -## Example: +## Example + The following command is used to reorder a mesh according to the second method. + ```bash NodeReordering -i input.vtu -o output.vtu -m 2 -``` \ No newline at end of file +``` diff --git a/web/content/docs/tools/preprocessing/createLayeredMeshFromRasters/index.md b/web/content/docs/tools/preprocessing/createLayeredMeshFromRasters/index.md index a22c39136f5..9882a46b614 100644 --- a/web/content/docs/tools/preprocessing/createLayeredMeshFromRasters/index.md +++ b/web/content/docs/tools/preprocessing/createLayeredMeshFromRasters/index.md @@ -5,21 +5,24 @@ author = "Julian Heinze" +++ ## Description -createLayeredMeshFromRasters is a tool for creating a 3D mesh from a 2D mesh by adding layers to the 2D mesh. -The layers are created from the x-y coordinates of the mesh combined with the z-coordinates from raster files (*.asc, *.grd, *.xyz). -The tool builds the 3D mesh starting with the bottom layer. + +createLayeredMeshFromRasters is a tool for creating a 3D mesh from a 2D mesh by adding layers to the 2D mesh. +The layers are created from the x-y coordinates of the mesh combined with the z-coordinates from raster files (`*.asc`, `*.grd`, `*.xyz`). +The tool builds the 3D mesh starting with the bottom layer. The bottom layer must cover the complete domain, i.e. it needs to have as many nodes as the 2D input mesh. If not an error will occur as there is no information on the lower boundary of the mesh. Currently, only inputs from line and triangle elements are supported, since mapping quads can result in invalid mesh elements. -The different layers have to be listed in an extra .txt-file, where the top to bottom arrangement is given by the order of the raster files in the .txt-file. +The different layers have to be listed in an extra `.txt`-file, where the top to bottom arrangement is given by the order of the raster files in the `.txt`-file. + ## Usage + ```bash - createLayeredMeshFromRasters -i -o -r - [-t ] [--ascii_output] + createLayeredMeshFromRasters -i -o -r + [-t ] [--ascii_output] [--] [--version] [-h] -Where: +Where: -i , --input-mesh-file (required) The file name of the 2D input mesh. @@ -48,7 +51,7 @@ Where: Displays usage information and exits. ``` -## Example: +## Example

@@ -62,7 +65,7 @@ Create layers below a given 2D mesh according to a list of raster files. createLayeredMeshFromRasters -i mesh_mapped.vtu -o mesh_layered.vtu -r list_raster_mesh.txt ``` -The .txt file that contains the list of raster files, in this example it is called "list_raster_mesh.txt", is specified as follows: +The `.txt`-file that contains the list of raster files, in this example it is called `list_raster_mesh.txt`, is specified as follows: ```bash path/to/raster-file/DEM.asc @@ -79,5 +82,5 @@ path/to/raster-file/m6.asc

-Fig.2 The layered 3D output mesh created from raster files. The different colors depict different material IDs. The z-values of the mesh are scaled by a factor of 10. -

\ No newline at end of file +Fig.2 The layered 3D output mesh created from raster files. The different colors depict different material IDs. The z-values of the mesh are scaled by a factor of 10. +

diff --git a/web/content/docs/tools/preprocessing/createQuadraticMesh/index.md b/web/content/docs/tools/preprocessing/createQuadraticMesh/index.md index c3bd8a4cb9e..f04e2806ef4 100644 --- a/web/content/docs/tools/preprocessing/createQuadraticMesh/index.md +++ b/web/content/docs/tools/preprocessing/createQuadraticMesh/index.md @@ -5,19 +5,21 @@ author = "Julian Heinze" +++ ## Description + This tool converts a linear mesh to a mesh of quadratic order. The order of a mesh is equal to the highest order of elements within the mesh. The quadratic order mesh allows shape functions of quadratic order to be considered in the finite element methods of the simulation. -More detailed information about the differences between a linear and quadratic mesh elements can be found in the [VTK book by kitware](https://kitware.github.io/vtk-examples/site/VTKBook/05Chapter5/). +More detailed information about the differences between a linear and quadratic mesh elements can be found in the [VTK book by Kitware](https://kitware.github.io/vtk-examples/site/VTKBook/05Chapter5/). ## Usage + ```bash -USAGE: +USAGE: createQuadraticMesh [-c] -o -i [--] [--version] [-h] -Where: +Where: -c, --add-centre-node add centre node @@ -37,8 +39,8 @@ Where: Displays usage information and exits. ``` -## Example: +## Example ```bash createQuadraticMesh -i input_mesh.vtu -o quadratic_mesh.vtu -``` \ No newline at end of file +``` diff --git a/web/content/docs/tools/preprocessing/createTetgenSmeshFromRasters/index.md b/web/content/docs/tools/preprocessing/createTetgenSmeshFromRasters/index.md index fd683d20e16..25c8805a25f 100644 --- a/web/content/docs/tools/preprocessing/createTetgenSmeshFromRasters/index.md +++ b/web/content/docs/tools/preprocessing/createTetgenSmeshFromRasters/index.md @@ -1,5 +1,5 @@ +++ -date = "" +date = "2023-06-22" title = "createTetgenSmeshFromRasters" author = "Julian Heinze" +++ @@ -11,7 +11,7 @@ The 2D input file is intended to define the upper surface of the resulting `*.sm The resulting `*.smesh` file is a *piecewise linear complex* (PLC) that describes a boundary representation for a layered 3D mesh. This PLC serves as input to TetGen's *Tetrahedral Mesh Generator* to create a 3D mesh. A more detailed explanation of the use and functionality of TetGen can be found in the manual. -Supported raster formats are ArcGIS ascii raster (`*.asc`), Surfer grids (`*.grd`), and XYZ raster files (`*.xyz`). +Supported raster formats are ArcGIS ASCII raster (`*.asc`), Surfer grids (`*.grd`), and XYZ raster files (`*.xyz`). Still, the list of raster files can be given in any text file format. ### Known limitations @@ -79,4 +79,4 @@ It could be called like: tetgen -pkA mesh_layered.smesh ``` -The **p** takes care of the tetrahedralization, **k** takes care of the generation of a vtk output, and **A** writes cell properties for regions to the output mesh. +The **p** takes care of the tetrahedralization, **k** takes care of the generation of a VTK output, and **A** writes cell properties for regions to the output mesh. diff --git a/web/content/docs/userguide/basics/conventions/index.md b/web/content/docs/userguide/basics/conventions/index.md index 50945202d52..c4f5e5ce625 100644 --- a/web/content/docs/userguide/basics/conventions/index.md +++ b/web/content/docs/userguide/basics/conventions/index.md @@ -28,7 +28,7 @@ respectively. Here, $Q$ in our formulation is an already integrated flux. Meaning it is typically a different quantity than the primary unknown of the `process` under consideration. It may be e.g. a secondary variable being a function of the primary unknown. This is for instance the case, if we consider prescribed fluxes of water in a porous medium on a Neumann boundary. Here, $Q$ would -be a prescribed Dary velocity integrated over some area being a function of the pressure gradient. +be a prescribed Darcy velocity integrated over some area being a function of the pressure gradient. For energy balances in OpenGeoSys the primary unknown is usually the temperature $T$, while corresponding fluxes $Q$ are usually expressed in terms of energy. @@ -165,23 +165,29 @@ For hydro-mechanical processes the fixed-stress split has been implemented, sinc For the sake of brevity, we do not describe the scheme itself, but intend to provide guidance for its stabilization parameter. On this parameter depends how many coupling iterations are needed and thus how long it takes to obtain a solution. The optimal value of this parameter is not a-priori known, only that it lies within a certain interval is known (see [[2]](#2)): -\begin{equation} + +$$ \frac{1}{2}\frac{\alpha^2}{K_\mathrm{1D}} \le \beta_\mathrm{FS} \le \frac{\alpha^2}{K_\mathrm{ph}}, -\end{equation} +$$ + where $\alpha$ denotes Biot's coefficient, and $K_\mathrm{1D}$ and $K_\mathrm{ph}$ are the bulk moduli described next. By $K_\mathrm{ph}$ we mean the bulk modulus adjusted to the spatial dimension, so in three dimensions it coincides with the drained bulk modulus, whereas in lower dimensions it becomes a constrained bulk modulus (2D plane strain, 1D uniaxial strain). Assuming isotropic, linear elasticity we have -\begin{eqnarray} + +$$\begin{eqnarray} K_\mathrm{3D} &=& \lambda + \frac{2}{3}\mu, \\ K_\mathrm{2D} &=& \lambda + \frac{2}{2}\mu, \\ K_\mathrm{1D} &=& \lambda + \frac{2}{1}\mu. \\ -\end{eqnarray} +\end{eqnarray}$$ + OGS sets the stabilization parameter, which corresponds to a coupling compressibility, via an optional tag `fixed_stress_stabilization_parameter` inside the tag `coupling_scheme`. -\begin{equation} + +$$ \beta_\mathrm{FS} = p_\mathrm{FS} \frac{\alpha^2}{K_\mathrm{3D}}, -\end{equation} +$$ + by default to $p_\mathrm{FS}=\frac{1}{2}$. For isotropic, linear elasticity we provide the interval [[2]](#2) and the recommended value [[3]](#3) in dependence on Poisson's ratio $\nu$ (note $\frac{\lambda}{\mu}=\frac{2\nu}{1-2\nu}$). diff --git a/web/content/docs/userguide/basics/jupyter-notebooks/index.md b/web/content/docs/userguide/basics/jupyter-notebooks/index.md index 3014872971c..283fdffeddb 100644 --- a/web/content/docs/userguide/basics/jupyter-notebooks/index.md +++ b/web/content/docs/userguide/basics/jupyter-notebooks/index.md @@ -23,7 +23,7 @@ Image `registry.opengeosys.org/ogs/ogs/ogs-serial-jupyter` contains: - The latest OpenGeoSys application with MFront-support and tools - A set of Python packages: - [ogs6py](https://github.com/joergbuchwald/ogs6py) — OGS model manipulation - - [VTUInterface](https://github.com/joergbuchwald/VTUinterface) — VTU / PVD IO + - [VTUinterface](https://github.com/joergbuchwald/VTUinterface) — VTU / PVD IO - [ogstools](https://pypi.org/project/ogstools/) — OGS-related helper scripts, e.g. `msh2vtu`: Gmsh to VTU conversion - [h5py](https://docs.h5py.org/en/latest/index.html) — HDF5 IO - [MFront python bindings](http://tfel.sourceforge.net/mfront-python.html) – Material model manipulation diff --git a/web/content/docs/userguide/basics/project_file_intro.md b/web/content/docs/userguide/basics/project_file_intro.md index ab5eb26af99..76626f980d5 100644 --- a/web/content/docs/userguide/basics/project_file_intro.md +++ b/web/content/docs/userguide/basics/project_file_intro.md @@ -8,7 +8,7 @@ weight = 3 The main input taken by OpenGeoSys is a path to a 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 +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 is intact, the main blocks can be @@ -18,14 +18,14 @@ Depending on the scope of the simulation, the content of the project file will d
Please note, that this page is not a complete description of the XML standard. It only provides some information to interact -with and understand OpenGeoSys "*.prj" files. More meta-information on xml can be found here: XML Standard. +with and understand OpenGeoSys "*.prj" files. More meta-information on XML can be found here: XML Standard.
The XML files structure follows an abstract idea of a tree: i.e., here one starts from the roots and continues up to the leaves. As such the main tag within an XML file is called root. In OpenGeoSys project files the root tag looks like this: `< 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 a process used in the simulation. The following xml-snippet shows a +the simulation. They define for example mesh files, or a process used in the simulation. The following XML-snippet shows a small structure containing the two elementary blocks, which are empty for now: ```xml @@ -72,7 +72,7 @@ If a value is set between `<` and `>`, beside the tag, it is called attribute. F ``` -The entity "planet" has the attribute "satellite_name", which is set to "Moon". +The entity `planet` has the attribute `satellite_name`, which is 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": diff --git a/web/content/docs/userguide/basics/working_with_project_files.md b/web/content/docs/userguide/basics/working_with_project_files.md index 1b1bef1b9df..ea5c7450410 100644 --- a/web/content/docs/userguide/basics/working_with_project_files.md +++ b/web/content/docs/userguide/basics/working_with_project_files.md @@ -21,7 +21,7 @@ It was published in this state to make existing content available to users and h ## 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). +page or GitLab). ## Creating a new project file diff --git a/web/content/docs/userguide/blocks/linear_solvers.md b/web/content/docs/userguide/blocks/linear_solvers.md index 9272a9a016b..637de4fda69 100644 --- a/web/content/docs/userguide/blocks/linear_solvers.md +++ b/web/content/docs/userguide/blocks/linear_solvers.md @@ -20,12 +20,12 @@ It was published in this state to make existing content available to users and h
An important parameter defined for each iterative linear solver is the "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. +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 tightly will result in an error message referring to problems, implying that a smaller time step needs to be set up. If the settings are too loose, results may be erroneous. As the variables are interconnected, it is possible to avoid error when one of the tolerances is set too low, by setting the other one a bit too high. -Generally, the error tolerance of a linear solver should always be tighter than "abstols". -Unlike "abstol", "error tolerance" is not specific to "process variables" and is defined as one value. +Generally, the error tolerance of a 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. diff --git a/web/content/docs/userguide/blocks/media.md b/web/content/docs/userguide/blocks/media.md index dec99f2266b..9231296f584 100644 --- a/web/content/docs/userguide/blocks/media.md +++ b/web/content/docs/userguide/blocks/media.md @@ -112,7 +112,7 @@ They can be used by the user to define the properties in a way, that is specific 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 most safe to use the "Constant" type for properties, if properties are not transient. If this is not +Generally, it is most safe to use the `Constant` type for properties, if properties are not transient. If this is not sufficient, the type "Parameter" can be used. Still, there are some limitations to what types of parameter can be used in different processes. @@ -121,32 +121,32 @@ In opposite to the parameters in the `parameter` block, in the `media` block par The types linear, function, and curve can depend on a set of variables 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. +- `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`. diff --git a/web/content/docs/userguide/blocks/processes.md b/web/content/docs/userguide/blocks/processes.md index 10928872ed5..1023697987e 100644 --- a/web/content/docs/userguide/blocks/processes.md +++ b/web/content/docs/userguide/blocks/processes.md @@ -90,7 +90,7 @@ For the process variables listed above, relative error tolerances can be defined The order can differ based on the order in which the processes are defined 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 value like displacement in the example above. -In such a case, a matching number of reltols has to be defined. +In such a case, a matching number of `reltols` has to be defined. @@ -100,13 +100,13 @@ Constitutive relation can be one of the [existing relations](/docs/userguide/blo 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 +* Hydro-Mechanics +* Phase-Field +* Richards-Mechanics * Small Deformation -* Thermo Mechanics -* Thermo Hydro Mechanics -* Thermo Richards Mechanics +* Thermo-Mechanics +* Thermo-Hydro-Mechanics +* Thermo-Richards-Mechanics * TH2M To define constitutive relation, tags ` ` are used. diff --git a/web/content/docs/userguide/blocks/time_loop.md b/web/content/docs/userguide/blocks/time_loop.md index eedf22d8f59..4942e63c9cc 100644 --- a/web/content/docs/userguide/blocks/time_loop.md +++ b/web/content/docs/userguide/blocks/time_loop.md @@ -48,7 +48,7 @@ In OpenGeoSys the following time step definitions are available: #### Single time step -This is the simplest type of time steppings used for solution of elliptic pdes as in the `SteadyStateDiffusion` process. +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 and is used for stead-state problems: ```xml @@ -87,8 +87,8 @@ being $0.05$ time unit long. 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. +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 the SI system, second is the common choice as time unit. @@ -141,7 +141,7 @@ especially for the solution of non-linear problems. ### Error tolerances Error tolerances will be applied to the solution vector -There are two two ways of defining error tolerances: +There are two ways of defining error tolerances: - relative ` ` - absolute ` ` @@ -180,7 +180,7 @@ In this part the selection of a convergence criterion is described. The followin - [Residual and PerComponentResidual](/docs/userguide/blocks/time_loop/#residual-and-percomponentresidual) All of the criteria mentioned above compare a value quantifying the error (a residual or a discrete change in time) with a -userdefined tolerance. +user-defined tolerance. There are three way how error tolerances can be set up: @@ -297,7 +297,7 @@ In order to do so, block ```xml ```has to be placed in ` It can contain arbitrary number of blocks ```xml ```, which define a cyclical pattern each. The block `````` has to contain two tags: `````` and ``````. `````` defines how many outputs with spacing of `````` time steps should be written. -In a sequence of blocks the starting timestep for a pair is the last timestep from the previous one. +In a sequence of blocks the starting time step for a pair is the last time step from the previous one. Following example illustrates this: ```xml @@ -321,14 +321,14 @@ Using this block in the project file will result in the output being written at The first file would be written as a result of the fist ``````. It will write output once (as the tag `````` has value of 1) after 10 time steps (10 is the value provided in the tag ``````). The second pair will write an output file after 90 time steps. -However, the counting starts not at timestep 0, but at the last timestep resulting from the previous pair. -In this cas this is timestep 10, hence second pair will write an output at 100 (10 time steps from first pair plus 90 time steps from second pair). +However, the counting starts not at time step 0, but at the last time step resulting from the previous pair. +In this case this is time step 10, hence second pair will write an output at 100 (10 time steps from first pair plus 90 time steps from second pair). The same applies to the third pair. It will write an output at 1000 as 1000 is the result of addition of 10, 90, and 900 from first, second and third steps respectively. Note, that specifically in this case the values in `````` tag can be summed directly, as each pair is repeated only once. Now, consider a more complicated pattern. -Let's assume, that the output has to be written at every timestep for the range 1-10 time steps, every tenth in the range 10-100 time steps and every hundredth for the range 100-1000. +Let's assume, that the output has to be written at every time step for the range 1-10 time steps, every tenth in the range 10-100 time steps and every hundredth for the range 100-1000. Block defining this pattern would be written as follows: ```xml @@ -349,10 +349,10 @@ Block defining this pattern would be written as follows: ``` This will result in output being written at time steps: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 200, 300, 400, 500, 600, 700, 800, 900 and 1000. -Note, that since output at 10th timestep is the last one resulting from first pair, it will be the starting point for the second pair, therefore the second pair needs to be repeated only 9 times. -Otherwise the last output from the second pair would be written at timestep 110. +Note, that since output at 10th time step is the last one resulting from first pair, it will be the starting point for the second pair, therefore the second pair needs to be repeated only 9 times. +Otherwise the last output from the second pair would be written at time step 110. The same principle applies to the third pair. -Output at timestep 100 is written by the second pair, therefore to get to 1000, third pair only needs to be repeated 9 times. +Output at time step 100 is written by the second pair, therefore to get to 1000, third pair only needs to be repeated 9 times. Regardless of the user defined output time steps, OpenGeoSys will write the output files at $t=0$ and $t=t_{end}$. @@ -363,10 +363,10 @@ They should contain text strings. Variables can be used to allow those strings to vary between files. The following variables can be called: -- meshname -- timestep -- time -- iteration +- `meshname` +- `timestep` +- `time` +- `iteration` They can be used in the file name with the syntax illustrated by the following example: diff --git a/web/content/docs/userguide/features/mfront.md b/web/content/docs/userguide/features/mfront.md index 343cf0de035..42cacc05a3d 100644 --- a/web/content/docs/userguide/features/mfront.md +++ b/web/content/docs/userguide/features/mfront.md @@ -85,7 +85,7 @@ mfront_behaviours_check_library( ) ``` -To make the new "ModelName" available rerun CMake's "configure" and "generate" steps, and recompile OpenGeoSys. +To make the new "ModelName" available rerun the "configure" and "generate" CMake-steps, and recompile OpenGeoSys. (This process should take less time than the first time, as only new code will be compiled.)
diff --git a/web/content/docs/userguide/features/python_bc.md b/web/content/docs/userguide/features/python_bc.md index 44335f73dec..86b1ff598df 100644 --- a/web/content/docs/userguide/features/python_bc.md +++ b/web/content/docs/userguide/features/python_bc.md @@ -73,10 +73,10 @@ OpenGeoSys will obtain values for a Dirichlet boundary condition by calling the The following variables are always passed as an input to the Dirichlet boundary condition method (in brackets the default variable name used in examples) is given: -- time (t), -- spatial coordinates (coords), -- node id (node_id), -- primary variables (primary_vars). +- time (`t`), +- spatial coordinates (`coords`), +- node id (`node_id`), +- primary variables (`primary_vars`). #### Output @@ -91,15 +91,15 @@ The order in which those variables are provided is important. ### Neumann boundary condition -OpenGeoSys will obtain values for a Neumann boundary condition by calling the method "getFlux". +OpenGeoSys will obtain values for a Neumann boundary condition by calling the method `getFlux`. #### Input The following variables are always passed as an input to the Dirichlet boundary condition method (in brackets the default variable name used in examples is given): -- time (t), -- spatial coordinates (coords), -- primary variables (primary_vars). +- time (`t`), +- spatial coordinates (`coords`), +- primary variables (`primary_vars`). The order in which those variables are provided is important. diff --git a/web/content/docs/userguide/troubleshooting/faq.md b/web/content/docs/userguide/troubleshooting/faq.md index b8d81aab9f3..1a170552c1b 100644 --- a/web/content/docs/userguide/troubleshooting/faq.md +++ b/web/content/docs/userguide/troubleshooting/faq.md @@ -5,7 +5,7 @@ author = "Lars Bilke and Feliks Kiszkurno" weight = 1 +++ -## "XSDError: Loaded schema file is invalid" error encountered when running DataExplorer +## `XSDError: Loaded schema file is invalid` error encountered when running DataExplorer You may encounter the following error (or similar) on opening `.gml`, `.cnd`, `std` or `.prj` files in the Data Explorer or file conversion tools (e.g., `OGSFileConverter`): diff --git a/web/content/docs/userguide/troubleshooting/general/index.md b/web/content/docs/userguide/troubleshooting/general/index.md index 58ff5fe1a8f..3bb491d71bf 100644 --- a/web/content/docs/userguide/troubleshooting/general/index.md +++ b/web/content/docs/userguide/troubleshooting/general/index.md @@ -10,7 +10,7 @@ toc = true ## Data Explorer -### XSDError: Loaded schema file is invalid +### `XSDError`: Loaded schema file is invalid 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`):
Material properties