\documentclass[english, twocolumn, 10pt, aps, superscriptaddress, floatfix, prb, citeautoscript]{revtex4-1}
\pdfoutput=1
\usepackage{xr}
\externaldocument{zigzag}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{verbatim}
\usepackage{units}
\usepackage{mathtools}
\usepackage{amsmath}
\usepackage{amssymb}
\usepackage{graphicx}
\usepackage{wasysym}
\usepackage{layouts}
\usepackage{siunitx}
\usepackage{bm}
\usepackage{xcolor}
\usepackage[colorlinks, citecolor={blue!50!black}, urlcolor={blue!50!black}, linkcolor={red!50!black}]{hyperref}
\usepackage{bookmark}
\usepackage{tabularx}
\usepackage{microtype}
\usepackage{babel}
\hypersetup{pdfauthor={Quantum Tinkerer},pdftitle={Enhanced proximity effect in zigzag-shaped Majorana Josephson junctions.}}

\setcounter{secnumdepth}{4}
\setcounter{tocdepth}{4}

\DeclareMathOperator{\e}{e}
\DeclareMathOperator{\de}{d\!}
\DeclareMathOperator{\Tr}{Tr}
\DeclareMathOperator{\diag}{diag}
\DeclareMathOperator{\Res}{Res}
\DeclareMathOperator{\sgn}{sgn}
\DeclareMathOperator{\Pf}{Pf}
\DeclareMathOperator{\Det}{Det}
\DeclareMathOperator{\rank}{rank}
\DeclareMathOperator{\im}{Im}
\DeclareMathOperator{\re}{Re}

