Formatting inline code (#2351)

* Started formatting of inline code

* More formatting of inline code

* Enlarge code blocks from \footnotesize to \small, as they are a quite important part of MLS

* More formatting of inline code

* Re-activate all chapters in order to build full MLS

* More formatting of inline code. Finished chapter 3.

* Improved inline formatting in chapter 3

* More formatting of inline code.

* More formatting of inline code.

* More formatting of inline code.

* Fix some LaTeX errors, after adding all the inline formatting.

* Fix formatting todos.

* More formatting of inline code, needs more work on \emph environments.

* Fixing double-dashes in code sections ("--" had been introduced during conversion from Word)

* Improved inline formatting (reducing %TODO-BACK).

* Nicer formatting inline code: replaced all instances of \lstinline[basicstyle=\ttfamily]! by shorter \lstinline!

* Fix remaining emphs+code

* Fix inline formatting of pre(m)

* Fixing parathesis outside of lstinline

chapters/dae.tex

@@ -51,7 +51,7 @@ \chapter{Modelica DAE Representation}\doublelabel{modelica-dae-representation}
 \textbf{m}(t\textsubscript{e}) & Modelica variables of type
 \emph{discrete Real, Boolean, Integer} which are unknown. These
 variables change their value only at event instants t\textsubscript{e}.
-pre(m) are the values of m immediately before the current event
+\lstinline!pre(m)! are the values of m immediately before the current event
 occurred.\\ \hline
 \textbf{y}(t) & Modelica variables of type \emph{Real} which do not fall
 into any other category (= algebraic variables).\\ \hline
@@ -63,8 +63,8 @@ \chapter{Modelica DAE Representation}\doublelabel{modelica-dae-representation}
 
 \end{longtable}
 
-For simplicity, the special cases of the noEvent() operator and of the
-reinit() operator are not contained in the equations above and are not
+For simplicity, the special cases of the \lstinline!noEvent()! operator and of the
+\lstinline!reinit()! operator are not contained in the equations above and are not
 discussed below.
 
 The generated set of equations is used for simulation and other analysis
@@ -97,7 +97,7 @@ \chapter{Modelica DAE Representation}\doublelabel{modelica-dae-representation}
 \end{enumerate}
 
 Note, that both the values of the conditions c as well as the values of
-m (all discrete Real, Boolean and Integer variables) are only changed at
+m (all \lstinline!discrete Real!, \lstinline!Boolean! and \lstinline!Integer! variables) are only changed at
 an event instant and that these variables remain constant during
 continuous integration. At every event instant, new values of the
 discrete variables m and of new initial values for the states x are

chapters/derivationofstream.tex

@@ -152,7 +152,7 @@ \section{Rationale for the formulation of the inStream() operator}\doublelabel{r
 
 \section{Special cases covered by the inStream() operator definition}\doublelabel{special-cases-covered-by-the-instream-operator-definition}
 \subsection{Stream connector is not connected (N=1):}\doublelabel{stream-connector-is-not-connected-n-1}
-For this case, the return value of the inStream() operator is arbitrary.
+For this case, the return value of the \lstinline!inStream()! operator is arbitrary.
 Therefore, it is set to the outflow value.
 
 \subsection{Connection of 2 stream connectors, one to one connections (N=2):}\doublelabel{connection-of-2-stream-connectors-one-to-one-connections-n-2}
@@ -162,7 +162,7 @@ \subsection{Connection of 2 stream connectors, one to one connections (N=2):}\do
 inStream(h_{outflow,2})&=&\frac{\text{max}(-\dot{m}_1,0)h_{outflow,1}}{\text{max}(-\dot{m}_1,0)}=h_{outflow,1}
 \end{eqnarray*}
 
-In this case, inStream() is continuous (contrary to $h_{mix}$) and does not
+In this case, \lstinline!inStream()! is continuous (contrary to $h_{mix}$) and does not
 depend on flow rates. The latter result means that this transformation
 may remove nonlinear systems of equations, which requires that either
 simplifications of the form ``a*b/a = b'' must be provided, or that this
@@ -195,7 +195,7 @@ \subsection{Connection of 3 stream connectors where one mass flow rate is identi
 properties discussed for two connected components still hold. The
 connection set equations reflect that the sensor does not any influence
 by discarding the flow rate of the latter. In several cases a non-linear
-equation system is removed by this transformation. However, inStream(..)
+equation system is removed by this transformation. However, \lstinline!inStream(..)!
 results in a discontinuous equation for the sensor, which is consistent
 with modeling the convective phenomena only. The discontinuous equation
 is uncritical, if the sensor variable is not used in a feedback loop
@@ -207,7 +207,7 @@ \subsection{Connection of 3 stream connectors where two mass flow rates are posi
 
 If uni-directional flow is present and an ideal splitter is modelled,
 the required flow direction should be defined in the connector instance
-with the ``min'' attribute (the ``max'' attribute could be also defined,
+with the ``\lstinline!min!'' attribute (the ``\lstinline!max!'' attribute could be also defined,
 however it does not lead to simplifications):
 
 \begin{lstlisting}[language=modelica]
@@ -218,7 +218,7 @@ \subsection{Connection of 3 stream connectors where two mass flow rates are posi
 \end{lstlisting}
 
 Consider the case of and all other mass flow rates positive (with the
-min attribute set accordingly). Connecting m1.c with m2.c and m3.c, such
+min attribute set accordingly). Connecting \lstinline!m1.c! with \lstinline!m2.c! and \lstinline!m3.c!, such
 that
 
 \begin{lstlisting}[language=modelica]
@@ -230,7 +230,7 @@ \subsection{Connection of 3 stream connectors where two mass flow rates are posi
 inStream(h_{outflow,1})=\frac{\text{max}(-\dot{m}_2,0)h_{outflow,2}+\text{max}(-\dot{m}_3,0)h_{outflow,3}}{\text{max}(-\dot{m}_2,0)+\text{max}(-\dot{m}_3,0)}=\frac{0}{0}
 \end{equation*}
 
-The inStream() operator cannot be evaluated for a connector, on which
+The \lstinline!inStream()! operator cannot be evaluated for a connector, on which
 the mass flow rate has to be negative by definition. The reason is that
 the value is arbitrary, which is why it is defined as follows.
 \begin{equation*}
@@ -252,11 +252,11 @@ \subsection{Connection of 3 stream connectors where two mass flow rates are posi
 mathematical solution does not exist. This specification only requires
 that a solution fulfills the balance equations. Additionally, a
 recommendation is given to compute all unknowns in a unique way, by
-providing an explicit formula for the inStream operator. Due to the
+providing an explicit formula for the \lstinline!inStream! operator. Due to the
 definition, that only flows where the corresponding ``min'' attribute is
 neither zero nor positive enter this formula, a meaningful physcial
 result is always obtained, even in case of zero mass flow rate. As a
 side effect, non-linear equation systems are automatically removed in
 special cases, like sensors or uni-directional flow, without any
 symbolic transformations (no equation must be analyzed; only the
-``min''-attributes of the corresponding flow variables).
+``\lstinline!min!''-attributes of the corresponding flow variables).