OilfieldToolsNet/opm-simulators
4
0
Fork 0
mirror of https://github.com/OPM/opm-simulators.git synced 2025-02-25 18:55:30 -06:00
Code Issues Packages Projects Releases Wiki Activity

handbook: cleanups, update the tutorial for the fully implicit models

Browse Source 
- there are no LaTeX files with capital letters anymore
- there are no more "dangling" references
This commit is contained in:
Andreas Lauser
2012-10-16 18:16:19 +02:00
parent 78edd159d7
commit 0c1a15c2de
16 changed files with 564 additions and 568 deletions
Download Patch File Download Diff File Expand all files Collapse all files

12
doc/handbook/ModelDescriptions/2p2cdecoupledpressuremodel.tex Normal file
View File

@@ -0,0 +1,12 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This file has been autogenerated from the LaTeX part of the %
% doxygen documentation; DO NOT EDIT IT! Change the model's .hh %
% file instead!! %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Provides a Finite Volume implementation for the pressure equation of a compressible system with two components. An I\-M\-P\-E\-S-\/like method is used for the sequential solution of the problem. Diffusion is neglected, capillarity can be regarded. Isothermal conditions and local thermodynamic equilibrium are assumed. Gravity is included. \[ c_{total}\frac{\partial p}{\partial t} + \sum_{\kappa} \frac{\partial v_{total}}{\partial C^{\kappa}} \nabla \cdot \left( \sum_{\alpha} X^{\kappa}_{\alpha} \varrho_{\alpha} \bf{v}_{\alpha}\right) = \sum_{\kappa} \frac{\partial v_{total}}{\partial C^{\kappa}} q^{\kappa}, \] where $\bf{v}_{\alpha} = - \lambda_{\alpha} \bf{K} \left(\nabla p_{\alpha} + \rho_{\alpha} \bf{g} \right) $. $ c_{total} $ represents the total compressibility, for constant porosity this yields $ - \frac{\partial V_{total}}{\partial p_{\alpha}} $, $p_{\alpha} $ denotes the phase pressure, $ \bf{K} $ the absolute permeability, $ \lambda_{\alpha} $ the phase mobility, $ \rho_{\alpha} $ the phase density and $ \bf{g} $ the gravity constant and $ C^{\kappa} $ the total \hyperlink{a00070}{Component} concentration. See paper S\-P\-E 99619 or \char`\"{}\-Analysis of a Compositional Model for Fluid
Flow in Porous Media\char`\"{} by Chen, Qin and Ewing for derivation.
The pressure base class \hyperlink{a00131}{F\-V\-Pressure} assembles the matrix and right-\/hand-\/side vector and solves for the pressure vector, whereas this class provides the actual entries for the matrix and R\-H\-S vector. The partial derivatives of the actual fluid volume $ v_{total} $ are gained by using a secant method.

9
doc/handbook/ModelDescriptions/2p2cdecoupledtransportmodel.tex Normal file
View File

@@ -0,0 +1,9 @@
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% This file has been autogenerated from the LaTeX part of the %
% doxygen documentation; DO NOT EDIT IT! Change the model's .hh %
% file instead!! %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The transport step is described by the finite volume model for the solution of the transport equation for compositional two-\/phase flow. \[ \frac{\partial C^\kappa}{\partial t} = - \nabla \cdot \left( \sum_{\alpha} X^{\kappa}_{\alpha} \varrho_{alpha} \bf{v}_{\alpha}\right) + q^{\kappa}, \] where $ \bf{v}_{\alpha} = - \lambda_{\alpha} \bf{K} \left(\nabla p_{\alpha} + \rho_{\alpha} \bf{g} \right) $. $ p_{\alpha} $ denotes the phase pressure, $ \bf{K} $ the absolute permeability, $ \lambda_{\alpha} $ the phase mobility, $ \rho_{\alpha} $ the phase density and $ \bf{g} $ the gravity constant and $ C^{\kappa} $ the total \hyperlink{a00070}{Component} concentration. The whole flux contribution for each cell is subdivided into a storage term, a flux term and a source term. Corresponding functions ({\ttfamily \hyperlink{a00145_a13998fc22be58456c4bf8e3f4b12d89c}{get\-Flux()}} and {\ttfamily \hyperlink{a00145_a40fc97d83d3d15cdd29574d3a38fdafb}{get\-Flux\-On\-Boundary()}}) are provided, internal sources are directly treated.

26
doc/handbook/ewoms-handbook.tex
View File

@@ -8,6 +8,10 @@
\usepackage{theorem}
\usepackage{color}
\usepackage{listings}
\definecolor{bashgray}{gray}{0.92}
\definecolor{cppgray}{gray}{0.95}
\lstset{language=C++, basicstyle=\ttfamily,
keywordstyle=\color{black}\bfseries, tabsize=4, stringstyle=\ttfamily,
commentstyle=\it, extendedchars=true, escapeinside={/*@}{@*/}}
@@ -15,14 +19,14 @@
% for listings of bash code in install.tex
\lstdefinestyle{Bash}
{language=Bash,
backgroundcolor=\color{lightgray},
backgroundcolor=\color{bashgray},
basicstyle=\ttfamily\small,
numbers=none,
captionpos=b,
tabsize=4,
breaklines=true,
frame=single,
rulecolor=\color{lightgray},
rulecolor=\color{bashgray},
framerule=1pt,
framesep=1pt,
rulesep=0pt,
@@ -33,6 +37,8 @@
\lstdefinestyle{eWomsCode}
{language=C++,
basicstyle=\ttfamily\scriptsize,
backgroundcolor=\color{bashgray},
rulecolor=\color{bashgray},
numbers=left,
numberstyle=\tiny,
numbersep=5pt,
@@ -159,16 +165,26 @@
\tableofcontents
\part{Getting Familiar}
\input{intro}
\input{getting-started}
\input{tutorial}
\input{structure}
\part{Concepts and Software Architecture}
\input{designpatterns}
\input{propertysystem}
\input{fluidframework}
\input{models}
\input{NewtonInANutshell}
\part{Guides}
\input{structure}
\input{install}
\input{guidelines}
\input{new-folder}
\input{newton-in-a-nutshell}
\input{models}
\bibliographystyle{plain}
\bibliography{ewoms-handbook}

16
doc/handbook/getting-started.tex
View File

@@ -1,11 +1,19 @@
\chapter{Getting started}
\chapter{Set-up and basic workflows}
First, we describe a quick installation procedure.
Then a quick start guide for the first \Dumux experience is provided.
This chapter is aimed at setting up a development environment for
\eWoms and to equip you with a rough understanding of the basic
workflows used for developing the software. We will first have a
brief look at the installation procedure; After that, we will run a
sample simulation and briefly discuss how to visualize its results.
Be aware, that this is only a very streamlined version of the \eWoms
development workflow, so make yourself confident with the tools
introduced in this section before you delve into the \Cplusplus code
in the next chapter.
\input{quick-install}
\input{quickstart-guide}
\input{parameterTree}
\input{parameters}
%%% Local Variables:
%%% mode: latex

7
doc/handbook/models.tex
View File

@@ -191,7 +191,7 @@ subdirectories of \texttt{dumux/boxmodels} of the \Dumux distribution.
\subsubsection{The non-isothermal two-component Stokes model: Stokes2cniModel}
\input{ModelDescriptions/stokes2cnimodel}
\subsection{Decoupled models}
\subsection{Semi-implicit models}
%
The basic idea the so-called decoupled models have in common is to reformulate the equations of multi-phase flow (e.g. Eq. \ref{A3:eqmass1}) into one equation for pressure and equations for phase-/component-/etc. transport. The pressure equation is the sum of the mass balance equations and thus considers the total flow of the fluid system. The new set of equations is considered as decoupled (or weakly coupled) and can thus be solved sequentially. The most popular decoupled model is the so-called fractional flow formulation for two-phase flow which is usually implemented applying an IMplicit Pressure Explicit Saturation algorithm (IMPES).
In comparison to a fully implicit model, the decoupled structure allows the use of different discretization methods for the different equations. The standard method used in the decoupled models is a cell centered finite volume method. Further schemes, so far only available for the two-phase pressure equation, are cell centered finite volumes with multi-point flux approximation (MPFA O-method) and mimetic finite differences.
@@ -209,8 +209,9 @@ An h-adaptive implementation of both \nameref{ch:2p_decoupled} and \nameref{ch:2
\paragraph{Saturation model}
\input{ModelDescriptions/2pdecoupledsaturationmodel}
%\subsubsection{The two-phase, two-component model}\label{ch:2p2c_decoupled}
%\input{ModelDescriptions/decoupled2p2c}
\subsubsection{The two-phase, two-component model}\label{ch:2p2c_decoupled}
\input{ModelDescriptions/2p2cdecoupledpressuremodel}
\input{ModelDescriptions/2p2cdecoupledtransportmodel}
%%% Local Variables:
%%% mode: latex

0
doc/handbook/newFolder.tex → doc/handbook/new-folder.tex
View File

11
doc/handbook/NewtonInANutshell.tex → doc/handbook/newton-in-a-nutshell.tex
View File

@@ -1,7 +1,7 @@
\chapter{Newton in a Nutshell}
Coming back to the example of chapter \ref{flow} the following mass conservation equation is to be solved:
For the isothermal immiscible multi-phase model for flow in porous
media, the following mass conservation equation needs to be solved:
\begin{align}
\underbrace{
\phi \frac{\partial \varrho_\alpha S_\alpha}{\partial t}
@@ -59,3 +59,8 @@ Comparing (\ref{GenSysEq}) with (\ref{NewtonAsUsed}) leads to:
This is equivalent to stating that the implemented algorithm solves for the change of the solution. Or in other words: until the $\textbf{u}$ does not change with one more \textsc{Newton-}iteration (do not confuse with timestep!).
In the rest of Dumux (everywhere besides in the solver), not the change of the solution is looked for, but the actual solution is used. Therefore the outcome of the linear solver needs to be reformulated as done in \verb+updateMethod.update(*this, u, *uOld, model);+. In this function the ``change in solution'' is changed to ``solution''. Afterwards the quantity \verb+*u+ stands for the solution.
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "ewoms-handbook"
%%% End:

0
doc/handbook/parameterTree.tex → doc/handbook/parameters.tex
View File

45
doc/handbook/propertysystem.tex
View File

@@ -1,25 +1,25 @@
\chapter{The \Dumux Property System}
\chapter{The \eWoms property system}
\label{sec:propertysystem}
This section is dedicated to the \Dumux property system. First, a high
This section is dedicated to the \eWoms property system. First, a high
level overview over its design and principle ideas is given, then
follows a short reference and a short self-contained example.
\section{Concepts and Features of the \Dumux Property System}
\section{Concepts and features of the \eWoms property system}
The \Dumux property system was designed as an attempt to mitigate the
The \eWoms property system was designed as an attempt to mitigate the
problems of traits classes. In fact, it can be seen as a traits system
which allows easy inheritance and any acyclic dependency of parameter
definitions. Just like traits, the \Dumux property system is a compile
definitions. Just like traits, the \eWoms property system is a compile
time mechanism, which means that there are no run-time performance
penalties associated with it. It is based on the following concepts:
\begin{description}
\item[Property:] In the context of the \Dumux property system, a
\item[Property:] In the context of the \eWoms property system, a
property is an arbitrary class body which may contain type
definitions, values and methods. Each property has a so-called
\textbf{property tag} which can be seen as a label with its name.
\item[Property Inheritance:] Just like normal classes, properties can
be arranged in hierarchies. In the context of the \Dumux property
be arranged in hierarchies. In the context of the \eWoms property
system, nodes of the inheritance hierarchy are called \textbf{type
tags}.
\end{description}
@@ -32,15 +32,15 @@ introspection denotes the ability to generate diagnostic messages
which can be used to find out where a certain property was defined and
how it was inherited.
\section{\Dumux Property System Reference}
\section{\eWoms property system reference}
All source files which use the \Dumux property system should include
All source files which use the \eWoms property system should include
the header file \texttt{dumux/ \hskip-1ex{}common/
\hskip-1ex{}propertysystem.hh}. Declaration of type tags and
property tags as well as defining properties must be done inside the
namespace \texttt{Dumux::Properties}.
\subsection*{Defining Type Tags}
\subsection*{Defining type tags}
New nodes in the type tag hierarchy can be defined using
\begin{lstlisting}[style=eWomsCode]
@@ -62,7 +62,7 @@ NEW_TYPE_TAG(MyDerivedTypeTag, INHERITS_FROM(MyBaseTypeTag1, MyBaseTypeTag2));
}}
\end{lstlisting}
\subsection*{Declaring Property Tags}
\subsection*{Declaring property tags}
New property tags -- i.e. labels for properties -- are declared
using
@@ -82,7 +82,7 @@ NEW_PROP_TAG(MyPropertyTag);
}}
\end{lstlisting}
\subsection*{Defining Properties}
\subsection*{Defining properties}
The value of a property on a given node of the type tag hierarchy is
defined using
@@ -130,7 +130,7 @@ SET_SCALAR_PROP(MyTypeTag, MyScalarValue, 12345.67890);
}}
\end{lstlisting}
\subsection*{Un-setting Properties}
\subsection*{Un-setting properties}
Sometimes some inherited properties do not make sense for a certain
node in the type tag hierarchy. These properties can be explicitly
@@ -158,15 +158,14 @@ UNSET_PROP(DerivedTypeTag, TestProp);
}}
\end{lstlisting}
\subsection*{Converting Tag Names to Tag Types}
\subsection*{Converting type tag names to \Cplusplus types}
For the \Cplusplus compiler, property and type tags are like ordinary
types. Both can thus be used as template arguments. To convert a
property tag name or a type tag name into the corresponding type, the
macros \texttt{TTAG(TypeTagName)} and \texttt{PTAG(PropertyTagName)}
For the \Cplusplus compiler, type tags are like ordinary types. Both
can thus be used as template arguments. To convert a type tag name
into the corresponding type, the macro \texttt{TTAG(TypeTagName)}
ought to be used.
\subsection*{Retrieving Property Values}
\subsection*{Retrieving property values}
The value of a property can be retrieved using
\begin{lstlisting}[style=eWomsCode]
@@ -209,7 +208,7 @@ class MyClass {
};
\end{lstlisting}
\subsection*{Nesting Property Definitions}
\subsection*{Nesting property definitions}
Inside property definitions there is access to all other properties
which are defined somewhere on the type tag hierarchy. The node for
@@ -228,7 +227,7 @@ public: typedef std::vector<Scalar> type;
\end{lstlisting}
\section{A Self-Contained Example}
\section{A self-contained example}
As a concrete example, let us consider some kinds of cars: Compact
cars, sedans, trucks, pickups, military tanks and the Hummer-H1 sports
@@ -255,7 +254,7 @@ diagram for the car types above might look like outlined in Figure
which make sense for at least one of the car types of (a).}
\end{figure}
Using the \Dumux property system, this inheritance hierarchy is
Using the \eWoms property system, this inheritance hierarchy is
defined by:
\begin{lstlisting}[name=propsyscars,style=eWomsCode]
#include <dumux/common/propertysystem.hh>
@@ -309,7 +308,7 @@ the following:
\end{itemize}
\noindent
Using the \Dumux property system, these assumptions are formulated
Using the \eWoms property system, these assumptions are formulated
using
\begin{lstlisting}[name=propsyscars,style=eWomsCode]
SET_INT_PROP(CompactCar, TopSpeed, GET_PROP_VALUE(TypeTag, GasUsage) * 30);

