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

streamlined the formatting of \Dune , \Dune-Root, changed some requesites related stuff

Browse Source
This commit is contained in:
Philipp Nuske 2011-01-03 16:53:52 +00:00 committed by Andreas Lauser
parent 283b4e2115
commit 3357e88a79
4 changed files with 20 additions and 19 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
doc/handbook/TipsNTricks.tex
View File

@ -1,6 +1,7 @@
\chapter{Tips \& Tricks}
This chapter tries to be a useful collection of tips and tricks that can be handy when working with
\Dumux. One of the most prominent ideas for developing DUNE/\Dumux is that reinventing the wheel in terms of FEM-code should
\Dumux. One of the most prominent ideas for developing \Dune / \Dumux is that reinventing the wheel in terms of FEM-code should
be avoided. We try to follow this idea also in the day-to-day work by stating the \emph{tell us dogma}: ``If you found something useful,
handy or for other reasons helping when working with \Dumux: put it into this chapter.'' (or at least write it to the mailing list \\ \verb+dumux@iws.uni-stuttgart.de+ so somebody else can).
\begin{itemize}
@ -20,14 +21,14 @@ Everybody using the same profile has the advantage of resulting in less conflic
and/or advanced features (hereafter called ``stuff'') to the repository. But maybe you forgot to commit this one and tiny change in one file you forgot about.
This may result in \Dumux not compiling any more on another person's computer after updating . How to prevent this?
Simply check out DUNE/\Dumux twice. How is this helping? Now you can work in one version and after commiting you can simply update the pristine version and see whether it still works there, too.
Simply check out \Dune / \Dumux twice. How is this helping? Now you can work in one version and after commiting you can simply update the pristine version and see whether it still works there, too.
This approach really helps keeping the bumps in the work-flow small.
\item Using DUNE debug streams:
\item Using \Dune debug streams:
DUNE provides a helpful feature, for keeping your debug-output organized.
\Dune provides a helpful feature, for keeping your debug-output organized.
In stead of juggling with a bazillion \verb+std::cout<<+ statements or keeping some debug-precompiler statements organized (which are generally and strongly discouraged see \ref{guidelines} ) in order not to get
flooded away by your output DUNE gives you a nice tool: so called debug streams.
flooded away by your output \Dune gives you a nice tool: so called debug streams.
These are streams (like \verb+cout+) but they can be switched on and off for the whole project.
May be if you are really in the dark you want to see all your debug information. Another time you may only want to be warned if something is going seriously wrong during a simulation.
@ -65,9 +66,9 @@ This can also be very useful, if you want to have information about where some w
\item optim.opts / debug.opts
As explained on page \pageref{buildIt} DUNE and \Dumux are built with the help of the \verb+dunecontrol+ buildsystem.
As explained on page \pageref{buildIt} \Dune and \Dumux are built with the help of the \verb+dunecontrol+ buildsystem.
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
(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
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
@ -79,7 +80,7 @@ be debugged because the debugger gets confused. But the cool thing is, that you
\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 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 \verb+debug.opts+
\item compiling without optimization takes also shorter time
\end{itemize}

1
doc/handbook/dumux-handbook.tex
View File

@ -3,6 +3,7 @@
\usepackage[ansinew]{inputenc}
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{theorem}
\usepackage{color}
\usepackage{listings}

13
doc/handbook/install.tex
View File

@ -19,9 +19,8 @@ Each \Dune module is associated with a directory name in the folder {\Dune}-ROOT
The gnu toolchain of \texttt{g++} and related gnu variants of developer tools like \texttt{libtool}, \texttt{make} and
and \texttt{automake} must be available in a recent version.
The \Dumux property system, which is used in most of the models, makes use of \texttt{libboost}.
It is thus necessary to install the developer version of \texttt{boost}.
It is thus necessary to install a \texttt{boost} version $\geqslant 1.33.1$.
The building of the documentation requires \LaTeX\ and auxiliary tools like \texttt{dvipdf} and \texttt{bibtex}.
Additionally, the program \texttt{convert} from the package ImageMagick is needed to build the handbook.
If you use the configuration switch \texttt{--enable-doxygen} in order to generate the doxygen files (documentation generator) you will also need \texttt{doxygen}.
Depending on the usage of external libraries the required software packages may vary.
@ -33,7 +32,7 @@ They can be obtained as so-called tarballs, i.e. \Dumux and \Dune code files of
The shell command \texttt{tar} can be used to extract them on your file system. This is explained in the next paragraph.
\paragraph{Obtaining the software by installing tarballs}
Download the tarballs from the website. You can install the obtained tarballs as follows: Create a {\Dune}-Root-directory, which we call here DUMUX.
Download the tarballs from the respective websites. You can install the obtained tarballs as follows: Create a {\Dune}-ROOT-directory, which we call here DUMUX.
For the installation in the shell, type the following commands:
\begin{itemize}
\item \texttt{mkdir DUMUX}
@ -77,7 +76,7 @@ and work yourself through that tutorial in order to get an understanding of the
\paragraph{Checkout of \Dumux}
In order to obtain an anonymous read-only copy of the stable part of \Dumux from the repository, the most simple way is to type
In order to obtain an anonymous read-only copy of the \emph{stable} part of \Dumux from the repository, the most simple way is to type
\begin{itemize}
\item \texttt{svn checkout --username=anonymous --password=''\\
\hspace{4cm} svn://svn.iws.uni-stuttgart.de/DUMUX/dumux/trunk dumux}
@ -97,7 +96,7 @@ You can omit the username option, if your username for the repository access is
Please choose either not to store the password or to store it by subversion in a secure way (check the documentation of subversion for that).
A leaked out password can be used by evil persons to vandalize a software repository.
When using subversion it is possible, provided that to you are granted developer and have write permissions to repositories, to feed back your own code or code modifications to the software repositories.
When using subversion it is possible, provided that to you are granted developer access and have write permissions to repositories, to feed back your own code or code modifications to the software repositories.
Moreover, with direct access to the repositories it is easier to keep up with code changes, to receive important bug fixes and to keep up with general developments of code.
\paragraph{External libraries and modules}
@ -156,7 +155,7 @@ It is also reported that \Dune was successfully build with the Intel C++ compile
\paragraph{Hint for IWS Users} Users from the Institute of Hydraulic Engineering, University of Stuttgart,
can also checkout a svn repository with several external libraries: \\
\texttt{svn checkout svn://svn.iws.uni-stuttgart.de/DUMUX/external/trunk external}.\\
\texttt{svn checkout svn://svn.iws.uni-stuttgart.de/DUMUX/external/trunk external}\\
This directory \texttt{external} contains a script to install external libraries, such as
\texttt{alberta}, \texttt{alu}, \texttt{ug}. It also contains METIS and the BLAS version of libGOTO2:
@ -174,7 +173,7 @@ But a \Dune build still needs to know where they are. You have to refer to them
\paragraph{Build \Dune and \Dumux}
\label{buildIt}
To compile \Dumux without additional options file, type in the {\Dune}-Root-directory (called \texttt{DUMUX} before):
To compile \Dumux without additional options file, type in the {\Dune}-ROOT-directory (called \texttt{DUMUX} before):
\begin{center}
\texttt{./dune-common/bin/dunecontrol all}
\end{center}

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

@ -47,7 +47,7 @@ numberstyle=\tiny, numbersep=5pt]{../../tutorial/tutorial_decoupled.cc}
\end{lst}
First, from line \ref{tutorial-decoupled:include-begin} to line
\ref{tutorial-decoupled:include-end} the Dune and \Dumux files containing
\ref{tutorial-decoupled:include-end} the \Dune and \Dumux files containing
essential functions and classes are included.
At line \ref{tutorial-decoupled:set-type-tag} the type tag of the
@ -59,7 +59,7 @@ single type tag. Retrieving them is done between line
property system, see section \ref{sec:propertysystem}.
The first thing which should be done at run time is to initialize the
message passing interface using DUNE's \texttt{MPIHelper} class. Line
message passing interface using \Dune's \texttt{MPIHelper} class. Line
\ref{tutorial-decoupled:init-mpi} line 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
@ -103,7 +103,7 @@ 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} --
in this case an \texttt{SGrid} is created. Since in Dune, there's no uniform
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
\ref{tutorial-decoupled:grid-begin} to \ref{tutorial-decoupled:grid-end},
@ -112,7 +112,7 @@ 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}). 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
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
the \textit{Dune Grid Interface HOWTO} \cite{DUNE-HP}.