mirror of
https://github.com/OPM/opm-simulators.git
synced 2025-02-25 18:55:30 -06:00
handbook: replace \textit by \emph
thanks to [at]pgdr for the suggestion.
This commit is contained in:
@@ -92,12 +92,12 @@ in the \Cplusplus11 standard.
|
|||||||
\section{Polymorphism}
|
\section{Polymorphism}
|
||||||
|
|
||||||
In object oriented programming, some methods often make sense for all
|
In object oriented programming, some methods often make sense for all
|
||||||
classes in a hierarchy, but what actually needs to be \textit{done}
|
classes in a hierarchy, but what actually needs to be \emph{done}
|
||||||
can differ for each concrete class. This observation motivates
|
can differ for each concrete class. This observation motivates
|
||||||
\textit{polymorphism}. Fundamentally, polymorphism means all
|
\emph{polymorphism}. Fundamentally, polymorphism means all
|
||||||
techniques in which a method call results in the processor executing code
|
techniques in which a method call results in the processor executing code
|
||||||
which is specific to the type of object for which the method is
|
which is specific to the type of object for which the method is
|
||||||
called\footnote{This is the \textit{poly} of polymorphism: There are
|
called\footnote{This is the \emph{poly} of polymorphism: There are
|
||||||
multiple ways to achieve the same goal.}.
|
multiple ways to achieve the same goal.}.
|
||||||
|
|
||||||
In \Cplusplus, there are two common ways to achieve polymorphism: The
|
In \Cplusplus, there are two common ways to achieve polymorphism: The
|
||||||
@@ -107,7 +107,7 @@ template mechanism.
|
|||||||
|
|
||||||
\subsection*{Dynamic Polymorphism}
|
\subsection*{Dynamic Polymorphism}
|
||||||
|
|
||||||
To utilize \textit{dynamic polymorphism} in \Cplusplus, the polymorphic
|
To utilize \emph{dynamic polymorphism} in \Cplusplus, the polymorphic
|
||||||
methods are marked with the \texttt{virtual} keyword in the base
|
methods are marked with the \texttt{virtual} keyword in the base
|
||||||
class. Internally, the compiler realizes dynamic polymorphism by
|
class. Internally, the compiler realizes dynamic polymorphism by
|
||||||
storing a pointer to a so-called \texttt{vtable} within each object of
|
storing a pointer to a so-called \texttt{vtable} within each object of
|
||||||
|
@@ -16,7 +16,7 @@ systems is straightforward and can be found, e.\ g., in
|
|||||||
\subsection{Basic Definitions and Assumptions for the Compositional
|
\subsection{Basic Definitions and Assumptions for the Compositional
|
||||||
Model Concept}
|
Model Concept}
|
||||||
\textbf{Components:}
|
\textbf{Components:}
|
||||||
The term \textit{component} stands for constituents of the phases which
|
The term \emph{component} stands for constituents of the phases which
|
||||||
can be associated with a unique chemical species, or, more generally, with
|
can be associated with a unique chemical species, or, more generally, with
|
||||||
a group of species exploiting similar physical behavior. In this work, we
|
a group of species exploiting similar physical behavior. In this work, we
|
||||||
assume a water-gas-NAPL system composed of the phases water (subscript
|
assume a water-gas-NAPL system composed of the phases water (subscript
|
||||||
|
@@ -95,7 +95,7 @@ parameters used by a simulation can be obtained by passing
|
|||||||
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=28, firstnumber=28]{../../tutorial/tutorial1problem.hh}
|
\lstinputlisting[style=eWomsCode, numbersep=5pt, firstline=28, firstnumber=28]{../../tutorial/tutorial1problem.hh}
|
||||||
\end{lst}
|
\end{lst}
|
||||||
|
|
||||||
For using \eWoms, the central file is the \textit{problem file} as
|
For using \eWoms, the central file is the \emph{problem file} as
|
||||||
shown in listing~\ref{tutorial1:problemfile}. This file is responsible
|
shown in listing~\ref{tutorial1:problemfile}. This file is responsible
|
||||||
for specifying the physical setup of the problem which is to be
|
for specifying the physical setup of the problem which is to be
|
||||||
simulated. In this context, all problems first need to set up the
|
simulated. In this context, all problems first need to set up the
|
||||||
@@ -186,7 +186,7 @@ at least the following methods:
|
|||||||
All of these methods take a single template argument,
|
All of these methods take a single template argument,
|
||||||
\texttt{Context}, and the three function arguments \texttt{context},
|
\texttt{Context}, and the three function arguments \texttt{context},
|
||||||
\texttt{spaceIdx} and \texttt{timeIdx}. Together, these form the
|
\texttt{spaceIdx} and \texttt{timeIdx}. Together, these form the
|
||||||
so-called \textit{execution context}. The execution context can be
|
so-called \emph{execution context}. The execution context can be
|
||||||
thought of as a collection of all available information for a given
|
thought of as a collection of all available information for a given
|
||||||
method. Thus, execution contexts a way to abstract away the
|
method. Thus, execution contexts a way to abstract away the
|
||||||
differences of discretization schemes. The following methods are
|
differences of discretization schemes. The following methods are
|
||||||
@@ -378,7 +378,7 @@ chapter~\ref{sec:fluidframework}.
|
|||||||
|
|
||||||
\item \textbf{Use a Full-Fledged Fluid System} \\
|
\item \textbf{Use a Full-Fledged Fluid System} \\
|
||||||
In \eWoms, the canonical way to describe fluid mixtures is via
|
In \eWoms, the canonical way to describe fluid mixtures is via
|
||||||
\textit{fluid systems}\footnote{For a thorough introduction into
|
\emph{fluid systems}\footnote{For a thorough introduction into
|
||||||
fluid systems and the concepts related to it, see chapter
|
fluid systems and the concepts related to it, see chapter
|
||||||
\ref{sec:fluidframework}}. In order to include a fluid system,
|
\ref{sec:fluidframework}}. In order to include a fluid system,
|
||||||
you first have to comment out lines
|
you first have to comment out lines
|
||||||
@@ -456,7 +456,7 @@ You can use the fluids of exercise 1b).
|
|||||||
\texttt{const auto \&pos=context.pos(spaceIdx, timeIdx);}
|
\texttt{const auto \&pos=context.pos(spaceIdx, timeIdx);}
|
||||||
|
|
||||||
When does the front cross the material border? In paraview, the
|
When does the front cross the material border? In paraview, the
|
||||||
animation view (\textit{View} $\rightarrow$ \textit{Animation View})
|
animation view (\emph{View} $\rightarrow$ \textit{Animation View})
|
||||||
is a convenient way to get a rough feeling of the time-step sizes.
|
is a convenient way to get a rough feeling of the time-step sizes.
|
||||||
\end{enumerate}
|
\end{enumerate}
|
||||||
|
|
||||||
|
Reference in New Issue
Block a user