57
doc/handbook/quick-install.tex
View File

@@ -1,10 +1,13 @@
\section{Quick Installation of \eWoms} \label{quick-install}
\section{Installation of \eWoms} \label{quick-install}
This only provides one quick way of installing \eWoms. As a
pre-requisite it is assumed that you are using \eWoms with a recent
Linux distribution that has the appropriate development packages
installed, but without the distribution packages of the \Dune core
modules installed. If you need more information, or if you have \Dune
This section describes a way of installing \eWoms that works in most
cases, but depending on your operating system of choice, \Cplusplus
compiler and features which you need, some tweaks are possibly. As a
pre-requisite it is assumed, that you are using a recent Linux
distribution that has the appropriate development packages (\Cplusplus
compiler, autoconf, automake, libtool and pkg-config amongst possibly
others) installed, but that you did not install \Dune via distribution
provided packages. If you need more information, or if you have \Dune
already installed, please have a look at the detailed installation
instructions in Section \ref{install}.
@@ -16,46 +19,52 @@ the tarballs for the \Dune-2.2 release as well as downloading and
unpacking the tarball for the \eWoms 2.2 release, or by retrieving the
code directly from their respective source-code repositories. If you
decide to use the first method, make sure to unpack all tarballs into
the same directory, for the second method you can enter the following
code snipplet into a terminal:
the same directory; if you prefer the second method, make sure that
you have the \texttt{git} version control system with the SVN plug-in
installed on your computer and enter the following code snipplet into
a terminal:
\begin{lstlisting}[style=Bash]
cd $YOUR_DUNE_ROOT_DIRECTORY
for DUNE_MODULE in common geometry grid istl localfunctions; do \
git svn clone https://svn.dune-project.org/svn/dune-$DUNE_MODULE/branches/release-2.2 $DUNE_MODULE \
done
git clone --branch "release-2.2" git://github.com/OPM/ewoms.git
\end{lstlisting}
%$
\subsection{Building \Dune and \eWoms}
\label{buildIt}
\eWoms is (almost) a standard \Dune module and is recommended to be
build using the \Dune build system~\cite{DUNE-BS}. \eWoms ships with a
few option files for \Dune's build script, \texttt{dunecontrol}. For
the first time compilation we recommend to use the options optimized
for the debugging experience, \texttt{debug.opts}:
\eWoms is \Dune module and is recommended to build it using the \Dune
build system~\cite{DUNE-BS}. To simplify things, \eWoms ships with a
few option files for \Dune's build script, \texttt{dunecontrol}. If
you are using \eWoms the first time, we recommend to use the one
optimized for the debugging experience, \texttt{debug.opts}:
\begin{lstlisting}[style=Bash]
# make sure you are in the DUNE's root directory
cd $YOUR_DUNE_ROOT_DIRECTORY
./dune-common/bin/dunecontrol --opts=ewoms/debug.opts all
\end{lstlisting}
%$
If you finished with developing and testing your own code on
Once you have finished developing and testing your own code on
small-scale problems, re-compile everything with compiler
optimizations enabled before a production run:
optimizations enabled before a production run in order to speed things
up by a factor of approximately 10:
\begin{lstlisting}[style=Bash]
# make sure you are in the DUNE's root directory
cd $YOUR_DUNE_ROOT_DIRECTORY
./dune-common/bin/dunecontrol --opts=ewoms/optim.opts all
\end{lstlisting}
%$
Sometimes it is necessary to have additional options which are
specific to the concrete operating system you use or you might also
have special needs. For this reason, the option files mentioned above
are to be rather understood as a starting point for specifying the own
options than as something which is fixed; feel free to copy and modify
them. For example, if you need external libraries, you might need to
add or modify quite many options. To avoid confusion, it can also be
helpful to use a different name for your customized option files.
specific to the operating system of your choice, or if you have
special requirements. For this reason, the option files mentioned
above should be rather understood as a starting point for your own
option files than as something fixed; feel free to copy and modify
them. To avoid confusion, it is usually helpful to rename your
customized option files, though.
%%% Local Variables:
%%% mode: latex

2
doc/handbook/quickstart-guide.tex
View File

@@ -1,4 +1,4 @@
\section[Quick start guide]{Quick start guide: The first run of a test application}
\section[Quick start guide]{Compiling and running a sample application}
\label{quick-start-guide}
The previous section showed how to install and compile \eWoms. This

3
doc/handbook/structure.tex
View File

@@ -125,9 +125,6 @@ Doxygen documentation should be considered.
\end{figure}
\end{landscape}
\input{guidelines}
\input{newFolder}
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "ewoms-handbook"

735
doc/handbook/tutorial-coupled.tex
View File

