diff --git a/doc/handbook/designpatterns.tex b/doc/handbook/designpatterns.tex
index 6ae714b5de14b5a32076cbb653ad1eb265054a6f..4b4116ac2bb20ef61ef9ba4117699caec1f94bee 100644
--- a/doc/handbook/designpatterns.tex
+++ b/doc/handbook/designpatterns.tex
@@ -8,17 +8,17 @@ reader already has basic experience in object oriented programming
with C++.
First, a quick motivation of C++ template programming is given. Then
-follows an introduction to polymorphism and the opportunities for it
+follows an introduction to polymorphism and its opportunities as
opened by the template mechanism. After that, some drawbacks
associated with template programming are discussed, in particular the
-blow-up of identifier names and proliferation of template arguments
+blow-up of identifier names, the proliferation of template arguments
and some approaches on how to deal with these problems.
\section{C++ Template Programming}
One of the main features of modern versions of the C++ programming
language is robust support for templates. Templates are a mechanism
-for code generation build directly into the compiler. For the
+for code generation built directly into the compiler. For the
motivation behind templates, consider a linked list of \texttt{double}
values which could be implemented like this:
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
@@ -41,7 +41,7 @@ only ``clean'' way to achive this without templates would be to copy
\texttt{value} attribute. It is obvious that this is a very
cumbersome, error-prone and unproductive process. For this reason,
recent standards of the C++ programming language specify the template
-mechanism, which is a way to let the compiler do the tedious work. Using
+mechanism, which is a way of letting the compiler do the tedious work. Using
templates, a generic linked list can be implemented like this:
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
template <class ValueType>
@@ -74,7 +74,7 @@ preprocessor -- as done for example by the UG framework~\cite{UG-HP}
\begin{description}
\item[Well Programmable:] Programming errors are directly detected by
the C++ compiler. Thus, diagnostic messages from the compiler are
- directly useful because the source code which gets compiled is the
+ directly useful because the source code compiled is the
same as the one written by the developer. This is not the case
for code generators and C-preprocessor macros where the actual
statements processed by the compiler are obfuscated.
@@ -91,13 +91,13 @@ quasi-standard Boost~\cite{BOOST-HP} libraries.
\section{Polymorphism}
-In object oriented programming, some methods often makes sense for all
+In object oriented programming, some methods often make sense for all
classes in a hierarchy, but what actually needs to be \textit{done}
can differ for each concrete class. This observation motivates
\textit{polymorphism}. Fundamentally, polymorphism means all
-techniques where a method call results in the processor executing code
+techniques in which a method call results in the processor executing code
which is specific to the type of object for which the method is
-called\footnote{This is \textit{poly} of polymorphism: There are
+called\footnote{This is the \textit{poly} of polymorphism: There are
multiple ways to achieve the same goal.}.
In C++, there are two common ways to achieve polymorphism: The
@@ -131,7 +131,7 @@ executed is dynamically determined at run time.
method to be defined in derived classes. Finally, the method
\texttt{range} may calculate the expected remaining kilometers the
car can drive given a fill level of the fuel tank. Since the
- \texttt{range} method can retrieve information it needs, it does not
+ \texttt{range} method can retrieve the information it needs, it does not
need to be polymorphic.
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
// The base class
@@ -215,14 +215,13 @@ depend on specific properties of the function arguments (e.g. constant
value elimination) or the contents of the function body (e.g. loop
unrolling). Unfortunately, inlining and other cross-method
optimizations are made next to impossible by dynamic
-polymorphism. This is because these optimizations are done by the
+polymorphism. This is because these optimizations are accomplished by the
compiler (i.e. at compile time) whilst the code which actually gets
executed is only determined at run time for \texttt{virtual}
methods. To overcome this issue, template programming can be used to
achive polymorphism at compile time. This works by supplying the type
of the derived class as an additional template parameter to the base
-class. Whenever the base class needs to call back the derived class,
-the \texttt{this} pointer of the base class is reinterpreted as a
+class. Whenever the base class needs to call back the derived class, \texttt{this} pointer of the base class is reinterpreted as
being a pointer to an object of the derived class and the method is
then called on the reinterpreted pointer. This scheme gives the C++
compiler complete transparency of the code executed and thus opens
@@ -231,10 +230,10 @@ happens at compile time, it is called ``static polymorphism'' because
the called method cannot be dynamically changed at runtime.
\begin{example}
Using static polymorphism, the base class of example \ref{example:DynPoly}
- can be implemented like:
+ can be implemented like this:
\begin{lstlisting}[name=staticcars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
// The base class. The 'Imp' template parameter is the
-// type of the implementation, i.e. the derived class
+// type of implementation, i.e. the derived class
template <class Imp>
class Car
{public:
@@ -303,10 +302,10 @@ provided.
\subsection*{Identifier-Name Blow-Up}
-One particular problem with advanced use of C++ templates is that the
+One particular problem with the advanced use of C++ templates is that the
canonical identifier names for types and methods quickly become really
long and unintelligible. For example, a typical error message
-generated using GCC 4.5 and \Dune-PDELab looks like
+generated using GCC 4.5 and \Dune-PDELab looks like this
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize, numbersep=5pt]
test_pdelab.cc:171:9: error: no matching function for call to ‘Dune::\
PDELab::GridOperatorSpace<Dune::PDELab::PowerGridFunctionSpace<Dune::\
@@ -327,7 +326,7 @@ ConstraintsTransformation<long unsigned int, double>, Dune::PDELab::\
ISTLBCRSMatrixBackend<2, 2>, true>::GridOperatorSpace()’
\end{lstlisting}
This seriously complicates diagnostics. Although there is no full
-solution for this problem yet, an effective way of dealing with such
+solution to this problem yet, an effective way of dealing with such
kinds of error messages is to ignore the type information and to just
look at the location given at the beginning of the line. If nested
templates are used, the lines printed by the compiler above the actual
@@ -387,7 +386,7 @@ order to keep the code maintainable.
\section{Traits Classes}
-A classic approach to reduce the number of template parameters is to
+A classic approach to reducing the number of template parameters is to
gather all the arguments in a special class, a so-called traits
class. Instead of writing
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
@@ -417,7 +416,7 @@ disadvantages of its own:
\begin{enumerate}
\item Hierarchies of traits classes are problematic. This is due to
the fact that each level of the hierarchy must be self-contained. As
- a result it is impossible to define parameters in the base class
+ a result, it is impossible to define parameters in the base class
which depend on parameters which only later get specified by a
derived traits class.
\item Traits quickly lead to circular dependencies. In practice
@@ -448,7 +447,7 @@ int main() {
}
\end{lstlisting}
Contrary to what is intended, \texttt{v} is a vector of integers. This
-problem can also not be solved using static polymorphism, since it
+problem can not be solved using static polymorphism, either, since it
would lead to a cyclic dependency between \texttt{MyBaseTraits} and
\texttt{MyDoubleTraits}.
diff --git a/doc/handbook/install.tex b/doc/handbook/install.tex
index 53acf0eb934a8037e8060fc1049c889aa5ebc555..42f6e17471644afef7de0ecf17cfaa215889d9de 100644
--- a/doc/handbook/install.tex
+++ b/doc/handbook/install.tex
@@ -3,9 +3,9 @@
In this section about the installation of \Dumux it is assumed that you work on a UNIX or Linux compatible operating system
and that you are familiar with the use of a command line shell. Installation means that you unpack \Dune together with \Dumux in a certain directory.
-Then, you compile it in that directory tree where you do the further work, too. You also should know how to install new software packages
-or you should have a person aside which can give you assistance with that. In section \ref{sec:prerequisites} we list some prerequisites for running \Dune and \Dumux.
-Please check this paragraph whether you can fulfill them. In addition, section \ref{sec:external-modules-libraries} provides some details on optional libraries and modules.
+Then, you compile it in that directory tree in which you do the further work, too. You also should know how to install new software packages
+or you should have a person on hand who can give you assistance with that. In section \ref{sec:prerequisites} we list some prerequisites for running \Dune and \Dumux.
+Please check in said paragraph whether you can fulfill them. In addition, section \ref{sec:external-modules-libraries} provides some details on optional libraries and modules.
In a technical sense \Dumux is a module of \Dune.
Thus, the installation procedure of \Dumux is the same as that of \Dune.
@@ -14,17 +14,17 @@ If you are interested in more details about the build system that is used,
they can be found in the {\Dune} Buildsystem Howto \cite{DUNE-BS}.
-All \Dune modules including \Dumux get extracted into a common directory, as it is done in a usual \Dune installation.
-We refer to that directory abstractly as {\Dune} root directory or shortly as {\Dune}-Root.
+All \Dune modules, including \Dumux, get extracted into a common directory, as it is done in an ordinary \Dune installation.
+We refer to that directory abstractly as {\Dune} root directory or, in short, as {\Dune}-Root.
If it is used as directory's path of a shell command it is typed as \texttt{\Dune-Root}.
For the real {\Dune} root directory on your file system any valid directory name can be chosen.
Source code files for each \Dune module are contained in their own subdirectory within {\Dune}-Root.
We name this directory of a certain module ``module root directory" or \texttt{module-root-directory} if it is a directory path,
e.g. for the module \texttt{dumux} these names are ``dumux root directory" respective \texttt{dumux-root-directory}.
-The real directory names for modules can be chosen arbitrarily, in this manual they are the same as the
+The real directory names for the modules can be chosen arbitrarily. In this manual they are the same as the
module name or the module name extended by a version number suffix.
-The name of each \Dune module is always defined in the file \texttt{dune.module}, which is in root
+The name of each \Dune module is defined in the file \texttt{dune.module}, which is in the root
directory of the respective module. This should not be changed by the user.
It is allowed to have own files and directories in \Dune-Root, which are not related to \Dune's needs.
@@ -45,11 +45,11 @@ It is thus necessary to install an appropriate developer package of \texttt{boos
which is sometimes also named \texttt{libboost}. The matching Ubuntu Linux package is \texttt{libboost-dev}.
The building of included documentation like this handbook requires \LaTeX\ and auxiliary tools
-like \texttt{dvipdf} and \texttt{bibtex}. One usually chooses a \LaTeX\ distribution like \texttt{texlive} for doing that.
+like \texttt{dvipdf} and \texttt{bibtex}. One usually chooses a \LaTeX\ distribution like \texttt{texlive} for this purpose.
It is possible to switch off the building of the documentation by setting the switch \texttt{--disable-documentation}
in the \texttt{CONFIGURE\_FLAGS} of the building options (see Chapter \ref{buildIt}).
Additional parts of documentation are contained within the source code files as special formatted comments.
-Extracting them can be done with \texttt{doxygen} (version $\geqslant$ 1.7.2 works).
+Extracting them can be done using \texttt{doxygen} (version $\geqslant$ 1.7.2 works).
See for this optional step Section \ref{sec:build-doxy-doc}.
Depending on whether you are going to use external libraries and modules for additional \Dune features,
@@ -60,13 +60,13 @@ The subversion (svn) software repositories can be accessed with help of a subver
contained in Apache Subversion of version $\geqslant$ 1.6.0 \cite{APACHE-SUBVERSION-HP}.
\subsection{Obtaining source code for \Dune and \Dumux}
-As stated before, the \Dumux release 2.0.2 and trunk (developer tree) is based on the \Dune release 2.1.0,
+As stated above, the \Dumux release 2.0.2 and trunk (developer tree) is based on the \Dune release 2.1.0,
comprising the core modules \texttt{dune-common}, \texttt{dune-grid}, \texttt{dune-istl}, \texttt{dune-localfunctions}
and the external dune module \texttt{dune-pdelab}. Thus, for a proper \Dumux installation these modules are required.
Two possibilities exist to get the source code of \Dune and \Dumux.
Firstly, \Dune and \Dumux can be downloaded as tar-files from the respective {\Dune} and {\Dumux} website. They have to be extracted as described in the next paragraph.
-Secondly, a method to obtain the most recent source code (or more generally any of its previous revisions) by direct access
+Secondly, a method to obtain the most recent source code (or, more generally, any of its previous revisions) by direct access
via Internet to the software repositories of the revision control system is described in the subsequent part.
However, if a user does not want to use the most recent version,
@@ -74,7 +74,7 @@ certain version tags (i.e. special names), version numbers and even software bra
of the software revision control system to provide access to different versions of the software.
\paragraph{Obtaining the software by installing tar-files}
-The slightly old-fashioned named tape-archive-file shortly named tar-file or tarball is a common file format for distributing collections of files contained within these archives.
+The slightly old-fashionedly named tape-archive-file, shortly named tar-file or tarball, is a common file format for distributing collections of files contained within these archives.
The extraction from the tar-files is done as follows:
Download the tarballs from the respective \Dune (version 2.1) and \Dumux websites to a certain folder in your file system.
Create the {\Dune} root directory, named DUMUX in the example below. Then extract the content of the tar-files, e.g. with the command-line program \texttt{tar}.
@@ -107,15 +107,15 @@ $ svn co https://svn.dune-project.org/svn/dune-pdelab/branches/2.1snapshot dune-
\paragraph{Obtaining \Dune and \Dumux from software repositories}
-Direct access to a software revision control system for downloading code can be of later advantage for the user.
+Direct access to a software revision control system for downloading code can be of advantage for the user later on.
It can be easier for him to keep up with code changes and to receive important bug fixes using the update command of the revision control system.
-\Dune and \Dumux use Apache Subversion for their software repositories. To access them a certain program is needed which is referred here shortly as subversion client.
+\Dune and \Dumux use Apache Subversion for their software repositories. To access them a certain program is needed which is referred to here shortly as subversion client.
In our description, we use the subversion client of the Apache Subversion software itself, which is a command-line tool named \texttt{svn}.
It is available for most Linux and UNIX distributions as software package.
-In the technical speech of Apache Subversion ``checking out a certain software version" means nothing more then fetching
-a local copy from the software repository and laying it out in the file system. Additionally to the software some more files for the use of the software revision control system itself are created. They are kept in directories named \texttt{.svn} and can be found in each subfolder that is under version control.
-If you have developer access to \Dumux, it is also possible to do the opposite, i.e. loading up a modified revision of software into the software repository. This is usually termed as ``software commit".
+In the technical language of Apache Subversion ``checking out a certain software version" means nothing more then fetching
+a local copy from the software repository and laying it out in the file system. In addition to the software some more files for the use of the software revision control system itself are created. They are kept in directories named \texttt{.svn} and can be found in each subfolder which is under version control.
+If you have developer access to \Dumux, it is also possible to do the opposite, i.e. to load up a modified revision of software into the software repository. This is usually termed as ``software commit".
The installation procedure is done as follows:
Create a {\Dune} root directory, named DUMUX in the lines below.
@@ -136,7 +136,7 @@ $ svn co https://svn.dune-project.org/svn/dune-pdelab/branches/2.1snapshot dune-
% The newest (unstable) developments are also provided in these repositories, usually in a folder called ``trunk''. Please check the \Dune website \cite{DUNE-DOWNLOAD-SVN} for further information. However, the current \Dumux release is based on the stable 2.1.0 release and it will not compile without further adaptations using the the newest versions of \Dune.
The additional module \texttt{dune-grid-howto} is a tutorial which provides information about the \Dune grid interface.
-It may give you an idea how some abstractions in \Dune are done.
+It may give you an idea of how some abstractions in \Dune are done.
The \texttt{dune-grid-howto} is not required by \Dumux, the installation is optional. It is done by:
\begin{lstlisting}[style=Bash]
@@ -144,7 +144,7 @@ $ svn co https://svn.dune-project.org/svn/dune-grid-howto/tags/2.1.0 dune-grid-h
\end{lstlisting}
The \texttt{dumux} module is checked out as described below (see also the \Dumux website \cite{DUMUX-HP}).
-Its file tree has to be created in the \Dune-Root directory, where the \Dune modules are also have been checked out to. Subsequently, the next command
+Its file tree has to be created in the \Dune-Root directory, where the \Dune modules have also been checked out to. Subsequently, the next command
is executed there, too. The dumux root directory is called \texttt{dumux} here.
\begin{lstlisting}[style=Bash]
@@ -159,9 +159,9 @@ you are allowed to commit own code and that you can access the \texttt{dumux-dev
This enhances \texttt{dumux} by providing (unstable) code from the developer group.
A developer usually checks out non-anonymously the modules \texttt{dumux} and \texttt{dumux-devel}.
\texttt{Dumux-devel} itself makes use of the stable part \texttt{dumux}. Hence, the two parts have to be checked out together.
-This is done by the commands below. But \texttt{joeuser} needs to be replaced by
+This is done using the commands below. But \texttt{joeuser} needs to be replaced by
the actual user name of the developer for accessing the software repository.
-One can omit the \texttt{--username} option in the commands above, if the user name for the repository access is
+One can omit the \texttt{--username} option in the commands above if the user name for the repository access is
identical to the one for the system account.
\begin{lstlisting}[style=Bash]
@@ -171,7 +171,7 @@ $ svn co --username=joeuser svn://svn.iws.uni-stuttgart.de/DUMUX/dune-mux/trunk
Please choose either not to store the password by subversion in an insecure way or
choose to store it by subversion in a secure way, e.g. together with \texttt{kwallet} or \texttt{gnomekeyring}.
-Check the documentation of subversion, how this is being done.
+Check the documentation of subversion for info on how this is done.
A leaked out password can be used by evil persons to abuse a software repository.
\paragraph{checkout-dumux script}
@@ -190,8 +190,8 @@ Patching of \Dune modules in order to work together with \Dumux
can be necessary for several reasons.
Software like a compiler or even a standard library
changes at times. But, for example, a certain release of a software-component that we depend on, may not reflect that change and thus it has to be modified.
-In the dynamic developing process of software that depends on other modules it is not always feasible
-to adapt everything to the most recent version of each module. Consequently, patches exist or they are be brought into existence. They may fix problems with a certain module
+In the dynamic developing process of software which depends on other modules it is not always feasible
+to adapt everything to the most recent version of each module. Consequently, patches exist or they will be brought into existence. They may fix problems with a certain module
of a certain release without introducing too much structural change. It can also happen
that a release gets amendments (updates) and a formerly useful patch becomes obsolete.
@@ -211,7 +211,7 @@ It can be removed by
$ path -p1 -R < ../dumux/patches/dune-istl-2.0.patch
\end{lstlisting}
-The \texttt{checkout-dumux} script also applies patches, if not explicitly requested to do not so.
+The \texttt{checkout-dumux} script also applies patches, if not explicitly requested not to do so.
\subsection{Build of \Dune and \Dumux}
\label{buildIt}
@@ -222,7 +222,7 @@ but also try to include error details.\\
It is possible to compile \Dumux with nearly no explicit options to the build system.
%, but experience showed that the code quality through all parts of \Dune is not yet high enough to give the compiler full
-%freedom for allowing certain kind optimizations.
+%freedom for allowing certain kinds of optimizations.
However, for the successful compilation of \Dune and \Dumux, it is currently necessary to pass the
%As options, switches for the optimization can be set in parts
%build system for code by default, it is safer to pass
@@ -235,11 +235,11 @@ $ # make sure you are in the directory DUNE-Root
$ ./dune-common/bin/dunecontrol --configure-opts="CXXFLAGS=-fno-strict-aliasing" all
\end{lstlisting}
-Too many options can make life hard, that's why usually option-files are being used together with dunecontrol and its sub-tools.
-Larger sets of options are kept in them. If you are going to compile with options suited for debugging of the code, the following
+Too many options can make life hard. That's why usually option-files are being used together with dunecontrol and its sub-tools.
+Larger sets of options are kept in them. If you are going to compile with options suited for debugging the code, the following
can be a starting point:
-%Below in command-line make sure to insert the right name of dumux' root directory, which is in case of installation from tar-files \texttt{dumux-2.0} or in case of installation from subversion just \texttt{dumux}. For a developer it is also possible to take options file from \texttt{dumux-devel}.
+%Below in command-line make sure to insert the right name of dumux' root directory, which is in the case of installation from tar-files \texttt{dumux-2.0} or in the case of installation from subversion just \texttt{dumux}. For a developer it is also possible to take the options file from \texttt{dumux-devel}.
\begin{lstlisting}[style=Bash]
$ # make sure you are in the directory DUNE-Root
@@ -248,7 +248,7 @@ $ gedit my-debug.opts # optional editing the options file
$ ./dune-common/bin/dunecontrol --opts=my-debug.opts all
\end{lstlisting}
-More optimized code, which is typically not usable for standard debugging tasks, can produced by
+More optimized code, which is typically not usable for standard debugging tasks, can be produced by
\begin{lstlisting}[style=Bash]
$ cp dumux/optim.opts my-optim.opts
@@ -259,12 +259,12 @@ Sometimes it is necessary to have additional options which
are specific to a package set of an operating system or
sometimes you have your own preferences.
Feel free to work with your own set of options, which may evolve over time.
-The option files above are more to be understood as a starting point
+The option files above are to be understood more as a starting point
for setting up an own customization than as something which is fixed.
The use of external libraries can make it necessary to add quite many options in an option-file.
It can be helpful to give your customized option file its own name, as done above.
-One avoids to confused it with the option files that came out of the distribution
-and that can be possibly updated by subversion later on.
+One avoids confusing it with the option files which came out of the distribution
+and which can be possibly updated by subversion later on.
\subsection{Building doxygen documentation} \label{sec:build-doxy-doc}
@@ -293,7 +293,7 @@ $ firefox html/index.html
If the \texttt{--enable-documentation} switch has been set in the configure flags of
\texttt{dunecontrol}, this does not necessarily mean that for every
-\Dune module the documentation is being build.
+\Dune module the documentation is being built.
However, at least Makefiles for building the documentation are generated.
Provided you run \texttt{dunecontrol} with the option above,
it should be possible to build documentation if available.
@@ -322,20 +322,20 @@ $ make dumux-handbook.pdf
\end{lstlisting}
-%At the time writing this to the author no general method of building documentation contained in \Dune's modules is known.
+%As of writing this, no general method of building documentation contained in \Dune's modules is known to the author.
%Alternatively, the tool CMake can be used to build \Dumux. Please check the file \texttt{INSTALL.cmake} for details.
\subsection{External libraries and modules} \label{sec:external-modules-libraries}
-The libraries described in the sequel of this paragraph provide additional functionality but are not generally required to run \Dumux.
+The libraries described below provide additional functionality but are not generally required to run \Dumux.
If you are going to use an external library check the information provided on the \Dune website \cite{DUNE-EXT-LIB}.
If you are going to use an external \Dune module the website on external modules \cite{DUNE-EXT-MOD} can be helpful.\\
%Further information on external modules and libraries seemed to be contained in {\Dune}s Wiki \cite{DUNE-MAIN-WIKI}.
Installing an external library can require additional libraries which are also used by \Dune.
-For some libraries, such as BLAS or MPI, multiple versions can be installed on system.
+For some libraries, such as BLAS or MPI, multiple versions can be installed on the system.
Make sure that it uses the same library as \Dune when configuring the external library.
In the following list, you can find some external modules and external libraries, and some more libraries and tools which are prerequisites for their use.
@@ -343,7 +343,7 @@ In the following list, you can find some external modules and external libraries
\begin{itemize}
\item \textbf{ALBERTA}: External library for use as GRID. Adaptive multi Level finite element toolbox using Bisectioning refinement and Error control by Residual Techniques for scientific Applications. Building it requires a Fortran compiler \texttt{gfortran}. Download: \texttt{\url{http://www.alberta-fem.de}}.
-\item \textbf{ALUGrid}: External library for use as GRID. ALUGrid is build by a C++-compiler like \texttt{g++}. If you want to build a parallel version, you will need \texttt{MPI}. It was successfully run with \texttt{openmpi}. The parallel version needs also a graph partitioner, such as \texttt{METIS}. It was run successfully in combination with \Dune using \texttt{METIS}. \\
+\item \textbf{ALUGrid}: External library for use as GRID. ALUGrid is built by a C++-compiler like \texttt{g++}. If you want to build a parallel version, you will need \texttt{MPI}. It was successfully run with \texttt{openmpi}. The parallel version needs also a graph partitioner, such as \texttt{METIS}. It was run successfully in combination with \Dune using \texttt{METIS}. \\
Download: \texttt{\url{http://aam.mathematik.uni-freiburg.de/IAM/Research/alugrid}}
\item \textbf{\Dune-multidomaingrid}: External module. If you going to run on the same grid different domains or subdomains,
@@ -367,13 +367,13 @@ The following are dependencies of some of the used libraries. You will need them
\item \textbf{BLAS}: Alberta makes use of BLAS. Thus install GotoBLAS2, ATLAS, non-optimized BLAS or BLAS provided by a chip manufacturer. Take care that the installation scripts select the intended version of BLAS. See \texttt{\url{http://en.wikipedia.org/wiki/Basic_Linear_Algebra_Subprograms}}.
-\item \textbf{GotoBLAS2}: This is an optimized version of BLAS. It covers not always available all processors of the day, but quite a broad range. Its license is now very open. A Fortran compiler like \texttt{gfortran} is needed to compile it.\\
+\item \textbf{GotoBLAS2}: This is an optimized version of BLAS. It covers not all processors of the day, but quite a broad range. Its license is now very open. A Fortran compiler like \texttt{gfortran} is needed to compile it.\\
Available by \texttt{\url{http://www.tacc.utexas.edu/tacc-projects/gotoblas2/}}.
\item \textbf{METIS}: This is a dependency of ALUGrid, if you are going to run it parallel.
-\item \textbf{Compilers}: Beside \texttt{g++} it has been reported that \Dune was successfully build with the Intel C++ compiler.
-C and Fortran compiler is needed for a some external libraries. As code of different compilers is linked together they have to be be compatible with each other. A good choice is the GNU compiler suite \texttt{gcc}, \texttt{g++} and \texttt{gfortran}.
+\item \textbf{Compilers}: Beside \texttt{g++} it has been reported that \Dune was successfully built with the Intel C++ compiler.
+C and Fortran compiler is needed for some external libraries. As code of different compilers is linked together they have to be be compatible with each other. A good choice is the GNU compiler suite \texttt{gcc}, \texttt{g++} and \texttt{gfortran}.
\item \textbf{libgomp}: External libraries, such as ALUGrid, can make use of OpenMP when used together with METIS. For that purpose it can be necessary to install the \texttt{libgomp} library.
% http://openmp.org/
@@ -403,7 +403,7 @@ $ cd external
$ ./installExternal.sh all
\end{lstlisting}
-It is also possible to install only the actual needed external libraries:
+It is also possible to install only the actually needed external libraries:
\begin{lstlisting}[style=Bash]
$ ./installExternal.sh -h # show, what options this script provide
diff --git a/doc/handbook/intro.tex b/doc/handbook/intro.tex
index a9a7780f5d1c8c06299b4a00becffe5aba841198..10fcd7e6df97293882172193323a5c6b06b7ba15 100644
--- a/doc/handbook/intro.tex
+++ b/doc/handbook/intro.tex
@@ -1,6 +1,6 @@
\chapter{Introduction}
-\Dumux aims to be a generic framework for simulation of multiphase
+\Dumux aims to be a generic framework for the simulation of multiphase
fluid flow and transport processes in porous media using contiuum
mechanical approaches. At the same time, \Dumux aims to deliver
top-notch computational performance, high flexibility, a sound
@@ -10,7 +10,7 @@ hardware architectures.
The means to achieve these somewhat contradictory goals are the
thorough use of object oriented design in conjunction with template
-programming. These requirements lead to C++ as the implementation
+programming. These requirements call for C++ as the implementation
language.
One of the more complex issues when dealing with parallel continuum
@@ -31,7 +31,7 @@ libraries\footnote{In fact, the performance penalty resulting from the
\includegraphics[width=.5\linewidth, keepaspectratio]{EPS/dunedesign}
\caption{
\label{fig:dune-design}
- A high-level overview on DUNE's design as available on the project's
+ A high-level overview of DUNE's design is available on the project's
web site~\cite{DUNE-HP}.
}
\end{figure}
@@ -44,12 +44,12 @@ cells, co-dimension $1$ are edges, and so on until co-dimension $n$
which are the cell's vertices. The DUNE grid interface generally
assumes that all entities are convex polytopes, which means that it
must be possible to express each entity as the convex hull of a set of
-vertices. For efficiency, all entities are further expressed in terms
+vertices. For the sake of efficiency, all entities are further expressed in terms
of so-called reference elements which are transformed to the actual
spatial incarnation within the grid by a so-called geometry
function. Here, a reference element for an
entity can be thought of as a prototype for the actual grid
-entity. For example, if we used a grid that used hexahedrons as cells,
+entity. For example, if we used a grid which applied hexahedrons as cells,
the reference element for each cell would be the unit cube $[0, 1]^3$
and the geometry function would scale and translate the cube so that
it matches the grid's cell. For a more thorough description of DUNE's
@@ -59,9 +59,9 @@ In addition to the grid interface, DUNE also provides quite a few
additional modules, of which the \texttt{dune-pdelab},
\texttt{dune-localfunctions} and \texttt{dune-istl} modules are the
most relevant in the context of this handbook. \texttt{dune-pdelab}
-provides a toolbox for discretization and includes matrix assemblers
+provides a toolbox for discretization and includes, among other things, matrix assemblers
for translating local stiffness matrices into a global linear system
-of equations and much more, while \texttt{dune-localfunctions}
+of equations, while \texttt{dune-localfunctions}
provides a set of generic finite element shape
functions. \texttt{dune-istl} is the \textbf{I}terative
\textbf{S}olver \textbf{T}emplate \textbf{L}ibrary and provides
@@ -70,12 +70,12 @@ generated systems.
\Dumux comes in form of an additional module \texttt{dumux}.
It depends on the DUNE core modules
-\texttt{dune-common}, \texttt{dune-grid}, \texttt{dune-istl}, \texttt{dune-localfunctions}, as well as from
+\texttt{dune-common}, \texttt{dune-grid}, \texttt{dune-istl}, \texttt{dune-localfunctions}, as well as on
the discretization module \texttt{dune-pdelab}.
-The main intention of \Dumux is to provide a framework for easy and efficient
+The main intention of \Dumux is to provide a framework for an easy and efficient
implementation of new physical models for porous media flow problems,
-ranging from problem formulation, the selection of
-spatial and temporal discretization schemes, as well as nonlinear solvers,
-up to general concepts for model coupling.
-Moreover, \Dumux includes ready to use numerical models and a few example applications.
+ranging from problem formulation and the selection of
+spatial and temporal discretization schemes as well as nonlinear solvers,
+to general concepts for model coupling.
+Moreover, \Dumux includes ready to use numerical models and a few example applications.
diff --git a/doc/handbook/propertysystem.tex b/doc/handbook/propertysystem.tex
index 4546c0f9f06f9e435fe36d78118514ea86f977ce..989e0ef3dbed56c5ea0aa8df9d3c6220129fd0f3 100644
--- a/doc/handbook/propertysystem.tex
+++ b/doc/handbook/propertysystem.tex
@@ -250,7 +250,7 @@ diagram for the car types above might look like outlined in Figure
}
\caption{ \textbf{(a)}~~A possible property inheritance graph for
various kinds of cars. The lower nodes inherit from higher ones;
- Inherited properties from nodes on right take precedence over the
+ Inherited properties from nodes on the right take precedence over the
properties defined on the left. ~~\textbf{(b)}~~Property names
which make sense for at least one of the car types of (a). }
\end{figure}
@@ -302,10 +302,10 @@ the following:
transmission, in every other aspect it is like a compact car.
\item A pick-up truck has a top speed of $120\;km/h$ and a payload of
$5\;t$. In every other aspect it is like a sedan or a truck but if in
- doubt it is more like a truck.
+ doubt, it is more like a truck.
\item The Hummer-H1 SUV exhibits the same top speed as a pick-up
truck. In all other aspects it is similar to a pickup and a tank,
- but if in doubt more like a tank.
+ but, if in doubt, more like a tank.
\end{itemize}
\noindent
diff --git a/doc/handbook/tutorial-coupled.tex b/doc/handbook/tutorial-coupled.tex
index 331597a6ebd4ab05a0fb29ec9d9325942e271f4d..bc91752fe89452e970d47899156b864a9a7b75ce 100644
--- a/doc/handbook/tutorial-coupled.tex
+++ b/doc/handbook/tutorial-coupled.tex
@@ -17,7 +17,7 @@ The advantage of the FE method is that unstructured grids can be used, while the
f(\tilde u(x^k_{ij})) \cdot \mathbf n^k_{ij} \: |e^k_{ij}| \qquad \textrm{with} \qquad \tilde u(x^k_{ij}) = \sum_i N_i(x^k_{ij}) \cdot \hat u_i .
\end{equation}
-In the following the discretization of the balance equation is going to be derived. From the \textsc{reynolds}s transport theorem follows the general balance equation:
+In the following, the discretization of the balance equation is going to be derived. From the \textsc{reynolds}s transport theorem follows the general balance equation:
\begin{equation}
\underbrace{\int_G \frac{\partial}{\partial t} \: u \: dG}_{1} + \underbrace{\int_{\partial G} (\mathbf{v} u + \mathbf w) \cdot \textbf n \: d\varGamma}_{2} = \underbrace{\int_G q \: dG}_{3}
@@ -99,7 +99,7 @@ where $V_i$ is the volume of the FV box $B_i$ associated with node i. The applic
V_i \frac{\partial \hat u_i}{\partial t} + \int_{\partial G} \left[ W_j \cdot F(\tilde u)\right] \cdot \mathbf n \: d\varGamma_G + \int_G \nabla W_j \cdot F(\tilde u) \: dG- V_i \cdot q = 0
\end{equation}
-Defining the weighting function $W_j$ to be piecewise constant over a control volume box $B_i$
+Defining the weighting function $W_j$ to be piecewisely constant over a control volume box $B_i$
\begin{equation}
W_j(x) = \begin{cases}
@@ -115,7 +115,7 @@ causes $\nabla W_j = 0$:
V_i \frac{\partial \hat u_i}{\partial t} + \int_{\partial B_i} \left[ W_j \cdot F(\tilde u)\right] \cdot \mathbf n \; d{\varGamma}_{B_i} - V_i \cdot q = 0 .
\end{equation}
-The consideration of the time discretization and inserting $W_j = 1$ finally leads to the discretized form which will be applied to the mathematical flow and transport equations:
+The consideration of the time discretization and inserting $W_j = 1$ finally lead to the discretized form which will be applied to the mathematical flow and transport equations:
\begin{equation}
\label{eq:discfin}
@@ -132,7 +132,7 @@ The process of solving a problem using \Dumux can be roughly divided into four p
\item A suitable model has to be chosen.
\end{enumerate}
-The problem that is solved in this tutorial is illustrated in Figure \ref{tutorial-coupled:problemfigure}. A rectangular domain with no flow boundaries on the top and on the bottom, which is initially saturated with oil, is considered. Water infiltrates from the left side into the domain. Gravity effects are neglected.
+The problem being solved in this tutorial is illustrated in Figure \ref{tutorial-coupled:problemfigure}. A rectangular domain with no flow boundaries on the top and on the bottom, which is initially saturated with oil, is considered. Water infiltrates from the left side into the domain. Gravity effects are neglected.
\begin{figure}[h]
\psfrag{x}{x}
@@ -151,7 +151,7 @@ The problem that is solved in this tutorial is illustrated in Figure \ref{tutori
\caption{Geometry of the tutorial problem with initial and boundary conditions.}\label{tutorial-coupled:problemfigure}
\end{figure}
-The equations that are solved here are the mass balances of oil and
+The equations solved here are the mass balances of oil and
water:
\begin{align}
\label{massbalancewater}
@@ -176,7 +176,7 @@ water:
Listing \ref{tutorial-coupled:mainfile} shows the main file
\texttt{tutorial/tutorial\_coupled.cc} for the coupled two-phase
-model. This file needs to be executed to solve the problem described
+model. This file needs to be executed in order to solve the problem described
above.
\begin{lst}[File tutorial/tutorial\_coupled.cc]\label{tutorial-coupled:mainfile} \mbox{}
@@ -201,7 +201,7 @@ message passing interface using \Dune's \texttt{MPIHelper} class. Line
\ref{tutorial-coupled:init-mpi} is essential if the simulation is
intended to be run on more than one processor at the same time. Next,
the command line arguments are parsed starting at line
-\ref{tutorial-coupled:parse-args-begin} until line
+\ref{tutorial-coupled:parse-args-begin} down to line
\ref{tutorial-coupled:parse-args-end}. In this example, it is checked if and
from which time on a previous run of the simulation should be restarted. Furthermore, we
parse the time when the simulation ends and the initial time step size.
@@ -211,7 +211,7 @@ After this, a grid is created in line
its leaf grid view in line \ref{tutorial-coupled:instantiate-problem}.
Finally, on line \ref{tutorial-coupled:begin-restart} a state written to
disk by a previous simulation run is restored if requested by the user.
-The simulation procedure is started at line
+The simulation procedure is started in line
\ref{tutorial-coupled:execute}.
\subsection{The problem class}
@@ -239,16 +239,16 @@ a static \texttt{create()} method which provides just that. Therein, the three v
Type \texttt{Dune::FieldVector} define the lower left corner of the domain
(\texttt{L}), the upper right corner of the domain (\texttt{H}) and the number
of cells in $x$ and $y$ direction (\texttt{N}). Next,
-the appropriate fluid system, that specifies both information about
+the appropriate fluid system, which specifies both information about
the fluid mixture as well as about the pure substances, has to be chosen.
The two-phase model defaults to the \texttt{FluidSystem2P} which assumes
-immiscibility of the phases, but requires that the wetting and non-wetting phases
-are explicitly set. In this case, liquid water which uses the relations from
+immiscibility of the phases, but requires 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 a liquid model oil is chosen as the
non-wetting phase on line \ref{tutorial-coupled:nonwettingPhase}.
-The final property, which is set on line
+The final property, which is set in line
\ref{tutorial-coupled:gravity}, is optional and tells the model not to
use gravity.
@@ -257,7 +257,7 @@ conditions, source terms or temperature within the domain -- but 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 must be derived from \texttt{TwoPBoxProblem} as done
-on line \ref{tutorial-coupled:def-problem}.
+in line \ref{tutorial-coupled:def-problem}.
The problem class always has at least five methods:
\begin{itemize}
@@ -276,11 +276,11 @@ For the definition of the the boundary condition types and of the values of the
two parameters are required:
\begin{description}
\item [values:] A vector which stores the result of the method. What
- the values in this vector mean is depending on the method: For
+ the values in this vector mean is dependent on the method: For
\texttt{dirichlet()} it contains the actual values of the primary
variables, for \texttt{boundaryTypes()} it contains the boundary
condition type. It has as many entries as the model has primary variables / equations.
- For the typical case where all equations have the same boundary
+ For the typical case in which all equations have the same boundary
condition at a certain position, there are two methods that set the appropriate conditions
for all primary variables / equations: Either \texttt{setAllDirichlet()} or \texttt{setAllNeumann()}
\item [vertex:] The boundary condition and the Dirichlet values are specified at the vertex, which represents a
@@ -320,8 +320,8 @@ methods. If the isothermal two-phase model is used, this includes
for example a \texttt{temperature()} method which returns the temperature in Kelvin
of the fluids and the rock matrix in the domain. This temperature is
then used by the model to calculate fluid properties which possibly
-depend on it, e.g. density. The \texttt{bboxMax()} method that is used here, is a vector
-that provides information about the spatial extends of the simulation domain. This method
+depend on it, e.g. density. The \texttt{bboxMax()} method that is used here is a vector
+providing information about the spatial extends of the simulation domain. This method
and the respective \texttt{bboxMin()} method
can be found in the base class \texttt{Dumux::BoxProblem<TypeTag>}.
@@ -337,7 +337,7 @@ letter, e.g. \texttt{Water}, and are derived from \texttt{Component}.
Most often, when two or more components are considered, fluid interactions
such as solubility effects come into play and properties of mixtures such as
-the density are of interest. These interactions are defined in
+density are of interest. These interactions are defined in
a specific \verb+fluidsystem+ in the folder \verb+dumux/material/fluidsystems+.
It features methods returning fluid properties like density, enthalpy, viscosity,
etc. by accessing the pure components as well as binary coefficients such as
@@ -345,17 +345,17 @@ Henry or diffusion coefficients, which are stored in
\verb+dumux/material/binarycoefficients+. New fluids which are not yet
available in the \Dumux distribution can be defined analogously.
-% In this example, a class for the definition of a two-phase system is used. This allows the choice
-% of the two components oil and water and to access the parameters that are relevant for the two-phase model.
+% 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{The definition of the parameters that are dependent on space}\label{tutorial-coupled:description-spatialParameters}
-In \Dumux, the properties of the porous medium such as \textit{intrinsic
+In \Dumux, the properties of the porous medium such as the \textit{intrinsic
permeability}, the \textit{porosity}, the \textit{heat capacity} as
well as the \textit{heat conductivity} can be defined in space using a
so-called \texttt{spatial parameters} class. However, because the soil
also has an effect on the material laws of the fluids (e.g. \textit{capillarity}),
-their selection and definition of their attributes (e.g. \textit{residual
+their selection and the definition of their attributes (e.g. \textit{residual
saturations}) are also accomplished in the spatial parameters.
The base class \texttt{Dumux::BoxSpatialParameters<TypeTag>} holds a general
@@ -446,10 +446,10 @@ To get an impression what the results should look like you can first run the ori
\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:
\begin{enumerate}
- \item Brine: The class \texttt{Dumux::Brine} acts as a adapter to the fluid system that alters a pure water class by adding some salt. Hence, the class \texttt{Dumux::Brine} uses a pure water class, such as \texttt{Dumux::H2O}, as a second template argument after the data type \texttt{<Scalar>} as a template argument (be aware to use the complete water class with its own template parameter).
- \item DNAPL: A standard set of chemical substances, such as Oil and Brine, is already included (via a list of \texttt{\#include ..} commandos) and hence easy accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file as well as select the component via the property system.
+ \item Brine: The class \texttt{Dumux::Brine} acts as an adapter to the fluid system that alters a pure water class by adding some salt. Hence, the class \texttt{Dumux::Brine} uses a pure water class, such as \texttt{Dumux::H2O}, as a second template argument after the data type \texttt{<Scalar>} as a template argument (be sure to use the complete water class with its own template parameter).
+ \item DNAPL: A standard set of chemical substances, such as Oil and Brine, is already included (via a list of \texttt{\#include ..} commandos) and hence easily accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file and select the component via the property system.
\end{enumerate}
-If you want to take a closer look 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 and which substances are already available please browse through the files in the directory
\texttt{/dumux/material/components}.
\item \textbf{Use the \Dumux fluid system} \\
@@ -494,7 +494,7 @@ the file \texttt{tutorialproblem\_coupled.hh} (e.g. with the name
\texttt{ex2\_tutorialproblem\_coupled.hh} and new spatial parameters
just like \texttt{tutorialspatialparameters\_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 a new classes with
+The new files should contain the definition of new classes with
names that relate to the file name, such as
\texttt{Ex2TutorialProblemCoupled}. Make sure that you also adjust the guardian
macros in lines \ref{tutorial-coupled:guardian1} and \ref{tutorial-coupled:guardian1}
@@ -502,7 +502,7 @@ macros in lines \ref{tutorial-coupled:guardian1} and \ref{tutorial-coupled:guard
\texttt{DUMUX\_TUTORIALPROBLEM\_COUPLED\_HH} to
\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_COUPLED\_HH}). Besides also adjusting the guardian macros,
the new problem file should define and use a new type tag for the problem as well as a new problem class
-e.g. \texttt{Ex2TutorialProblemCoupled}. Make sure you assign your newly defined spatial
+e.g. \texttt{Ex2TutorialProblemCoupled}. Make sure to assign your newly defined spatial
parameter class to the \texttt{SpatialParameters} property for the new
type tag. \\
After this, change the \texttt{create()} method of the \texttt{Grid}
diff --git a/doc/handbook/tutorial-decoupled.tex b/doc/handbook/tutorial-decoupled.tex
index 7bb5c0f39f01e8805f4c386489246c2157dc28b7..1d1f762ef0fd7aca367187d611d1e3331866d9fe 100644
--- a/doc/handbook/tutorial-decoupled.tex
+++ b/doc/handbook/tutorial-decoupled.tex
@@ -64,20 +64,20 @@ message passing interface using \Dune's \texttt{MPIHelper} class. Line
intended to be run on more than one processor at the same time. Next,
the command line arguments are parsed starting at line
\ref{tutorial-decoupled:parse-args-begin} until line
-\ref{tutorial-decoupled:parse-args-end}. In this case, we check weather and
+\ref{tutorial-decoupled:parse-args-end}. In this case, we check whether and
at which time a previous run of the simulation should be restarted, and we
parse the time when the simulation ends. As the maximum time-step in the
sequential model is strictly bound by a CFL-criterion, the first time-step
size is initialized with the simulation time.
-After this, a grid is created on line \ref{tutorial-decoupled:create-grid}
+After this, a grid is created in line \ref{tutorial-decoupled:create-grid}
and the time manager controlling the simulation run is instantiated
with the start parameters in line \ref{tutorial-decoupled:initTimeManager}.
The problem is instantiated with the time manager and information about the grid
(via its leaf grid view) on line \ref{tutorial-decoupled:instantiate-problem}.
If demanded, on line \ref{tutorial-decoupled:mainRestart} a state written to
disk by a previous simulation run is restored on request by the user.
-Finally, the simulation proceedure is started by the time manager at line
+Finally, the simulation proceedure is started by the time manager in line
\ref{tutorial-decoupled:execute}.
@@ -96,13 +96,13 @@ numberstyle=\tiny, numbersep=5pt, firstline=28]{../../tutorial/tutorialproblem_d
First, both \Dune grid handlers and the decoupled model of \Dumux
have to be included. Then, a new type tag is created for the problem
-on line \ref{tutorial-decoupled:create-type-tag}. In this case, the
+in line \ref{tutorial-decoupled:create-type-tag}. In this case, the
new type tag inherits all properties defined for the \texttt{DecoupledTwoP}
type tag, which means that for this problem the two-phase decoupled approach
is chosen as discretization scheme (defined via the include in line
\ref{tutorial-decoupled:parent-problem}). On line \ref{tutorial-decoupled:set-problem},
a problem class is attached to the new type tag, while the grid which
-is going to be used is defined on line \ref{tutorial-decoupled:set-grid-type} --
+is going to be used is defined in line \ref{tutorial-decoupled:set-grid-type} --
in this case an \texttt{SGrid} is created. Since in \Dune, there's no uniform
mechanism to allocate grids, the \texttt{Grid} property also contains
a static \texttt{create()} method which provides just that: From line
@@ -113,10 +113,10 @@ Type \texttt{Dune::FieldVector} define the lower left corner of the domain
of cells in $x$ and $y$ direction (\texttt{N}). The grid of type
\texttt{Dune::SGrid} is then generated in line \ref{tutorial-decoupled:grid-end}.
For more information about the \Dune grid interface, the different grid types
-that are supported and the generation of different grids it is referred to
+that are supported and the generation of different grids consult
the \textit{Dune Grid Interface HOWTO} \cite{DUNE-HP}.
-Next, we select the material of the simulation: In case of a pure two-phase
+Next, we select the material of the simulation: In the case of a pure two-phase
model, each phase is a bulk fluid, and the complex (compositional) fluidsystems
do not need to be used. However, they can be used (see exercise 1 \ref{dec-ex1-fluidsystem}).
Instead, we use a simplified fluidsystem container that provides classes
@@ -134,7 +134,7 @@ wetting phase velocity rather than e.g. a total velocity is used for the
transport system. As we regard capillary pressure, a capillary diffusive
term is regarded, selected in line \ref{tutorial-decoupled:DiffusivePart}.
Line \ref{tutorial-decoupled:cfl} assigns the CFL-factor to be used in the
-simulation run. The final property on line \ref{tutorial-decoupled:gravity}
+simulation run. The final property in line \ref{tutorial-decoupled:gravity}
is optional and tells the model not to use gravity.
After all necessary information is written into the property system and
@@ -145,7 +145,7 @@ As its property, the problem class itsself is also derived from a parent,
\ref{tutorial-decoupled:constructor-problem}) is able to hold two vectors,
which is not needed in this tutorial.
-Besides the definition of the boundary and initial conditions (discussed in
+Beside the definition of the boundary and initial conditions (discussed in
subsection \label{decoupled-problem:boundary}), the problem class also contains
general information about the current simulation. First, the name used by
the \texttt{VTK-writer} to generate output is defined in the method of line
@@ -161,14 +161,14 @@ Hence, they all feature a common argument list:
\begin{itemize}
\item \texttt{globalPos}: A vector holding the global Coordinates.
\item \texttt{element} or \texttt{intersection}: Input for an iterator, that is
- depending weather the parameter of the method is defined in an element, such as
+ depending on whether the parameter of the method is defined in an element, such as
initial values, or on an intersection, such as a boundary condition.
\end{itemize}
In the following, there are the methods for general parameters, source- or
sinkterms, boundary conditions (lines \ref{tutorial-decoupled:bctype} to
\ref{tutorial-decoupled:neumann}) and initial values for the transported
quantity in line \label{tutorial-decoupled:init}. For more information
-on the functions, it is referred to the documentation in the code.
+on the functions, consult the documentation in the code.
\subsection{The definition of the parameters that are dependent on space}\label{tutorial-decoupled:description-spatialParameters}
@@ -179,7 +179,7 @@ Listing \ref{tutorial-decoupled:spatialparametersfile} shows the file
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
numberstyle=\tiny, numbersep=5pt, firstline=26]{../../tutorial/tutorialspatialparameters_decoupled.hh}
\end{lst}
-As this file only slightly differs from the coupled version, it is referred to
+As this file only slightly differs from the coupled version, consult
chapter \ref{tutorial-coupled:description-spatialParameters} for explanations.
However, as a standard Finite-Volume--scheme is used, in contrast to the box-method
in the coupled case, the argument list here is the same as for the problem
@@ -202,7 +202,7 @@ For Exercise 1 you only have to make some small changes in the tutorial files.
\begin{enumerate}
\item \textbf{Altering output}
To get an impression what the results should look like you can first run the original version of the decoupled tutorial model by typing \texttt{./tutorial\_decoupled 1e5}. The number behind the simulation name defines the timespan of the simulation run in seconds. For the visualisation with paraview please refer to \ref{quick-start-guide}.\\
-As you can see, the simulation creates roughly 150 output files. To reduce these to perform longer simulations, change the method responsible for output (line \ref{tutorial-decoupled:output} in the file \texttt{tutorialproblem\_decoupled}) to write an output only every 20 timesteps by changeing the divisor. 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 roughly 150 output files. To reduce these in order to perform longer simulations, change the method responsible for output (line \ref{tutorial-decoupled:output} in the file \texttt{tutorialproblem\_decoupled}) as to write an output only every 20 timesteps by changeing the divisor. 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} \\
Change the size of the model domain so that you get a rectangle
@@ -212,10 +212,10 @@ Change the boundary conditions in the file \texttt{tutorialproblem\_decoupled.hh
\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:
\begin{enumerate}
- \item Brine: The class \texttt{Dumux::Brine} acts as a adapter to the fluid system that alters a pure water class by adding some salt. Hence, the class \texttt{Dumux::Brine} uses a pure water class, such as \texttt{Dumux::H2O}, as a second template argument after the data type \texttt{<Scalar>} as a template argument (be aware to use the complete water class with its own template parameter).
- \item DNAPL: A standard set of chemical substances, such as Oil and Brinde, is already included (via a list of \texttt{\#include ..} commandos) and hence easy accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file as well as select the component via the property system.
+ \item Brine: The class \texttt{Dumux::Brine} acts as an adapter to the fluid system that alters a pure water class by adding some salt. Hence, the class \texttt{Dumux::Brine} uses a pure water class, such as \texttt{Dumux::H2O}, as a second template argument after the data type \texttt{<Scalar>} as a template argument (be sure to use the complete water class with its own template parameter).
+ \item DNAPL: A standard set of chemical substances, such as Oil and Brine, is already included (via a list of \texttt{\#include ..} commandos) and hence easily accessible by default. This is not the case for the class \texttt{Dumux::SimpleDNAPL}, however, which is located in the folder \texttt{dumux/material/components/}. Try to include the file as well as select the component via the property system.
\end{enumerate}
-If you want to take a closer look 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 at how the fluid classes are defined and which substances are already available please browse through the files in the directory
\texttt{/dumux/material/components}.
\item \textbf{Use the \Dumux fluid system}\label{dec-ex1-fluidsystem} \\
@@ -240,7 +240,7 @@ When does the front cross the material border? In paraview, the option \textit{V
\end{enumerate}
\subsubsection{Exercise 2}
-For this exercise you should create a new proplem file analogous to
+For this exercise you should create a new problem file analogous to
the file \texttt{tutorialproblem\_decoupled.hh} (e.g. with the name
\texttt{ex2\_tutorialproblem\_decoupled.hh} and new spatial parameters
just like \texttt{tutorialspatialparameters\_decoupled.hh}. These files need to
@@ -252,9 +252,9 @@ Make sure that you also adjust the guardian
macros in lines \ref{tutorial-decoupled:guardian1} and \ref{tutorial-decoupled:guardian2}
in the header files (e.g. change \\
\texttt{DUMUX\_TUTORIALPROBLEM\_DECOUPLED\_HH} to
-\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_DECOUPLED\_HH}). Besides also adjusting the guardian macros,
+\texttt{DUMUX\_EX2\_TUTORIALPROBLEM\_DECOUPLED\_HH}). Beside also adjusting the guardian macros,
the new problem file should define and use a new type tag for the problem as well as a new problem class
-e.g. \texttt{Ex2TutorialProblemDecoupled}. Make sure you assign your newly defined spatial
+e.g. \texttt{Ex2TutorialProblemDecoupled}. Make sure to assign your newly defined spatial
parameter class to the \texttt{SpatialParameters} property for the new
type tag.
@@ -262,7 +262,7 @@ After this, change the \texttt{create()} method of the \texttt{Grid}
property so that it matches the domain described
by figure \ref{tutorial-decoupled:ex2_Domain}. Adapt the problem class
so that the boundary conditions are consistent with figure
-\ref{tutorial-decoupled:ex2_BC}. Initially the domain is fully saturated
+\ref{tutorial-decoupled:ex2_BC}. Initially, the domain is fully saturated
with water and the pressure is $p_w = 2 \times 10^5 \text{Pa}$ . Oil
infiltrates from the left side. Create a grid with $20$ cells in
$x$-direction and $10$ cells in $y$-direction. The simulation time
diff --git a/doc/handbook/tutorial.tex b/doc/handbook/tutorial.tex
index 8d437c68cdaeb433fc633afd513f56e71290d9cf..9b30b3914b2fe7ebc2830d7a0f62815337d6154b 100644
--- a/doc/handbook/tutorial.tex
+++ b/doc/handbook/tutorial.tex
@@ -1,10 +1,10 @@
\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 mass balance equations, balance equations of components, energy balance equations, etc. In contrast a decoupled model consists of a pressure equation which is iteratively coupled to a saturation equation, concentration equations, energy balance equations, etc.
+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 mass balance equations, balance equations of components, energy balance equations, etc. In contrast, a decoupled model consists of a pressure equation which is iteratively coupled to a saturation equation, concentration equations, energy balance equations, etc.
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, non-isothermal two-phase two-component models, etc.
-In section \ref{box} a short introduction about the box method is given. The box method is used for the spatial discretization of the system of equations. The other two sections of the tutorial demonstrate how to solve problems first using a 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.
+In section \ref{box} a short introduction about the box method is given. The box method is used for the spatial discretization of the system of equations. The other two sections of the tutorial demonstrate how to solve problems using, first, a coupled model (section \ref{tutorial-coupled}) and, second, using a decoupled model (section \ref{tutorial-decoupled}). Being the easiest case, an isothermal two-phase system (two fluid phases, one solid phase) will be considered.
\input{tutorial-coupled}
\input{tutorial-decoupled}
%\input{tutorial-newmodel}