mirror of
https://github.com/OPM/opm-simulators.git
synced 2024-12-23 07:53:29 -06:00
Compled Tips&Tricks. Fixed various over- and underfull boxed and even more warnings.
This commit is contained in:
Christoph Grueninger
Andreas Lauser
parent
e660848dc9
commit
e5085ee4c8
@ -24,7 +24,7 @@ This list shows the algorithmic outline of a typical \Dumux run employing a full
|
||||
\begin{tabbing}
|
||||
\textbf{\numberThis{main}{init}} \hspace{0.01\textwidth} \=
|
||||
\textbf{\numberThis{time step}{prep}} \hspace{0.01\textwidth} \=
|
||||
\textbf{\numberThis{\textsc{Newton} step}{elem}} \hspace{0.01\textwidth} \=
|
||||
\textbf{\numberThis{Newton step}{elem}} \hspace{0.01\textwidth} \=
|
||||
\textbf{\numberThis{Element}{calc}} \hspace{0.01\textwidth} \\
|
||||
\\
|
||||
initialize \\
|
||||
@ -88,7 +88,7 @@ finalize\\
|
||||
\textcircled{\ref{init}} main\\
|
||||
\textcircled{\ref{prep}} time step\\
|
||||
\textcircled{\ref{elem}} \textsc{Newton} step\\
|
||||
\textcircled{\ref{calc}} Element-wise assembly\\
|
||||
\textcircled{\ref{calc}} Element-wise assembly
|
||||
|
||||
\section{Structure -- by implementation}
|
||||
\label{implementation}
|
||||
@ -413,7 +413,7 @@ $\left \lbrace
|
||||
\verb?derivative is (residual(+eps) - residual(-eps))/2eps?\\
|
||||
\end{tabular}
|
||||
\right .
|
||||
$\\
|
||||
$
|
||||
\end{minipage}
|
||||
\hspace{.25\textwidth}
|
||||
{\scriptsize$\overrightarrow{}$ }
|
||||
|
||||
@ -53,30 +53,32 @@ which translates into a line in the output file reading\\
|
||||
\lstinline{# This was written from [..]/DUMUX_kila/dumux/dumux/io/outputToFile.hh, line 261}\\
|
||||
This can also be very useful, if you want to have information about where some warning or debug information was issued.
|
||||
|
||||
\paragraph{Opttion files optim.opts and debug.opts}
|
||||
\paragraph{Option files optim.opts and debug.opts}
|
||||
|
||||
As explained on page \pageref{buildIt} \Dune and \Dumux are built with the help of the \texttt{dunecontrol}.
|
||||
A lot of options need to be specified for that, which is done in the \verb+debug.opts+ resp. \verb+optim.opts+
|
||||
(plus \verb+.suse11.2+ if applicable) in your \verb+dumux-devel+ directory. These two files differ in the way \Dune / \Dumux is compiled: either for debugging or for fast simulation. Switching between these two states is really
|
||||
A lot of options need to be specified for that, which is done in the \texttt{debug.opts} resp. \texttt{optim.opts}
|
||||
(plus \texttt{.suse11.2} if applicable) in your \texttt{dumux-devel} directory. These two files differ in the way \Dune and \Dumux are compiled: either for debugging or for fast simulation. Switching between these two states is really
|
||||
worth it: speedup of factor $\approx 2$.
|
||||
|
||||
If you want your \Dumux fast than simply build dunecontrol with the \verb+optim.opts+. BUT: Programs that are compiled with optimization can hardly
|
||||
If you want your \Dumux fast than simply build dunecontrol with the \texttt{optim.opts}. BUT: Programs that are compiled with optimization can hardly
|
||||
be debugged because the debugger gets confused. But the cool thing is, that you do NOT need to run dunecontrol if you want to start debugging. You can simply remove the optimization options from your application's Makefile:
|
||||
\begin{itemize}
|
||||
\item open your application's Makefile with the text editor of your choice
|
||||
\item find the line including \verb+CXXFLAGS = [...]+
|
||||
\item find the line including \texttt{CXXFLAGS =}
|
||||
\item these are the options given to the C++ compiler
|
||||
\item add \verb+-g+ (debugging symbols)
|
||||
\item remove \verb+-O3+ (third level optimization, i.e. do not care for anything but execution speed), \verb+-march=native+ and \verb+-DNDEBUG+.
|
||||
\item add \texttt{-g} (debugging symbols)
|
||||
\item remove \texttt{-O3} (third level optimization, i.\,e. do not care for anything but execution speed), \texttt{-march=native} and \texttt{-DNDEBUG}.
|
||||
\item build your application again.
|
||||
\item as long as you only debug your application (and no \Dune stuff) this works, otherwise recompile with dunecontrol and \verb+debug.opts+
|
||||
\item as long as you only debug your application (and no \Dune stuff) this works, otherwise recompile with dunecontrol and \texttt{debug.opts}
|
||||
\item compiling without optimization takes also shorter time
|
||||
\end{itemize}
|
||||
|
||||
(The other possibility is to run dunecontrol with \verb+debug.opts+ and afterwards adding \verb+-O3+ into your application Makefile. The performance penalty does not make a big difference and so do the other options besides \verb+-O3+.)
|
||||
(The other possibility is to run dunecontrol with \texttt{debug.opts} and afterwards adding \texttt{-O3} into your application Makefile. The performance penalty does not make a big difference and so do the other options besides \texttt{-O3})
|
||||
|
||||
Debugging with the optimization options active will lead to erratic beviour while debugging.
|
||||
Debugging with the optimization options active will lead to erratic behavior while debugging.
|
||||
|
||||
\paragraph{Faster build with dunecontrol}
|
||||
A complete build using \texttt{./dune-common/bin/dunecontrol --opts=\$DUMUX\_ROOT/debug.opts all} takes some time. If there were just small changes in the folder structure, it is usually sufficient to run dunecontrol with option \texttt{autogen} instead of \texttt{all}, and afterwards creating the makefiles with option \texttt{configure}.
|
||||
A complete build using \texttt{dunecontrol} takes some time. If there were just small changes in the folder structure, it is usually sufficient to run dunecontrol with option \texttt{autogen} instead of \texttt{all}, and afterwards creating the makefiles with option \texttt{configure}.
|
||||
|
||||
An other possibility to speed up dunecontrol is caching of configure results. Add to the configure flags the line \texttt{--cache-file=/tmp/dune-config.cache} in you options file.
|
||||
|
||||
|
||||
@ -184,8 +184,8 @@ int main()
|
||||
}
|
||||
\end{lstlisting}
|
||||
|
||||
For both types of cars, \texttt{Lupo} and \texttt{S} the
|
||||
\texttt{printMaxRange} function works as expected, yielding
|
||||
For both types of cars, \texttt{Lupo} and \texttt{S} the function
|
||||
\texttt{printMaxRange} works as expected, yielding
|
||||
$1003.3\;\mathrm{km}$ for the Lupo and $722.2\;\mathrm{km}$ for the
|
||||
S-Class.
|
||||
\end{example}
|
||||
|
||||
@ -775,7 +775,7 @@
|
||||
and Steam)},
|
||||
title = {Revised Release on the IAPS Formulation 1985 for the Viscosity of
|
||||
Ordinary Water Substance},
|
||||
howpublished = {http://www.iapws.org/},
|
||||
howpublished = {\url{http://www.iapws.org/}},
|
||||
year = {2003}
|
||||
}
|
||||
|
||||
@ -784,7 +784,7 @@
|
||||
and Steam)},
|
||||
title = {Revised Release on the IAPWS Industrial Formulation 1997 for the
|
||||
Thermodynamic Properties of Water and Steam},
|
||||
howpublished = {http://www.iapws.org/IF97-Rev.pdf},
|
||||
howpublished = {\url{http://www.iapws.org/IF97-Rev.pdf}},
|
||||
year = {1997}
|
||||
}
|
||||
|
||||
@ -806,7 +806,7 @@
|
||||
doi = {DOI: 10.1016/j.future.2003.07.011},
|
||||
issn = {0167-739X},
|
||||
keywords = {Computational sciences},
|
||||
url = {http://www.sciencedirect.com/science/article/B6V06-49NXY7J-F/2/e8260e5d8f19639019cddea4776c024c}
|
||||
url = {\url{http://www.sciencedirect.com/science/article/B6V06-49NXY7J-F/2/e8260e5d8f19639019cddea4776c024c}}
|
||||
}
|
||||
|
||||
@PHDTHESIS{SHETA1999,
|
||||
|
||||
@ -28,6 +28,15 @@
|
||||
aboveskip=\bigskipamount,
|
||||
belowskip=\bigskipamount
|
||||
}
|
||||
% for listings of DuMuX code
|
||||
\lstdefinestyle{DumuxCode}
|
||||
{language=C++,
|
||||
basicstyle=\ttfamily\scriptsize,
|
||||
numbers=left,
|
||||
numberstyle=\tiny,
|
||||
numbersep=5pt,
|
||||
breaklines=true
|
||||
}
|
||||
\lstset{showstringspaces=false}
|
||||
|
||||
\usepackage{hyperref}
|
||||
@ -41,6 +50,8 @@
|
||||
\usepackage{rotating}
|
||||
\usepackage{subfig}
|
||||
\usepackage{units}
|
||||
\usepackage{url}
|
||||
\usepackage{breakurl}
|
||||
|
||||
\ifpdf
|
||||
\usepackage{auto-pst-pdf}
|
||||
@ -55,13 +66,12 @@
|
||||
}
|
||||
\usepackage{layout}
|
||||
|
||||
%\usepackage{ngerman}
|
||||
\usepackage[english]{babel}
|
||||
|
||||
\DeclareGraphicsExtensions{.eps, .jpg}
|
||||
|
||||
\newcommand{\Dune}{{DUNE}\xspace}
|
||||
\newcommand{\Dumux}{Du\-Mu$^x$\xspace}
|
||||
\newcommand{\Dumux}{\texorpdfstring{Du\-Mu$^x$\xspace}{DuMuX}}
|
||||
|
||||
\newcommand{\porosity}{\phi}
|
||||
\newcommand{\saturation}{S}
|
||||
|
||||
@ -9,7 +9,6 @@ effort to write them in the first place. The remainder of this section
|
||||
is almost a verbatim copy of the DUNE coding guidelines found at
|
||||
\cite{DUNE-HP}. These guidelines are also recommended for coding with
|
||||
\Dumux as developer and user.
|
||||
\\
|
||||
|
||||
In order to keep the code maintainable we have decided upon a set of
|
||||
coding rules. Some of them may seem like splitting hairs to you, but
|
||||
@ -20,12 +19,12 @@ been written by oneself.
|
||||
\item Naming:
|
||||
\begin{itemize}
|
||||
\item Comments: they are helpful! Please document freely what each part of your code does.
|
||||
\item all comments / documentation is in english
|
||||
\item all comments / documentation is in English
|
||||
\item Variables: Names for variables should only consist of letters and digits. The first letter should be a lower case one. If your variable names consists of several words, then the first letter of each new word should be capital. As we decided on the only exception are the begin and end methods.
|
||||
\item Variables should be named as self-explaining as possible: especially abbreviations should be avoided (saturation in stead of S)
|
||||
\item Method parameters which are not self-explanatory should always
|
||||
have a meaningful comment a at calling sites. Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
localResidual.eval(/*includeBoundaries=*/true);
|
||||
\end{lstlisting}
|
||||
\item Private Data Variables: Names of private data variables end with an underscore and are the only variables that contain underscores.
|
||||
|
||||
@ -158,7 +158,7 @@ subdirectories of \texttt{dumux/boxmodels} of the \Dumux distribution.
|
||||
\subsubsection{The single-phase, two-component model: OnePTwoCBoxModel}
|
||||
\input{ModelDescriptions/1p2cboxmodel}
|
||||
|
||||
\subsubsection{The two-phase model using the \textsc{Richards} assumption: RichardsBoxModel}
|
||||
\subsubsection{The two-phase model using the Richards assumption: RichardsBoxModel}
|
||||
\input{ModelDescriptions/richardsboxmodel}
|
||||
|
||||
\subsubsection{The two-phase model: TwoPBoxModel}
|
||||
@ -182,13 +182,13 @@ subdirectories of \texttt{dumux/boxmodels} of the \Dumux distribution.
|
||||
\subsubsection{The $M$-phase, $N$-component model: MpNcBoxModel}
|
||||
\input{ModelDescriptions/mpncboxmodel}
|
||||
|
||||
\subsubsection{The \textsc{Stokes} model: StokesModel}
|
||||
\subsubsection{The Stokes model: StokesModel}
|
||||
\input{ModelDescriptions/stokesmodel}
|
||||
|
||||
\subsubsection{The isothermal two-component \textsc{Stokes} model: Stokes2cModel}
|
||||
\subsubsection{The isothermal two-component Stokes model: Stokes2cModel}
|
||||
\input{ModelDescriptions/stokes2cmodel}
|
||||
|
||||
\subsubsection{The non-isothermal two-component \textsc{Stokes} model: Stokes2cniModel}
|
||||
\subsubsection{The non-isothermal two-component Stokes model: Stokes2cniModel}
|
||||
\input{ModelDescriptions/stokes2cnimodel}
|
||||
|
||||
\subsection{Decoupled models}
|
||||
|
||||
@ -76,7 +76,6 @@ Secondly you can see, that there is a variable in the input file which the prog
|
||||
If you also want to specify the grid and spatial extension of your problem via the parameter file, please have a look at
|
||||
\newline
|
||||
\texttt{/test/boxmodels/2p/}.
|
||||
\newline
|
||||
|
||||
\subsection{Technical Issues}
|
||||
In case you want to learn more about how the input files work, please have a look at the very helpful \Dune documentation, look for \texttt{Dune::ParameterTree}.
|
||||
|
||||
@ -43,7 +43,7 @@ namespace \texttt{Dumux::Properties}.
|
||||
\subsection*{Defining Type Tags}
|
||||
|
||||
New nodes in the type tag hierarchy can be defined using
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
NEW_TYPE_TAG(NewTypeTagName, INHERITS_FROM(BaseTagName1, BaseTagName2, ...));
|
||||
\end{lstlisting}
|
||||
where the \texttt{INHERITS\_FROM} part is optional. To avoid
|
||||
@ -52,7 +52,7 @@ once for a program.
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
namespace Dumux {
|
||||
namespace Properties {
|
||||
NEW_TYPE_TAG(MyBaseTypeTag1);
|
||||
@ -66,7 +66,7 @@ NEW_TYPE_TAG(MyDerivedTypeTag, INHERITS_FROM(MyBaseTypeTag1, MyBaseTypeTag2));
|
||||
|
||||
New property tags -- i.e. labels for properties -- are declared
|
||||
using
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
NEW_PROP_TAG(NewPropTagName);
|
||||
\end{lstlisting}
|
||||
A property tag can be declared arbitrarily often, in fact it is
|
||||
@ -75,7 +75,7 @@ are used.
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
namespace Dumux {
|
||||
namespace Properties {
|
||||
NEW_PROP_TAG(MyPropertyTag);
|
||||
@ -86,7 +86,7 @@ NEW_PROP_TAG(MyPropertyTag);
|
||||
|
||||
The value of a property on a given node of the type tag hierarchy is
|
||||
defined using
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
SET_PROP(TypeTagName, PropertyTagName)
|
||||
{
|
||||
// arbitrary body of a struct
|
||||
@ -97,7 +97,7 @@ although properties may be overwritten for derived type tags.
|
||||
|
||||
Also, the following convenience macros are available to define simple
|
||||
properties:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
SET_TYPE_PROP(TypeTagName, PropertyTagName, type);
|
||||
SET_BOOL_PROP(TypeTagName, PropertyTagName, booleanValue);
|
||||
SET_INT_PROP(TypeTagName, PropertyTagName, integerValue);
|
||||
@ -106,7 +106,7 @@ SET_SCALAR_PROP(TypeTagName, PropertyTagName, floatingPointValue);
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
namespace Dumux {
|
||||
namespace Properties {
|
||||
NEW_TYPE_TAG(MyTypeTag);
|
||||
@ -135,7 +135,7 @@ SET_SCALAR_PROP(MyTypeTag, MyScalarValue, 12345.67890);
|
||||
Sometimes some inherited properties do not make sense for a certain
|
||||
node in the type tag hierarchy. These properties can be explicitly
|
||||
un-set using
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
UNSET_PROP(TypeTagName, PropertyTagName);
|
||||
\end{lstlisting}
|
||||
The un-set property can not be set for the same type tag, but of
|
||||
@ -143,7 +143,7 @@ course derived type tags may set it again.
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
namespace Dumux {
|
||||
namespace Properties {
|
||||
NEW_TYPE_TAG(BaseTypeTag);
|
||||
@ -169,11 +169,11 @@ ought to be used.
|
||||
\subsection*{Retrieving Property Values}
|
||||
|
||||
The value of a property can be retrieved using
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
GET_PROP(TypeTag, PropertyTag)
|
||||
\end{lstlisting}
|
||||
or using the convenience macros
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
GET_PROP_TYPE(TypeTag, PropertyTag)
|
||||
GET_PROP_VALUE(TypeTag, PropertyTag)
|
||||
\end{lstlisting}
|
||||
@ -182,19 +182,19 @@ GET_PROP_VALUE(TypeTag, PropertyTag)
|
||||
\noindent
|
||||
The first convenience macro retrieves the type defined using
|
||||
\texttt{SET\_TYPE\_PROP} and is equivalent to
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
GET_PROP(TypeTag, PropertyTag)::type
|
||||
\end{lstlisting}
|
||||
while the second convenience macro retrieves the value of any property
|
||||
defined using \texttt{SET\_\{INT,BOOL,SCALAR\}\_PROP} and is
|
||||
defined using one of the macros \texttt{SET\_}$\{$\texttt{INT,BOOL,SCALAR}$\}$\texttt{\_PROP} and is
|
||||
equivalent to
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
GET_PROP(TypeTag, PropertyTag)::value
|
||||
\end{lstlisting}
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:\nolinebreak
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
template <TypeTag>
|
||||
class MyClass {
|
||||
// retrieve the ::value attribute of the 'NumEq' property
|
||||
@ -219,7 +219,7 @@ retrieve other properties using the \texttt{GET\_PROP} macros.
|
||||
|
||||
\vskip1ex\noindent
|
||||
Example:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
SET_PROP(MyModelTypeTag, Vector)
|
||||
{
|
||||
private: typedef typename GET_PROP_TYPE(TypeTag, Scalar) Scalar;
|
||||
@ -257,7 +257,7 @@ diagram for the car types above might look like outlined in Figure
|
||||
|
||||
Using the \Dumux property system, this inheritance hierarchy is
|
||||
defined by:
|
||||
\begin{lstlisting}[name=propsyscars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[name=propsyscars,style=DumuxCode]
|
||||
#include <dumux/common/propertysystem.hh>
|
||||
#include <iostream>
|
||||
|
||||
@ -275,7 +275,7 @@ Figure \ref{fig:car-propertynames} lists a few property names which
|
||||
make sense for at least one of the nodes of Figure
|
||||
\ref{fig:car-hierarchy}. These property names can be declared as
|
||||
follows:
|
||||
\begin{lstlisting}[name=propsyscars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[name=propsyscars,style=DumuxCode]
|
||||
NEW_PROP_TAG(TopSpeed); // [km/h]
|
||||
NEW_PROP_TAG(NumSeats); // []
|
||||
NEW_PROP_TAG(CanonCaliber); // [mm]
|
||||
@ -311,7 +311,7 @@ the following:
|
||||
\noindent
|
||||
Using the \Dumux property system, these assumptions are formulated
|
||||
using
|
||||
\begin{lstlisting}[name=propsyscars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[name=propsyscars,style=DumuxCode]
|
||||
SET_INT_PROP(CompactCar, TopSpeed, GET_PROP_VALUE(TypeTag, GasUsage) * 30);
|
||||
SET_INT_PROP(CompactCar, NumSeats, 5);
|
||||
SET_INT_PROP(CompactCar, GasUsage, 4);
|
||||
@ -337,7 +337,7 @@ SET_INT_PROP(HummerH1, TopSpeed, GET_PROP_VALUE(TTAG(Pickup), TopSpeed));
|
||||
\noindent
|
||||
At this point, the Hummer-H1 has a $120\;mm$ canon which it inherited
|
||||
from its military ancestor. It can be removed by
|
||||
\begin{lstlisting}[name=propsyscars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[name=propsyscars,style=DumuxCode]
|
||||
UNSET_PROP(HummerH1, CanonCaliber);
|
||||
|
||||
}} // close namespaces
|
||||
@ -346,7 +346,7 @@ UNSET_PROP(HummerH1, CanonCaliber);
|
||||
\noindent
|
||||
Now property values can be retrieved and some diagnostic messages can
|
||||
be generated. For example
|
||||
\begin{lstlisting}[name=propsyscars,basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[name=propsyscars,style=DumuxCode]
|
||||
int main()
|
||||
{
|
||||
std::cout << "top speed of sedan: " << GET_PROP_VALUE(TTAG(Sedan), TopSpeed) << "\n";
|
||||
@ -359,7 +359,7 @@ int main()
|
||||
}
|
||||
\end{lstlisting}
|
||||
will yield the following output:
|
||||
\begin{lstlisting}[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny, numbersep=5pt]
|
||||
\begin{lstlisting}[style=DumuxCode]
|
||||
top speed of sedan: 210
|
||||
top speed of truck: 100
|
||||
Properties for Sedan:
|
||||
|
||||
@ -25,7 +25,7 @@ $ checkout-dumux -gme -u joeuser -p password -d DUMUX
|
||||
Building of \Dune and \Dumux is done by the command-line script \texttt{dunecontrol} as described in \Dune Installation Notes \cite{DUNE-INST}
|
||||
and in much more comprehensive form in the \Dune Buildsystem Howto \cite{DUNE-BS}.
|
||||
If something fails during the execution of \texttt{dunecontrol} feel free to report it to the \Dune or \Dumux developer mailing list,
|
||||
but also try to include error details.\\
|
||||
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
|
||||
|
||||
@ -57,8 +57,7 @@ model. This file has to be compiled and executed in order to solve the problem d
|
||||
above.
|
||||
|
||||
\begin{lst}[File tutorial/tutorial\_coupled.cc]\label{tutorial-coupled:mainfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=29]{../../tutorial/tutorial_coupled.cc}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=29]{../../tutorial/tutorial_coupled.cc}
|
||||
\end{lst}
|
||||
|
||||
From line \ref{tutorial-coupled:include-begin} to line
|
||||
@ -88,7 +87,7 @@ 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{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny]{../../tutorial/tutorial_coupled.input}
|
||||
\lstinputlisting[style=DumuxCode]{../../tutorial/tutorial_coupled.input}
|
||||
\end{lst}
|
||||
|
||||
To provide an error message, the usage message which is displayed to
|
||||
@ -107,8 +106,7 @@ so-called \textit{problem file} as shown in
|
||||
listing~\ref{tutorial-coupled:problemfile}.
|
||||
|
||||
\begin{lst}[File tutorial/tutorialproblem\_coupled.hh]\label{tutorial-coupled:problemfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=28]{../../tutorial/tutorialproblem_coupled.hh}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=28]{../../tutorial/tutorialproblem_coupled.hh}
|
||||
\end{lst}
|
||||
|
||||
First, a new type tag is created for the problem in line
|
||||
@ -262,8 +260,7 @@ should be derived from the base class
|
||||
\verb+tutorialspatialparameters_coupled.hh+:
|
||||
|
||||
\begin{lst}[File tutorial/tutorialspatialparameters\_coupled.hh]\label{tutorial-coupled:spatialparametersfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=28]{../../tutorial/tutorialspatialparameters_coupled.hh}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=28]{../../tutorial/tutorialspatialparameters_coupled.hh}
|
||||
\end{lst}
|
||||
|
||||
First, the spatial parameters type tag is created on line
|
||||
@ -349,7 +346,7 @@ to make only some small changes in the tutorial files.
|
||||
\begin{enumerate}
|
||||
|
||||
\item \textbf{Running the Program} \\
|
||||
To get an impression what the results should look like you can first run the original version of the coupled tutorial model by typing \texttt{./tutorial\_coupled}. Note, that the time-step size is automatically adapted during the simulation. For the visualization of the results using paraview please refer to section \ref{quick-start-guide}.\\
|
||||
To get an impression what the results should look like you can first run the original version of the coupled tutorial model by typing \texttt{./tutorial\_coupled}. Note, that the time-step size is automatically adapted during the simulation. For the visualization of the results using paraview please refer to section \ref{quick-start-guide}.
|
||||
|
||||
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\
|
||||
Change the size of the model domain so that you get a rectangle with
|
||||
@ -494,7 +491,7 @@ compile the program.
|
||||
|
||||
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}.\\
|
||||
via \textit{parameter input files}.
|
||||
|
||||
In the code, parameters can be read via the macro
|
||||
\texttt{GET\_RUNTIME\_PARAM(TypeTag, Scalar,
|
||||
|
||||
@ -42,8 +42,7 @@ effects are neglected.
|
||||
Listing \ref{tutorial-deoucpled:mainfile} shows how the main file, which has to be executed, has to be set up, if the problem described above is to be solved using a decoupled model. This main file can be found in the directory \texttt{/tutorial} of the stable part of \Dumux.
|
||||
|
||||
\begin{lst}[File tutorial/tutorial\_decoupled.cc]\label{tutorial-deoucpled:mainfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=28]{../../tutorial/tutorial_decoupled.cc}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=28]{../../tutorial/tutorial_decoupled.cc}
|
||||
\end{lst}
|
||||
|
||||
First, from line \ref{tutorial-decoupled:include-begin} to line
|
||||
@ -71,7 +70,7 @@ precedence. Listing~\ref{tutorial-decoupled:parameter-file} shows the
|
||||
default parameter file for the tutorial problem.
|
||||
|
||||
\begin{lst}[File tutorial/tutorial\_decoupled.input]\label{tutorial-decoupled:parameter-file} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,numberstyle=\tiny]{../../tutorial/tutorial_decoupled.input}
|
||||
\lstinputlisting[style=DumuxCode]{../../tutorial/tutorial_decoupled.input}
|
||||
\end{lst}
|
||||
|
||||
To provide an error message, the usage message which is displayed to
|
||||
@ -90,8 +89,7 @@ so-called \textit{problem file} as shown in listing
|
||||
\texttt{tutorialproblem\_decoupled.hh}.
|
||||
|
||||
\begin{lst}[File tutorial/tutorialproblem\_decoupled.hh]\label{tutorial-decoupled:problemfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=28]{../../tutorial/tutorialproblem_decoupled.hh}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=28]{../../tutorial/tutorialproblem_decoupled.hh}
|
||||
\end{lst}
|
||||
|
||||
First, both \Dune grid handlers and the decoupled model of \Dumux
|
||||
@ -158,7 +156,7 @@ function argument: Both are \Dune entities, depending on whether the parameter o
|
||||
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:initial}. For more information
|
||||
quantity in line \ref{tutorial-decoupled:initial}. For more information
|
||||
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}
|
||||
@ -167,8 +165,7 @@ Listing \ref{tutorial-decoupled:spatialparametersfile} shows the file
|
||||
\verb+tutorialspatialparameters_decoupled.hh+:
|
||||
|
||||
\begin{lst}[File tutorial/tutorialspatialparameters\_decoupled.hh]\label{tutorial-decoupled:spatialparametersfile} \mbox{}
|
||||
\lstinputlisting[basicstyle=\ttfamily\scriptsize,numbers=left,
|
||||
numberstyle=\tiny, numbersep=5pt, firstline=26]{../../tutorial/tutorialspatialparameters_decoupled.hh}
|
||||
\lstinputlisting[style=DumuxCode, numbersep=5pt, firstline=26]{../../tutorial/tutorialspatialparameters_decoupled.hh}
|
||||
\end{lst}
|
||||
As this file only slightly differs from the coupled version, consult
|
||||
chapter \ref{tutorial-coupled:description-spatialParameters} for explanations.
|
||||
@ -194,7 +191,7 @@ As you can see, the simulation creates many output files. To reduce these in ord
|
||||
\item \textbf{Changing the Model Domain and the Boundary Conditions} \\
|
||||
Change the size of the model domain so that you get a rectangle
|
||||
with edge lengths of x = 300 m \\ and y = 300 m and with discretisation lengths of $\Delta \text{x} = 20$ m and $\Delta \text{y} = 10$ m. \\
|
||||
Change the boundary conditions in the file \texttt{tutorialproblem\_decoupled.hh} so that water enters from the bottom and oil flows out at the top boundary. The right and the left boundary should be closed for water and oil fluxes. \\
|
||||
Change the boundary conditions in the file \texttt{tutorialproblem\_decoupled.hh} so that water enters from the bottom and oil flows out at the top boundary. The right and the left boundary should be closed for water and oil fluxes.
|
||||
|
||||
\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:
|
||||
|
||||
Loading…
Reference in New Issue
Block a user