@@ -1,16 +1,23 @@
\section[Fully-Implicit Model]{Solving a Problem Using a Fully-Coupled Model}\label{tutorial-coupled}
\section[Fully-Implicit Model]{Solving a problem using a fully-implicit model}
\label{tutorial-coupled}
The process of setting up a problem using \Dumux can be roughly divided into four parts:
The process of setting up a problem using \eWoms can be roughly
divided into four parts:
\begin{enumerate}
\item A suitable model has to be chosen.
\item The geometry of the problem and correspondingly a grid have to be defined.
\item Material properties and constitutive relationships have to be selected.
\item Boundary conditions and initial conditions have to be specified.
\item The geometry of the problem and correspondingly a grid have to
be defined.
\item Boundary and initial conditions and material properties have to be
selected.
\end{enumerate}
The problem being solved in this tutorial is illustrated in Figure \ref{tutorial-coupled:problemfigure}.
A rectangular domain with no-flow boundaries on the top and on the bottom, which is initially saturated with oil, is considered.
Water infiltrates from the left side into the domain and replaces the oil. Gravity effects are neglected here.
The physical set-up of the flow problem being solved in this tutorial
is illustrated in Figure \ref{tutorial-coupled:problemfigure}: It
consists of a rectangular domain with no-flow boundary conditions on
the top and on the bottom of the domain, which is initially fully
saturated by oil. Water infiltrates from the left side into the domain
and replaces the oil. The effect of gravity is neglected for this
problem.
\begin{figure}[ht]
\psfrag{x}{x}
@@ -49,295 +56,207 @@ The solved equations are the mass balances of water and oil:
0
\end{align}
\subsection{The Main File}
\subsection{The main source file}
Listing \ref{tutorial-coupled:mainfile} shows the main application file
\texttt{tutorial/tutorial\_coupled.cc} for the coupled two-phase
model. This file has to be compiled and executed in order to solve the problem described
above.
Listing \ref{tutorial-coupled:mainfile} shows the main application
file \texttt{tutorial/tutorial\_coupled.cc} uses the fully implicit
model that assumes immiscibility. This file has to be compiled and
executed in order to solve the problem described above.
\begin{lst}[File tutorial/tutorial\_coupled.cc]\label{tutorial-coupled:mainfile} \mbox{}
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=24, firstnumber=24]{../../tutorial/tutorial_coupled.cc}
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=25, firstnumber=25]{../../tutorial/tutorial_coupled.cc}
\end{lst}
From line \ref{tutorial-coupled:include-begin} to line
\ref{tutorial-coupled:include-end} the required headers are included.
In \eWoms, this file is usually quite short, as most of the work for
setting up the simulation is done by the generic startup routine
\texttt{Dumux::start()}. The tasks left for the main source file are:
\begin{itemize}
\item Inclusion of the necessary header files from line
\ref{tutorial-coupled:include-begin} to line
\ref{tutorial-coupled:include-end}.
\item Specifying the type tag of the problem which is going to be
simulated at line \ref{tutorial-coupled:set-type-tag}.
\item Starting the simulation using default \eWoms startup routine
\texttt{Dumux::start()} on line \ref{tutorial-coupled:call-start}.
\end{itemize}
At line \ref{tutorial-coupled:set-type-tag} the type tag of the
problem, which is going to be simulated, is specified. All other data
types can be retrieved via the \Dumux property system and only depend
on this single type tag. For a more thorough introduction to the
\Dumux property system, see chapter~\ref{sec:propertysystem}.
After this, the default startup routine \texttt{Dumux::start()} is
called on line \ref{tutorial-coupled:call-start}. This function deals
with parsing the command line arguments, reading the parameter file,
setting up the infrastructure necessary for \Dune, loading the grid, and
starting the simulation.
Required parameters for the start of the simulation,
such as the initial time-step size, the simulation time or details of the grid,
The default \eWoms startup routine deals with parsing the command line
arguments, reading the parameter file, properly setting up the \Dune
infrastructure, creating the grid, and starting the actual simulation.
Required parameters for the start of the simulation, such as the
initial time-step size, the simulation time or details of the grid,
can be either specified by command line arguments of the form
(\texttt{-ParameterName ParameterValue}), in the file specified by the
\texttt{-ParameterFile} argument, or if the latter is not specified,
in the file \mbox{\texttt{tutorial\_coupled.input}}.
If a parameter is
specified on the command line as well as in the parameter file, the
values provided in the command line have
precedence. Listing~\ref{tutorial-coupled:parameter-file} shows the
default parameter file for the tutorial problem.
(\texttt{--parameter-name=value}), in the file specified by the
\texttt{--parameter-file="file\_name"} argument. A list of all
recognized parameters that can be specified at run time can be printed
by passing the \texttt{--help} argument to the exectutable of the
simulation.
%\begin{lst}[File tutorial/tutorial\_coupled.input]\label{tutorial-coupled:parameter-file} \mbox{}
%\lstinputlisting[style=eWomsCode]{../../tutorial/tutorial_coupled.input}
%\end{lst}
\subsection{The problem file}
To provide an error message, the usage message which is displayed to
the user if the simulation is called incorrectly, is printed via the
custom function which is defined on
line~\ref{tutorial-coupled:usage-function}.
In this function the usage message is customized to the problem at hand.
This means that at least the necessary parameters are listed here.
For more information about the input file please refer to section \ref{sec:inputFiles}.
\subsection{The Problem Class}
When solving a problem using \Dumux, the most important file is the
When solving a problem using \eWoms, the most important file is the
so-called \textit{problem file} as shown in
listing~\ref{tutorial-coupled:problemfile}.
\begin{lst}[File tutorial/tutorialproblem\_coupled.hh]\label{tutorial-coupled:problemfile} \mbox{}
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=24, firstnumber=24]{../../tutorial/tutorialproblem_coupled.hh}
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=25, firstnumber=25]{../../tutorial/tutorialproblem_coupled.hh}
\end{lst}
First, a new type tag is created for the problem in line
This file specifies everything that is related to the physical
problem. It first sets up the properties relevant for this problem
using the \eWoms property system (for more information see chapter
\ref{sec:propertysystem})
\begin{itemize}
\item First, a new type tag is created for the problem in line
\ref{tutorial-coupled:create-type-tag}. In this case, the new type
tag inherits all properties from the \texttt{BoxTwoP} type tag, which
means that for this problem the two-phase box model is chosen as
discretization scheme. Further, it inherits from the spatial
parameters type tag, which is defined in the problem-dependent spatial
parameters file (line
\ref{tutorial-coupled:define-spatialparameters-typetag}). On line
\ref{tutorial-coupled:set-problem}, a problem class is attached to the
new type tag, while the grid which is going to be used is defined in
line \ref{tutorial-coupled:set-grid} -- in this case that is
\texttt{Dune::YaspGrid}. Since there's no uniform mechanism to
allocate grids in \Dune, \Dumux features the concept of grid creators.
In this case the generic \texttt{CubeGridCreator} which creates a
structured hexahedron grid of a specified size and resolution. For
this grid creator the physical domain of the grid is specified via the
discretization scheme.
\item On line \ref{tutorial-coupled:set-problem}, a problem class is
specified for the new type tag, while the grid which is going to be
used is defined in line \ref{tutorial-coupled:set-grid} -- in this
case that is \texttt{Dune::YaspGrid}.
\item Since there's no uniform mechanism to allocate grids in \Dune,
\eWoms features the concept of grid creators. In this case the
generic \texttt{CubeGridCreator} is used. This grid creator constructs a structured
hexahedron grid of a specified size and resolution. For this grid
creator the physical domain of the grid is specified via the
run-time parameters \texttt{Grid.upperRightX},
\texttt{Grid.upperRightY}, \texttt{Grid.numberOfCellsX} and
\texttt{Grid.numberOfCellsY}. These parameters can be specified via
the command-line or in a parameter file.
Next, the appropriate fluid system, which specifies the thermodynamic
relations of the fluid phases, has to be chosen. By default, the
two-phase model uses the \texttt{TwoPImmiscibleFluidSystem}, which
assumes immiscibility of the phases, but requires the components
used for the wetting and non-wetting phases to be explicitly set. In
this case, liquid water which uses the relations from
IAPWS'97~\cite{IAPWS1997} is chosen as the wetting phase on line
\ref{tutorial-coupled:wettingPhase} and liquid oil is chosen as the
non-wetting phase on line \ref{tutorial-coupled:nonwettingPhase}. The
last property, which is set in line \ref{tutorial-coupled:gravity},
tells the model not to use gravity.
Parameters which are specific to a physical set-up to be simulated,
such as boundary and initial conditions, source terms or temperature
within the domain, and which are required to solve the differential
equations of the models are specified via a \textit{problem} class. If
the two-phase box model is used, this class should be derived from
\texttt{TwoPBoxProblem} as done in line
\ref{tutorial-coupled:def-problem}.
The problem class always has at least five methods:
\begin{itemize}
\item A method \texttt{boundaryTypes()} specifying the type of
boundary conditions at each vertex.
\item A method \texttt{dirichlet()} specifying the actual values for
the \textsc{Dirichlet} conditions at each \textsc{Dirichlet} vertex.
\item A method \texttt{neumann()} specifying the actual values for
the \textsc{Neumann} conditions, which are usually evaluated at the
integration points of the \textsc{Neumann} boundary faces.
\item A method for source or sink terms called \texttt{source()}, usually evaluated at
the center of a control volume.
\item A method called \texttt{initial()} for specifying the initial
conditions at each vertex.
\end{itemize}
For the definition of the the boundary condition types and of the
values of the \textsc{Dirichlet} boundaries, two parameters are
available:
\begin{description}
\item [values:] A vector which stores the result of the method. What
the values in this vector mean is dependent on the method: For
\texttt{dirichlet()} it contains the actual values of the primary
variables, for \texttt{boundaryTypes()} it contains the boundary
condition types. It has as many entries as the model has primary variables / equations.
For the typical case, in which all equations have the same boundary
condition type at a certain position, there are two methods that set the appropriate conditions
for all primary variables / equations: \texttt{setAllDirichlet()} and \texttt{setAllNeumann()}.
\item [vertex:] The boundary condition and the Dirichlet values are
specified for a vertex, which represents a control volume in the box
discretization. This avoids the specification of two different
boundary condition types for one equation at different control
volumes. Be aware that the second parameter is a Dune grid entity
with the codimension \texttt{dim}.
\end{description}
Next, an appropriate fluid system -- which specifies the thermodynamic
relations of the fluid phases -- has to be chosen. By default, the
fully-implicit immiscible model uses the
\texttt{TwoPImmiscibleFluidSystem}. This fluid system simplifies
things considerably by assuming immiscibility of the phases, but it
requires to explicitly specify the fluids used for the wetting and
non-wetting phases. In this case, liquid water based on the relations
from IAPWS'97~\cite{IAPWS1997} is chosen as the wetting phase on line
\ref{tutorial-coupled:wettingPhase} and liquid oil is chosen as the
non-wetting phase on line \ref{tutorial-coupled:nonwettingPhase}. The
next property, which is set in line \ref{tutorial-coupled:gravity},
tells the model not to use gravity. This is then followed by the
specifcation default values for parameters specifying the temporal and
spatial domain from line \ref{tutorial-coupled:default-params-begin}
to line \ref{tutorial-coupled:default-params-end}. The values of thos
can be overwritten at run-time if desired.
To ensure that no boundaries are undefined, a small safeguard value
\texttt{eps\_} is usually added when comparing spatial
coordinates. The left boundary is hence not detected by checking, if the
first coordinate of the global position is equal to zero, but by testing whether it is
smaller than a very small value \texttt{eps\_}.
Following the property definition is the definition actual physical
set-up to be simulated. This is done by means of the \textit{problem
class}. The problem class specifies boundary and initial conditions,
source terms or spatial quantities like temperature, porosity,
intrinsic permeability and the parameters of the material law within
the domain. Since there are quite a few methods of the problem called
by the \eWoms models, and often there are sensible defaults for these
methods, it is strongly recomended to derive the problem class from
the class specified by the \texttt{BaseProblem} property as can be
seen on line \ref{tutorial-coupled:def-problem}\footnote{Technically,
deriving the problem from the \texttt{BaseProblem} property is not
required if it implements all necessary methods. Do not complain if
things explode in this case, though.}.
Methods which make statements about boundary segments of the grid
(such as \texttt{neumann()}) are called with six arguments:
\begin{description}
\item[values:] A vector \texttt{neumann()}, in which the mass fluxes per area unit
over the boundary segment are specified.
\item[element:] The element of the grid where the boundary segment
is located.
\item[fvElementGeometry:] The finite-volume geometry induced on the
finite element by the box scheme.
\item[isIt:] The \texttt{Intersection} of the boundary segment as given by the grid.
\item[scvIdx:] The index of the sub-control volume in
\texttt{fvElementGeometry} which is assigned to the boundary segment.
\item[boundaryFaceIdx:] The index of the boundary face in
\texttt{fvElementGeometry} which represents the boundary segment.
\end{description}
For isothermal multi-phase porous media models, problem class must always provide at least
the following methods:
\begin{itemize}
\item \texttt{initial()} for specifying the initial condition within
the domain.
\item \texttt{source()} specifying the source term for each conservation quantity.
\item \texttt{boundary()} specifying the conditions which apply on the domain boundary.
\item \texttt{temperature()} specifying temperature at a given time
and at a given position of the domain. If energy is conserved, this
method is not necessary, but energy fluxes must be provided in the
\texttt{boundary()} and \texttt{source()} methods and an initial
temperature needs to be defined in the \texttt{initial()} method.
\item \texttt{intrinsicPermeability()} returns the intrinsic
permeability matrix $\mathbf{K}$ in $[m^2]$ at a given location.
\item \texttt{porosity()} returns the ratio of pore space to
total volume of the medium at a given location.
\item \texttt{materialLawParams()} returns the function parameters for
the capillary pressure and relative permeability relations at a
given location.
\end{itemize}
Similarly, the \texttt{initial()} and \texttt{source()} methods
specify properties of control volumes and thus only get
\texttt{values}, \texttt{element}, \texttt{fvGeometry} and
\texttt{scvIdx} as arguments.
All of these methods take a single template argument,
\texttt{Context}, and the three function arguments \texttt{context},
\texttt{spaceIdx} and \texttt{timeIdx}. Together these form the
\textit{execution context}. The execution context can be thought of as
a collection of all available information when a given method is
called. Execution contexts are thus a way to abstract the differences
of the different discretization schemes. The following methods are
provided by all \text{context} objects:
\begin{itemize}
\item \texttt{pos(spaceIdx, timeIdx)}: This method returns the
relevant position of the execution context within the physical
domain.
\item \texttt{globalSpaceIndex(spaceIdx, timeIdx)}: Returns a global
index for the spatial entity which is described by the execution
context. This index can be used to store spatially dependent
information in an array.
\item \texttt{element()}: Returns the \Dune grid element for which the
execution context is valid.
\item \texttt{gridView()}: Returns the \Dune grid view of which the
element is part of.
\item \texttt{problem()}: Returns the \eWoms object which describes
the physical problem to be solved.
\item \texttt{model()}: Returns the \eWoms model which is used to simulate
the physical problem.
\end{itemize}
In addition to these five methods, there might be some model-specific
methods. If the isothermal two-phase model is used, this includes for
example a \texttt{temperature()} method which returns the temperature
in \textsc{Kelvin} of the fluids and the rock matrix in the
domain. This temperature is then used by the model to calculate fluid
properties which possibly depend on it, e.g. density. The
\texttt{bboxMax()} (``\textbf{max}imum coordinated of the grid's
\textbf{b}ounding \textbf{b}ox'') method is used here to
determine the extend of the physical domain. It returns a vector with the
maximum values of each global coordinate of the grid. This method
and the analogous \texttt{bboxMin()} method are provided by the base
class \texttt{Dumux::BoxProblem<TypeTag>}.
The execution contexts for the \texttt{source} and \texttt{boundary}
methods provide the following methods in addition:
\begin{itemize}
\item \texttt{volVars(spaceIdx, timeIdx)}: The secondary variables
used by the model relevant for the execution context. These are
useful to specify solution dependent source and boundary terms.
\item \texttt{primaryVars(spaceIdx, timeIdx)}: The vector of primary
variables to which the model solves for.
\end{itemize}
\subsection{Defining Fluid Properties}\label{tutorial-coupled:description-fluid-class}
Finally, the execution context for the \texttt{boundary} method
provides the methods \texttt{boundarySegmentArea(spaceIdx, timeIdx)},
and \texttt{normal(spaceIdx, timeIdx)}, which return the area and
outer unit normal of the execution context's boundary segment.
The \Dumux distribution includes some common substances which can be
used out of the box. The properties of the pure substances (such as
When specifying the boundary conditions in the problem class, a small
safeguard value \texttt{eps\_} is usually added when comparing spatial
coordinates. For the problem considered here, the left boundary might
hence not be detected if checking whether the first coordinate of the
global position is equal to zero, but by testing whether it is smaller
than a very small value \texttt{eps\_}. Also, the \texttt{bboxMax()}
(``\textbf{max}imum coordinate of the grid's \textbf{b}ounding
\textbf{b}ox'') method is used here to determine the extend of the
physical domain. It returns a vector with the maximum values of each
global coordinate of the grid. This method and the analogous
\texttt{bboxMin()} method are provided by the problem's base class.
In addition to these methods, there might be some additional
model-specific methods.
\subsection{Defining fluid properties}
\label{tutorial-coupled:description-fluid-class}
The \eWoms distribution includes some common substances which can be
used out of the box. The properties of pure substances (such as
the components nitrogen, water, or the pseudo-component air) are
provided by header files located in the folder
\verb+dumux/material/components+.
\texttt{dumux/material/components}.
Most often, when two or more components are considered, fluid
interactions such as solubility effects come into play and properties
of mixtures such as density or enthalpy are of interest. These
interactions are defined by {\em fluid systems}, which are located in
\verb+dumux/material/fluidsystems+. A more thorough overview of the
\Dumux fluid framework can be found in chapter~\ref{sec:fluidframework}.
% In this example, a class for the definition of a two-phase system is used. This allows for the choice
% of the two components oil and water and for access of the parameters that are relevant for the two-phase model.
\subsection{Defining Spatially Dependent Parameters}\label{tutorial-coupled:description-spatialParameters}
In \Dumux, many properties of the porous medium can depend on the
spatial location. Such properties are the \textit{intrinsic
permeability}, the parameters of the \textit{capillary pressure} and
the \textit{relative permeability}, the \textit{porosity}, the
\textit{heat capacity} as well as the \textit{heat conductivity}. Such
parameters are defined using a so-called \textit{spatial parameters}
class.
If the box discretization is to used, the spatial parameters class
should be derived from the base class
\texttt{Dumux::BoxSpatialParams<TypeTag>}. Listing
\ref{tutorial-coupled:spatialparametersfile} shows the file \\
\verb+tutorialspatialparams_coupled.hh+:
%\begin{lst}[File tutorial/tutorialspatialparameters\_coupled.hh]\label{tutorial-coupled:spatialparametersfile} \mbox{}
%\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=25, firstnumber=25]{../../tutorial/tutorialspatialparams_coupled.hh}
%\end{lst}
First, the spatial parameters type tag is created on line
\ref{tutorial-coupled:define-spatialparameters-typetag}. The type tag
for the problem is then derived from it. The \Dumux properties defined on
the type tag for the spatial parameters are, for example, the spatial
parameters class itself (line
\ref{tutorial-coupled:set-spatialparameters}) or the capillary
pressure/relative permeability relations\footnote{Taken together, the
capillary pressure and the relative permeability relations are
called \textit{material law}.} which ought to be used by the
simulation (line
\ref{tutorial-coupled:rawlaw} \label{tutorial-coupled:materialLaw}).
\Dumux provides several material laws in the folder
\verb+dumux/material/fluidmatrixinteractions+. The selected one --
here it is a relation according to a regularized version of
\textsc{Brooks} \& \textsc{Corey} -- is included in line
\ref{tutorial-coupled:rawLawInclude}.
After the selection, an adapter class is specified in line \ref{tutorial-coupled:eff2abs} to
translate between effective and absolute saturations. Like this,
residual saturations can be specified in a generic way. As only the employed
material law knows the names of the parameters which it
requires, it provides a parameter class
\texttt{RegularizedBrooksCoreyParams} which has the type
\texttt{Params} and which is defined in line
\ref{tutorial-coupled:matLawObjectType}. In this case, the spatial
parameters only require a single set of parameters which means that it
only requires a single material parameter object as can be seen in
line~\ref{tutorial-coupled:matParamsObject}.
In line \ref{tutorial-coupled:permeability}, a method returning the
intrinsic permeability is specified. As can be seen, the method has
to be called with three arguments:
\begin{description}
\item[\texttt{element}:] Just like for the problem itself, this
parameter describes the considered element by means of a \Dune
entity. Elements provide information about their geometry and
position and can be mapped to a global index.
\item[\texttt{fvElementGeomtry}:] It holds information about the finite-volume
geometry of the element induced by the box method.
\item[\texttt{scvIdx}:] This is the index of the sub-control volume of the
element which is considered. It is equivalent to the local index
of the vertex which corresponds to the considered control volume in
the element.
\end{description}
The intrinsic permeability is usually a tensor. Thus the method returns
a $\texttt{dim} \times \texttt{dim}$-matrix, where \texttt{dim} is the
dimension of the grid.
The method \texttt{porosity()} defined in line
\ref{tutorial-coupled:porosity} is called with the same arguments as
\texttt{intrinsicPermeability()} and returns a scalar value for
porosity dependent on the position in the domain.
Next, the method \texttt{materialLawParams()}, defined in line
\ref{tutorial-coupled:matLawParams}, returns the
\verb+materialLawParams+ object that is applied at the specified
position. Although in this case only one object is returned, in
general, the problem may be heterogeneous, which necessitates
returning different objects at different positions in space. While
the selection of the type of this object was already explained (line
\ref{tutorial-coupled:rawLawInclude}), some specific parameter values
of the used material law, such as the \textsc{Brooks} \&
\textsc{Corey} parameters, are still needed. This is done in the
constructor at line \ref{tutorial-coupled:setLawParams}. Depending on
the type of the \texttt{materialLaw} object, the \texttt{set}-methods
might be different than those given in this example. The name of the
access / set functions as well as the rest of the implementation of
the material description can be found in
\verb+dumux/material/fluidmatrixinteractions/2p+.
When two or more components are considered, interactions between pure
substances become relevant and properties of these mixtures of
substances -- e.g. composition, density or enthalpy -- are of
interest. Such interactions are defined by {\em fluid systems}, which
are located in \texttt{dumux/material/fluidsystems}. A more thorough
overview of the \eWoms fluid framework can be found in
chapter~\ref{sec:fluidframework}.
\subsection{Exercises}
\label{tutorial-coupled:exercises}
The following exercises will give you the opportunity to learn how you
can change soil parameters, boundary conditions, run-time parameters
and fluid properties in \Dumux.
and fluid properties in \eWoms.
\subsubsection{Exercise 1}
\renewcommand{\labelenumi}{\alph{enumi})} For Exercise 1 you have
@@ -349,99 +268,154 @@ to make only some small changes in the tutorial files.
To get an impression what the results should look like you can first run the original version of
the coupled tutorial model by typing \texttt{./tutorial\_coupled}.
Note, that the time-step size is automatically adapted during the simulation.
For the visualization of the results using paraview please refer to section \ref{quick-start-guide}.
For visualizing the results using the program \texttt{paraview}, please refer to section \ref{quick-start-guide}.
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\
\item \textbf{Changing the Model Domain} \\
Change the size of the model domain so that you get a rectangle with
edge lengths of $\text{x} = \unit[400]{m}$ and $\text{y} = \unit[500]{m}$ and with
discretization lengths of $\Delta \text{x} = \unit[20]{m}$ and $\Delta
\text{y} = \unit[20]{m}$. For this you have to edit the parameter file (\texttt{tutorialproblem\_coupled.input})
and run the program again.\\
Note, that you do not have to recompile the program if you make changes to the parameter file.
edge lengths of $\text{x} = \unit[400]{m}$ and $\text{y} =
\unit[500]{m}$ and with discretization lengths of $\Delta \text{x} =
\unit[20]{m}$ and $\Delta \text{y} = \unit[20]{m}$. For this you can
either change the properties defined between lines
\ref{tutorial-coupled:default-params-begin} and
\ref{tutorial-coupled:default-params-end} (don't forget to
re-compile the program in this case), or pass you may pass them as
command line parameters to the simulation when you run it. Note,
that you do not have to recompile the program if you add command
line parameters to the executable.
If you chose to change the problem file, re-compile the simulation
by typing \texttt{make tutorial\_coupled}. In both cases, don't
forget run the simulation as explained above.
\item \textbf{Boundary Conditions} \\
Change the boundary conditions in the file
\texttt{tutorialproblem\_coupled.hh} so that water enters from the
bottom and oil is extracted from the top boundary. The right and the
left boundary should be closed for water and oil fluxes. \\
The Neumannn Boundary conditions are multiplied by the normal (pointing outwards), so an influx is negative, an outflux always positive.
Such information can easily be found in the documentation of the functions (also look into base classes).
Compile the main file by typing \texttt{make tutorial\_coupled} and
run the model as explained above.
left boundary should be closed for water and oil fluxes.
Note that in \eWoms, flux boundary conditions are specified as
fluxes of the conserved quantities into the direction of the outer
normal per area. This means a mass flux into the domain is negative,
a flux out of the domain is always positive. Re-compile the
simulation by typing \texttt{make tutorial\_coupled} and re-run it
as explained above.
\item \textbf{Changing the Shape of the Discrete Elements} \\
In order to complete this exercise you need a grid module capable of handling
simplex grids, like \texttt{ALUSimplexGrid}. If this is not the case please skip this exercise.
Change the types of elements used for discretizing the domain. In line \ref{tutorial-coupled:set-gridcreator} of the problem
file the type of gridcreator is chosen. By choosing a different grid creator you can discretize the domain with different elements.
In order to complete this exercise you need a \Dune grid module that
is capable of handling simplex grids. By default, \Dune does not
include such a grid manager in its core modules, but one such grid
manager that is freely available
\texttt{ALUGrid}~\cite{ALUGRID-HP}. If you did not install such a
grid manager, please skip this exercise.
Hint: You can find some pre-defined grid creators in
\texttt{dumux/common/}; For this excercise you can change the
include statement from \texttt{cubegridcreator.hh} to
\texttt{simplexgridcreator.hh} and the \texttt{GridCreator} property
from \texttt{CubeGridCreator} to \texttt{SimplexGridCreator}.
To complete this excercise, change the problem's grid creator on
line \ref{tutorial-coupled:set-gridcreator} to
\texttt{SimplexGridCreator<TypeTag>} and the type of the grid to
\texttt{Dune::ALUSimplexGrid<2, 2>} on line
\ref{tutorial-coupled:set-grid}. You also need to change the include
statement from \texttt{cubegridcreator.hh} to
\texttt{simplexgridcreator.hh} on line
\ref{tutorial-coupled:include-grid-creator}.
Besides having to change the grid creator it is also necessary to
change the type of a DUNE grid in line
\ref{tutorial-coupled:set-grid} to a grid which supports the types
of elements which the grid creator uses. In this example, you can
change the \texttt{Grid} property from \texttt{ALUCubeGrid} to
\texttt{ALUSimplexGrid}. The resulting grid can be examined by
starting the simulation, loading the result in paraview, and
selecting \texttt{Surface with Edges} as the visualization mode.
The resulting grid can be examined by re-compiling and starting the
simulation, loading the result into \texttt{paraview}, and selecting
\texttt{Surface with Edges} as the visualization mode.
\item \textbf{Changing Fluids} \\
Now you can change the fluids. Use DNAPL instead of Oil and Brine instead of Water. To do that, you have to select different components via the property system in the problem file:
In this exercise you will change the fluids used. Use DNAPL instead
of Oil and Brine instead of Water. To do that, you may follow the
steps:
\begin{enumerate}
\item Brine: Brine is thermodynamically very similar to pure water but also considers a fixed amount of salt in the liquid phase.
Hence, the class \texttt{Dumux::Brine} calls back to a class which represents pure water. This can be, for example \texttt{Dumux::H2O}, or texttt{Dumux::SimpleH2O}.
The class which represents pure water is passed to
\texttt{Dumux::Brine} as the second template argument after the data
type for scalar values, i.e. the full definition of the brine
component is \texttt{Dumux::Brine<Scalar, Dumux::H2O>}. The file
which defines the brine component is located in the folder
\texttt{dumux/material/components/}.
Try to include the file and select the component as the wetting phase via the property system.
\item DNAPL:
Now let's include a component representing a DNAPL (\textbf{d}ense \textbf{n}on-\textbf{a}queous \textbf{p}hase \textbf{l}iquid)
which is also located in the folder \texttt{dumux/material/components/}. Try to include the file and select the component as the non-wetting phase via the property system.
\item Brine: Brine is thermodynamically very similar to pure water but
also considers a fixed amount of salt in the liquid phase. Hence,
the class \texttt{Dumux::Brine} calls back to a class which
represents pure water. This can be, for example \texttt{Dumux::H2O},
or \texttt{Dumux::SimpleH2O}. The class which represents pure water
is passed to \texttt{Dumux::Brine} as the second template argument
after the data type for scalar values, i.e. the full definition of
the brine component is \texttt{Dumux::Brine<Scalar,
Dumux::H2O<Scalar> >}. The file which defines the brine component
is located in the folder \texttt{dumux/material/components/}.
Include this file and select use the brine component as the wetting phase.
\item DNAPL: Now let us include a component representing an oil that
is heavier than water (in environmental engineering this class of
substances is often called \textbf{d}ense
\textbf{n}on-\textbf{a}queous \textbf{p}hase \textbf{l}iquid
(DNAPL)) which is also located in the folder
\texttt{dumux/material/components/}. Try to include the file and
use the \texttt{DNAPL} component as the non-wetting phase.
\end{enumerate}
If you want to take a closer look on how the fluid classes are defined and which substances are already available please browse through the files in the directory
\texttt{/dumux/material/components} and read chapter~\ref{sec:fluidframework}.
If you want to take a closer look on how the fluid classes are defined
and which substances are available in the \eWoms distribution, feel
free to browse through the files in the directory
\texttt{dumux/material/components} and to read
chapter~\ref{sec:fluidframework}.
\item \textbf{Use a Full-Fledged Fluid System} \\
In \Dumux, the canonical way to describe fluid mixtures is via \textit{fluid systems}\footnote{For a thorough introduction into fluid systems and the concenpts related to it, see chapter \ref{sec:fluidframework}}.
In order to include a fluid system, you first have to comment out lines \ref{tutorial-coupled:2p-system-start}
In \eWoms, the canonical way to describe fluid mixtures is via
\textit{fluid systems}\footnote{For a thorough introduction into
fluid systems and the concepts related to it, see chapter
\ref{sec:fluidframework}}. In order to include a fluid system,
you first have to comment out lines
\ref{tutorial-coupled:2p-system-start}
to \ref{tutorial-coupled:2p-system-end} in the problem file.\\
Now include the file \texttt{fluidsystems/h2oairfluidsystem.hh} in the material folder, and set a type property \texttt{FluidSystem} (see line \ref{tutorial-coupled:set-fluidsystem})
with the appropriate type, which is:\\
\texttt{Dumux::FluidSystems::H2OAir<typename GET\_PROP\_TYPE(TypeTag, Scalar)>}.\\
However, this is a rather complicated fluid system which
considers mixtures of components and also uses tabulated components that need to be initialized -- i.e. the tables need to be filled with values.
The initialization of the fluid system is normally done in the constructor of the problem by calling \texttt{GET\_PROP\_TYPE(TypeTag, FluidSystem)::init();}.
Remember that in \Cplusplus, the constructor always the same name as the respective class, i.e. \texttt{TutorialProblemCoupled(..)}.\\
As water flow replacing a gas is much faster, test your simulation only until $2000$ seconds and start with a time step of $1$ second.\\
Please reverse the changes made in this part of the exercise, as we will continue to use immiscible phases from here on and hence do not need a complex fluid system.
Now include the file
\texttt{dumux/material/fluidsystems/h2oairfluidsystem.hh}, and
instruct the model to use this fluid system by setting
\texttt{FluidSystem} via:\\
\begin{lstlisting}[style=eWomsCode]
SET_TYPE_PROP(TutorialProblemCoupled,
FluidSystem,
Dumux::FluidSystems::H2OAir<typename GET\_PROP\_TYPE(TypeTag, Scalar)>)
\end{lstlisting}
However, this is a rather complicated fluid system which considers
mixtures of components and also uses tabulated components that need to
be initialized -- i.e. some components use tables for expensive to
calculate quantities that need to be filled with values. The
initialization of the fluid system is normally done in the constructor
of the problem by calling \texttt{FluidSystem::init();}.
Remember that in \Cplusplus, the constructor always the same name as
the respective class, i.e. \texttt{TutorialProblemCoupled(..)}.
As water flow replacing a gas is much faster, test your simulation
only until $2000$ seconds and start with a time step of $1$ second.
Please revert the changes made in this part of the exercise, as we
will continue to use immiscible phases from here on and hence do not
need a complex fluid system.
\item \textbf{Changing Constitutive Relations} \\
Use an unregularized linear law with an entry pressure of $p_e = 0.0\;\text{Pa}$ and maximal capillary pressure of e.g. $p_{c_{max}} = 2000.0\;\text{Pa}$ instead of using a
regularized Brooks-Corey law for the
relative permeability and for the capillary pressure saturation relationship. To do that you have
to change the material law property (line \ref{tutorial-coupled:eff2abs}) in \texttt{tutorialspatialparams\_coupled.hh}. Leave the type definition of \texttt{Scalar} and remove
the type definition of \texttt{BrooksAndCorey} in the private section of the property definition. Exchange the \texttt{EffToAbsLaw} with the \texttt{LinearMaterial} law type in the
public section.
You can find the material laws in the folder
\verb+dumux/material/fluidmatrixinteractions+. The necessary parameters
of the linear law and the respective \texttt{set}-functions can be found
in the file \\
\verb+dumux/material/fluidmatrixinteractions/2p/linearmaterialparams.hh+.\\
Call the \texttt{set}-functions from the constructor of the \texttt{tutorialspatialparams\_coupled.hh}.
Instead of using a regularized Brooks-Corey law for the relative
permeability and for the capillary pressure saturation relationship,
use an linear material law which does not consider residual
saturation. The new material law should exhibit an entry pressure of
$p_e = 0.0\;\text{Pa}$ and maximal capillary pressure of
$p_{c_{max}} = 2000.0\;\text{Pa}$. To do that, you have to change
the material law property on line
\ref{tutorial-coupled:eff2abs} as follows:
\begin{itemize}
\item First, switch to the linear material law. This can be achieved
by replacing \texttt{RegularizedBrooksCorey} in the private section
of the property definition by \texttt{LinearMaterial} and rename
\texttt{RawMaterialLaw} to \texttt{TwoPMaterialLaw}. Also remove the
line which contains the \texttt{EffToAbsLaw} typedef.
\item Then adapt the necessary parameters of the linear law and the
respective \texttt{set}-functions can be found in the file
\texttt{dumux/material/fluidmatrixinteractions/2p/linearmaterialparams.hh}.\\
Call the \texttt{set}-functions from the constructor of the problem.
\item Finally, re-compile and re-run the simulation. In order to
successfully compile the simulation, you also have to include the
header file which contains the linear material law. This header is
called \texttt{linearmaterial.hh} and is located in the same
directory as the header for the regularized Brooks-Corey law,
\texttt{regularizedbrookscorey.hh}.
\end{itemize}
\item \textbf{Heterogeneities} \\
Set up a model domain with the soil properties given in Figure
\ref{tutorial-coupled:exercise1_d}. Adjust the boundary conditions
so that water is again flowing from the left to the right of the
so that water is flowing from the left to the right of the domain again.
\begin{figure}[ht]
\psfrag{K1 =}{$\mathbf{K} = 10^{-8}\;\text{m}^2$}
\psfrag{phi1 =}{$\phi = 0.15$}
@@ -453,52 +427,48 @@ Call the \texttt{set}-functions from the constructor of the \texttt{tutorialspat
\includegraphics[width=0.5\linewidth,keepaspectratio]{EPS/exercise1_c.eps}
\caption{Exercise 1f: Set-up of a model domain with a heterogeneity. $\Delta x = 20 \;\text{m}$ $\Delta y = 20\;\text{m}$.}\label{tutorial-coupled:exercise1_d}
\end{figure}
domain. You can use the fluids of exercise 1b).\\
\textbf{Hint:} The current position of the control volume can be obtained using \texttt{element\allowbreak.geometry()\allowbreak.corner(scvIdx)}, which
returns a vector of the global coordinates of the current position.\\
You can use the fluids of exercise 1b).
\textbf{Hint:} The relevant position in the domain can be obtained using
\texttt{const auto \&pos=context.pos(spaceIdx, timeIdx);}
When does the front cross the material border? In paraview, the
animation view (\textit{View} $\rightarrow$ \textit{Animation
View}) is a convenient way to get a rough feeling of the time-step
sizes.
animation view (\textit{View} $\rightarrow$ \textit{Animation View})
is a convenient way to get a rough feeling of the time-step sizes.
\end{enumerate}
\subsubsection{Exercise 2}
For this exercise you should create a new problem file analogous to
the file \texttt{tutorialproblem\_coupled.hh} (e.g. with the name
\texttt{ex2\_tutorialproblem\_coupled.hh} and new spatial parameters
just like \texttt{tutorialspatialparams\_coupled.hh}. The new
problem file needs to
be included in the file \texttt{tutorial\_coupled.cc}.
The new files should contain the definition of new classes with names
that relate to the file name, such as
For this exercise, first create a new problem file analogous to the
file \texttt{tutorialproblem\_coupled.hh} (e.g. with the name
\texttt{ex2\_tutorialproblem\_coupled.hh} and new spatial parameters
just like \texttt{tutorialspatialparams\_coupled.hh}. The new problem
file needs to be included in the file \texttt{tutorial\_coupled.cc}.
The new file should contain definitions of new classes with names that
relate to the file name, such as
\texttt{Ex2TutorialProblemCoupled}. Make sure that you also adjust the
guardian macros in lines \ref{tutorial-coupled:guardian1} and
\ref{tutorial-coupled:guardian1}
in the header files (e.g. change
\mbox{\texttt{DUMUX\_TUTORIALPROBLEM\_COUPLED\_HH}} to\\
\mbox{\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_COUPLED\_HH}}). Include the new problem file in \texttt{tutorial\_coupled.cc}.
Besides adjusting the guardian macros, the new problem file should define and
use a new type tag for the problem as well as a new problem class
e.g. \mbox{\texttt{Ex2TutorialProblemCoupled}}. The type tag for the problem
should be adjusted, too. For this, modify line \ref{tutorial-coupled:set-type-tag}
in the problem file and the adapt the \texttt{main} function in the
file \texttt{tutorial\_coupled.cc}.
\ref{tutorial-coupled:guardian1} in the header files (e.g. change
\mbox{\texttt{DUMUX\_TUTORIALPROBLEM\_COUPLED\_HH}} to
\mbox{\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_COUPLED\_HH}}). Include the
new problem file in \texttt{tutorial\_coupled.cc}. Besides adjusting
the guardian macros, the new problem file should define and use a new
type tag for the problem as well as a new problem class
e.g. \mbox{\texttt{Ex2TutorialProblemCoupled}}. The type tag for the
problem should be adjusted, too. For this, modify line
\ref{tutorial-coupled:set-type-tag} in the problem file and the adapt
the \texttt{main} function in the file \texttt{tutorial\_coupled.cc}.
After this, change the run-time parameters so that they match the
domain described by figure \ref{tutorial-coupled:ex2_Domain}. Adapt
the problem class so that the boundary conditions are consistent with
After this, change the domain parameters so that they match the domain
described by figure \ref{tutorial-coupled:ex2_Domain}. Adapt the
problem class so that the boundary conditions are consistent with
figure \ref{tutorial-coupled:ex2_BC}. Initially, the domain is fully
saturated with water and the pressure is $p_w = 5 \times
saturated with water and the pressure is $p_w = 5\cdot
10^5\;\text{Pa}$. Oil infiltrates from the left side. Create a grid
with $20$ cells in $x$-direction and $10$ cells in $y$-direction. The
simulation time should be set to $10^6\;\text{s}$ with an
initial time step size of $100\;\text{s}$.
Now include your new problem file in the main file and replace the
\texttt{TutorialProblemCoupled} type tag by the one you've created and
compile the program.
simulation time should end at $10^6\;\text{s}$ with an initial time
step size of $100\;\text{s}$.
\begin{figure}[ht]
\psfrag{K1}{K $= 10^{-7}\;\text{m}^2$}
@@ -532,39 +502,24 @@ compile the program.
\end{figure}
\begin{itemize}
\item Increase the simulation time to e.g. $4\times 10^7 \;\text{s}$. Investigate the saturation: Is the value range reasonable?
\item What happens if you increase the resolution of the grid?
\item Increase the simulation time to e.g. $4\times 10^7
\;\text{s}$. Investigate the saturation of the wetting phas: Is the
value range reasonable?
\item What happens if you use a grid with more cells in each direction?
\end{itemize}
\subsubsection{Exercise 3: Parameter File Input}
As you have experienced, compilation takes quite some time. Therefore,
\Dumux provides a simple method to read in parameters at run-time
via \textit{parameter input files}.
In the code, parameters can be read via the macro
\texttt{GET\_RUNTIME\_PARAM(TypeTag, Scalar,
MyWonderfulGroup.MyWonderfulParameter);}. In this exercise we will explore the possibilities of the
parameter file. For this we take a look at the file \texttt{ex3\_tutorial\_coupled.input} in the \texttt{solutions\_coupled} folder.
Besides the parameters which you already used in the parameter file above, there are parameters which can be used to control the
Newton and the Linear solver (groups: \texttt{Newton} and \texttt{LinearSolver}). Run-time parameters used in the problem or spatial parameters classes
can also be set with the respective group names (\texttt{Problem} and \texttt{SpatialParams}) in the parameter file. For the latter parameters to be included in the program
they have to be assigned in the problem or spatial parameters constructor. This can be done as shown in the files \texttt{ex3\_tutorialproblem\_coupled.diff}
and \texttt{ex3\_tutorialspatialparams\_coupled.diff} in the \texttt{solutions\_coupled} folder. Add some (for
example \texttt{Newton.MaxSteps} and \texttt{Problem.EnableGravity}) to the
parameter file \texttt{tutorial\_coupled.input} and observe what
happens if they are modified. For more information about the input file please refer to section \ref{sec:inputFiles}.
\subsubsection{Exercise 4: Create a New Component}
\subsubsection{Exercise 3: Create a New Component}
Create a new file for the benzene component called \texttt{benzene.hh}
and implement a new component. (You may get a hint by looking at
existing components in the directory \verb+/dumux/material/components+). \\
Use benzene as a new fluid and run the model of Exercise 2 with water
and benzene. Benzene has a density of $889.51 \, \text{kg} /
\text{m}^3$ and a viscosity of $0.00112 \, \text{Pa} \; \text{s}$.
and implement a new component. (You may copy and modify one of the
existing components located in the directory
\texttt{dumux/material/components}. Use benzene as a new fluid and
run the model of Exercise 2 with water and benzene. Benzene has a
density of $889.51 \, \text{kg} / \text{m}^3$ and a viscosity of
$0.00112 \, \text{Pa} \; \text{s}$.
\clearpage \newpage
%%% Local Variables:
%%% mode: latex
%%% TeX-master: "ewoms-handbook"

27
doc/handbook/tutorial-decoupled.tex
View File

@@ -61,25 +61,11 @@ with parsing the command line arguments, reading the parameter file,
setting up the infrastructure necessary for \Dune, loading the grid, and
starting the simulation. All parameters can
be either specified by command line arguments of the form
(\texttt{-ParameterName ParameterValue}), in the file specified by the
\texttt{-parameterFile} argument, or if the latter is not specified,
in the file \texttt{tutorial\_decoupled.input}. If a parameter is
(\texttt{--ParameterName=ParameterValue}), in the file specified by the
\texttt{--ParameterFile=filename.ini} argument. If a parameter is
specified on the command line as well as in the parameter file, the
values provided in the command line have
precedence. Listing~\ref{tutorial-decoupled:parameter-file} shows the
default parameter file for the tutorial problem.
%\begin{lst}[File tutorial/tutorial\_decoupled.input]\label{tutorial-decoupled:parameter-file} \mbox{}
%\lstinputlisting[style=eWomsCode]{../../tutorial/tutorial_decoupled.input}
%\end{lst}
To provide an error message, the usage message which is displayed to
the user if the simulation is called incorrectly, is printed via the
custom function which is defined on
line~\ref{tutorial-decoupled:usage-function}. In this function the usage
message is customized to the problem at hand. This means that at least
the necessary parameters are listed here. For more information about
the input file please refer to section \ref{sec:inputFiles}.
precedence.
\subsection{The problem class} \label{decoupled_problem}
@@ -167,10 +153,7 @@ Listing \ref{tutorial-decoupled:spatialparametersfile} shows the file
\begin{lst}[File tutorial/tutorialspatialparams\_decoupled.hh]\label{tutorial-decoupled:spatialparametersfile} \mbox{}
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=24, firstnumber=24]{../../tutorial/tutorialspatialparams_decoupled.hh}
\end{lst}
As this file only slightly differs from the coupled version, consult
chapter \ref{tutorial-coupled:description-spatialParameters} for explanations.
However, as a standard Finite-Volume--scheme is used, in contrast to the box-method
in the coupled case, the argument list here is the same as for the problem
The argument list here is the same as for the problem
functions: Either an \texttt{element}, or only the global position if the function is called \texttt{...AtPos(...)}.
\subsection{Exercises}
@@ -185,7 +168,7 @@ For Exercise 1 you only have to make some small changes in the tutorial files.
\begin{enumerate}
\item \textbf{Altering output}
To get an impression what the results should look like you can first run the original version of the decoupled tutorial model by typing \texttt{./tutorial\_decoupled}. The runtime parameters which are set can be found in the input file (listing~\ref{tutorial-decoupled:parameter-file}). If the input file has the same name than the main file (e.g. \texttt{tutorial\_decoupled.cc} and \texttt{tutorial\_decoupled.input}), it is automatically chosen. If the name differs the program has to be started typing \texttt{./tutorial\_decoupled -parameterFile <filename>.input}. For more options you can also type \texttt{./tutorial\_decoupled -h}. For the visualisation with paraview please refer to \ref{quick-start-guide}.\\
To get an impression what the results should look like you can first run the original version of the decoupled tutorial model by typing \texttt{./tutorial\_decoupled}. The runtime parameters which are set printed at the start of the simulation. If the input file has the same name than the main file (e.g. \texttt{tutorial\_decoupled.cc} and \texttt{tutorial\_decoupled.input}), it is automatically chosen. If the name differs the program has to be started typing \texttt{./tutorial\_decoupled -parameterFile <filename>.input}. For more options you can also type \texttt{./tutorial\_decoupled -h}. For the visualisation with paraview please refer to \ref{quick-start-guide}.\\
As you can see, the simulation creates many output files. To reduce these in order to perform longer simulations, change the method responsible for output (line \ref{tutorial-decoupled:outputinterval} in the file \texttt{tutorialproblem\_decoupled}) as to write an output only every 20 timesteps. Compile the main file by typing \texttt{make tutorial\_decoupled} and run the model. Now, run the simulation for 5e5 seconds.
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\

