OilfieldToolsNet/opm-simulators
4
0
Fork 0
mirror of https://github.com/OPM/opm-simulators.git synced 2024-12-23 07:53:29 -06:00
Code Issues Packages Projects Releases Wiki Activity

Scanned chaper install in the manual.

Browse Source
This commit is contained in:
Christoph Grueninger 2012-02-24 12:42:40 +00:00 committed by Andreas Lauser
parent e5085ee4c8
commit e71e298b00
7 changed files with 33 additions and 43 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
doc/handbook/designpatterns.tex
View File

@ -185,7 +185,7 @@ int main()
\end{lstlisting}
For both types of cars, \texttt{Lupo} and \texttt{S} the function
\texttt{printMaxRange} works as expected, yielding
\texttt{printMaxRange} works as expected, it yields
$1003.3\;\mathrm{km}$ for the Lupo and $722.2\;\mathrm{km}$ for the
S-Class.
\end{example}

2
doc/handbook/dumux-handbook.bib
View File

@ -999,7 +999,7 @@
}
@MISC{WIKIPED-ALIASING,
title = {wikipedia about aliasing an optimzation: \url{http://en.wikipedia.org/wiki/Aliasing\_(computing)}},
title = {wikipedia about aliasing data location in memory: \url{http://en.wikipedia.org/wiki/Aliasing\_(computing)}},
key = {WikipediaAliasing}
}

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

@ -37,7 +37,8 @@
numbersep=5pt,
breaklines=true
}
\lstset{showstringspaces=false}
\lstset{showstringspaces=false,
breaklines=true}
\usepackage{hyperref}
\usepackage{psfrag}

2
doc/handbook/fluidframework.tex
View File

@ -346,7 +346,7 @@ only needs to provide the following thermodynamic relations:
\end{description}
Fluid systems may chose not to implement some of these methods and
throw a \texttt{Dune::NotImplemented} exception instead. Obviously,
throw an exception of type \lstinline{Dune::NotImplemented} instead. Obviously,
such fluid systems cannot be used for models that depend on those
methods.

41
doc/handbook/parameterTree.tex
View File

@ -1,7 +1,7 @@
\section{Parameter Files in \Dumux}
\label{sec:inputFiles}
In section \ref{quick-start-guide} an application was started using an input file.
This file is worth taking a look at because using it considerably improves usability.
This file is worth taking a closer look at because using it considerably improves usability.
\begin{itemize}
\item The parameter file is read in by the compiled program. This way you can change
@ -10,7 +10,7 @@ values in there without having to recompile the whole application.
\item The parameter file is easily extendable.
\end{itemize}
After having run the example application from section \ref{quick-start-guide} you will (almost) get the following output\footnote{If you did not get the output, restart the application the following way:
After having run the example application from section \ref{quick-start-guide} you will (almost) get the following output\footnote{If you did not get the output, restart the application the following way:
\texttt{./test{\_}2p -parameterFile ./test\_2p.input -PrintParameters 1 }} at the end of the simulation run:
\begin{lstlisting}[style=Bash]
###############################
@ -57,28 +57,33 @@ SpatialParameters.sthIMadeUp = "42"
\end{lstlisting}
A number of things can be learned from this. Most prominently it tells you the parameters, that can easily be added to the input file without having to change anything in the source code.
By simply adding the lines \newline \texttt{[ Newton ]\newline RelTolerance = 1e-11}\newline to the input file you can specify that the newton solver considers itself converged for an error a thousand times smaller.
By simply adding the lines\\
\texttt{[ Newton ]\\
RelTolerance = 1e-11}\\
to the input file you can specify that the Newton solver considers itself converged for an error a thousand times smaller.
Secondly you can see, that there is a variable in the input file which the program did not use:
\newline
\texttt{SpatialParameters.sthIMadeUp = "42"}.
\newline
This output was generated by adding the line \newline \verb+sthIMadeUp = 42 # [strangeUnit]+\newline at the end of the parameter file. Because the application did not read in this value it is shown here under \texttt{UNUSED PARAMETERS}. You can also see, that the variable was grouped into the SpatialParameters group, because no new group was started.
\newline
\texttt{SpatialParameters.sthIMadeUp = "42"}.
\newline
This output was generated by adding the line \\
\lstinline{sthIMadeUp = 42 # [strangeUnit]}\\
at the end of the parameter file. Because the application did not read in this value it is shown here under \texttt{UNUSED PARAMETERS}. You can also see, that the variable was grouped into the SpatialParameters group, because no new group was started.
This feature is \emph{very} useful for debugging or spotting typos. If you want to overwrite one of the parameters listed under \texttt{Compile-time specified parameters} and misspelled it in the input file, it will be listed in the \texttt{UNUSED PARAMETERS} section.
This feature is \emph{very} useful for debugging or spotting typos. If you want to overwrite one of the parameters listed under \texttt{Compile-time specified parameters} and misspelled it in the input file, it will be listed in the \texttt{UNUSED PARAMETERS} section.
For further use of the input file please refer to the problem file
For further use of the input file please refer to the problem file
\newline
\texttt{/test/boxmodels/2p2c/injectionproblem.hh}.
\newline
In there, a number of parameters are read in for use in the actual problem.
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/2p2c/injectionproblem.hh}.
\newline
In there, a number of parameters are read in for use in the actual problem.
\texttt{/test/boxmodels/2p/}.
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/}.
\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}.
\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}.
The parameter tree can also be filled without the help of a text file. Everything that is specified in a \Dumux input file can also be specified directly on the command line. If there is also an input file, the respective parameter on the command line has precedence.

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

@ -13,7 +13,6 @@ It is contained in the download section of the \Dumux web page \cite{DUMUX-HP}.
For example the second line below will check out the required \Dune modules and \texttt{dumux},
\texttt{dumux-devel} and the \texttt{external} folder, which contains some useful external software and libraries.
Again, \texttt{joeuser} needs to be replaced by the actual user name.
\begin{lstlisting}[style=Bash]
$ checkout-dumux -h # show help,
$ checkout-dumux -gme -u joeuser -p password -d DUMUX
@ -28,26 +27,17 @@ If something fails during the execution of \texttt{dunecontrol} feel free to rep
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 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
the option \texttt{-fno-strict-aliasing} to the C++-compiler
\cite{WIKIPED-ALIASING}, which is done here via a command-line argument to \texttt{dunecontrol}:
\begin{lstlisting}[style=Bash]
$ # 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.
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 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
$ cp dumux/debug.opts my-debug.opts # create a personal version
@ -56,7 +46,6 @@ $ ./dune-common/bin/dunecontrol --opts=my-debug.opts all
\end{lstlisting}
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
$ ./dune-common/bin/dunecontrol --opts=my-optim.opts all

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

@ -1,17 +1,12 @@
\section[Quick start guide]{Quick start guide: The first run of a test application}\label{quick-start-guide}
The previous chapter showed how to install and compile \Dumux. This chapter shall give a very brief introduction how to run a first test application and how to visualize the first output files. Only the rough steps will be described here. More detailed explanations can be found in the tutorials in the following chapter.
The previous section showed how to install and compile \Dumux. This chapter shall give a very brief introduction how to run a first test application and how to visualize the first output files. Only the rough steps will be described here. More detailed explanations can be found in the tutorials in the following chapter.
\begin{enumerate}
\item Go to the directory \texttt{/test}. There, various test application folders can be found. Let us consider as example \texttt{boxmodels/test{\_}2p}:
\item Enter the folder \texttt{boxmodels/2p}. If everything was compiled correctly, there should be an executable \texttt{test{\_}2p}. Otherwise, type \texttt{make test{\_}2p} in order to compile the application. To run the simulation, type\\
\texttt{./test{\_}2p -parameterFile ./test\_2p.input}\\
into the console. The parameter \texttt{-parameterFile} specifies that all important parameters (like first timestep size, end of simulation and location of the grid file) can be found in a text file in the same directory with the name \texttt{test\_2p.input}.
\item The simulation starts and produces some .vtu output files and also a .pvd file. The .pvd file can be used to examine time series and summarizes the .vtu-files. It is possible to stop a running application by pressing $<ctrl><c>$.
\item The simulation starts and produces some .vtu output files and also a .pvd file. The .pvd file can be used to examine time series and summarizes the .vtu files. It is possible to stop a running application by pressing $<$Ctrl$><$c$>$.
\item You can display the results using the visualization tool ParaView (or alternatively VisIt). Just type \texttt{paraview} in the console and open the .pvd file. On the left hand side, you can choose the desired parameter to be displayed.
\end{enumerate}
%
%
%