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

Further work on the installation chapter of the handbook

Browse Source
This commit is contained in:
Klaus Mosthaf 2010-10-27 17:06:30 +00:00 committed by Andreas Lauser
parent 2f9338825f
commit 47724af9dc
1 changed files with 37 additions and 46 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

83
doc/handbook/install.tex
View File

@ -14,11 +14,10 @@ After installing source code for all requirered \Dune modules including the \Dum
\paragraph{Basic prerequisites} \label{prerequisites}
The gnu toolchain of \texttt{g++} and related gnu variants of developertools like \texttt{libtool}, \texttt{make} and
and \texttt{automake} must be available in a recent version. \Dumux property system (i.e. parts of code) makes use of libboost. It is thus necessary
to install developer version of \texttt{boost}.
The building of documentation requirers latex and auxiliary tools like dvipdf, bibtex (e.g. as of tex-live distribution) installed. Additionally the program convert of package ImageMagick is needed too build the handbook. If you use configuration-switch --enable-doxygen for documentation you will also need doxygen.
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}.
The building of the documentation requires LaTeX and auxiliary tools like dvipdf and 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 (automatic documentation) you will also need \texttt{doxygen}.
Depending on usage of external libraries the required software packages may vary. Beside the section on external properties below it is a good idea also to check \Dune-Wiki for informations about working with external packages. \\
Depending on the usage of external libraries the required software packages may vary. Beside the section on external modules below it is a good idea to check \Dune-Wiki for information about the external packages.
\subsection{Obtaining \Dune and \Dumux}
Two possibilities exist to obtain \Dune and \Dumux. They can be obtained as so-called tarballs, i.e. \Dumux and \Dune code files of a certain version are packed into tar-archive files for download from the the respective {\Dune} and {\Dumux} website. The shell command \texttt{tar} can be used to extract them on your filesystem. This is explained in the next paragraph.
@ -61,98 +60,90 @@ and work yourself through that tutorial in order to get an understanding of the
\paragraph{Checkout of \Dumux}
In order to access an anonymous read-only copy of the stable part of \Dumux from the reposository, the most simple way is to type
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
\begin{itemize}
\item \texttt{svn checkout --username=anonymous --password='' \\
\item \texttt{svn checkout --username=anonymous --password=''
svn://svn.iws.uni-stuttgart.de/DUMUX/dumux/trunk dumux}
\end{itemize}
% On the subversion repository, the \Dumux project is divided into a stable and a developers part, which should stay in separate folders
If you also want to commit new developments to the repositories, you can ask the \Dumux project leader to get developers access fully or in some certain parts. The developer part is only available to people which belong to the \Dumux developer group and have non-anonymous access. If you have developer rights the checkout looks as follows:
If you also want to commit new developments to the repositories, you can ask the \Dumux project leader to get either full developers access or access for certain parts of \Dumux. The developer part \texttt{dumux-devel} is only available for people who belong to the \Dumux developer group and have non-anonymous access to the subversion repositories. If you have developer rights the checkout looks as follows:
\begin{itemize}
\item \texttt{svn checkout --username=yourusername \\
\hspace{4cm} svn://svn.iws.uni-stuttgart.de/DUMUX/dumux/trunk dumux}
\item \texttt{svn checkout --username=yourusername \\
\hspace{4cm} svn://svn.iws.uni-stuttgart.de/DUMUX/dune-mux/trunk dumux-devel}
\end{itemize}
The \texttt{dune-devel} makes use of \texttt{dumux} thats why it is also checked out. You can ommit the username option, if the username for the repository access is identical to the one for your system account. Please choose either not to store the password that way or store it by subversion in a secure way, check documentation of subversion for that. A leaked out password can be used by evil persons to vandalize a software repository.
% If you also want to commit new developments or changes to the repositories, you can ask one of the LH$^2$ administrators to add you to the svn group ( \texttt{svndune}).
\texttt{dumux-devel} is based on the stable part of \texttt{dumux} and hence it has to be also checked out. You can ommit the username option, if your username for the repository access is identical to the one for your system account. 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, i.e. write permissions to repositories, to feed back
your own code or code changes to software repositories. With direct access to software repositories it is also easier for you to keep up with code changes as for important bug fixes or to keep up with general developments of code.
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. Moreover, with direct access to the repositories it is easier to keep up with code changes, to recieve important bug fixes and to keep up with general developments of code.
\paragraph{Dune External libraries}
The following libraries provide additional functionality, but are not required to run \Dumux.
If you going to use an external library check information provided on \Dune website.
The following libraries provide additional functionality but are not required to run \Dumux. If you are going to use an external library check the information provided on the \Dune website.
\begin{itemize}
\item \textbf{UG}: UG is toolbox for Unstructured Grids: for \Dumux is build by autotools and C++-Compiler. Additionally the tools \texttt{lex}/\texttt{yacc} or gnu-versions \texttt{flex}/\texttt{bison} are needed.
\item \textbf{UG}: UG is a toolbox for Unstructured Grids: As \Dumux, it is build by \texttt{autotools} and a C++-compiler. Additionally, the tools \texttt{lex}/\texttt{yacc} or the gnu-versions \texttt{flex}/\texttt{bison} are needed.
\item \textbf{Alberta}: Adaptive multiLevel finite element toolbox using Bisectioning refinement and Error control by Residual Techniques for scientific Applications: A fortran compiler like \texttt{gfortran} is needed.
\item \textbf{Alberta}: Adaptive multiLevel finite element toolbox using Bisectioning refinement and Error control by Residual Techniques for scientific Applications: A fortran compiler like \texttt{gfortran} is required.
\item \textbf{Alugrid}: Alugrid is build by C++-compiler like \texttt{g++}. If you build a parallel version you will need MPI, it was successful run with \texttt{openmpi}. Parallel version need also a graph partitioner, i.e. METIS or PARTY. It was run successfuly in context with \Dune with \texttt{Metis}.
\item \textbf{ALUGrid}: ALUGrid is build by a C++-compiler like \texttt{g++}. If you want to build a parallel version, you will need MPI. It was successfully run with \texttt{openmpi}. The parallel version needs also a graph partitioner, such as \texttt{METIS} or \texttt{PARTY}. It was run successfully in combination with \Dune using \texttt{METIS}.
\item \textbf{PARDISO} The package PARDISO is a thread-safe, high-performance, robust, memory efficient and easy to use software for solving large sparse symmetric and unsymmetric linear systems of equations on shared memory multiprocessors.
\item \textbf{pardiso} Is a solver for linear equation systems. It is only available as binary.
\item \textbf{SuperLU} SuperLU is a general purpose library for the direct solution of large, sparse, nonsymmetric systems of linear equations.
\item \textbf{SuperLU} Another solver for linear equation systems.
\item \textbf{\Dune multidomaingrid} If you going to run on the same grid different domains or subdomains, this can be a package of choice. To be precise this is an external \Dune module which as \Dumux gets build by \Dune build system, not only external library.
\item \textbf{\Dune-multidomaingrid} If you going to run on the same grid different domains or subdomains, this can be a package of choice. To be precise, this is not only external library but an external \Dune module which like \Dumux is build by the \Dune build system. The dune-multidomaingrid module provides a meta grid that allows the subdivison of arbitrary \Dune grids into subdomains, e.g. for multi-physics approaches.
\end{itemize}
These following are dependencies. You will need them depending of which parts of \Dune and external parts you run.
The following are dependencies of some of the libraries above. You will need them depending on which modules of \Dune and which external libraries you use.
\begin{itemize}
\item \textbf{MPI}: parallel version of \Dune needs MPI also some of the external dependencies when they are going to be build for parallel computing. \texttt{Openmpi} and \texttt{MPICH} in a recent version had been reported to work.
\item \textbf{MPI}: The parallel version of \Dune and also some of the external dependencies need MPI when they are going to be build for parallel computing. \texttt{Openmpi} and \texttt{MPICH} in a recent version have been reported to work.
\item \textbf{lex/yacc} or \textbf{flex/bison}. These are quite common developing tools, code generators for lexical analyser a nd parser. Is a dependency to UG.
\item \textbf{lex/yacc} or \textbf{flex/bison}. These are quite common developing tools, code generators for lexical analyzers and parsers. This is a prerequisite for UG.
\item \textbf{boost} The Boost-C++-Libraries. Install a developer version. \Dumux property system makes use of libboost also \Dune Multidomaingrid.
\item \textbf{boost} The Boost-C++-Libraries. Install a developer version. The \Dumux property system and \Dune-Multidomaingrid make use of \texttt{libboost}.
\item \textbf{BLAS}: Alberta makes use of BLAS thus install libGOTO, ATLAS, non-optimized BLAS or BLAS by chipmanufacturer. Take care that installation scripts select intended version of BLAS.
\item \textbf{BLAS}: Alberta makes use of BLAS. Thus install libGOTO, ATLAS, non-optimized BLAS or BLAS by chipmanufacturer. Take care that the installation scripts select the intended version of BLAS.
\item \textbf{METIS} Is a dependency to Alugrid, if you run it in parallel, this part is beeing used to partitionate your grid.
\item \textbf{METIS} This is a dependency of Alugrid. If you run it parallel this part is beeing used to partitionate your grid.
\item \textbf{libGOTO} Is an optimized version of BLAS. It's not always available for all architectures and
its license is not open. For research and education it is possibble to have a copy without additional costs.
A fortran compiler like gfortran is needed to compile it.
\item \textbf{libGOTO} is an optimized version of BLAS. It is not always available for all architectures and
the license is not open. For research and education it is possibble to obtain a copy without additional costs.
A fortran compiler like \texttt{gfortran} is needed to compile it.
\item \textbf{make,autogen,automake,libtool}
For make use the gnu version of make, the other are also gnu building tools dependencies to build most code of \Dune and \Dumux. Autogen, automake are referred as autools.
\item \textbf{make, autogen, automake, libtool}
You can make use of the gnu version of \texttt{make}. The other tools are also gnu building tools and they are required to build most of the \Dune and \Dumux code. \texttt{autogen} and \texttt{automake} are referred to as \texttt{autools}.
\item \textbf{latex, convert, doxygen} For building \Dumux documentation one will need them.
Convert is a ImageMagicks image conversion tool. Latex is macro frontend to TeX font setting system, install for example texlive. Many parts of code documentation is done inline, with doxygen will extract and make html or latex
from that.
\item \textbf{LaTeX, convert, doxygen} In order to build the \Dumux documentation these tools are needed.
\texttt{convert} is a ImageMagicks image conversion tool. LaTeX is macro frontend to the TeX font setting system. Install for example texlive. Many parts of the code documentation is done inline using doxygen, which extracts the documentation and makes html or LaTeX out of that.
\item \textbf{Compilers} We recommend to use gnu comiler suite, i.e. gcc/g++/gfortran version 4.5 or 4.4. It is also reported that \Dune was successfully build by Intel C++ compiler. \Dune is build by a C++ compiler. The C and Fortran compiler is only needed for few external libraries.
\item \textbf{Compilers} We recommend to use the gnu compiler suite, i.e. \texttt{gcc}/\texttt{g++}/\texttt{gfortran} version 4.4 or 4.5. It is also reported that \Dune was successfully build with the Intel C++ compiler. \Dune is build by a C++ compiler. The C and Fortran compiler is only needed for a few external libraries.
\item \textbf{libgomp} Dune seems makes use of OpenMP. Thus it can be necessary to install it.
\item \textbf{libgomp} \Dune can make use of OpenMP. Thus it can be necessary to install the \texttt{libgomp} library.
% http://openmp.org/
\item \textbf{libgmp} The Gnu Multiple Precision Arithmetic Library (GMP) is also a dependency to \Dune. it might be necessary to install it.
\item \textbf{libgmp} The Gnu Multiple Precision Arithmetic Library (GMP) is also a prerequisite for \Dune. It may be necessary to install it.
% http://gmplib.org/
\end{itemize}
\paragraph{Hint for IWS Users} User of Institute of Hydraulic Engineering of Stuttgart University
can also svn check out a repository for external libraries:
\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}. \\
This directory \texttt{external} contains a script to install external libraries, i.e.
alberta, alu, ug it also contains metis and the blas version libGOTO:
This directory \texttt{external} contains a script to install external libraries, such as
\texttt{alberta}, \texttt{alu}, \texttt{ug}. It also contains \texttt{METIS} and the blas version of \texttt{libGOTO2}:
\begin{center}
\texttt{./installExternal.sh all}
\end{center}
it is also possible to install only parts, e.g.:\\
it is also possible to install only certain parts of the external libraries:\\
\begin{center}
\texttt{./installExternal.sh alberta}
\end{center}
These libraries are then build within this external-directory and not installed in
a different place. But a dune build still has to know about where they are.
You have to refer to them as options to \Dune build, e.g. from your options file \texttt{debug.opts}.
The libraries are then build within the external-directory and are not installed in a different place. But a \Dune build still needs to know where they are. You have to refer to them as options for the \Dune build, for example in your options file \texttt{debug.opts}.
\paragraph{Build \Dune and \Dumux}