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{theorem}
\usepackage{color} \usepackage{color}
\usepackage{listings} \usepackage{listings}
\definecolor{bashgray}{gray}{0.92}
\definecolor{cppgray}{gray}{0.95}
\lstset{language=C++, basicstyle=\ttfamily, \lstset{language=C++, basicstyle=\ttfamily,
keywordstyle=\color{black}\bfseries, tabsize=4, stringstyle=\ttfamily, keywordstyle=\color{black}\bfseries, tabsize=4, stringstyle=\ttfamily,
commentstyle=\it, extendedchars=true, escapeinside={/*@}{@*/}} commentstyle=\it, extendedchars=true, escapeinside={/*@}{@*/}}
@@ -15,14 +19,14 @@
% for listings of bash code in install.tex % for listings of bash code in install.tex
\lstdefinestyle{Bash} \lstdefinestyle{Bash}
{language=Bash, {language=Bash,
backgroundcolor=\color{lightgray}, backgroundcolor=\color{bashgray},
basicstyle=\ttfamily\small, basicstyle=\ttfamily\small,
numbers=none, numbers=none,
captionpos=b, captionpos=b,
tabsize=4, tabsize=4,
breaklines=true, breaklines=true,
frame=single, frame=single,
rulecolor=\color{lightgray}, rulecolor=\color{bashgray},
framerule=1pt, framerule=1pt,
framesep=1pt, framesep=1pt,
rulesep=0pt, rulesep=0pt,
@@ -33,6 +37,8 @@
\lstdefinestyle{eWomsCode} \lstdefinestyle{eWomsCode}
{language=C++, {language=C++,
basicstyle=\ttfamily\scriptsize, basicstyle=\ttfamily\scriptsize,
backgroundcolor=\color{bashgray},
rulecolor=\color{bashgray},
numbers=left, numbers=left,
numberstyle=\tiny, numberstyle=\tiny,
numbersep=5pt, numbersep=5pt,
@@ -159,16 +165,26 @@
\tableofcontents \tableofcontents
\part{Getting Familiar}
\input{intro} \input{intro}
\input{getting-started} \input{getting-started}
\input{tutorial} \input{tutorial}
\input{structure}
\part{Concepts and Software Architecture}
\input{designpatterns} \input{designpatterns}
\input{propertysystem} \input{propertysystem}
\input{fluidframework} \input{fluidframework}
\input{models}
\input{NewtonInANutshell} \part{Guides}
\input{structure}
\input{install} \input{install}
\input{guidelines}
\input{new-folder}
\input{newton-in-a-nutshell}
\input{models}
\bibliographystyle{plain} \bibliographystyle{plain}
\bibliography{ewoms-handbook} \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. This chapter is aimed at setting up a development environment for
Then a quick start guide for the first \Dumux experience is provided. \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{quick-install}
\input{quickstart-guide} \input{quickstart-guide}
\input{parameterTree} \input{parameters}
%%% Local Variables: %%% Local Variables:
%%% mode: latex %%% 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} \subsubsection{The non-isothermal two-component Stokes model: Stokes2cniModel}
\input{ModelDescriptions/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). 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. 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} \paragraph{Saturation model}
\input{ModelDescriptions/2pdecoupledsaturationmodel} \input{ModelDescriptions/2pdecoupledsaturationmodel}
%\subsubsection{The two-phase, two-component model}\label{ch:2p2c_decoupled} \subsubsection{The two-phase, two-component model}\label{ch:2p2c_decoupled}
%\input{ModelDescriptions/decoupled2p2c} \input{ModelDescriptions/2p2cdecoupledpressuremodel}
\input{ModelDescriptions/2p2cdecoupledtransportmodel}
%%% Local Variables: %%% Local Variables:
%%% mode: latex %%% 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} \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} \begin{align}
\underbrace{ \underbrace{
\phi \frac{\partial \varrho_\alpha S_\alpha}{\partial t} \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!). 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. 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} \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 level overview over its design and principle ideas is given, then
follows a short reference and a short self-contained example. 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 problems of traits classes. In fact, it can be seen as a traits system
which allows easy inheritance and any acyclic dependency of parameter 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 time mechanism, which means that there are no run-time performance
penalties associated with it. It is based on the following concepts: penalties associated with it. It is based on the following concepts:
\begin{description} \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 property is an arbitrary class body which may contain type
definitions, values and methods. Each property has a so-called definitions, values and methods. Each property has a so-called
\textbf{property tag} which can be seen as a label with its name. \textbf{property tag} which can be seen as a label with its name.
\item[Property Inheritance:] Just like normal classes, properties can \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 system, nodes of the inheritance hierarchy are called \textbf{type
tags}. tags}.
\end{description} \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 which can be used to find out where a certain property was defined and
how it was inherited. 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/ the header file \texttt{dumux/ \hskip-1ex{}common/
\hskip-1ex{}propertysystem.hh}. Declaration of type tags and \hskip-1ex{}propertysystem.hh}. Declaration of type tags and
property tags as well as defining properties must be done inside the property tags as well as defining properties must be done inside the
namespace \texttt{Dumux::Properties}. namespace \texttt{Dumux::Properties}.
\subsection*{Defining Type Tags} \subsection*{Defining type tags}
New nodes in the type tag hierarchy can be defined using New nodes in the type tag hierarchy can be defined using
\begin{lstlisting}[style=eWomsCode] \begin{lstlisting}[style=eWomsCode]
@@ -62,7 +62,7 @@ NEW_TYPE_TAG(MyDerivedTypeTag, INHERITS_FROM(MyBaseTypeTag1, MyBaseTypeTag2));
}} }}
\end{lstlisting} \end{lstlisting}
\subsection*{Declaring Property Tags} \subsection*{Declaring property tags}
New property tags -- i.e. labels for properties -- are declared New property tags -- i.e. labels for properties -- are declared
using using
@@ -82,7 +82,7 @@ NEW_PROP_TAG(MyPropertyTag);
}} }}
\end{lstlisting} \end{lstlisting}
\subsection*{Defining Properties} \subsection*{Defining properties}
The value of a property on a given node of the type tag hierarchy is The value of a property on a given node of the type tag hierarchy is
defined using defined using
@@ -130,7 +130,7 @@ SET_SCALAR_PROP(MyTypeTag, MyScalarValue, 12345.67890);
}} }}
\end{lstlisting} \end{lstlisting}
\subsection*{Un-setting Properties} \subsection*{Un-setting properties}
Sometimes some inherited properties do not make sense for a certain Sometimes some inherited properties do not make sense for a certain
node in the type tag hierarchy. These properties can be explicitly node in the type tag hierarchy. These properties can be explicitly
@@ -158,15 +158,14 @@ UNSET_PROP(DerivedTypeTag, TestProp);
}} }}
\end{lstlisting} \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 For the \Cplusplus compiler, type tags are like ordinary types. Both
types. Both can thus be used as template arguments. To convert a can thus be used as template arguments. To convert a type tag name
property tag name or a type tag name into the corresponding type, the into the corresponding type, the macro \texttt{TTAG(TypeTagName)}
macros \texttt{TTAG(TypeTagName)} and \texttt{PTAG(PropertyTagName)}
ought to be used. ought to be used.
\subsection*{Retrieving Property Values} \subsection*{Retrieving property values}
The value of a property can be retrieved using The value of a property can be retrieved using
\begin{lstlisting}[style=eWomsCode] \begin{lstlisting}[style=eWomsCode]
@@ -209,7 +208,7 @@ class MyClass {
}; };
\end{lstlisting} \end{lstlisting}
\subsection*{Nesting Property Definitions} \subsection*{Nesting property definitions}
Inside property definitions there is access to all other properties Inside property definitions there is access to all other properties
which are defined somewhere on the type tag hierarchy. The node for which are defined somewhere on the type tag hierarchy. The node for
@@ -228,7 +227,7 @@ public: typedef std::vector<Scalar> type;
\end{lstlisting} \end{lstlisting}
\section{A Self-Contained Example} \section{A self-contained example}
As a concrete example, let us consider some kinds of cars: Compact As a concrete example, let us consider some kinds of cars: Compact
cars, sedans, trucks, pickups, military tanks and the Hummer-H1 sports 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).} which make sense for at least one of the car types of (a).}
\end{figure} \end{figure}
Using the \Dumux property system, this inheritance hierarchy is Using the \eWoms property system, this inheritance hierarchy is
defined by: defined by:
\begin{lstlisting}[name=propsyscars,style=eWomsCode] \begin{lstlisting}[name=propsyscars,style=eWomsCode]
#include <dumux/common/propertysystem.hh> #include <dumux/common/propertysystem.hh>
@@ -309,7 +308,7 @@ the following:
\end{itemize} \end{itemize}
\noindent \noindent
Using the \Dumux property system, these assumptions are formulated Using the \eWoms property system, these assumptions are formulated
using using
\begin{lstlisting}[name=propsyscars,style=eWomsCode] \begin{lstlisting}[name=propsyscars,style=eWomsCode]
SET_INT_PROP(CompactCar, TopSpeed, GET_PROP_VALUE(TypeTag, GasUsage) * 30); 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 This section describes a way of installing \eWoms that works in most
pre-requisite it is assumed that you are using \eWoms with a recent cases, but depending on your operating system of choice, \Cplusplus
Linux distribution that has the appropriate development packages compiler and features which you need, some tweaks are possibly. As a
installed, but without the distribution packages of the \Dune core pre-requisite it is assumed, that you are using a recent Linux
modules installed. If you need more information, or if you have \Dune 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 already installed, please have a look at the detailed installation
instructions in Section \ref{install}. 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 unpacking the tarball for the \eWoms 2.2 release, or by retrieving the
code directly from their respective source-code repositories. If you code directly from their respective source-code repositories. If you
decide to use the first method, make sure to unpack all tarballs into 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 the same directory; if you prefer the second method, make sure that
code snipplet into a terminal: 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] \begin{lstlisting}[style=Bash]
cd $YOUR_DUNE_ROOT_DIRECTORY
for DUNE_MODULE in common geometry grid istl localfunctions; do \ 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 \ git svn clone https://svn.dune-project.org/svn/dune-$DUNE_MODULE/branches/release-2.2 $DUNE_MODULE \
done done
git clone --branch "release-2.2" git://github.com/OPM/ewoms.git git clone --branch "release-2.2" git://github.com/OPM/ewoms.git
\end{lstlisting} \end{lstlisting}
%$
\subsection{Building \Dune and \eWoms} \subsection{Building \Dune and \eWoms}
\label{buildIt} \label{buildIt}
\eWoms is (almost) a standard \Dune module and is recommended to be \eWoms is \Dune module and is recommended to build it using the \Dune
build using the \Dune build system~\cite{DUNE-BS}. \eWoms ships with a build system~\cite{DUNE-BS}. To simplify things, \eWoms ships with a
few option files for \Dune's build script, \texttt{dunecontrol}. For few option files for \Dune's build script, \texttt{dunecontrol}. If
the first time compilation we recommend to use the options optimized you are using \eWoms the first time, we recommend to use the one
for the debugging experience, \texttt{debug.opts}: optimized for the debugging experience, \texttt{debug.opts}:
\begin{lstlisting}[style=Bash] \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 ./dune-common/bin/dunecontrol --opts=ewoms/debug.opts all
\end{lstlisting} \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 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] \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 ./dune-common/bin/dunecontrol --opts=ewoms/optim.opts all
\end{lstlisting} \end{lstlisting}
%$
Sometimes it is necessary to have additional options which are Sometimes it is necessary to have additional options which are
specific to the concrete operating system you use or you might also specific to the operating system of your choice, or if you have
have special needs. For this reason, the option files mentioned above special requirements. For this reason, the option files mentioned
are to be rather understood as a starting point for specifying the own above should be rather understood as a starting point for your own
options than as something which is fixed; feel free to copy and modify option files than as something fixed; feel free to copy and modify
them. For example, if you need external libraries, you might need to them. To avoid confusion, it is usually helpful to rename your
add or modify quite many options. To avoid confusion, it can also be customized option files, though.
helpful to use a different name for your customized option files.
%%% Local Variables: %%% Local Variables:
%%% mode: latex %%% 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} \label{quick-start-guide}
The previous section showed how to install and compile \eWoms. This 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{figure}
\end{landscape} \end{landscape}
\input{guidelines}
\input{newFolder}
%%% Local Variables: %%% Local Variables:
%%% mode: latex %%% mode: latex
%%% TeX-master: "ewoms-handbook" %%% TeX-master: "ewoms-handbook"

