opm-simulators/doc/handbook/TipsNTricks.tex

\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
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 inform at least the other developers and write 
to the mailing list \texttt{dumux@iws.uni-stuttgart.de} so somebody else can.

\paragraph{Using the \Dumux-Eclipse profile}

Everybody using the same profile has the advantage of resulting in less conflicts when different developing environments are used:
\begin{enumerate}
  \item in eclipse open: \texttt{Window} $\rightarrow$ \texttt{Preferences} $\rightarrow$ \texttt{C/C++}  $\rightarrow$ \texttt{Code Style}
  \item press the \texttt{Import} button
  \item choose the file \texttt{eclipse\_profile.xml} from your dumux-devel directory
  \item make sure that that now \Dumux is chosen in \texttt{Select a profile}
\end{enumerate}

\paragraph{Checking whether commit worked}

\Dumux is developed with the help of Subversion (short SVN, see \texttt{http://subversion.apache.org/pronunciation/index.html}). This means that at some point you will commit your new 
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. You can prevent this by checking out \Dune and \Dumux twice. Now you can work in one version and after committing 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.

\paragraph{Using \Dune debug streams}

\Dune provides a helpful feature, for keeping your debug-output organized. 
  In stead of juggling with a bazillion \texttt{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 by the so called debug streams. 

  These are streams like \texttt{cout} but they can be switched on and off for the whole project. 
  Maybe 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. 
  This can be achieved by setting the debug streams to desired values. There are five levels:
\begin{verbatim}
5 - grave (dgrave)
4 - warning (dwarn)
3 - info (dinfo)
2 - verbose (dverb)
1 - very verbose (dvverb)
\end{verbatim}

They are used as follows: \lstinline{Dune::dinfo << "message";} or \lstinline{Dune::dgrave  << "message";} .
The debug streams are switched on/off via  setting \lstinline{#define DUNE_MINIMAL_DEBUG_LEVEL 4}
in the source your application. If the value is set to i.\,g. 4 the output generated after \lstinline{Dune::dinfo} (level 4 and 5) will printed anywhere.

\paragraph{Filename and line number by predefined macro}

If you want to  know where some output or debug information came from, you can use the predefined macros \lstinline{__FILE__} and \lstinline{__LINE__}
which are used like\\
\lstinline{dataFile << "# This was written from "<< __FILE__ << ", line " <<__LINE__ << "\n";}\\
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{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 \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 \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 \texttt{CXXFLAGS =}
\item these are the options given to the C++ compiler
\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 \texttt{debug.opts}
\item compiling without optimization takes also shorter time
\end{itemize}

(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 behavior while debugging. 

\paragraph{Faster build with dunecontrol}
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.