38
doc/handbook/tutorial.tex
View File

@@ -1,10 +1,42 @@
\chapter[Tutorial]{Tutorial}\label{chp:tutorial}
In \Dumux two sorts of models are implemented: Fully-coupled models and decoupled models. In the fully-coupled models a flow system is described by a system of strongly coupled equations, which can be for example mass balance equations for phases, mass balance equations for components or energy balance equations. In contrast, a decoupled model consists of a pressure equation, which is iteratively coupled to a saturation equation, concentration equations, energy balance equations, etc.
\eWoms provides two sorts of models: Models which use a fully-implicit
discretization in space and time and models that are
semi-implicit.
Examples for different kinds of both, coupled and decoupled models, are isothermal two-phase models, isothermal two-phase two-component models, non-isothermal two-phase models and non-isothermal two-phase two-component models.
The semi-implicit solve the combined mass balance equation for all
phases implicitly -- which yields a pressure -- and then transport the
conserved quantities in an explicit step based on the result of the
(implicit) pressure step. For this reason these models are also called
to be based on the IMPES approach (\textbf{i}mplicit \textbf{p}ressure
\textbf{e}xplicit \textbf{s}aturation) or, more generally, on the
IMPET approach (IMPES (\textbf{i}mplicit \textbf{p}ressure
\textbf{e}xplicit \textbf{t}ransport).
The fully-implicit models, describe the conservation quantities of a
flow system as a system of strongly coupled partial differential
equations. Physically, these conservation quantities are mass,
momentum and energy; Although the momentum is usually not explicitly
conserved in the context of flow models for porous media.
In section \ref{box} a short introduction to the vertex centered
finite volume scheme (VCFV or box method) used by \eWoms as the
spatial discretization of the fully-implicit models is given. The
decoupled models usually employ a cell-centered finite volume scheme
which is quite similar to the VCFV discretization, except that this
scheme does not require to construct a dual grid centered around the
primary grid's vertices.
The following two sections of the tutorial first introduce how to
solve flow problems using a fully-coupled model (section
\ref{tutorial-coupled}) and then how to solve the same problem using a
semi-implicit model (section \ref{tutorial-decoupled}). Being the
easiest case, an isothermal two-phase system (two fluid phases, one
solid phase) will be considered. The source code of these tutorials is
shipped with the \eWoms source package and can be found in the
\texttt{tutorial} directory.
In section \ref{box} a short introduction to the box method is given. The box method is used in the fully-coupled models for the spatial discretization of the system of equations. The decoupled models employ usually a cell-centered finite volume scheme. The following two sections of the tutorial demonstrate how to solve problems using, first, a fully-coupled model (section \ref{tutorial-coupled}) and, second, using a decoupled model (section \ref{tutorial-decoupled}). Being the easiest case, an isothermal two-phase system (two fluid phases, one solid phase) will be considered.
\input{tutorial-coupled}
\input{tutorial-decoupled}
%\input{tutorial-newmodel}

124
examples/tutorialproblem_coupled.hh
View File

@@ -20,7 +20,7 @@
/*!
* \file
*
* \brief Tutorial problem for a fully coupled twophase box model.
* \copydoc Dumux::TutorialProblemCoupled
*/
#ifndef DUMUX_TUTORIAL_PROBLEM_COUPLED_HH // guardian macro /*@\label{tutorial-coupled:guardian1}@*/
#define DUMUX_TUTORIAL_PROBLEM_COUPLED_HH // guardian macro /*@\label{tutorial-coupled:guardian2}@*/
@@ -37,12 +37,11 @@
#include <dumux/material/fluidmatrixinteractions/2p/efftoabslaw.hh>
#include <dumux/material/fluidmatrixinteractions/mp/2padapter.hh>
// The DUNE grid used
// For the DUNE grid
#include <dune/grid/yaspgrid.hh>
#include <dumux/common/cubegridcreator.hh>
#include <dumux/common/cubegridcreator.hh> /*@\label{tutorial-coupled:include-grid-creator}@*/
// Dune::FieldVector and Dune::FieldMatrix
#include <dune/common/fvector.hh>
// For Dune::FieldMatrix
#include <dune/common/fmatrix.hh>
namespace Dumux {
@@ -63,62 +62,56 @@ SET_PROP(TutorialProblemCoupled, Problem) /*@\label{tutorial-coupled:set-problem
SET_TYPE_PROP(TutorialProblemCoupled, Grid, Dune::YaspGrid</*dim=*/2>); /*@\label{tutorial-coupled:set-grid}@*/
SET_TYPE_PROP(TutorialProblemCoupled, GridCreator, Dumux::CubeGridCreator<TypeTag>); /*@\label{tutorial-coupled:set-gridcreator}@*/
// Set the wetting phase
SET_PROP(TutorialProblemCoupled, WettingPhase) /*@\label{tutorial-coupled:2p-system-start}@*/
{
private: typedef typename GET_PROP_TYPE(TypeTag, Scalar) Scalar;
public: typedef Dumux::LiquidPhase<Scalar, Dumux::H2O<Scalar> > type; /*@\label{tutorial-coupled:wettingPhase}@*/
};
// Set the wetting phase /*@\label{tutorial-coupled:2p-system-start}@*/
SET_TYPE_PROP(TutorialProblemCoupled, WettingPhase, /*@\label{tutorial-coupled:wettingPhase}@*/
Dumux::LiquidPhase<typename GET_PROP_TYPE(TypeTag, Scalar), Dumux::H2O<Scalar> >);
// Set the non-wetting phase
SET_PROP(TutorialProblemCoupled, NonwettingPhase)
{
private: typedef typename GET_PROP_TYPE(TypeTag, Scalar) Scalar;
public: typedef Dumux::LiquidPhase<Scalar, Dumux::LNAPL<Scalar> > type; /*@\label{tutorial-coupled:nonwettingPhase}@*/
}; /*@\label{tutorial-coupled:2p-system-end}@*/
SET_TYPE_PROP(TutorialProblemCoupled, NonwettingPhase, /*@\label{tutorial-coupled:nonwettingPhase}@*/
Dumux::LiquidPhase<typename GET_PROP_TYPE(TypeTag, Scalar), Dumux::LNAPL<Scalar> >); /*@\label{tutorial-coupled:2p-system-end}@*/
// Set the material law
SET_PROP(TutorialProblemCoupled, MaterialLaw)
{
private:
// material law typedefs
// Retrieve the C++ type used to represent scalar values
typedef typename GET_PROP_TYPE(TypeTag, Scalar) Scalar;
// select material law to be used
// Select the base material law to be used
typedef RegularizedBrooksCorey<Scalar> RawMaterialLaw; /*@\label{tutorial-coupled:rawlaw}@*/
// adapter for absolute law
// Converts absolute saturations into effective ones before
// passing it to the base material law
typedef EffToAbsLaw<RawMaterialLaw> TwoPMaterialLaw; /*@\label{tutorial-coupled:eff2abs}@*/
// Retrieve the index of the wetting phase
typedef typename GET_PROP_TYPE(TypeTag, FluidSystem) FluidSystem;
enum { wPhaseIdx = FluidSystem::wPhaseIdx };
public:
// Convert two-phase material law into a general M-phase one.
typedef TwoPAdapter<wPhaseIdx, TwoPMaterialLaw> type;
};
// Disable gravity
SET_BOOL_PROP(TutorialProblemCoupled, EnableGravity, false); /*@\label{tutorial-coupled:gravity}@*/
// define how long the simulation should run [s]
// define how long the simulation should run [s] /*@\label{tutorial-coupled:default-params-begin}@*/
SET_SCALAR_PROP(TutorialProblemCoupled, EndTime, 100e3);
// define the size of the initial time step [s]
SET_SCALAR_PROP(TutorialProblemCoupled, InitialTimeStepSize, 500.0);
// define the properties required by the cube grid creator
// define the physical size of the problem's domain [m]
SET_SCALAR_PROP(TutorialProblemCoupled, DomainSizeX, 300.0);
SET_SCALAR_PROP(TutorialProblemCoupled, DomainSizeY, 60.0);
SET_SCALAR_PROP(TutorialProblemCoupled, DomainSizeZ, 0.0);
// // define the number of cells used for discretizing the physical domain
SET_INT_PROP(TutorialProblemCoupled, CellsX, 100);
SET_INT_PROP(TutorialProblemCoupled, CellsY, 1);
SET_INT_PROP(TutorialProblemCoupled, CellsZ, 0);
}
SET_INT_PROP(TutorialProblemCoupled, CellsZ, 1); /*@\label{tutorial-coupled:default-params-end}@*/
} // namespace Properties
/*!
* \ingroup TwoPBoxModel
*
* \brief Tutorial problem for a fully coupled twophase box model.
*/
//! Tutorial problem using the fully-implicit immiscible model.
template <class TypeTag>
class TutorialProblemCoupled
: public GET_PROP_TYPE(TypeTag, BaseProblem) /*@\label{tutorial-coupled:def-problem}@*/
@@ -130,21 +123,17 @@ class TutorialProblemCoupled
// Grid dimension
enum { dimWorld = GridView::dimensionworld };
typedef typename GridView::ctype CoordScalar;
typedef Dune::FieldVector<CoordScalar, dimWorld> GlobalPosition;
// The type of the intrinsic permeability tensor
typedef Dune::FieldMatrix<Scalar, dimWorld, dimWorld> DimMatrix;
// Dumux specific types
// eWoms specific types are specified via the property system
typedef typename GET_PROP_TYPE(TypeTag, TimeManager) TimeManager;
typedef typename GET_PROP_TYPE(TypeTag, PrimaryVariables) PrimaryVariables;
typedef typename GET_PROP_TYPE(TypeTag, RateVector) RateVector;
typedef typename GET_PROP_TYPE(TypeTag, BoundaryRateVector) BoundaryRateVector;
typedef typename GET_PROP_TYPE(TypeTag, FluidSystem) FluidSystem;
typedef typename GET_PROP_TYPE(TypeTag, Indices) Indices;
// get material law from property system
typedef typename GET_PROP_TYPE(TypeTag, MaterialLaw) MaterialLaw;
// determine type of the parameter objects depening on selected material law
typedef typename GET_PROP_TYPE(TypeTag, MaterialLawParams) MaterialLawParams; /*@\label{tutorial-coupled:matLawObjectType}@*/
// phase indices
@@ -152,7 +141,7 @@ class TutorialProblemCoupled
enum { wPhaseIdx = FluidSystem::wPhaseIdx };
enum { nPhaseIdx = FluidSystem::nPhaseIdx };
// indices of the conservation equations
// Indices of the conservation equations
enum { contiWEqIdx = Indices::conti0EqIdx + wPhaseIdx };
enum { contiNEqIdx = Indices::conti0EqIdx + nPhaseIdx };
@@ -162,58 +151,39 @@ public:
: ParentType(timeManager, GET_PROP_TYPE(TypeTag, GridCreator)::grid().leafView())
, eps_(3e-6)
{
// set main diagonal entries of the permeability tensor to a value
// setting to a single value means: isotropic, homogeneous
// Use an isotropic and homogeneous intrinsic permeability
K_ = this->toDimMatrix_(1e-7);
//set residual saturations
materialParams_.setSwr(0.0); /*@\label{tutorial-coupled:setLawParams}@*/
materialParams_.setSnr(0.0);
// Parameters of the Brooks-Corey law
materialParams_.setPe(500.0); // entry pressure [Pa] /*@\label{tutorial-coupled:setLawParams}@*/
materialParams_.setLambda(2); // shape parameter
//parameters of Brooks & Corey Law
materialParams_.setPe(500.0);
materialParams_.setLambda(2);
// Set the residual saturations
materialParams_.setSwr(0.0);
materialParams_.setSnr(0.0);
}
//! Specifies the problem name. This is used as a prefix for files
//! generated by the simulation.
//! Specifies the problem name. This is used for files generated by the simulation.
const char *name() const
{ return "tutorial_coupled"; }
//! Returns true if a restart file should be written.
bool shouldWriteRestartFile() const /*@\label{tutorial-coupled:restart}@*/
{ return false; }
//! Returns true if the current solution should be written to disk
//! as a VTK file
bool shouldWriteOutput() const /*@\label{tutorial-coupled:output}@*/
{
return (this->timeManager().timeStepIndex() % 5 == 0) ||
this->timeManager().willBeFinished() ;
}
//! Returns the temperature within a finite volume. We use constant
//! 10 degrees Celsius.
//! Returns the temperature at a given position.
template <class Context>
Scalar temperature(const Context &context, int spaceIdx, int timeIdx) const
{ return 283.15; }
//! Returns the intrinsic permeability tensor K \f$[m^2]\f$
//! depending on the position in the domain.
//! Returns the intrinsic permeability tensor [m^2] at a position.
template <class Context>
const DimMatrix &intrinsicPermeability(const Context &context, /*@\label{tutorial-coupled:permeability}@*/
int spaceIdx, int timeIdx) const
{ return K_; }
//! Defines the porosity \f$[-]\f$ of the porous medium depending
//! on the position in the domain.
//! Defines the porosity [-] of the medium at a given position
template <class Context>
Scalar porosity(const Context &context, /*@\label{tutorial-coupled:porosity}@*/
int spaceIdx, int timeIdx) const
Scalar porosity(const Context &context, int spaceIdx, int timeIdx) const /*@\label{tutorial-coupled:porosity}@*/
{ return 0.2; }
//! Returns the parameter object for the material law (i.e. Brooks-Corey)
//! depending on the position in the domain
//! Returns the parameter object for the material law at a given position
template <class Context>
const MaterialLawParams& materialLawParams(const Context &context, /*@\label{tutorial-coupled:matLawParams}@*/
int spaceIdx, int timeIdx) const
@@ -224,13 +194,13 @@ public:
void boundary(BoundaryRateVector &values,
const Context &context, int spaceIdx, int timeIdx) const
{
const GlobalPosition &pos = context.pos(spaceIdx, timeIdx);
const auto &pos = context.pos(spaceIdx, timeIdx);
if (pos[0] < eps_) {
// Free-flow conditions on left boundary
const auto &materialParams = this->materialLawParams(context, spaceIdx, timeIdx);
Scalar Sw = 1.0;
ImmiscibleFluidState<Scalar, FluidSystem> fs;
Scalar Sw = 1.0;
fs.setSaturation(wPhaseIdx, Sw);
fs.setSaturation(nPhaseIdx, 1.0 - Sw);
fs.setTemperature(temperature(context, spaceIdx, timeIdx));
@@ -255,19 +225,19 @@ public:
values.setNoFlow();
}
//! Evaluates the source term for all conserved quantities at a
//! given position in the pysical domain [(m^3 * s)]. Positive
//! values mean that mass is created.
//! Evaluates the source term for all conserved quantities at a given position
//! of the domain [kg/(m^3 * s)]. Positive values mean that mass is created.
template <class Context>
void source(RateVector &values, const Context &context, int spaceIdx, int timeIdx) const
void source(RateVector &source, const Context &context, int spaceIdx, int timeIdx) const
{
values[contiWEqIdx] = 0.0;
values[contiNEqIdx]= 0.0;
source[contiWEqIdx] = 0.0;
source[contiNEqIdx] = 0.0;
}
//! Evaluates the initial value at a given position in the domain.
template <class Context>
void initial(PrimaryVariables &values, const Context &context, int spaceIdx, int timeIdx) const
void initial(PrimaryVariables &values,
const Context &context, int spaceIdx, int timeIdx) const
{
ImmiscibleFluidState<Scalar, FluidSystem> fs;
@@ -296,6 +266,6 @@ private:
// small epsilon value
Scalar eps_;
};
}
} // namespace Dumux
#endif