753
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} \begin{enumerate}
\item A suitable model has to be chosen. \item A suitable model has to be chosen.
\item The geometry of the problem and correspondingly a grid have to be defined. \item The geometry of the problem and correspondingly a grid have to
\item Material properties and constitutive relationships have to be selected. be defined.
\item Boundary conditions and initial conditions have to be specified. \item Boundary and initial conditions and material properties have to be
selected.
\end{enumerate} \end{enumerate}
The problem being solved in this tutorial is illustrated in Figure \ref{tutorial-coupled:problemfigure}. The physical set-up of the flow problem being solved in this tutorial
A rectangular domain with no-flow boundaries on the top and on the bottom, which is initially saturated with oil, is considered. is illustrated in Figure \ref{tutorial-coupled:problemfigure}: It
Water infiltrates from the left side into the domain and replaces the oil. Gravity effects are neglected here. 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] \begin{figure}[ht]
\psfrag{x}{x} \psfrag{x}{x}
@@ -49,295 +56,207 @@ The solved equations are the mass balances of water and oil:
0 0
\end{align} \end{align}
\subsection{The Main File} \subsection{The main source file}
Listing \ref{tutorial-coupled:mainfile} shows the main application file Listing \ref{tutorial-coupled:mainfile} shows the main application
\texttt{tutorial/tutorial\_coupled.cc} for the coupled two-phase file \texttt{tutorial/tutorial\_coupled.cc} uses the fully implicit
model. This file has to be compiled and executed in order to solve the problem described model that assumes immiscibility. This file has to be compiled and
above. executed in order to solve the problem described above.
\begin{lst}[File tutorial/tutorial\_coupled.cc]\label{tutorial-coupled:mainfile} \mbox{} \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} \end{lst}
From line \ref{tutorial-coupled:include-begin} to line In \eWoms, this file is usually quite short, as most of the work for
\ref{tutorial-coupled:include-end} the required headers are included. 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 The default \eWoms startup routine deals with parsing the command line
problem, which is going to be simulated, is specified. All other data arguments, reading the parameter file, properly setting up the \Dune
types can be retrieved via the \Dumux property system and only depend infrastructure, creating the grid, and starting the actual simulation.
on this single type tag. For a more thorough introduction to the Required parameters for the start of the simulation, such as the
\Dumux property system, see chapter~\ref{sec:propertysystem}. initial time-step size, the simulation time or details of the grid,
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,
can be either specified by command line arguments of the form can be either specified by command line arguments of the form
(\texttt{-ParameterName ParameterValue}), in the file specified by the (\texttt{--parameter-name=value}), in the file specified by the
\texttt{-ParameterFile} argument, or if the latter is not specified, \texttt{--parameter-file="file\_name"} argument. A list of all
in the file \mbox{\texttt{tutorial\_coupled.input}}. recognized parameters that can be specified at run time can be printed
If a parameter is by passing the \texttt{--help} argument to the exectutable of the
specified on the command line as well as in the parameter file, the simulation.
values provided in the command line have
precedence. Listing~\ref{tutorial-coupled:parameter-file} shows the
default parameter file for the tutorial problem.
%\begin{lst}[File tutorial/tutorial\_coupled.input]\label{tutorial-coupled:parameter-file} \mbox{} \subsection{The problem file}
%\lstinputlisting[style=eWomsCode]{../../tutorial/tutorial_coupled.input}
%\end{lst}
To provide an error message, the usage message which is displayed to When solving a problem using \eWoms, the most important file is the
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
so-called \textit{problem file} as shown in so-called \textit{problem file} as shown in
listing~\ref{tutorial-coupled:problemfile}. listing~\ref{tutorial-coupled:problemfile}.
\begin{lst}[File tutorial/tutorialproblem\_coupled.hh]\label{tutorial-coupled:problemfile} \mbox{} \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} \end{lst}
First, a new type tag is created for the problem in line This file specifies everything that is related to the physical
\ref{tutorial-coupled:create-type-tag}. In this case, the new type problem. It first sets up the properties relevant for this problem
tag inherits all properties from the \texttt{BoxTwoP} type tag, which using the \eWoms property system (for more information see chapter
means that for this problem the two-phase box model is chosen as \ref{sec:propertysystem})
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
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} \begin{itemize}
\item A method \texttt{boundaryTypes()} specifying the type of \item First, a new type tag is created for the problem in line
boundary conditions at each vertex. \ref{tutorial-coupled:create-type-tag}. In this case, the new type
\item A method \texttt{dirichlet()} specifying the actual values for tag inherits all properties from the \texttt{BoxTwoP} type tag, which
the \textsc{Dirichlet} conditions at each \textsc{Dirichlet} vertex. means that for this problem the two-phase box model is chosen as
\item A method \texttt{neumann()} specifying the actual values for discretization scheme.
the \textsc{Neumann} conditions, which are usually evaluated at the \item On line \ref{tutorial-coupled:set-problem}, a problem class is
integration points of the \textsc{Neumann} boundary faces. specified for the new type tag, while the grid which is going to be
\item A method for source or sink terms called \texttt{source()}, usually evaluated at used is defined in line \ref{tutorial-coupled:set-grid} -- in this
the center of a control volume. case that is \texttt{Dune::YaspGrid}.
\item A method called \texttt{initial()} for specifying the initial \item Since there's no uniform mechanism to allocate grids in \Dune,
conditions at each vertex. \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.
\end{itemize} \end{itemize}
For the definition of the the boundary condition types and of the Next, an appropriate fluid system -- which specifies the thermodynamic
values of the \textsc{Dirichlet} boundaries, two parameters are relations of the fluid phases -- has to be chosen. By default, the
available: fully-implicit immiscible model uses the
\begin{description} \texttt{TwoPImmiscibleFluidSystem}. This fluid system simplifies
\item [values:] A vector which stores the result of the method. What things considerably by assuming immiscibility of the phases, but it
the values in this vector mean is dependent on the method: For requires to explicitly specify the fluids used for the wetting and
\texttt{dirichlet()} it contains the actual values of the primary non-wetting phases. In this case, liquid water based on the relations
variables, for \texttt{boundaryTypes()} it contains the boundary from IAPWS'97~\cite{IAPWS1997} is chosen as the wetting phase on line
condition types. It has as many entries as the model has primary variables / equations. \ref{tutorial-coupled:wettingPhase} and liquid oil is chosen as the
For the typical case, in which all equations have the same boundary non-wetting phase on line \ref{tutorial-coupled:nonwettingPhase}. The
condition type at a certain position, there are two methods that set the appropriate conditions next property, which is set in line \ref{tutorial-coupled:gravity},
for all primary variables / equations: \texttt{setAllDirichlet()} and \texttt{setAllNeumann()}. tells the model not to use gravity. This is then followed by the
\item [vertex:] The boundary condition and the Dirichlet values are specifcation default values for parameters specifying the temporal and
specified for a vertex, which represents a control volume in the box spatial domain from line \ref{tutorial-coupled:default-params-begin}
discretization. This avoids the specification of two different to line \ref{tutorial-coupled:default-params-end}. The values of thos
boundary condition types for one equation at different control can be overwritten at run-time if desired.
volumes. Be aware that the second parameter is a Dune grid entity
with the codimension \texttt{dim}.
\end{description}
To ensure that no boundaries are undefined, a small safeguard value Following the property definition is the definition actual physical
\texttt{eps\_} is usually added when comparing spatial set-up to be simulated. This is done by means of the \textit{problem
coordinates. The left boundary is hence not detected by checking, if the class}. The problem class specifies boundary and initial conditions,
first coordinate of the global position is equal to zero, but by testing whether it is source terms or spatial quantities like temperature, porosity,
smaller than a very small value \texttt{eps\_}. 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 For isothermal multi-phase porous media models, problem class must always provide at least
(such as \texttt{neumann()}) are called with six arguments: the following methods:
\begin{description} \begin{itemize}
\item[values:] A vector \texttt{neumann()}, in which the mass fluxes per area unit \item \texttt{initial()} for specifying the initial condition within
over the boundary segment are specified. the domain.
\item[element:] The element of the grid where the boundary segment \item \texttt{source()} specifying the source term for each conservation quantity.
is located. \item \texttt{boundary()} specifying the conditions which apply on the domain boundary.
\item[fvElementGeometry:] The finite-volume geometry induced on the \item \texttt{temperature()} specifying temperature at a given time
finite element by the box scheme. and at a given position of the domain. If energy is conserved, this
\item[isIt:] The \texttt{Intersection} of the boundary segment as given by the grid. method is not necessary, but energy fluxes must be provided in the
\item[scvIdx:] The index of the sub-control volume in \texttt{boundary()} and \texttt{source()} methods and an initial
\texttt{fvElementGeometry} which is assigned to the boundary segment. temperature needs to be defined in the \texttt{initial()} method.
\item[boundaryFaceIdx:] The index of the boundary face in \item \texttt{intrinsicPermeability()} returns the intrinsic
\texttt{fvElementGeometry} which represents the boundary segment. permeability matrix $\mathbf{K}$ in $[m^2]$ at a given location.
\end{description} \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 All of these methods take a single template argument,
specify properties of control volumes and thus only get \texttt{Context}, and the three function arguments \texttt{context},
\texttt{values}, \texttt{element}, \texttt{fvGeometry} and \texttt{spaceIdx} and \texttt{timeIdx}. Together these form the
\texttt{scvIdx} as arguments. \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 The execution contexts for the \texttt{source} and \texttt{boundary}
methods. If the isothermal two-phase model is used, this includes for methods provide the following methods in addition:
example a \texttt{temperature()} method which returns the temperature \begin{itemize}
in \textsc{Kelvin} of the fluids and the rock matrix in the \item \texttt{volVars(spaceIdx, timeIdx)}: The secondary variables
domain. This temperature is then used by the model to calculate fluid used by the model relevant for the execution context. These are
properties which possibly depend on it, e.g. density. The useful to specify solution dependent source and boundary terms.
\texttt{bboxMax()} (``\textbf{max}imum coordinated of the grid's \item \texttt{primaryVars(spaceIdx, timeIdx)}: The vector of primary
\textbf{b}ounding \textbf{b}ox'') method is used here to variables to which the model solves for.
determine the extend of the physical domain. It returns a vector with the \end{itemize}
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>}.
\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 When specifying the boundary conditions in the problem class, a small
used out of the box. The properties of the pure substances (such as 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 the components nitrogen, water, or the pseudo-component air) are
provided by header files located in the folder 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 When two or more components are considered, interactions between pure
interactions such as solubility effects come into play and properties substances become relevant and properties of these mixtures of
of mixtures such as density or enthalpy are of interest. These substances -- e.g. composition, density or enthalpy -- are of
interactions are defined by {\em fluid systems}, which are located in interest. Such interactions are defined by {\em fluid systems}, which
\verb+dumux/material/fluidsystems+. A more thorough overview of the are located in \texttt{dumux/material/fluidsystems}. A more thorough
\Dumux fluid framework can be found in chapter~\ref{sec:fluidframework}. overview of the \eWoms 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+.
\subsection{Exercises} \subsection{Exercises}
\label{tutorial-coupled:exercises} \label{tutorial-coupled:exercises}
The following exercises will give you the opportunity to learn how you The following exercises will give you the opportunity to learn how you
can change soil parameters, boundary conditions, run-time parameters can change soil parameters, boundary conditions, run-time parameters
and fluid properties in \Dumux. and fluid properties in \eWoms.
\subsubsection{Exercise 1} \subsubsection{Exercise 1}
\renewcommand{\labelenumi}{\alph{enumi})} For Exercise 1 you have \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 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}. the coupled tutorial model by typing \texttt{./tutorial\_coupled}.
Note, that the time-step size is automatically adapted during the simulation. 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} \\
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\
Change the size of the model domain so that you get a rectangle with 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 edge lengths of $\text{x} = \unit[400]{m}$ and $\text{y} =
discretization lengths of $\Delta \text{x} = \unit[20]{m}$ and $\Delta \unit[500]{m}$ and with discretization lengths of $\Delta \text{x} =
\text{y} = \unit[20]{m}$. For this you have to edit the parameter file (\texttt{tutorialproblem\_coupled.input}) \unit[20]{m}$ and $\Delta \text{y} = \unit[20]{m}$. For this you can
and run the program again.\\ either change the properties defined between lines
Note, that you do not have to recompile the program if you make changes to the parameter file. \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 Change the boundary conditions in the file
\texttt{tutorialproblem\_coupled.hh} so that water enters from the \texttt{tutorialproblem\_coupled.hh} so that water enters from the
bottom and oil is extracted from the top boundary. The right and the bottom and oil is extracted from the top boundary. The right and the
left boundary should be closed for water and oil fluxes. \\ 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.
\item \textbf{Changing the Shape of the Discrete Elements} \\ Note that in \eWoms, flux boundary conditions are specified as
In order to complete this exercise you need a grid module capable of handling fluxes of the conserved quantities into the direction of the outer
simplex grids, like \texttt{ALUSimplexGrid}. If this is not the case please skip this exercise. normal per area. This means a mass flux into the domain is negative,
Change the types of elements used for discretizing the domain. In line \ref{tutorial-coupled:set-gridcreator} of the problem a flux out of the domain is always positive. Re-compile the
file the type of gridcreator is chosen. By choosing a different grid creator you can discretize the domain with different elements. simulation by typing \texttt{make tutorial\_coupled} and re-run it
as explained above.
Hint: You can find some pre-defined grid creators in \item \textbf{Changing the Shape of the Discrete Elements} \\
\texttt{dumux/common/}; For this excercise you can change the In order to complete this exercise you need a \Dune grid module that
include statement from \texttt{cubegridcreator.hh} to is capable of handling simplex grids. By default, \Dune does not
\texttt{simplexgridcreator.hh} and the \texttt{GridCreator} property include such a grid manager in its core modules, but one such grid
from \texttt{CubeGridCreator} to \texttt{SimplexGridCreator}. manager that is freely available
\texttt{ALUGrid}~\cite{ALUGRID-HP}. If you did not install such a
grid manager, please skip this exercise.
Besides having to change the grid creator it is also necessary to To complete this excercise, change the problem's grid creator on
change the type of a DUNE grid in line line \ref{tutorial-coupled:set-gridcreator} to
\ref{tutorial-coupled:set-grid} to a grid which supports the types \texttt{SimplexGridCreator<TypeTag>} and the type of the grid to
of elements which the grid creator uses. In this example, you can \texttt{Dune::ALUSimplexGrid<2, 2>} on line
change the \texttt{Grid} property from \texttt{ALUCubeGrid} to \ref{tutorial-coupled:set-grid}. You also need to change the include
\texttt{ALUSimplexGrid}. The resulting grid can be examined by statement from \texttt{cubegridcreator.hh} to
starting the simulation, loading the result in paraview, and \texttt{simplexgridcreator.hh} on line
selecting \texttt{Surface with Edges} as the visualization mode. \ref{tutorial-coupled:include-grid-creator}.
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} \\ \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} \begin{enumerate}
\item Brine: Brine is thermodynamically very similar to pure water but also considers a fixed amount of salt in the liquid phase. \item Brine: Brine is thermodynamically very similar to pure water but
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}. also considers a fixed amount of salt in the liquid phase. Hence,
The class which represents pure water is passed to the class \texttt{Dumux::Brine} calls back to a class which
\texttt{Dumux::Brine} as the second template argument after the data represents pure water. This can be, for example \texttt{Dumux::H2O},
type for scalar values, i.e. the full definition of the brine or \texttt{Dumux::SimpleH2O}. The class which represents pure water
component is \texttt{Dumux::Brine<Scalar, Dumux::H2O>}. The file is passed to \texttt{Dumux::Brine} as the second template argument
which defines the brine component is located in the folder after the data type for scalar values, i.e. the full definition of
\texttt{dumux/material/components/}. the brine component is \texttt{Dumux::Brine<Scalar,
Try to include the file and select the component as the wetting phase via the property system. Dumux::H2O<Scalar> >}. The file which defines the brine component
\item DNAPL: is located in the folder \texttt{dumux/material/components/}.
Now let's include a component representing a DNAPL (\textbf{d}ense \textbf{n}on-\textbf{a}queous \textbf{p}hase \textbf{l}iquid) Include this file and select use the brine component as the wetting phase.
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 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} \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 If you want to take a closer look on how the fluid classes are defined
\texttt{/dumux/material/components} and read chapter~\ref{sec:fluidframework}. 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} \\ \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 \eWoms, the canonical way to describe fluid mixtures is via
In order to include a fluid system, you first have to comment out lines \ref{tutorial-coupled:2p-system-start} \textit{fluid systems}\footnote{For a thorough introduction into
to \ref{tutorial-coupled:2p-system-end} in the problem file.\\ fluid systems and the concepts related to it, see chapter
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}) \ref{sec:fluidframework}}. In order to include a fluid system,
with the appropriate type, which is:\\ you first have to comment out lines
\texttt{Dumux::FluidSystems::H2OAir<typename GET\_PROP\_TYPE(TypeTag, Scalar)>}.\\ \ref{tutorial-coupled:2p-system-start}
However, this is a rather complicated fluid system which to \ref{tutorial-coupled:2p-system-end} in the problem file.\\
considers mixtures of components and also uses tabulated components that need to be initialized -- i.e. the tables need to be filled with values. Now include the file
The initialization of the fluid system is normally done in the constructor of the problem by calling \texttt{GET\_PROP\_TYPE(TypeTag, FluidSystem)::init();}. \texttt{dumux/material/fluidsystems/h2oairfluidsystem.hh}, and
Remember that in \Cplusplus, the constructor always the same name as the respective class, i.e. \texttt{TutorialProblemCoupled(..)}.\\ instruct the model to use this fluid system by setting
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.\\ \texttt{FluidSystem} via:\\
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. \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} \\ \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 Instead of using a regularized Brooks-Corey law for the relative
regularized Brooks-Corey law for the permeability and for the capillary pressure saturation relationship,
relative permeability and for the capillary pressure saturation relationship. To do that you have use an linear material law which does not consider residual
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 saturation. The new material law should exhibit an entry pressure of
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 $p_e = 0.0\;\text{Pa}$ and maximal capillary pressure of
public section. $p_{c_{max}} = 2000.0\;\text{Pa}$. To do that, you have to change
You can find the material laws in the folder the material law property on line
\verb+dumux/material/fluidmatrixinteractions+. The necessary parameters \ref{tutorial-coupled:eff2abs} as follows:
of the linear law and the respective \texttt{set}-functions can be found \begin{itemize}
in the file \\ \item First, switch to the linear material law. This can be achieved
\verb+dumux/material/fluidmatrixinteractions/2p/linearmaterialparams.hh+.\\ by replacing \texttt{RegularizedBrooksCorey} in the private section
Call the \texttt{set}-functions from the constructor of the \texttt{tutorialspatialparams\_coupled.hh}. 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} \\ \item \textbf{Heterogeneities} \\
Set up a model domain with the soil properties given in Figure Set up a model domain with the soil properties given in Figure
\ref{tutorial-coupled:exercise1_d}. Adjust the boundary conditions \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] \begin{figure}[ht]
\psfrag{K1 =}{$\mathbf{K} = 10^{-8}\;\text{m}^2$} \psfrag{K1 =}{$\mathbf{K} = 10^{-8}\;\text{m}^2$}
\psfrag{phi1 =}{$\phi = 0.15$} \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} \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} \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} \end{figure}
domain. You can use the fluids of exercise 1b).\\ 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.\\ \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 When does the front cross the material border? In paraview, the
animation view (\textit{View} $\rightarrow$ \textit{Animation animation view (\textit{View} $\rightarrow$ \textit{Animation View})
View}) is a convenient way to get a rough feeling of the time-step is a convenient way to get a rough feeling of the time-step sizes.
sizes.
\end{enumerate} \end{enumerate}
\subsubsection{Exercise 2} \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 For this exercise, first create a new problem file analogous to the
that relate to the file name, such as 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 \texttt{Ex2TutorialProblemCoupled}. Make sure that you also adjust the
guardian macros in lines \ref{tutorial-coupled:guardian1} and guardian macros in lines \ref{tutorial-coupled:guardian1} and
\ref{tutorial-coupled:guardian1} \ref{tutorial-coupled:guardian1} in the header files (e.g. change
in the header files (e.g. change \mbox{\texttt{DUMUX\_TUTORIALPROBLEM\_COUPLED\_HH}} to
\mbox{\texttt{DUMUX\_TUTORIALPROBLEM\_COUPLED\_HH}} to\\ \mbox{\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_COUPLED\_HH}}). Include the
\mbox{\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_COUPLED\_HH}}). Include the new problem file in \texttt{tutorial\_coupled.cc}. new problem file in \texttt{tutorial\_coupled.cc}. Besides adjusting
Besides adjusting the guardian macros, the new problem file should define and the guardian macros, the new problem file should define and use a new
use a new type tag for the problem as well as a new problem class type tag for the problem as well as a new problem class
e.g. \mbox{\texttt{Ex2TutorialProblemCoupled}}. The type tag for the problem e.g. \mbox{\texttt{Ex2TutorialProblemCoupled}}. The type tag for the
should be adjusted, too. For this, modify line \ref{tutorial-coupled:set-type-tag} problem should be adjusted, too. For this, modify line
in the problem file and the adapt the \texttt{main} function in the \ref{tutorial-coupled:set-type-tag} in the problem file and the adapt
file \texttt{tutorial\_coupled.cc}. the \texttt{main} function in the file \texttt{tutorial\_coupled.cc}.
After this, change the run-time parameters so that they match the After this, change the domain parameters so that they match the domain
domain described by figure \ref{tutorial-coupled:ex2_Domain}. Adapt described by figure \ref{tutorial-coupled:ex2_Domain}. Adapt the
the problem class so that the boundary conditions are consistent with problem class so that the boundary conditions are consistent with
figure \ref{tutorial-coupled:ex2_BC}. Initially, the domain is fully 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 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 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 simulation time should end at $10^6\;\text{s}$ with an initial time
initial time step size of $100\;\text{s}$. 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.
\begin{figure}[ht] \begin{figure}[ht]
\psfrag{K1}{K $= 10^{-7}\;\text{m}^2$} \psfrag{K1}{K $= 10^{-7}\;\text{m}^2$}
@@ -532,39 +502,24 @@ compile the program.
\end{figure} \end{figure}
\begin{itemize} \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 Increase the simulation time to e.g. $4\times 10^7
\item What happens if you increase the resolution of the grid? \;\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} \end{itemize}
\subsubsection{Exercise 3: Parameter File Input} \subsubsection{Exercise 3: Create a New Component}
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}
Create a new file for the benzene component called \texttt{benzene.hh} 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 and implement a new component. (You may copy and modify one of the
existing components in the directory \verb+/dumux/material/components+). \\ existing components located in the directory
Use benzene as a new fluid and run the model of Exercise 2 with water \texttt{dumux/material/components}. Use benzene as a new fluid and
and benzene. Benzene has a density of $889.51 \, \text{kg} / run the model of Exercise 2 with water and benzene. Benzene has a
\text{m}^3$ and a viscosity of $0.00112 \, \text{Pa} \; \text{s}$. density of $889.51 \, \text{kg} / \text{m}^3$ and a viscosity of
$0.00112 \, \text{Pa} \; \text{s}$.
\clearpage \newpage \clearpage \newpage
%%% Local Variables: %%% Local Variables:
%%% mode: latex %%% mode: latex
%%% TeX-master: "ewoms-handbook" %%% 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 setting up the infrastructure necessary for \Dune, loading the grid, and
starting the simulation. All parameters can starting the simulation. All parameters can
be either specified by command line arguments of the form be either specified by command line arguments of the form
(\texttt{-ParameterName ParameterValue}), in the file specified by the (\texttt{--ParameterName=ParameterValue}), in the file specified by the
\texttt{-parameterFile} argument, or if the latter is not specified, \texttt{--ParameterFile=filename.ini} argument. If a parameter is
in the file \texttt{tutorial\_decoupled.input}. If a parameter is
specified on the command line as well as in the parameter file, the specified on the command line as well as in the parameter file, the
values provided in the command line have values provided in the command line have
precedence. Listing~\ref{tutorial-decoupled:parameter-file} shows the precedence.
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}.
\subsection{The problem class} \label{decoupled_problem} \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{} \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} \lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=24, firstnumber=24]{../../tutorial/tutorialspatialparams_decoupled.hh}
\end{lst} \end{lst}
As this file only slightly differs from the coupled version, consult The argument list here is the same as for the problem
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
functions: Either an \texttt{element}, or only the global position if the function is called \texttt{...AtPos(...)}. functions: Either an \texttt{element}, or only the global position if the function is called \texttt{...AtPos(...)}.
\subsection{Exercises} \subsection{Exercises}
@@ -185,7 +168,7 @@ For Exercise 1 you only have to make some small changes in the tutorial files.
\begin{enumerate} \begin{enumerate}
\item \textbf{Altering output} \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. 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} \\ \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} \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-coupled}
\input{tutorial-decoupled} \input{tutorial-decoupled}
%\input{tutorial-newmodel} %\input{tutorial-newmodel}

124
examples/tutorialproblem_coupled.hh
View File

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