\renewcommand{\comment}[2]{#2}
% Uncomment the following line for paragraph descriptions to appear in the file.
% \renewcommand{\comment}{\paragraph}

\DeclarePairedDelimiter\abs{\lvert}{\rvert}
\DeclarePairedDelimiter\norm{\lVert}{\rVert}

\makeatletter
\let\oldabs\abs
\def\abs{\@ifstar{\oldabs}{\oldabs*}}
\let\oldnorm\norm
\def\norm{\@ifstar{\oldnorm}{\oldnorm*}}
\makeatother

\newcommand{\ev}[1]{\langle#1\rangle}
\newcommand{\bra}[1]{\langle#1|}
\newcommand{\ket}[1]{|#1\rangle}
\newcommand{\bracket}[2]{\langle#1|#2\rangle}

\newcolumntype{L}[1]{>{\raggedright\arraybackslash}p{#1}}
\newcolumntype{C}[1]{>{\centering\arraybackslash}p{#1}}
\newcolumntype{R}[1]{>{\raggedleft\arraybackslash}p{#1}}

\begin{document}

\appendix

\section{Zigzag devices and disorder}\label{appendix:mfp_vs_gap}

\comment{We compare $E_\textrm{gap}(l_e)$ for zigzag and straight systems at $\phi=0$ and $\phi=\pi$; and confirm that the zigzag and disorder both increase $E_\textrm{gap}$ through a similar mechanism.}
The right amount of disorder improves the Majorana properties~\cite{Haim2019} and scatters long trajectories in a similar fashion to the zigzag geometry cutting off long trajectories.
We simulate devices with disorder---parameterized by its mean free path $l_e$---and calculate $E_\textrm{gap}(l_e)$ for straight and zigzag devices at different phases and magnetic fields, see Fig.~\ref{fig:mfp_vs_gap}.
For the parameters we chose, at $\phi=0$ we observe that an optimal value of $l_e$ results in an enhancement that is at best equal to that of the zigzag device.
At $\phi=\pi$ we observe that zigzag geometry outperforms disorder.

\begin{figure}[!htb]
\centering
\includegraphics[width=0.9\columnwidth]{figures/mfp_vs_gap.pdf}
\caption{Comparison of the gap of zigzag devices (dashed lines) and straight devices (solid lines) as function of mean free path $l_e$.
Each $E_\textrm{gap}$ value is averaged over 40 disorder realizations and is calculated using a translationally invariant system where the unit-cell is $L_x=3z_x$, with $z_x=\SI{1300}{\nm}$.
\label{fig:mfp_vs_gap}}
\end{figure}

\section{Zigzag device with a single superconductor}\label{appendix:NS_junction}

\comment{We run the simulation and observe that the phase diagrams are the same but the zigzag device is still better.}
A zigzag-shaped device with a single superconductor shows a similar enhancement of the superconducting gap as the Josephson junction devices.
We demonstrate this by simulating a straight and a zigzag device and computing $E_\textrm{gap}(B_x, \; \mu)$ in Fig.~\ref{fig:ns_junction}.
We observe that the order of magnitude increase of $E_\textrm{gap}$ also occurs upon the introduction of a zigzag geometry.

\begin{figure}[!htb]
\centering
\includegraphics[width=0.9\columnwidth]{figures/phasediagrams_NS.pdf}
\caption{Same as Fig.~\ref{fig:phasediagrams} (c) and (d) but with one superconductor instead of two.
We observe that the zigzag geometry also increases the gap in this case.
\label{fig:ns_junction}}
\end{figure}

\section{Direction of the magnetic field}\label{appendix:direction_B}

\comment{Zigzag geometry removes the need for precise field alignment.}
Because the zigzag geometry cuts off long trajectories---leaving only short trajectories---this device requires a less precise alignment of the magnetic field.
To show this, we perform a simulation of a straight and zigzag device with a rotated field (see Fig.~\ref{fig:tilted_angle_phase_diagram}).
We observe that the zigzag device still has a sizeable gap with a $10^\circ$ misaligned magnetic field, wherea a $1^\circ$ misalignment makes a straight device gapless.

\comment{Likewise a inhomogeneous magnetic field does not matter.}
Strong screening of the magnetic field by the superconductors may distort the magnetic field pattern.
To determine whether this effect degrades the device quality, we simulate a device with the magnetic field parallel to the NS interface, shown in Fig.~\ref{fig:syst_snaking_magnetic_field}.
We find that the resulting gap is comparable to that of a device with the magnetic field purely in the $x$-direction, as shown in Fig.~\ref{fig:snaking_magnetic_field}.

\begin{figure}[!htb]
\centering
\includegraphics[width=0.9\columnwidth]{figures/tilted_angle_phase_diagram.pdf}
\caption{The topological gap as a function of the magnetic field magnitude $B$ and its angle $\theta=\arctan{B_y/B_x}$ for a straight device (a) and a zigzag device (b).
Note that the colormaps and the $\theta$-axes differ between panels: the zigzag-shaped device becomes gapless at $\theta$ an order of magnitude larger compared to the straight device.
\label{fig:tilted_angle_phase_diagram}}
\end{figure}

\begin{figure}[!htb]
\centering
\includegraphics{figures/syst_snaking_magnetic_field.pdf}
\caption{
The magnetic field pattern emulating strong screening by the superconductors.
\label{fig:syst_snaking_magnetic_field}}
\end{figure}

\begin{figure}[!htb]
\centering
\includegraphics{figures/snaking_magnetic_field.pdf}
\caption{
Comparison of the zigzag device's band structures with the magnetic field following the shape of the junction (orange) (see Fig.~\ref{fig:syst_snaking_magnetic_field}) and a magnetic field in the $x$-direction (blue) for different values of $z_y$.
\label{fig:snaking_magnetic_field}}
\end{figure}

\section{Interface transparency vs.~path length cut-off}

The zigzag geometry both increases the interface transparency (because particles typically hit the superconductor
closer to normal incidence) as well as sets an upper limit to the trajectory length.
The change in the interface transparency alone is not sufficient to explain the increase of the topological gap.
To verify this, we compute the dispersion of a system with $z_x = z_y = \SI{80}{\nm}$ comparable to the Fermi wavelength $\lambda_\textrm{F}$ and $W=\SI{400}{\nm}$, so that the angle of the boundaries is sufficiently large, but the boundary modulation is much smaller than the width.
We observe that $E_\textrm{gap}$ becomes $\SI{6.1}{\mu \eV}$, a two-fold increase compared to the straight system, not the order of magnitude increase resulting from the cutting off of long trajectories.

\bibliographystyle{apsrev4-1}
\bibliography{zigzag}

\end{document}


%\index{M7!history}
The documented aerosol modules (Sulphate, BCOC, DUST, SALT) produce
aerosols independent of each other. Nitrate is somewhat special since
it depends on SALT and sulphate, and sulphate depends on the
tropospheric chemistry.

M7 tries to put the aerosol packages together. The inclusion of M7
builds on this approach in the following way:
\begin{enumerate}
  \item All the separate modules are left untouched.
  \item If M7 is activated the emissions of the components which
    are concerned by M7 are transferred to a new array and the
    original emission arrays become irrelevant.
  \item All the M7 tracers have their own loss terms depending
    on the microphysics.
\end{enumerate}

You turn on the M7 application by setting \verb#M7 := Y# in
\makefile. Running the aerosol modules separately is of coarse good if
you want to save CPU time and only want to run 8 carbon tracers
instead of full chemistry/sulfate/M7 run.

% Physics
\subsection{Physics}
\index{M7!physics}
M7 is a microphysical model. This means that it's purpose is to
calculate interaction between different types of aerosols. The output
is the size of the aerosols and their mixing state (i.e. water soluble
or insoluble). M7 splits the aerosol size distribution into the
following size distributed modes
\begin{itemize2}
  \item Nucleation mode, water soluble, size: $\sim 1 nm$
  \item Aitken mode, water soluble,  size: $\sim 0.01 {\mu}m$
  \item Accumulation mode, water soluble, size: $\sim 0.1 {\mu}m$
  \item Coarse mode, water soluble, size: $\sim 1 {\mu}m$
  \item Aitken mode, insoluble,  size: $\sim 0.01 {\mu}m$
  \item Accumulation insoluble, size: $\sim 0.1 {\mu}m$
  \item Coarse mode, insoluble, size: $\sim 1 {\mu}m$
\end{itemize2}

{\bf Important}\\
{\bf M7 does not treat semivolatile aerosol species} like nitrate or
secondary organics. This is both a good thing and a bad thing. It is
good because it greatly  reduces the complexity of the problem, and it
is bad because.. well... you can not calculate the effect these
tracers would have on aerosol microphysics.

% M7 tracers
\subsection{M7 tracers}
\index{M7!tracers}
The M7 tracers are listed in Table \ref{tbl:m7tracers}.

\begin{table*}
\caption{Tracers included in the M7 model. All the aerosol species
  (250--274) have lifetimes of days-weeks and they all need to be
  transported. Water species (275--278) are in equilibrium (see below)
  and should not be transported. Soluble species (except water) are
  washed out in convection. There are 17 soluble species in M7.}
\label{tbl:m7tracers}
\begin{minipage}{\linewidth}
\begin{tabular}{|c|l|l|c|c|}
\hline
Nr  & Component name & Remarks                 & Soluble   &  Transport \\
\hline \hline
80  & SO4GAS     &  Gas phase sulf. acid       &  N/A (No) & No\\
\hline
250 & SO4NUC     &    nucleation mode sulphate &  Yes      &  Yes\\
\hline
251 & SO4AT      &    aitken mode sulphate     &  Yes      &  Yes\\
\hline
252 & SO4AC      &    accumulation mode sulphate &  Yes    &  Yes\\
\hline
253 & SO4CRS     &    coarse mode sulphate  &  Yes       &  Yes\\
\hline
254 & BCKS       &  aitken mode soluble BC  &  Yes       &  Yes\\
\hline
255 & BCAS       &    accumulation mode BC  &  Yes       &  Yes\\
\hline
256 & BCCS       &    coarse mode BC        &  Yes       &  Yes\\
\hline
257 & BCKI       &    aitken mode BC        &  No        &  Yes\\
\hline
258 & OCKS       &    aitken mode OC        &  Yes       &  Yes\\
\hline
259 & OCAS       &    accumulation mode OC  &  Yes       &  Yes\\
\hline
260 & OCCS       &    coarse mode OC        &  Yes       &  Yes\\
\hline
261 & OCKI       &    aitken mode OC        &  No        &  Yes\\
\hline
262 & SSAS       & accumulation mode Seasalt &  Yes      &  Yes\\
\hline
263 & SSCS       &  coarse mode seasalt      &  Yes      &  Yes\\
\hline
264 & DUAS       &    accumulation mode dust  &  Yes     &  Yes\\
\hline
265 & DUCS       &    coarse mode dust        &  Yes     &  Yes\\
\hline
266 & DUAI       &    accumulation mode dust  &  No      &  Yes\\
\hline
267 & DUCI       &   coarse mode dust        &  No       &  Yes\\
\hline
268 & NNUC       &    Nucleation mode number &  Yes      &  Yes\\
\hline
269 & NKS        &    Aitken mode number      &  Yes     &  Yes\\
\hline
270 & NAS        &    Accumulation mode number  &  Yes   &  Yes\\
\hline
271 & NCS        &   coarse mode number        &  Yes    &  Yes\\
\hline
272 & NKI        &   aikten mode number      &  No       &  Yes\\
\hline
273 & NAI        &    accumulation mode number  &  No    &  Yes\\
\hline
274 & NCI        &   Coarse mode number         & No     &  Yes\\
\hline
275 & H2ONUC     &   nucleation mode water      &  Yes   &  No\\
\hline
276 & H2OKS      &  aitken mode water           &  Yes   &  No \\
\hline
277 & H2OAS      &  accumulation mode water     & Yes    &  No\\
\hline
278 & H2OCS      &  coarse mode water           & Yes    &  No \\
\hline
\end{tabular}
\end{minipage}
\end{table*}

Thus, when running M7, you need 51 tracers from tropospheric
chemistry, 7 from sulfate and one extra (\verb#SO4GAS#), and further
you need the 8 BC/OC species, which are not transported or washed
out. The tracers washed out in convection are all the
water-soluble. Table \ref{tbl:tracerm7} shows in more detail the
tracers need for running M7.

\begin{table}
\caption{Explanation of the number of tracers needed for running
  M7. Note that several tracers are dummy tracers (the 8 of BCOC, the
  2 of dust, the 2 of salt). These tracers are handled by the 25 M7
  tracers when running M7. The sulphate species are converted
  immediately to M7 species. The number in parenthesis for
  Transport indicates the  number of tracers if you exclude the
  tracers labeled \textcolor{red}{\it Maybe} in Table
  \ref{tbl:tropcomp}.}
 \label{tbl:tracerm7}
\begin{minipage}{\linewidth}
\begin{tabular}{|l|c|c|c|}
\hline
Application      & Tracers  & Transport  & Washout \\
\hline
TROPCHEM         &  51      &  40 (35)   &  8 \\
\hline
SALT             &  2\footnote{dummy tracers} &  0   &  0 \\
\hline
DUST             &  2\footnote{dummy tracers} &  0   &  0 \\
\hline
SULPHATE\footnote{no transport or washout of old $SO_4$}
                 & 7        &  4          &  3 \\
\hline
SO4GAS           &  1       &  0          &  0 \\
\hline
BCOC             &  8\footnote{dummy tracers}  &  0   &  0 \\
\hline
M7               &  25      &  25         &  17 \\
\hline
M7(water)        &  4       &  0          &  0 \\
\hline
\hline
SUM              & 100      &  69 (64)    &  28 \\
\hline
\end{tabular}
\end{minipage}
\end{table}

\subsection{Technical information}
\index{M7!technical information}

The M7 model is activated by the logical switch LM7. This logical
variable currently has to be set in the main program. When this
logical switch is activated, the emissions calculated for the
M7-relevant components are removed from the \verb#POLLX# array and put
in the \verb#PRODM7# array.

The idea is that the old aerosols tracers still exist in the
model. However, they are in a way irrelevant if M7 is used and there
is no need for transporting them.

\subsection{Interaction with other parts of aerosol codes}
\index{M7!aerosol code interaction}

\subsubsection{Carbon particles}
\index{M7!carbon particles}
The carbon particles in their old form should not be transported if M7
is used. However, they should be included as tracers in the \inptrctm\
file.

If the logical LM7 is recognized by the model, the emissions of BC
and OC are put into the \verb#prodm7# array and enters the M7 tracer
list. They are not put into the places they have as BC/OC tracers as
described in section \ref{sxn:bcoc}.

\subsubsection{Sulphate model}
\index{M7!sulphate model}
M7 needs explicit input about how much sulphate is formed in gas phase
and how much is formed in the aqueous phase. Therefore, another
tracer, number 80, \verb#SO4gas# is used when M7 is used.
The tracer which represents sulphate in the sulphate application (see
chapter \ref{sxn:sulphate}) which is tracer number 73 is only
representing aqueous phase sulphate when M7 is used.

There is no need for transporting the sulphate tracers since the mass
produced in the sulphate tracers are moved to the M7-tracers in the
same timestep. These tracers are later the ones being transported and
being lost by dry- and wet deposition.

\subsubsection{Dust and Seasalt models}
\index{M7!dust and seasalt models}

The dust and seasalt models are activated when it finds tracers
named \verb#SALTXX# or \verb#DUSTXX# (where \verb#XX# is bin number)
in the standard version (see more description in section
\ref{sxn:dust} and \ref{sxn:salt}. To not re-organize the code too
much, this feature is kept, and you still need tracers called
\verb#DUST01# and \verb#SALT01# to be able to run these modules.

However, when running M7, the standard versions of these codes are
no longer relevant. Therefore, you need 2 dust species and 2 salt
species to activate the model. These species have to be listed in
\inptrctm\ {\bf but they do not need to be transported}.

\subsubsection{Salt model}
\label{sxn:salt2m7}\index{M7!seasalt model}

The logical variable LM7 is sent directly into the salt model.
If the salt model recognizes this variable as TRUE, it will
not care about fall speeds and dry deposition, but only output
the emissions into the \verb#prodm7# array.

In the case of LM7 being true in the seasalt application, a production
routine giving modal emissions are being activated. This is different
from the standard model in the way that in the standard model,
the production routines distributes the production to size bins.

\subsubsection{Dust model}
\index{M7!dust model}

When using M7, the whole DUST model (DEAD) is still run. This is
strictly not necessary since M7 does not really care about what
happens in DEAD except for one thing: It wants the emissions.

It would have been possible to send the logical LM7 to the dust model
and only output the emissions if M7 is used, and not call the
deposition routines in a similar way to what is done for the salt
model (section \ref{sxn:salt2m7}. However: In the case of dust,
the complete call to DEAD  kept because of the following reasons
\begin{itemize}
  \item The dust code is more complicated than the salt code and
    sending around the logical LM7 in it could be messy.
  \item DEAD is not developed at UiO, and if anyone wants to upgrade
    to a more recent version of DEAD, it would be easier not having to
    re-code it using the variable LM7 also.
\end{itemize}

The code to DEAD will update the concentrations of the tracer
\verb#DUST01# which should not transported in CTM2. However, DEAD also
puts the emissions in a 2D field which can be accessed with the
subroutine \verb#dustfield2main#.

All that is needed to include dust in M7 is the call to
\verb#dustfield2main# and fetch the emissions. These are then
processed in the \verb#prodm7# variable.


\documentclass[11pt,a4paper]{article}

% These are extra packages that you might need for writing the equations:
\usepackage{amsmath}
\usepackage{amsfonts}
\usepackage{amssymb}
\usepackage{booktabs}
\usepackage{hyperref}
\usepackage{listings}
\usepackage{xcolor}
\lstset {language=C++,
		 basicstyle=\ttfamily,
         keywordstyle=\color{blue}\ttfamily,
         stringstyle=\color{red}\ttfamily,
         commentstyle=\color{purple}\ttfamily,
         morecomment=[l][\color{magenta}]{\#},
       	 basicstyle=\tiny}

% You need the following package in order to include figures in your report:
\usepackage{graphicx}

% With this package you can set the size of the margins manually:
\usepackage[left=2cm,right=2cm,top=2cm,bottom=2cm]{geometry}

\begin{document}

% Enter the exercise number, your name and date here:
\noindent\parbox{\linewidth}{
 \parbox{.25\linewidth}{ \large HPCSE I, Exercise 03 }\hfill
 \parbox{.5\linewidth}{\begin{center} \large Beat Hubmann \end{center}}\hfill
 \parbox{.2\linewidth}{\begin{flushright} \large Oct 19, 2018 \end{flushright}}
}
\noindent\rule{\linewidth}{2pt}

\section{Question 1}

\subsection{Task a)}

The program was implemented as instructed and can be found attached to this submission.
\subsubsection{Task a.1}
An implementation based on \texttt{\#pragma omp for nowait reduction(+: sum)} was chosen. In a parallel section before the loop, each thread is assigned its own random number generator with thread-dependent seed.

\subsubsection{Task a.2}
An implementation around \texttt{\#pragma omp for nowait} was chosen. The random number generators were dealt with as in the task above. The individual threads' results were written into an unpadded vector \texttt{std::vector<double>}.

\subsubsection{Task a.3}
An approach identical to task a.2 above was chosen, except for padding the vector with the number of \texttt{double} vector elements necessary to obtain a separate 64-bit cache line for each thread.

\subsection{Task b)}
The results of running the compiled program on Euler and my own machine (a 2018 Macbook Pro) are plotted in figures~\ref{fig1}~and~\ref{fig2}. The impact on performance of false sharing is clearly evident in both plots. Also, it is in line with expectations that the performance of the implementation using padded vectors almost matches what the built in reduction method achieves.

\begin{figure}[ht]
\begin{center}
\includegraphics[scale=0.5]{results.png}
\end{center}
\caption{Parallel Monte Carlo integration on Euler compute cluster.}
\label{fig1}
\end{figure}

\begin{figure}[ht]
\begin{center}
\includegraphics[scale=0.5]{results_mbp.png}
\end{center}
\caption{Parallel Monte Carlo integration on 2018 Macbook Pro.}
\label{fig2}
\end{figure}

\subsection{Task c}
\begin{itemize}
    \item Yes, for the amount of tasks $N$ significantly larger than the number of threads, the workload is distributed evenly among the threads. For smaller $N$ this balance might not been exactly achievable.
    \item No, there is no perfect scaling as there is unparallelized overhead, but the modes \texttt{m=1} and \texttt{m=3} are not far off.
    \item A serial program and a single thread OpenMP program will get the same results provided the random generator seed remains unchanged. A multi-threaded OpenMP program on the other hand may show very small differences in the order of magnitude of machine precision when compared to the serial/single-thread results. This is due to the fact that each thread's random number generator is initialized with a different seed and also due to small numerical floating point rounding errors when adding the individual thread results.
\end{itemize}

\section{Question 2}

There is a problem with the global variable \texttt{pos} in the \texttt{if} statement starting on line 13: In order to write to the array \texttt{good\_members}, the value of \texttt{pos}
must be read in line 14. This read is not protected from race conditions with the atomic write on line 17. As \texttt{\#pragma omp atomic} cannot be extended to several statements, a possible (but still ugly)
solution would be to replace the \texttt{for} loop block from lines 12 to 19 with snippet~\ref{lst1}.

\begin{lstlisting}[float, caption={Proposed modification for correctness in task 2.}, label={lst1}]
    #pragma omp parallel for
    for (int i= 0; i < N; i++)
    {
        if (is_good(i)) // No change until here
        {
            int thread_pos{0}; // Define thread specific position variable
            #pragma omp critical // This block replaces the #pragma omp atomic section
            {
                thread_pos= pos; // Protected read
                pos++; // Protected write
            }
            good_members[thread_pos]= i; // Use thread specific variable
        }
    }
\end{lstlisting}

%\begin{thebibliography}{99}
%
%\bibitem{nasa}
%	NASA,
%	\emph{Haswell Processors},
%	online (\url{https://www.nas.nasa.gov/hecc/support/kb/haswell-processors_492.html}),
%	accessed 30-Sep-2018.
%
%\bibitem{intel}
%	Intel Corporation,
%	\emph{Intel Xeon Processor E5-2680 v3 Product Specifications},
%	online (\url{https://ark.intel.com/products/81908/}),
%	accessed 30-Sep-2018.
%
%\bibitem{euler}
%	ETH Zurich,
%	\emph{scientific computing wiki: Euler},
%	online (\url{https://scicomp.ethz.ch/wiki/Euler#Euler_II}),
%	accessed 30-Sep-2018.
%
%\bibitem{kou}
%	Petros Koumoutsakos,
%	\emph{HPCSE I Lecture Notes},
%	online (\url{http://www.cse-lab.ethz.ch/wp-content/uploads/2018/09/HPCSE_I_1_Intro.pdf}),
%	accessed 30-Sep-2018.
%
%\end{thebibliography}
%

%\appendix
%\section{Question 4, task d)}\label{app}
%\lstinputlisting{ex01_q4_task_d.cpp}
\end{document}


\subsection{Excitation laser power optimization}
\label{subsec:power_optim}

Firstly, we tried to establish the optimal laser power for excitation in
right-angle geometry using a spinning cell.
We used commercial samples of polyU (Sigma) dissolved in 80\,mM cacodylate
buffer with ph 6.4 to the concentration of 500\,\g{m}M per nucleobase.
We chose 244\,nm excitation laser wavelength with 10, 2, and 1 mW at samples.
The 150\,\g{m}L of the sample was rotated at 9600\,rpm during the measurement.
The spectral series were measured with 30\,s (10 and 2\,mW excitation) and
60\,s (1\,mW excitation) accumulation time per spectrum.
The beginning of each measurement was slightly delayed from the start of
the exposure to the laser because the samples needed to be adjusted for
optimal signal.
The adjustment took 26\,s for 10\,mW excitation, 90\,s for 2\,mW, and 69\,s
for 1\,mW excitation.

Further analysis was performed on the integral intensity of measured Raman
bands.
The band shapes were modeled as described in
\cref{band_intensities}
with the experimentally estimated Lorentzian curve fraction coefficient
$c_\text{L} = 0.5$, which visually gave the best band shape fit.
The linear function $a_0 + a_1\wn$ was added to the shape function
\eqnref{band_intensities:shape}
as the model of the spectral background.

The analysis was performed on the polyU integral intensity represented by
its band at 1231\,\icm{} compared to the intensity of the cacodylate band at
607\,\icm{} to account for the excitation laser power and sample adjustment
variations during the measurement.
\Figref{power_optim:triplexes_pU}
clearly shows that the polyU band also contains a shoulder at 1248\,\icm{}, and
is overlapping with the cacodylate band at 1276\,\icm.
Therefore, the band was modeled by the shape function
(\eqnref{band_intensities:shape})
with three components, but its intensity was calculated as a sum of the pulyU
bands without the cacodylate one.
The cacodylate band was modeled as having two components, at 607 and 640\,\icm,
but only the first one was used for the integral intensity calculation.

\begin{figure}
	\centering
	\input{results_and_discussion/assets/power_optimization_triplexes/%
		power_optimization_triplexes_pU}
	\caption[%
		Example UV RR spectrum of polyU dissolved in cacodylate buffer.%
	]{%
		\captiontitle{%
			Example UV RR spectrum of polyU dissolved in cacodylate buffer.%
		}
		The fits of shape functions
		(\eqnref{band_intensities:shape})
		to the bands of polyU and cacodylate used in intensity estimation fit are
		marked by green, and red lines, respectively, and the areas used for
		intensity calculation are filled with the corresponding colors.
	}
	\label{\figlabel{power_optim:triplexes_pU}}
\end{figure}

The time dependence of the intensity of polyU band at 1231\,\icm{} (normalized
to the intensity of cacodylate band at 607\,\icm) was modeled by the
exponential decay curve
\begin{equation}
	I = I_0 \text{e}^{-\lambda t} + b,
	\label{\eqnlabel{power_optim:decay}}
\end{equation}
where $I_0$ is initial intensity, $\lambda$ is the decay constant, and $b$ is
the baseline constant.
The normalized results (subtracted by $b$) can be seen in
\figref{power_optim:triplexes}.

\begin{figure}
	\centering
	\input{results_and_discussion/assets/power_optimization_triplexes/%
		power_optimization_triplexes}
	\caption[%
		Decrease of the integral intensity of polyU band at 1231\,\icm{} for
		different excitation laser powers in raw spectra.%
	]{%
		\captiontitle{%
			Decrease of the integral intensity of polyU band at 1231\,\icm{} for
			different excitation laser powers in raw spectra.%
		}
		It was normalized to the integral intensity of the cacodylate band at
		607\,\icm{}, which was used as the internal intensity standard.
		The values were fitted by exponential decay curves
		\eqnref{power_optim:decay}
		and the baseline constant $b$ from the fit was subtracted from the plots.
	}
	\label{\figlabel{power_optim:triplexes}}
\end{figure}

We can see, that the lines intersect almost at the same point, which is
expected outcome, but this point is not at 0\,s.
This is caused by the fact that the time axis denotes the ends of the spectrum
accumulation, whereas the intensity comes from the whole time period of the
spectrum acquisition, which is even more enhanced by the fact that band's
intensity lowers during the measurement.
The lifetimes $\tau$ can be calculated from decay constants $\lambda$ from
\eqnref{power_optim:decay}
\begin{equation}
	\tau = \frac{1}{\lambda}.
	\label{\eqnlabel{power_optim:lifetime}}
\end{equation}
We can also calculate total accumulated relative energy from the decay curve
by
\begin{equation*}
	E_{0,\text{r}}
		= \int_0^{\infty}{I_0 \text{e}^{-\lambda t}\text{d}t}
		= \frac{I_0}{\lambda}
\end{equation*}
and energy accumulated from time $T_0$ by
\begin{equation*}
	E_r	= \int_{T_0}^{\infty}{I_0 \text{e}^{-\lambda t}\text{d}t}
		= \frac{I_0}{\lambda} \text{e}^{-\lambda T_0}.
\end{equation*}
Energy fractions can then be calculated by dividing the relative energies by
the maximal total relative energy. The resulting lifetimes, total accumulated
energy fractions $E_0$, and energy fractions $E$ accumulated from time
$T = 60\pm20$\,s, which was regarded as reasonable approximate for the time
needed for adjustment of the sample before measurement could start, can be
seen in
\tabref{power_optim:lifetimes_triplexes}.

\begin{table}
	\centering
	\input{results_and_discussion/assets/power_lifetimes_triplexes}
	\caption[%
		Lifetimes of polyU in dependence on excitation power estimated from raw
		spectra.%
	]{%
		\captiontitle{%
			Lifetimes $\tau$ of the polyU in dependence on excitation power $P$
			estimated from raw spectra.%
		}
		$E_0$ are total energies accumulated by detector divided by maximal value
		across all the excitation powers $P$, and $E$ are energies accumulated from
		time $T = 60\pm20$\,s, which was needed for the adjustment of the
		samples before the acquisition can even start, but the sample needs to be
		irradiated by the excitation laser.
		The last column contains fractions of the samples $r$ which were not
		destroyed by photodecomposition after the time $T$.
	}
	\label{\tablabel{power_optim:lifetimes_triplexes}}
\end{table}

The results show that the 10\,mW power gave the best results if we do not take
into account adjustment of the samples, but as you can see in
\figref{power_optim:triplexes},
the signal intensity quickly lowers with time.
The lifetimes can also vary significantly in dependence on a sample which can
lower the reliability of the band intensity estimations.
The table shows that, after 1-minute adjustment of the sample, the 10\,mW
excitation photodecomposes about 35\% of the sample, whereas, with the 1\,mW
excitation, only around 6\% of the sample is destroyed.
The accumulated energies are calculated as integral to infinity, but we can
effectively measure only smaller portions of the decay with lower powers,
favoring measurements with higher powers.

Further investigation of the spectral decay behavior shows that this simple
approach does not reveal that a single decay curve cannot model such a complex
system.
This effect is clearly visible if we subtract the cacodylate buffer background
from the spectra.
The resulting spectrum can be seen in
\figref{power_optim:triplexes2_pU}.

\begin{figure}
	\centering
	\input{results_and_discussion/assets/power_optimization_triplexes2/%
		power_optimization_triplexes2_pU}
	\caption[%
		Example UV RR spectrum of polyU dissolved in cacodylate buffer with
	  the cacodylate buffer background subtracted.%
	]{%
		\captiontitle{%
			Example UV RR spectrum of polyU dissolved in cacodylate buffer with
			the cacodylate buffer background subtracted.%
		}
		The fit of shape function
		(\eqnref{band_intensities:shape})
		to the band of polyU used in intensity estimation fit is marked by a green
		line together with the area used for the intensity calculation.
	}
	\label{\figlabel{power_optim:triplexes2_pU}}
\end{figure}

The polyU band at 1230\,\icm{} can then be modeled directly without the
interference of the cacodylate band at 1276\,\icm{}.
It can be seen from the polyU band intensity dependence plot in
\figref{power_optim:triplexes2}
that the background subtraction process slightly obscures the intensity
normalization so that the fast decay curves cannot be modeled here.
However, we can also see a slower decay trend which is not evident from the fit
to the intensities of the polyU band calculated from the spectra without
subtracted background.
This is caused by the fact that it is harder to reliably decouple
the contribution of the overlapping polyU and cacodylate bands with the
lowering polyU band intensity.

\begin{figure}
	\centering
	\input{results_and_discussion/assets/power_optimization_triplexes2/%
		power_optimization_triplexes2}
	\caption[%
		Decrease of the integral intensity of the polyU band at 1231\,\icm{}
		for different excitation powers in background-corrected spectra.%
	]{%
		\captiontitle{%
			Decrease of the integral intensity of the polyU band at 1231\,\icm{}
			for different excitation powers in background-corrected spectra.%
		}
		The intensity was normalized to the subtracted spectrum of cacodylate
		buffer, which was used as the internal intensity standard.
		The values were fitted by exponential decay curves
		\eqnref{power_optim:decay}.
		The baseline constant $b$ from the fit was subtracted from the plots.
	}
	\label{\figlabel{power_optim:triplexes2}}
\end{figure}

For analysis of the optimal measurement conditions, we ignored the first 3, 3,
and 10 spectra for excitations at 1, 2, and 10\,mW, respectively, which visibly
deviated from the slow decay curves.
We used
\eqnref{power_optim:decay}
to estimate the lifetime $\tau$, total accumulated energy fractions $E_0$, and
energy fractions $E$ accumulated from time $T = 60\pm20$\,s the same way as
for the samples without subtracted background (see
\tabref{power_optim:lifetimes_triplexes2}).
The baseline constant $b$ was used only for the power of 10 mW, where it
decayed quickly to constant noise caused by the fit for an almost undetectable
band.
The table clearly shows that the slow decay process depends linearly on
excitation power.
In other words, the total accumulated energy is the same for all the
excitation powers, and that the lifetime is inversely related to the excitation
power.

\begin{table}
	\centering
	\input{results_and_discussion/assets/power_lifetimes_triplexes2}
	\caption[%
		Lifetimes of the polyU in dependence on excitation power estimated from
		the background-corrected spectra.%
	]{%
		\captiontitle{%
			Lifetimes $\tau$ of the polyU in dependence on excitation power $P$
			estimated from the background-corrected spectra.%
		}
		$E_0$ are total energies accumulated by detector divided by maximal value
		across all the excitation powers $P$, and $E$ are energies accumulated from
		the time $T = 60\pm20$\,s, which was needed for the adjustment of the
		samples before the acquisition can even start, but the sample needs to
		be irradiated by the excitation laser.
		The last column contains fractions of the samples $r$ that were not
		destroyed by photodecomposition after time $T$.
	}
	\label{\tablabel{power_optim:lifetimes_triplexes2}}
\end{table}

We can see that the system is complex, and our current methods cannot correctly
analyze the underlying processes.
Photoproducts can influence the resulting spectra, and therefore we
decided to use relatively lower excitation powers like 1\,mW or 0.5\,mW even
though the higher excitation power could probably give higher quality spectra.

We also tried to optimize the excitation laser power for the backscattering
measurements in thermostated cell holder.
We used 3\,mL of 125\,\g{m}M polyU samples dissolved in 40\,mM cacodylate
buffer with pH 6.8.
257\,nm was used as an excitation laser wavelength and a magnetic stirred
stirred the samples.
The spectral series was measured in 20\,s accumulation time per
spectrum.
The measurements in the thermostated cell holder were easier to set up
because the backscattering geometry and robust construction of the holder
were less sensitive to displacements which meant that the adjustments could be
performed on helper samples and, the real samples weren't exposed to the
laser power before measurement.

The analysis of the results was performed with the same steps as the analysis
of the measurements with a spinning cell using the integral intensity of the
polyU band at 1231\,\icm{} and the cacodylate band at 607\,\icm{}.
As we used 20 times
larger volumes of samples and 4 times lower concentrations, we should roughly
expect 5 times longer lifetimes, which means that we could observe only the
fast decay components, (see
\figref{power_optim:hairpins}
and
\tabref{power_optim:lifetimes_hairpins}).

\begin{figure}
	\centering
	\input{results_and_discussion/assets/power_optimization_hairpins/%
		power_optimization_hairpins}
	\caption[%
		Decrease of the integral intensity of the polyU band at 1231\,\icm{}
		for different excitation laser powers in raw spectra using
		backscattering geometry.%
	]{%
		\captiontitle{%
			Decrease of the integral intensity of the polyU band at 1231\,\icm{}
			for different excitation laser powers in raw spectra using
			backscattering geometry.%
		}
		It was normalized to the integral intensity of the cacodylate band at
		607\,\icm{}, which was used as the internal intensity standard.
		The values were fitted by exponential decay curves
		\eqnref{power_optim:decay}.
		The baseline constant $b$ from the fit was subtracted from the plots.
	}
	\label{\figlabel{power_optim:hairpins}}
\end{figure}

\begin{table}
	\centering
	\input{results_and_discussion/assets/power_lifetimes_hairpins}
	\caption[%
		Lifetimes of the polyU in dependence on excitation power
		estimated from raw spectra in backscattering geometry.%
	]{%
		\captiontitle{%
			Lifetimes $\tau$ of the polyU in dependence on excitation power $P$
			estimated from raw spectra in backscattering geometry.%
		}
		$E_0$ are total energies accumulated by detector divided by maximal value
		across all the excitation powers $P$.
	}
	\label{\tablabel{power_optim:lifetimes_hairpins}}
\end{table}

It can be seen that the lifetimes are proportionally longer with lower
excitation laser power and no further special effects are observable.
The lifetimes are slightly lower than the expected 5 times longer lifetimes as
compared to the
\tabref{power_optim:lifetimes_triplexes}
but almost in the range of estimated errors.
It can be caused by many effects like underestimated errors, different
excitation laser wavelength (257\,nm instead of 244\,nm), less effective
stirring in larger volumes, or longer laser path in the samples.
We can also see that higher intensity gives more reliable results with
lower errors because of a better SNR.
We decided to perform further measurements with 4\,mW of excitation power at
257\,nm and 5\,mW at 244\,nm.


% $Id$

\section{Appendix A: Master List of Constants}
\label{const:cmaster}

\subsection{ESMC\_CALKIND}
This flag is documented in section \ref{const:calkindflag_c}.

\subsection{ESMC\_COORDSYS}
This flag is documented in section \ref{const:ccoordsys}.

\subsection{ESMC\_DECOMP}
\label{const:cdecompflag}
{\sf DESCRIPTION:\\}
Indicates how DistGrid elements are decomposed over DEs.

The type of this flag is:

{\tt type(ESMC\_Decomp\_Flag)}

The valid values are:
\begin{description}
\item [ESMC\_DECOMP\_BALANCED]
      Decompose elements as balanced as possible across DEs. The maximum
      difference in number of elements per DE is 1, with the extra elements on
      the lower DEs.
\item [ESMC\_DECOMP\_CYCLIC]
      Decompose elements cyclically across DEs.
\item [ESMC\_DECOMP\_RESTFIRST]
      Divide elements over DEs. Assign the rest of this division to the first
      DE.
\item [ESMC\_DECOMP\_RESTLAST]
      Divide elements over DEs. Assign the rest of this division to the last DE.
\item [ESMC\_DECOMP\_SYMMEDGEMAX]
      Decompose elements across the DEs in a symmetric fashion. Start with the
      maximum number of elements at the two edge DEs, and assign a decending
      number of elements to the DEs as the center of the decomposition is
      approached from both sides.
\end{description}

{\tt type(ESMC\_ExtrapMethod\_Flag)}
\label{opt:cextrapmethod}

{\sf DESCRIPTION:\\}
Specify which extrapolation method to use on unmapped destination points after
regridding.

The type of this flag is:

{\tt type(ESMC\_ExtrapMethod\_Flag)}

The valid values are:
\begin{description}
\item [ESMC\_EXTRAPMETHOD\_NONE]
      Indicates that no extrapolation should be done.
\item [ESMC\_EXTRAPMETHOD\_NEAREST\_STOD]
      Inverse distance weighted average.
      Here the value of a destination point is the weighted average of the
      closest N source points. The weight is the reciprocal of the distance of
      the source point from the destination point raised to a power P. All the
      weights contributing to one destination point are normalized so that they
      sum to 1.0. The user can choose N and P when using this method, but
      defaults are also provided.
\item [ESMC\_EXTRAPMETHOD\_NEAREST\_IDAVG]
      Nearest source to destination.
      Here each destination point is mapped to the closest source point. A given
      source point may go to multiple destination points, but no destination
      point will receive input from more than one source point.
\end{description}

\subsection{ESMC\_FILEFORMAT}
This flag is documented in section \ref{const:cfileformat}.

\subsection{ESMC\_GRIDITEM}
This flag is documented in section \ref{const:cgriditem}.

\subsection{ESMC\_GRIDSTATUS}
This flag is documented in section \ref{const:cgridstatus}.

\subsection{ESMC\_INDEX}
\label{const:indexflag}

{\sf DESCRIPTION:\\}
Indicates whether index is local (per DE) or global (per object).

The type of this flag is:

{\tt type(ESMC\_IndexFlag)}

The valid values are:
\begin{description}
\item [ESMC\_INDEX\_DELOCAL]
      Indicates that DE-local index space starts at lower bound 1 for each DE.
\item [ESMC\_INDEX\_GLOBAL]
      Indicates that global indices are used. This means that DE-local index
      space starts at the global lower bound for each DE.
\item [ESMC\_INDEX\_USER]
      Indicates that the DE-local index bounds are explicitly set by the user.
\end{description}

\subsection{ESMC\_LINETYPE}
\label{opt:lineType}

{\sf DESCRIPTION:\\}  This argument allows the user to select the path of the
line which connects two points on the surface of a sphere.
This in turn controls the path along which distances are calculated and the
shape of the edges that make up a cell.

The type of this flag is:

{\tt type(ESMC\_LineType\_Flag)}

The valid values are:
\begin{description}
\item [ESMC\_LINETYPE\_CART]
    Cartesian line. When this option is specified distances are calculated in a
    straight line through the 3D Cartesian space in which the sphere is
    embedded. Cells are approximated by 3D planes bounded by 3D Cartesian lines
    between their corner vertices.
    When calculating regrid weights, this line type is currently the default for
    the following regrid methods: ESMC\_REGRIDMETHOD\_BILINEAR,
    ESMC\_REGRIDMETHOD\_PATCH, ESMC\_REGRIDMETHOD\_NEAREST\_STOD, and
    ESMC\_REGRIDMETHOD\_NEAREST\_DTOS.
\item [ESMC\_LINETYPE\_GREAT\_CIRCLE]
    Great circle line. When this option is specified distances are calculated
    along a great circle path (the shortest distance between two points on a
    sphere surface). Cells are bounded by great circle paths between their
    corner vertices. When calculating regrid weights, this line type is
    currently the default for the following regrid method:
    ESMC\_REGRIDMETHOD\_CONSERVE.
\end{description}

\subsection{ESMC\_LOGKIND}
This flag is documented in section \ref{const:clogkindflag}.

\subsection{ESMC\_LOGMSG}
This flag is documented in section \ref{const:clogmsgflag}.

\subsection{ESMC\_MESHELEMTYPE}
This flag is documented in section \ref{const:cmeshelemtype}.

\subsection{ESMF\_METHOD}
\label{const:cmethod}

{\sf DESCRIPTION:\\}
Specify standard ESMF Component method.

The type of this flag is:

{\tt type(ESMF\_Method\_Flag)}

The valid values are:
\begin{description}
\item [ESMF\_METHOD\_FINALIZE]
      Finalize method.
\item [ESMF\_METHOD\_INITIALIZE]
      Initialize method.
\item [ESMF\_METHOD\_READRESTART]
      ReadRestart method.
\item [ESMF\_METHOD\_RUN]
      Run method.
\item [ESMF\_METHOD\_WRITERESTART]
      WriteRestart method.
\end{description}

\subsection{ESMC\_POLEKIND}
This flag is documented in section \ref{const:cpolekind}.

\subsection{ESMC\_REDUCE}
\label{const:creduce}
{\sf DESCRIPTION:\\}
Indicates reduce operation.

The type of this flag is:

{\tt type(ESMC\_Reduce\_Flag)}

The valid values are:
\begin{description}
\item [ESMC\_REDUCE\_SUM]
      Use arithmetic sum to add all data elements.
\item [ESMC\_REDUCE\_MIN]
      Determine the minimum of all data elements.
\item [ESMC\_REDUCE\_MAX]
      Determine the maximum of all data elements.
\end{description}

\subsection{ESMC\_REGION}
\label{const:cregion}
{\sf DESCRIPTION:\\}
Specifies various regions in the data layout of an Array or Field object.

The type of this flag is:

{\tt type(ESMC\_Region\_Flag)}

The valid values are:
\begin{description}
\item [ESMC\_REGION\_TOTAL]
      Total allocated memory.
\item [ESMC\_REGION\_SELECT]
      Region of operation-specific elements.
\item [ESMC\_REGION\_EMPTY]
      The empty region contains no elements.
\end{description}

\subsection{ESMC\_REGRIDMETHOD}
This flag is documented in section \ref{opt:cregridmethod}.

\subsection{ESMC\_STAGGERLOC}
This flag is documented in section \ref{const:cstaggerloc}.

\subsection{ESMC\_TYPEKIND}
\label{const:ctypekind}

{\sf DESCRIPTION:\\}
Named constants used to indicate type and kind combinations supported by the
overloaded ESMC interfaces. The corresponding Fortran kind-parameter constants
are described in the ESMF\_TYPEKIND section of Appendices of the ESMF Fortran
reference manual.

The type of these named constants is:

{\tt type(ESMC\_TypeKind\_Flag)}

The named constants are:
\begin{description}
\item [ESMC\_TYPEKIND\_I1]
      Indicates 1 byte integer. \newline
      (Only available if ESMF was built with
      {\tt ESMF\_NO\_INTEGER\_1\_BYTE = FALSE}. This is {\em not} the default.)
\item [ESMC\_TYPEKIND\_I2]
      Indicates 2 byte integer. \newline
      (Only available if ESMF was built with
      {\tt ESMF\_NO\_INTEGER\_2\_BYTE = FALSE}. This is {\em not} the default.)
\item [ESMC\_TYPEKIND\_I4]
      Indicates 4 byte integer.
\item [ESMC\_TYPEKIND\_I8]
      Indicates 8 byte integer.
\item [ESMC\_TYPEKIND\_R4]
      Indicates 4 byte real.
\item [ESMC\_TYPEKIND\_R8]
      Indicates 8 byte real.
\end{description}

\subsection{ESMC\_UNMAPPEDACTION}
\label{const:unmappedaction}
{\sf DESCRIPTION:\\}
Indicates what action to take with respect to unmapped destination points
and the entries of the sparse matrix that correspond to these points.

The type of this flag is:

{\tt type(ESMC\_UnmappedAction\_Flag)}

The valid values are:
\begin{description}
	\item[ESMC\_UNMAPPEDACTION\_ERROR]
	An error is issued when there exist destination points in a regridding
	operation that are not mapped by corresponding source points.
	\item[ESMC\_UNMAPPEDACTION\_IGNORE]
	Destination points which do not have corresponding source points are
	ignored and zeros are used for the entries of the sparse matrix
	that is generated.
\end{description}


We will now explain how to fill a data file.
First you must specify some basic information like the dimension of your domain, its name, the problem type...
To define the problem dimension, we use the following keyword:

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    {\bf{Dimension}}  \textit{2}  or {\bf{Dimension}}  \textit{3}
    \end{alltt}
    \end{minipage}}
    \end{center}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Problems} \label{pbs}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You have to define the problem type that you wish to solve.

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    {\bf{Pb\textit{\_type}}} \textit{my\_problem}
    \end{alltt}
    \end{minipage}}
    \end{center}

Here are some of the available problem types:
\begin{itemize}
%\item \textbf{Pb\_Hydraulique$\left[\mbox{\_Turbulent}\right]$}
%\item \textbf{Pb\_Thermohydraulique$\left[\mbox{\_Turbulent}\right]$}
%\item \textbf{Pb\_Hydraulique\_Concentration$\left[\mbox{\_Turbulent}\right]$}
\item for incompressible flow: \textbf{Pb\_$\left[\mbox{\textcolor{magenta}{Thermo}}\right]$hydraulique$\left[\mbox{\textcolor{darkblue}{\_Concentration}}\right]\hspace{-0.15cm}\left[\mbox{\textcolor{Greeen}{\_Turbulent}}\right]$},
\item for quasi-compressible flow: \textbf{Pb\_Thermohydraulique$\left[\mbox{\textcolor{Greeen}{\_Turbulent}}\right]$\_QC},
%\item for quasi-compressible flow:\\
%    \textbf{Pb\_Thermohydraulique$\left[\mbox{\textcolor{Greeen}{\_Turbulent}}\right]$\_QC$\left[\mbox{\textcolor{mauve}{\_fraction\_massique}}\right]$},
\item for solid: \textbf{Pb\_Conduction},
\item you can find all \href{\REFERENCEMANUAL\#Pbbase}{problem types} in the Reference Manual.
\end{itemize}

where:
\begin{itemize}
\item \textbf{hydraulique}: means that we will solve Navier Stokes equations without energy equation,
\item \textbf{\textcolor{magenta}{Thermo}}: means that we will solve Navier Stokes equations with energy equation,
\item \textbf{\textcolor{darkblue}{Concentration}}: that we will solve multiple constituent transportation equations,
\item \textbf{\textcolor{Greeen}{Turbulent}}: that we will simulate a turbulent flow and specify a turbulent model (RANS or LES). (Since version v1.8.0, \textcolor{Greeen}{Turbulence} models are in TrioCFD not in TRUST).
\item \textbf{Conduction}: resolution of the heat equation,
\item \textbf{QC}: Navier Stokes equations with energy equation for quasi-compressible fluid under low Mach approach,
%\item \textbf{\textcolor{mauve}{fraction\_massique}}: hydraulic and energy equations are solved and a list of passive scalar equations may be added.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Domain definition}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
To define the domain, you must name it. This is done thanks to the following block:

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    {\bf{Domaine}}  \textit{my\_domain}
    \end{alltt}
    \end{minipage}}
    \end{center}

Then you must add your mesh to your simulation.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Mesh} \label{Mesh}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Notice the presence of the tags:
\begin{alltt}
\textcolor{blue}{\# BEGIN MESH \#}
...
\textcolor{blue}{\# END MESH \#}
\end{alltt}
in the data file of section \ref{data}.
This is necessary for parallel calculation (see section \ref{parallel}).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Allowed meshes}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\trust allows:
\begin{itemize}
\item quadrangular or triangular undeformed meshing for 2D cases (Figure \ref{2D_mesh}),
\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=2, line width=1pt]
\coordinate (A) at (0,0) ;
\coordinate (B) at (1.5,0) ;
\coordinate (C) at (1.5,1) ;
\coordinate (D) at (0,1) ;
\draw[black] (A) -- (B) -- (C) -- (D) -- cycle ;
\coordinate (E) at (3,0) ;
\coordinate (F) at (4.5,0) ;
\coordinate (G) at (3.75,1) ;
\draw[black] (E) -- (F) -- (G) -- cycle ;
\end{tikzpicture}
\caption{2D allowed elements}
\label{2D_mesh}
\end{center}
\end{figure}

\item hexahedral or tetrahedral undeformed meshing for 3D cases (Figure \ref{3D_mesh}).
\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=2, line width=1pt]
\coordinate (A) at (0  ,0  ,0) ;
\coordinate (B) at (1.5,0  ,0) ;
\coordinate (C) at (1.5,1  ,0) ;
\coordinate (D) at (0  ,1  ,0) ;
\coordinate (E) at (0  ,0  ,-0.5) ;
\coordinate (F) at (1.5,0  ,-0.5) ;
\coordinate (G) at (1.5,1  ,-0.5) ;
\coordinate (H) at (0  ,1  ,-0.5) ;
\draw (D) -- (A) -- (B) -- (C) -- (D) -- (H) -- (G) -- (F) -- (B);
\draw (C) -- (G);
\draw [dashed] (A) -- (E) -- (H);
\draw [dashed] (E) -- (F);
\coordinate (I) at (3   ,0  ,0) ;
\coordinate (J) at (4.5 ,0  ,0) ;
\coordinate (K) at (3.75,1.2,0) ;
\coordinate (L) at (4   ,0.5,-0.7) ;
\draw[black] (K) -- (I) -- (J) -- (K) -- (L) -- (J) ;
\draw [dashed] (I) -- (L);
\end{tikzpicture}
\caption{3D allowed elements}
\label{3D_mesh}
\end{center}
\end{figure}
\end{itemize}

\textbf{Be carefull} non standard and hybrid meshing are not supported! (cf Figure \ref{hybr})

\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=2, line width=1pt]
\coordinate (A1) at (0,0) ;
\coordinate (A2) at (0,1) ;
\coordinate (A3) at (0,2) ;
\coordinate (B1) at (1.5,0  ) ;
\coordinate (B2) at (1.5,0.5) ;
\coordinate (B3) at (1.5,1  ) ;
\coordinate (B4) at (1.5,1.5) ;
\coordinate (B5) at (1.5,2  ) ;
\coordinate (C1) at (3,0  ) ;
\coordinate (C2) at (3,0.5) ;
\coordinate (C3) at (3,1  ) ;
\coordinate (C4) at (3,1.5) ;
\coordinate (C5) at (3,2  ) ;
\draw (A1) -- (C1) -- (C5) -- (A3) -- (A1);
\draw (A2) -- (C3);
\draw (B1) -- (B5);
\draw (B4) -- (C4);
\draw (B2) -- (C2);
\draw [ultra thick,red] (-0.25,2.25) -- (3.25,-0.25) ;

\coordinate (D1) at (4   ,0) ;
\coordinate (D2) at (5.5 ,0) ;
\coordinate (D3) at (5.5 ,1.25) ;
\coordinate (D4) at (4   ,1.25) ;
\coordinate (D5) at (4.75,2.25) ;
\draw (D4) -- (D1) -- (D2) -- (D3) -- (D4) -- (D5) -- (D3);
\draw [ultra thick,red] (3.75,2) -- (6,-0.25) ;

\coordinate (E1) at (6.5 ,0   ,0) ;
\coordinate (E2) at (8   ,0   ,0) ;
\coordinate (E3) at (8   ,1.25,0) ;
\coordinate (E4) at (6.5 ,1.25,0) ;
\coordinate (E5) at (7.25,2.25,0) ;
\coordinate (E6) at (8   ,0   ,-0.7) ;
\coordinate (E7) at (8   ,1.25,-0.7) ;
\coordinate (E8) at (6.5 ,1.25,-0.7) ;
\draw (E4) -- (E1) -- (E2) -- (E3) -- (E4) -- (E5) -- (E3);
\draw (E2) -- (E6) -- (E7) -- (E8) -- (E4);
\draw (E8) -- (E5) -- (E7) -- (E3) -- (E8);
\draw [ultra thick,red] (6.5,2) -- (8.5,-0.25) ;

\end{tikzpicture}
\caption{Prohibited meshes}
\label{hybr}
\end{center}
\end{figure}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Import a mesh file}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
If your mesh was generated with an external tool like \href{http://www.salome-platform.org}{Salom\'e} (open source software), \href{http://resource.ansys.com/Products/Other+Products/ANSYS+ICEM+CFD}{ICEM} (commercial software), \href{http://gmsh.info/}{Gmsh} (open source software, included in \trust package) or \href{http://www-cast3m.cea.fr/}{Cast3M} (CEA software), then you must use one of the following keywords into your data file:

\begin{itemize}
\item \href{\REFERENCEMANUAL\#readmed}{\textbf{Read\_MED}} for a MED file from \href{http://www.salome-platform.org}{Salom\'e}, \href{http://gmsh.info/}{Gmsh},... ,
\item \href{\REFERENCEMANUAL\#readfile}{\textbf{Read\_File}} for a binary mesh file from \href{http://resource.ansys.com/Products/Other+Products/ANSYS+ICEM+CFD}{ICEM},
\item for another format, see the \href{\REFERENCEMANUAL\#read}{\trustref Reference Manual}.
\end{itemize}

If you want to learn how to build a mesh with Salom\'e or Gmsh and read it with \trust, you can look at the exercises of the \trust tutorial: \href{TRUST_tutorial.pdf\#salome}{here} for Salom\'e and \href{TRUST_tutorial.pdf\#gmsh}{here} for Gmsh.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Quickly create a mesh}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Here is an example of a simple geometry (of non complex channel type) using the internal tool of \trust:
\begin{center}
\fbox{ \begin{minipage}[c]{0.9\textwidth}
\begin{alltt}
{\bf{Mailler}} \textit{my\_domain}

\{

\hspace{1cm}        \textcolor{blue}{/* Define the domain with one cavity */}

\hspace{1cm}        \textcolor{blue}{/* cavity 1m*2m with 5*22 cells */}

\hspace{1cm}        {\bf{Pave}} \textit{box}

\hspace{1cm}        \{

\hspace{2cm}            {\bf{Origine}} 0. 0.

\hspace{2cm}            {\bf{Longueurs}} 1 2

\hspace{2cm}            \textcolor{blue}{/* Cartesian grid */}

\hspace{2cm}            {\bf{Nombre\_de\_Noeuds}} 6 23

\hspace{2cm}            \textcolor{blue}{/* Uniform mesh */}

\hspace{2cm}            {\bf{Facteurs}} 1. 1.

\hspace{1cm}        \}

\hspace{1cm}        \{

\hspace{2cm}            \textcolor{blue}{/* Definition and names of boundary conditions */}

\hspace{2cm}            {\bf{bord}} \textit{Inlet}   \hspace{0.25cm} X = 0.  0. <= Y <= 2.

\hspace{2cm}            {\bf{bord}} \textit{Outlet}  \hspace{0.05cm} X = 1.  0. <= Y <= 2.

\hspace{2cm}            {\bf{bord}} \textit{Upper}   \hspace{0.25cm} Y = 2.  0. <= X <= 1.

\hspace{2cm}            {\bf{bord}} \textit{Lower}   \hspace{0.25cm} Y = 0.  0. <= X <= 1.

\hspace{1cm}        \}

\}
\end{alltt}
\end{minipage}}
\end{center}

To use this mesh in your data file, you just have to add the previous block in your data file or save it in a file named for example "\textit{my\_mesh.geo}" and add the line:\\
\begin{center}
\fbox{ \begin{minipage}[c]{0.5\textwidth}
\begin{alltt}
{\bf{Read\_file}} \textit{my\_mesh.geo} \textcolor{red}{{\bf{;}}}
\end{alltt}
\end{minipage}}
\end{center}

\underline{Do not forget the semicolon at the end of the line!}\\

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Transform mesh within the data file}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You can also make transformations on your mesh after the \textbf{"Mailler"} or \textbf{"Read\_*"} command, using the following keywords:
\begin{itemize}
\item \href{\REFERENCEMANUAL\#triangulate}{\textbf{Trianguler}} to triangulate your 2D cells and create an unstructured mesh.
\item \href{\REFERENCEMANUAL\#tetraedriser}{\textbf{Tetraedriser}} to tetrahedralise 3D cells and create an unstructured mesh.
\item \href{\REFERENCEMANUAL\#raffineranisotrope}{\textbf{Raffiner\_anisotrope}}/\href{\REFERENCEMANUAL\#raffinerisotrope}{\textbf{Raffiner\_isotrope}} to triangulate/tetrahedralise elements of an untructured mesh.
\item \href{\REFERENCEMANUAL\#extrudebord}{\textbf{ExtrudeBord}} to generate an extruded mesh from a boundary of a tetrahedral or an hexahedral mesh.
\Note that ExtrudeBord in VEF generates 3 or 14 tetrahedra from extruded prisms.
\item \href{\REFERENCEMANUAL\#regroupebord}{\textbf{RegroupeBord}} to build a new boundary with several boundaries of the domain.
\item \href{\REFERENCEMANUAL\#transformer}{\textbf{Transformer}} to transform the coordinates of the geometry.
\item for other commands, see the section \href{\REFERENCEMANUAL\#interprete}{interprete} of the \trustref Reference Manual.
\end{itemize}

\Note that theses mesh modifications work on all mesh types (i.e. also for \textbf{*.geo} or \textbf{*.bin} or \textbf{*.med} files).

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Test your mesh}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
The keyword \href{\REFERENCEMANUAL\#discretiserdomaine}{\textbf{Discretiser\_domaine}} is useful to discretize the domain (faces will be created) without defining a problem.
Indeed, you can create a minimal data file, post-process your mesh in lata format (for example) and visualize it with VisIt. \\

\Note that you must name all the boundaries!\\

Here is an example of this kind of data file:

\begin{center}
\fbox{ \begin{minipage}[c]{0.8\textwidth}
\begin{center}
\textbf{my\_data\_file.data}
\end{center}
\end{minipage}}
\fbox{ \begin{minipage}[c]{0.8\textwidth}
\begin{alltt}
{\bf{dimension 3}}

{\bf{Domaine}} \textit{my\_domain}

{\bf{Mailler}} \textit{my\_domain}

\{

\hspace{1cm}    {\bf{Pave}} \textit{box}

\hspace{1cm}    \{

\hspace{2cm}        {\bf{Origine}} 0. 0. 0.

\hspace{2cm}        {\bf{Longueurs}} 1 2 1

\hspace{2cm}        {\bf{Nombre\_de\_Noeuds}} 6 23 6

\hspace{2cm}        {\bf{Facteurs}} 1. 1. 1.

\hspace{1cm}    \}

\hspace{1cm}    \{

\hspace{2cm}        {\bf{bord}} \textit{Inlet}  \hspace{0.25cm} X = 0. 0. <= Y <= 2.  0. <= Z <= 1.

\hspace{2cm}        {\bf{bord}} \textit{Outlet} \hspace{0.05cm} X = 1.  0. <= Y <= 2.  0. <= Z <= 1.

\hspace{2cm}        {\bf{bord}} \textit{Upper}  \hspace{0.25cm} Y = 2.  0. <= X <= 1.  0. <= Z <= 1.

\hspace{2cm}        {\bf{bord}} \textit{Lower}  \hspace{0.25cm} Y = 0. 0. <= X <= 1.  0. <= Z <= 1.

\hspace{2cm}        {\bf{bord}} \textit{Front}  \hspace{0.25cm} Z = 0. 0. <= X <= 1.  0. <= Y <= 2.

\hspace{2cm}        {\bf{bord}} \textit{Back}   \hspace{0.45cm} Z = 1. 0. <= X <= 1.  0. <= Y <= 2.

\hspace{1cm}    \}

\}

{\bf{discretiser\_domaine}} \textit{my\_domain}

{\bf{postraiter\_domaine}} \{ {\bf{domaine}} \textit{my\_domain} {\bf{format lata}} \}

{\bf{End}}
    \end{alltt}
\end{minipage}}
\end{center}

To use it, launch in a bash terminal:
\begin{verbatim}
# if not already done
> source $my_path_to_TRUST_installation/env_TRUST.sh
# then
> trust my_data_file
> visit -o my_data_file.lata &
\end{verbatim}

To see how to use VisIt, look at the first \trust tutorial exercise: \href{TRUST_tutorial.pdf\#exo1}{Flow around an obstacle}.\\

If you want to learn how to make a mesh with Salom\'e or Gmsh and read it with \trust, you can look at the exercises of the \trust tutorial: \href{TRUST_tutorial.pdf\#salome}{here} for Salom\'e and \href{TRUST_tutorial.pdf\#gmsh}{here} for Gmsh.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Discretization}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You have to specify the discretization type which can be \href{\REFERENCEMANUAL\#vdf}{\textbf{VDF}}, \href{\REFERENCEMANUAL\#ef}{\textbf{EF}} or \href{\REFERENCEMANUAL\#vefprep1b}{\textbf{VEFPreP1B}}.\\

In \textbf{VDF} discretization, the locations of the unknowns are drawn in the Figure \ref{fig_VDF}.\\

\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=2, line width=1pt]
\coordinate (A) at (0,0) ;
\coordinate (B) at (1,0) ;
\coordinate (C) at (2,0) ;
\coordinate (D) at (2,1) ;
\coordinate (E) at (2,2) ;
\coordinate (F) at (1,2) ;
\coordinate (G) at (0,2) ;
\coordinate (H) at (0,1) ;
\draw[black] (A) -- (C) -- (E) -- (G) -- cycle ;
\draw[black] (H) -- (D) ;
\draw[black] (F) -- (B) ;
\draw[black,fill=red] (0.5,0.5) circle (0.07);
\draw[black,fill=red] (1.5,0.5) circle (0.07);
\draw[black,fill=red] (0.5,1.5) circle (0.07);
\draw[black,fill=red] (1.5,1.5) circle (0.07);
\draw[blue] [->] [>=latex] (0.5,0) -- (0.5,0.35);
\draw[blue] [->] [>=latex] (0.5,1) -- (0.5,1.35);
\draw[blue] [->] [>=latex] (0.5,2) -- (0.5,2.35);
\draw[blue] [->] [>=latex] (1.5,0) -- (1.5,0.35);
\draw[blue] [->] [>=latex] (1.5,1) -- (1.5,1.35);
\draw[blue] [->] [>=latex] (1.5,2) -- (1.5,2.35);
\draw[blue] [->] [>=latex] (0,0.5) -- (0.35,0.5);
\draw[blue] [->] [>=latex] (1,0.5) -- (1.35,0.5);
\draw[blue] [->] [>=latex] (2,0.5) -- (2.35,0.5);
\draw[blue] [->] [>=latex] (0,1.5) -- (0.35,1.5);
\draw[blue] [->] [>=latex] (1,1.5) -- (1.35,1.5);
\draw[blue] [->] [>=latex] (2,1.5) -- (2.35,1.5);
\draw[blue] (4,2) node[above]{$\vec{V} \cdot \vec{n}$} ;
\draw[blue] [<-] (1.65,2.2) -- (3.7,2.1);
\draw[blue] [<-] (2.25,1.6) -- (3.7,2.1);
\draw[red] (4,0.5) node {$P, T, k, \varepsilon, ...$} ;
\draw[red] [<-] (1.6,1.4) -- (3.45,0.55);
\end{tikzpicture}
\caption{VDF unknown locations}
\label{fig_VDF}
\end{center}
\end{figure}

For \textbf{VEFPreP1B}, the locations of the unknowns are drawn in the Figure \ref{fig_VEF}.\\

\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=1, line width=1pt]
\coordinate (A) at (1.5,0) ;
\coordinate (B) at (6,0.5) ;
\coordinate (C) at (8,3.5) ;
\coordinate (D) at (2.5,4.5) ;
\coordinate (E) at (0,3) ;
\coordinate (F) at (4,2.5) ;
\draw[black] (A) -- (B) -- (C) -- (D) -- (E) -- (A) -- (F) -- (B);
\draw[black] (C) -- (F) -- (D);
\draw[black] (E) -- (F);
\draw[black,fill=black] (A) circle (0.15);
\draw[black,fill=black] (B) circle (0.15);
\draw[black,fill=black] (C) circle (0.15);
\draw[black,fill=black] (D) circle (0.15);
\draw[black,fill=black] (E) circle (0.15);
\draw[black,fill=black] (F) circle (0.15);
\draw[black,fill=red] (3.75,1) circle (0.15);
\draw[black,fill=red] (6,2) circle (0.15);
\draw[black,fill=red] (4.75,3.5) circle (0.15);
\draw[black,fill=red] (2.2,3.4) circle (0.15);
\draw[black,fill=red] (1.75,1.75) circle (0.15);
\begin{scope}[xshift=5cm, yshift=1.5cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=7cm, yshift=2cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=5.2cm, yshift=4cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=1.25cm, yshift=3.75cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=0.75cm, yshift=1.5cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=2.75cm, yshift=1.25cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=3.75cm, yshift=0.25cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=6cm, yshift=3cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=3.25cm, yshift=3.5cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\begin{scope}[xshift=2cm, yshift=2.75cm]
\draw[blue] [->] [>=latex] (0,0) -- (0.8,0.3);
\end{scope}
\draw[blue] (11.5,3.5) node {$\vec{V_x}, \vec{V_y}, \vec{V_z}, T, k, \varepsilon, ...$} ;
\draw[blue] [->] [>=latex] (9.5,3.5) -- (5.6,4.1);
\draw[blue] [->] [>=latex] (9.5,3.5) -- (3.5,3.5);
\draw[blue] [->] [>=latex] (9.5,3.5) -- (6.25,3);
\draw[red] (11.5,2) node {$P$ for P0 discretization} ;
\draw[red] [->] [>=latex] (9.25,2) -- (6.25,2);
\draw[black] (11.5,1) node {$P$ for P1 discretization} ;
\draw[black] [->] [>=latex] (9.25,1) -- (6.25,0.5);
\end{tikzpicture}
\caption{VEF unknown locations in 2D}
\label{fig_VEF}
\end{center}
\end{figure}

In 3D for the pressure, we can also use the P0+P1+Pa discretization for flow with a strong source term and a low velocity field.
In this case P0+P1 pressure gradient has trouble to match the source term so we use P0+P1+Pa discretization (cf Figure \ref{fig_VEF_pressure_loc}).

\begin{figure}[h!]
\begin{center}
\begin{tikzpicture}[scale=1, line width=1pt]
\coordinate (A) at (0.5,1) ;
\coordinate (B) at (3,0.5) ;
\coordinate (C) at (4,2.5) ;
\coordinate (D) at (2,4) ;
\draw[black] (B) -- (C) -- (D) -- (A) -- (B) -- (D);
\draw[black,dashed] (A) -- (C);
\draw[black,fill=black] (A) circle (0.15);
\draw[black,fill=black] (B) circle (0.15);
\draw[black,fill=black] (C) circle (0.15);
\draw[black,fill=black] (D) circle (0.15);
\draw[black,fill=Greeen] (1.75,0.75) circle (0.15);
\draw[black,fill=Greeen] (3.5,1.5) circle (0.15);
\draw[black,fill=Greeen] (3,3.25) circle (0.15);
\draw[black,fill=Greeen] (1.25,2.5) circle (0.15);
\draw[black,fill=Greeen] (2.25,1.75) circle (0.15);
\draw[black,fill=Greeen] (2.5,2.25) circle (0.15);
\draw[black,fill=red] (2.2,2) circle (0.15);
\draw[black] (10,3) node {$P$ for P1 discretization} ;
\draw[black] [->] [>=latex] (7.75,3) -- (2.2,4);
\draw[black] [->] [>=latex] (7.75,3) -- (4.2,2.5);
\draw[red] (10,2) node {$P$ for P0 discretization} ;
\draw[red] [->] [>=latex] (7.75,2) -- (2.5,2);
\draw[Greeen] (10,1) node {$P$ for Pa discretization} ;
\draw[Greeen] [->] [>=latex] (7.75,1) -- (3.7,1.5);
\draw[Greeen] [->] [>=latex] (7.75,1) -- (2,0.75);
\end{tikzpicture}
\caption{VEF pressure location in 3D}
\label{fig_VEF_pressure_loc}
\end{center}
\end{figure}

To specify the wanted discretization, you have to add the following block to your data file:

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    \textit{{\bf{Discretization\_type}} my\_discretization}

    [{\bf{Read }} \textit{my\_discretization \{ ... \}}]
    \end{alltt}
    \end{minipage}}
    \end{center}

You can add parameters to your discretization with the optional keyword \href{\REFERENCEMANUAL\#read}{\textbf{Read}} (see \href{\REFERENCEMANUAL\#vefprep1b}{\textbf{VEFPreP1B discretization}}).

On the \href{http://triocfd.cea.fr/}{TrioCFD website}, you can find information about:
\begin{itemize}
\item \textbf{VDF} discretization in the \href{http://triocfd.cea.fr/Documents/DOCS THESES/these_chatelain_2004.pdf}{PhD thesis of A. Chatelain},
\item \textbf{VEFPreP1B} discretization (Crouzet-Raviart elements) in the \href{http://triocfd.cea.fr/Documents/DOCS THESES/these_fortin_2006.pdf}{PhD thesis of T. Fortin} and \href{http://triocfd.cea.fr/Documents/DOCS THESES/These_Heib_2003.pdf}{PhD thesis of S. Heib}.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Time schemes}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Now you can choose your time scheme to solve your problem. For this you must
specify the time scheme type wanted and give it a name.
then you have to specify its parameters by filling the associated \textbf{"Read"} block.

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    {\bf{\textit{Scheme\_type}}} \textit{my\_time\_scheme}

    {\bf{Read}} \textit{my\_time\_scheme} \{ ... \}
    \end{alltt}
    \end{minipage}}
    \end{center}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Some available time schemes}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%Here are some \href[page=DOCLINK_TIME SCHEMES]{\REFERENCEMANUAL}{available types of explicit schemes}:
Here are some available types of explicit schemes:
\begin{itemize}
\item \href{\REFERENCEMANUAL\#eulerscheme}{\textbf{Scheme\_Euler\_explicit}},
\item \href{\REFERENCEMANUAL\#schemaadamsbashforthorder2}{\textbf{Schema\_Adams\_Bashforth\_order\_2}},
%\item \textbf{Schema\_Adams\_Bashforth\_order\_3}
%\item \textbf{Runge\_Kutta\_Rationnel\_ordre\_2}
\item \href{\REFERENCEMANUAL\#rungekuttaordre3}{\textbf{Runge\_Kutta\_ordre\_3}},
%\item \textbf{Runge\_Kutta\_ordre\_4\_D3P}
%\item \textbf{Schema\_Predictor\_Corrector}
%\item \textbf{Sch\_CN\_iteratif}
%\item \textbf{Sch\_CN\_EX\_iteratif}
%\item \textbf{Schema\_Phase\_Field}
%\item \textbf{RK3\_FT}
\end{itemize}

%And also some \href[page=DOCLINK_TIME SCHEMES]{\REFERENCEMANUAL}{available types of implicit schemes}:
And also some available types of implicit schemes:
\begin{itemize}
\item \href{\REFERENCEMANUAL\#schemaeulerimplicite}{\textbf{Scheme\_Euler\_implicit}},
%\item \textbf{Schema\_Adams\_Moulton\_order\_2}
\item \href{\REFERENCEMANUAL\#schemaadamsmoultonorder3}{\textbf{Schema\_Adams\_Moulton\_order\_3}}.
%\item \textbf{Schema\_Backward\_Differentiation\_order\_2}
%\item \textbf{Schema\_Backward\_Differentiation\_order\_3}
\end{itemize}

For other schemes, see \href{\REFERENCEMANUAL\#schematempsbase}{this section} of the Reference Manual.\\

\Note that you can use semi-implicit schemes activating the \textbf{diffusion\_implicite} keyword in your explicit time scheme.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Calculation stopping condition}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
You must specify at least one stopping condition for you simulation.
It can be:
\begin{itemize}
\item the final time: \textbf{tmax}
\item the maximal allowed cpu time: \textbf{tcpumax}
\item the number of time step: \textbf{nb\_pas\_dt\_max}
\item the convergency treshold: \textbf{seuil\_statio}
\end{itemize}

\Note that if the time step reaches the minimal time step \textbf{dt\_min}, \trust will stop the calculation.\\

If you want to stop properly your running calculation (i.e. with all saves), you may use the \textit{my\_data\_file}.stop file (cf section \ref{stopfile}).
When the simulation is running, you can see the "\textbf{0}" value in that file.\\

To stop it, put a "\textbf{1}" instead of the "\textbf{0}", save the file and at the next iteration the calculation will stop properly.\\

When you don't change anything in that file, at the end of the calculation, you can see that it is writen "\textbf{Finished correctly}".

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Medium/Type of fluide}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
To specify the medium or fluid, you must add the following block.

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    {\bf{\textit{Fluid\_type}}} \textit{my\_medium}

    {\bf{Read}} \textit{my\_medium} \{ ... \}
    \end{alltt}
    \end{minipage}}
    \end{center}

{\bf{\textit{Fluid\_type}}} can be one of the following:
\begin{itemize}
\item \href{\REFERENCEMANUAL\#fluideincompressible}{\textbf{Fluide\_incompressible}}
\item \href{\REFERENCEMANUAL\#fluidequasicompressible}{\textbf{Fluide\_quasi\_compressible}}
%\item \textbf{Fluide\_Ostwald}
%\item \textbf{Constituant}
\item \href{\REFERENCEMANUAL\#solide}{\textbf{Solide}}
\item for other types and more information see \href{\REFERENCEMANUAL\#milieubase}{\trustref Reference Manual}.
\end{itemize}

If you want to use more than one medium, you can add another blocks for each medium or fluid.\\

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Add gravity}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
If needed, you can add a gravity term to your simulation. This is done by adding
a uniform field, no matter his name. For example in 2D:

    \begin{center}
    \fbox{ \begin{minipage}[c]{0.5\textwidth}
    \begin{alltt}
    \textcolor{blue}{\# Gavity vector definition \#}

    {\bf{Uniform\_field}} \textit{my\_gravity}

    {\bf{Read}} \textit{my\_gravity 2 0 -9.81}

    \end{alltt}
    \end{minipage}}
    \end{center}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Objects association and discretization}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Association}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Until now, we have created some objects, now we must associate them together.
For this, we must use the \href{\REFERENCEMANUAL\#associate}{\textbf{Associate}} interpretor:
    \begin{center}
    \fbox{ \begin{minipage}[c]{0.7\textwidth}
    \begin{alltt}
    \textcolor{blue}{\# Association between the different objects \#}

    {\bf{Associate}} \textit{my\_problem my\_domain}

    {\bf{Associate}} \textit{my\_problem my\_time\_scheme}

    {\bf{Associate}} \textit{my\_problem my\_medium}

    [{\bf{Associate}} \textit{my\_medium my\_gravity}]
    \end{alltt}
    \end{minipage}}
    \end{center}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Discretization}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Then you must discretize your domain using the \href{\REFERENCEMANUAL\#discretize}{\textbf{Discretize}} interpretor:
    \begin{center}
    \fbox{ \begin{minipage}[c]{0.7\textwidth}
    \begin{alltt}
    {\bf{Discretize}}  \textit{my\_problem  my\_discretization}
    \end{alltt}
    \end{minipage}}
    \end{center}

The problem \textit{my\_problem} is discretized according to the \textit{my\_discretization} discretization.\\

IMPORTANT: A number of objects must be already associated (a domain, time scheme, central object) prior to invoking the \textbf{Discretize} keyword. The physical properties of this central object must also have been read.\\

\Note that when the discretization step succeeds, the mesh is validated by the code.\\

At this level of your data file, you can visualize your mesh with the "\textbf{-mesh}" option of the trust script, it will directly open your mesh with VisIt.
\begin{verbatim}
# if not already done
> source $my_path_to_TRUST_installation/env_TRUST.sh
# then
> trust -mesh my_data_file
\end{verbatim}
It will only run the mesh and stop, the problem will not be solved.


% !TEX root = ../zeth-protocol-specification.tex

\section{Generating the inputs of the $\mix$ function (\inp{\mix})}\label{zeth-protocol:mix-inp}

In the following section, we assume that the system is initialized. In other words, we assume that a ledger $\ledger$ is available (i.e.~an \ethereum~network is operated by a set of miners), the $\mixer$ contract is deployed on $\ledger$. Likewise, we assume that the public parameters $\pparams_{\zksnark} \gets \zksnark.\kgen(\secparam, \RELCIRC)$ are available to $\mixer$ and to all parties willing to call the $\mix$ function of $\mixer$. Furthermore, we assume that there exists a set of \ethereum~and \zeth~users, and that the \emph{payment address} of each \zeth~user is easily discoverable. In the rest of this section, the set of \emph{payment addresses} discovered by a zeth user $\zparty{U}$ is represented as a list attribute $\zparty{U}.\keystore$ indexed by usernames.

\medskip

In order for $\zparty{U}$ to transact via \zeth, $\zparty{U}$ needs to create an object $\inp{\mix}$ of type $\mixInputDType$ to pass to the $\mix$ function of $\mixer$:
\begin{enumerate}
    \item Create an object $\priminputs$ of type $\primInputDType$ to represent the primary input, and an object $\auxinputs$ of type $\auxInputDType$ to represent the auxiliary input, where:
    \begin{enumerate}
        \item $\priminputs.\mkroot \in \rootset$, where $\rootset$ is the set of \emph{all} Merkle roots corresponding to one of the state of the Merkle tree on $\mixer$ containing \emph{all} the commitments to the input notes, in $\auxinputs.\jsins{}$, in its set of leaves.
        \item $\auxinputs.\znotes{j}.\noter \sample \BB^{\noterLen}, \forall j \in [\jsout]$, and $\auxinputs.\pphi \sample \BB^{\phiLen}$
        \item The public values $(\auxinputs.\vin, \auxinputs.\vout) \in {(\BB^{\zvalueLen})}^{2}$, $\auxinputs.\znotes{j}.\notev$ and $\auxinputs.\znotes{j}.\apk\ \forall j \in [\jsout]$ are all set by the sender, $\zparty{U}$, as desired as long as they satisfy the \gls{joinsplit-eq}.
        \item All attributes of the $\priminputs$ and $\auxinputs$ objects should be derived as specified in the statement (see~\cref{zeth-protocol:statement}), alongside a signature hash ($\auxinputs.\hsig$) that is generated as the hash of the nullifiers and a one-time signing verification key (non-malleability, see~\cref{appendix:trnm}), using the desired signature scheme $\otsigscheme$ (see~\cref{instantiation:otsig}):
            \begin{align}
                & (\sk_{\otsig}, \vk_{\otsig}) = \otsigscheme.\kgen(\secparam) \label{zeth-protocol:otsig-generation} \\
                & \auxinputs.\hsig = \crhhsig{\indexedset{\auxinputs.\jsins{i}.\nf{}}{i \in [\jsin]}, \vk_{\otsig}}
            \end{align}
        \item $\inp{\mix}.\primInp \gets \priminputs$
    \end{enumerate}
    \begin{notebox}
        If one of the attributes of $\priminputs$ and $\auxinputs$ is not correctly generated, then the proof of computational integrity generated in the next step will be rejected on $\mixer$, and the state of $\mixer$ will not be modified.
    \end{notebox}
\item Generate a zk-SNARK proof \zkp~to prove, in zero-knowledge, that the relation $\RELCIRC$ (\cref{zeth-protocol:statement}) holds on the primary and auxiliary inputs, using the desired zk-SNARK scheme $\zksnark$ (see~\cref{instantiation:zksnark}):
    \begin{enumerate}
        \item $\zkp \gets \zksnark.\prover(\pparams_{\zksnark}, \priminputs, \auxinputs)$
        \item $\inp{\mix}.\zkproof \gets \zkp$
    \end{enumerate}

\item Encrypt all the $\auxinputs.\znotes{}$ using the recipient's \emph{payment address}, using the encryption scheme $\encscheme$ (see~\cref{instantiation:enc}).
    \begin{enumerate}
        \item For all $j \in [\jsout]$, do:
        \begin{align*}
            & \ct_j \gets \encscheme.\enc(\auxinputs.\znotes{j}, \zparty{U}.\keystore[\varstyle{recipient}_j].\pubaddr.\pkenc)
        \end{align*}
        \item $\inp{\mix}.\ciphers \gets \indexedset{\ct_j}{j \in [\jsout]}$
    \end{enumerate}
\item Generate a signature $\otsSigma$ on the inputs of the \mix~function, in order to prevent any malleability attacks~(c.f.~\cref{appendix:trnm}), using the desired signature scheme $\otsigscheme$ (see~\cref{instantiation:otsig}):
    \begin{enumerate}
        \item\label{zeth-protocol:mix-inp:create-otsig} Using the one-time signature keypair generated in~\cref{zeth-protocol:otsig-generation}, do:
            \begin{align*}
                & \datatobesigned = \eparty{S}.\addr \concat \inp{\mix}.\primInp \concat \inp{\mix}.\zkp \concat \inp{\mix}.\ciphers \\
                & \otsSigma = \otsigscheme.\sig(\sk_{\otsig}, \crhots{\datatobesigned})
            \end{align*}
        \item $\inp{\mix}.\otssig \gets \otsSigma$
        \item $\inp{\mix}.\otsvk \gets \vk_{\otsig}$
    \end{enumerate}
    Here, $\eparty{S}.\addr$ represents the address of the $\ethereum{}$ user $\eparty{S}$ who must sign the transaction (see~\cref{zeth-protocol:create-tx}). In general, this is likely to be owned by the holder $\zparty{U}$ of the $\zeth{}$ notes to be spent, but this is not a requirement.
\end{enumerate}

\begin{remark}\label{zeth-protocol:mix-inp:otsig-for-dispatch-call}
  \cref{zeth-protocol:process-tx:dispatch-call} describes a situation in which the proof data $\inp{\mix}.\zkp$ is not available (having been verified by some external mechanism). In such cases, $\datatobesigned$ in \cref{zeth-protocol:mix-inp:create-otsig} \MAY{} be replaced with:
  \[
  \datatobesigned = \eparty{S}.\addr \concat \inp{\mix}.\primInp \concat \inp{\mix}.\ciphers
  \]
  This modification, mentioned here for completeness, \MUSTNOT{} be used except as described in \cref{zeth-protocol:process-tx:dispatch-call}.
\end{remark}


\subsection{Jets}
\label{sec:jet}

Jets are another important features for many physics analyses at the LHC, and especially the key signatures for vector boson fusion/scattering (VBF/VBS) processes.
In ATLAS detector, jets are reconstructed as groups of topologically associated energy deposits in the calorimeters,
tracks associated with charged particles measured in the inner tacking detector, or simulated particles.
This section introduces the jet reconstruction, jet energy scale (JES) calibration and the b-jet tagging techniques.

\textbf{Jet reconstruction}

Jets are reconstructed using anti-$k_{t}$ algorithm~\cite{Cacciari_2008} within various radius parameter $R$,
and usually $R = 0.4$, namely small-$R$ jets, are used in most cases.
The \textsc{FastJet} software package\cite{Cacciari2012} is utilized for jet finding and reconstruction.
A collection of four-momentum vectors are used as inputs at each combination step in jet clustering,
the total four-momentum is therefore computed as the sum of four-vector of all its constituents.
There are three types of jets in ATLAS:
\begin{itemize}
	\item \textit{Truth jets:} use stable simulated particles as the inputs to jet algorithm.
	\item \textit{Track jets:} use charged tracks measured from inner detector as inputs to jet algorithm.
	\item \textit{Calorimeter jets:} make use of the energy deposits in calorimeters as inputs to jet algorithm.
\end{itemize}
Figure~\ref{fig:jet_reco_overview} shows the schematic of ATLAS jet reconstruction.
\begin{figure}[!htb]
  \centering
  \includegraphics[width=1.0\textwidth]{figures/Simulation/threetypes_jet_reco.png}
  \caption{A overview schematic of ATLAS jet reconstruction~\cite{Aad:2014bia}.}
  \label{fig:jet_reco_overview}
\end{figure}

The \textit{truth jets} are reconstructed using anti-$k_{t}$ algorithm with $R = 0.4$ by using final-state, stable particles from MC simulation as inputs.
It requires the candidate particles with lifetime $c_{\tau}$ > 10 mm and excludes the particles from pile-up.
Truth jets with $p_{T} > 7 GeV$ and $|\eta| < 4.5$ are then used for jets calibration described later.

The \textit{track jets} are reconstructed from charged particles within the full acceptance of inner detector ($|\eta| < 2.5$).
The track reconstruction has been introduced in section~\ref{sec:track}.
Reconstructed jets with $p_{T} > 500 MeV$ and associated with primary vertex are then selected.
Tracks are assigned to jets using ghost association\cite{CACCIARI2008119}, a procedure that treats selected tracks as four-vectors of infinitesimal magnitude during the jet reconstruction and assigns them to the jet which they are clustered with.
In addition, muon track segments are used as a compensation for those uncaptured jet energy carried by energetic particles passing through the calorimeters without being completely absorbed.
Similar to the ID track, muon segments are assigned to jets using the method of ghost association mentioned above as well.

The \textit{calorimeter jets} are reconstructed using a set of three-dimensional, positive-energy topological clusters (topo-clusters) made of calorimeter cell energies as input to the anti-$k_{t}$ algorithm\cite{Aaboud:2017jcu}.
Topo-clusters are built from nearby calorimeter cells that contains a significant energy above a noise threshold,
which is estimated from measurements of calorimeter electronic noise and simulated pile-up noise.
Those calorimeter cell energies are measured at electromagnetic energy scale (EM scale) corresponding to the energy deposited by electromagnetically interacting particles.
And jets passing a \pt threshold of 7 GeV are reconstructed with the anti-$k_{t}$ algorithm.

\textbf{Jet energy scale calibration}

Figure~\ref{fig:jet_cali} elaborates an overview of ATLAS jet calibration scheme for EM-scale calorimeter jets.
In this procedure, the jet energies are scaled to truth jets, which is reconstructed at the particle-level.
Each step of the calibration corrects the full four-momentum unless otherwise stated, scaling the jet \pt, energy, and mass.
\begin{figure}[!htb]
  \centering
  \includegraphics[width=1.0\textwidth]{figures/Simulation/jet_calibration.png}
  \caption{A overview schematic of ATLAS jet calibration\cite{Aaboud:2017jcu}.}
  \label{fig:jet_cali}
\end{figure}

First of all, the origin correction recompute the four-momentum of jets to point them to the hard-scatter primary vertex instead of the centre of detector, and in the meantime keep the jet energy unchanged.
This correction improves the $\eta$ resolution of jets by roughly 25\% at a jet $p_{T}$ of 20~\gev~ and > 5 times improvement for jet with $p_{T}$ above 200~\gev,
as measured from the difference between reconstructed jets and truth jets in MC simulation.
Secondly, the pile-up correction is adopted to remove the excess energy due to in-time and out-of-time pile-up,
which consists of two processes: an area-based $p_{T}$ density subtraction applied on the top of each event; and a residual correction derived from the simulation.
Thirdly, the absolute JES calibration corrects the jet four-momentum to the particle-level energy scale, using truth jets in di-jet MC events.
Furthermore, the step of global sequential calibration uses calorimeter, track and MS-based variables to reduce the flavor dependence and energy leakage effects.
Finally, the residual in situ calibration is utilized to correct jets in data by using well-measured objects such as photons, Z bosons and calibrated jets.

\textbf{B-jet tagging}

Tagging of b-jets plays a important role in many physics analyses involving b- or t- quark.
In the meantime, lots of analyses need to apply b-jet veto to suppress \ttbar process.
There are three major types of algorithms that have been developed to distinguish b-quark jets from light-quark (u,d,s) jets~\cite{ATL-PHYS-PUB-2016-012}:
\begin{itemize}
	\item \textbf{Impact parameter based algorithms (IP2D and IP3D):} b-hadrons usually have long lifetime ($\sim$1.5 ps, $c_{\tau}\sim450~\mu$m), which leads to large impact parameter for tracks produced from b-hadron decay. The impact parameter taggers are developed based on these variables. The IP2D tagger makes use of the transverse impact parameter significance $d_{0}/\sigma(d_{0})$ as discriminant, while IP3D tagger uses two-dimensional discriminant of both transverse and longitudinal impact parameter significances: $d_{0}/\sigma(d_{0})$ and $z_{0}sin\theta/\sigma(z_{0})$.
	\item \textbf{Secondary vertex finding algorithm (SV1)} makes use of the secondary vertex formed by decay products of b-hadron within the jet. All track pairs within a jet are tested for a two-track vertex hypothesis, and removed if they are likely to originate from a long-live particle decay (eg. $K_{s}$ or $\Lambda$), hadronic interactions or photon conversions. After that, a new vertex is fitted with all tracks from remaining two-track vertices, and the outliers are removed from this set of tracks.
	\item \textbf{Decay chain multi-vertex algorithm (JetFitter)}\cite{Piacquadio_2008} exploits the topological structure of weak b- and c- hadron decays inside the jet and tries to reconstruct the full b-hadron decay chain. A Kalman filter is adopted to find a common line between primary vertex and b-/c- vertices, as well as their position in this line, which gives a approximated flight path for the b-hadron. In this approach, the b- and c-hadron vertices, whenever resolution allows, can be resolved, even when there is only a single track associated to them.
\end{itemize}
The final discrimination commonly used in many physics analyses is called \textbf{Multivariate Algorithm (MV2)}, which is based on Boosted Decision Tree (BDT) implemented in the TMVA package\cite{Speckmayer_2010} by combining the outputs from underlying taggers mentioned above.
The MV2 was trained using jets in $t\bar{t}$ sample, where the b-jets are treated as signal while the c- and light-flavor jets are treated as backgrounds.
There are three kinds of MV2 depending on the fraction of c-jets in background for training: \textit{MV2c00}, \textit{MV2c10} and \textit{MV2c20}.
Figure~\ref{fig:jet_mv2} presents the output score of MV2c10 for different flavor jets.
\begin{figure}[!htb]
  \centering
  \includegraphics[width=0.5\textwidth]{figures/Simulation/jet_mv2c10.png}
  \caption{MV2c10 BDT output for b- (solid blue), c- (dashed green) and light-flavour (dotted red) jets in $t\bar{t}$ events\cite{ATL-PHYS-PUB-2016-012}.}
  \label{fig:jet_mv2}
\end{figure}