\chapter{Verification Dataset}
\label{chapter:vds}

\section{Overview}

\begin{table}
\caption{ \smr\ VDS content for the various frequency modes of \smr\..}
\label{table:comp}
\scalebox{0.9}{%
\footnotesize
\begin{tabular}{|l|l|l|l|l|}
\hline
\textbf{\smr}           & \textbf{\smr}            & \textbf{Instrument} &  \textbf{Species}                         & \textbf{Number of}\\
\textbf{Frequency mode} & \textbf{Frequency range [GHz]} &               &                                           & \textbf{measurements}\\
\hline
                     01 &  501.180--501.580,       & SMILES              & \chem{O_3}, \chem{ClO}                    &   2398, 1384 \\
                        &  501.980--502.380        & MLS                 & \chem{O_3}, \chem{ClO}, \chem{N_{2}O}     &  14726       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{N_{2}O}                 &   7228       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{N_{2}O}                 &   6850       \\
                        &                          & SAGEIII             & \chem{O_3}                                &   3115       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   7587       \\
                        &                          & SMR                 & \chem{O_3}, \chem{ClO}, \chem{N_{2}O}     &  10450, 9824, 10371 \\

\hline
                     02 &  544.102--544.902        & SMILES              & \chem{O_3}, \chem{HNO_3}                  &   2367, 1353  \\
                        &                          & MLS                 & \chem{O_3}, \chem{HNO_3}, T               &  14275        \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{HNO_3}                  &   7176        \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{HNO_3}                  &   6734        \\
                        &                          & SAGEIII             & \chem{O_3}                                &   3063        \\
                        &                          & OSIRIS              & \chem{O_3}                                &   7442        \\
                        &                          & SMR                 & \chem{O_3}, \chem{HNO_3}, T               &  11168, 11137, 11177 \\

\hline
                     08 &  488.950--489.350,       & SMILES              & \chem{O_3}                                &    618       \\
                        &  488.350--488.750        & MLS                 & \chem{O_3}, \chem{H_{2}O}                 &  14276       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{H_{2}O}                 &   6249       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{H_{2}O}                 &   5940       \\
                        &                          & SAGEIII             & \chem{O_3}, \chem{H_{2}O}                 &    284       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   2749       \\
                        &                          & SMR                 & \chem{O_3}                                &   8068       \\

\hline
                     13 &  556.598--557.398        & SMILES              & \chem{O_3}                                &    364       \\
                        &                          & MLS                 & \chem{O_3}, \chem{H_{2}O}, T              &  12516       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{H_{2}O}                 &   5001       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{H_{2}O}                 &   4845       \\
                        &                          & MIPAS               & \chem{O_3}, \chem{H_{2}O}                 &   5001       \\
                        &                          & SAGEIII             & \chem{O_3}, \chem{H_{2}O}                 &    170       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   1870       \\
                        &                          & SMR                 & \chem{O_3}, \chem{H_{2}O}, T              &   2644       \\

\hline
                     14 &  576.062--576.862        & SMILES              & \chem{O_3}                                &    409       \\
                        &                          & MLS                 & \chem{O_3}, \chem{CO}, T                  &  12758       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{CO}                     &   5005       \\
                        &                          & MIPAS-ESA           & \chem{O_3}                                &   1212       \\
                        &                          & SAGEIII             & \chem{O_3}                                &    170       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   1913       \\
                        &                          & SMR                 & \chem{O_3}, \chem{CO}, T                  &      6       \\

\hline
                     17 &   489.950--490.750       & SMILES              & \chem{O_3}                                &    527       \\
                        &                          & MLS                 & \chem{O_3}, \chem{H_{2}O}                 &  14191       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{H_{2}O}                 &   6126       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{H_{2}O}                 &   5817       \\
                        &                          & SAGEIII             & \chem{O_3}, \chem{H_{2}O}                 &    263       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   2862       \\
                        &                          & SMR                 & \chem{O_3}, \chem{H_{2}O}                 &   7179       \\

\hline
                     19 &   556.550--557.350       & SMILES              & \chem{O_3}                                &    604       \\
                        &                          & MLS                 & \chem{O_3}, \chem{H_{2}O}, T              &  13360       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{H_{2}O}                 &   6127       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{H_{2}O}                 &   5822       \\
                        &                          & SAGEIII             & \chem{O_3}, \chem{H_{2}O}                 &    444       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   2779       \\
                        &                          & SMR                 & \chem{O_3}, \chem{H_{2}O}, T              &   8299       \\

\hline
                     21 &   551.152--551.552,      & SMILES              & \chem{O_3}                                &    583       \\
                        &   551.752--552.152       & MLS                 & \chem{O_3}, \chem{H_{2}O}, T              &  12707       \\
                        &                          & MIPAS-KIT           & \chem{O_3}, \chem{H_{2}O}, \chem{NO}      &   4819       \\
                        &                          & MIPAS-ESA           & \chem{O_3}, \chem{H_{2}O}                 &   4673       \\
                        &                          & SAGEIII             & \chem{O_3}, \chem{H_{2}O}                 &     80       \\
                        &                          & OSIRIS              & \chem{O_3}                                &   2508       \\
                        &                          & SMR                 & \chem{O_3}, \chem{H_{2}O}, \chem{NO}, T   &   8201       \\
\hline
                     22 &   576.254 - 576.654,     & MLS                 & \chem{CO}                                 &   7691       \\
                        &   577.069 - 577.469      & MIPAS-KIT           & \chem{CO}                                 &   2401       \\
\hline
                     24 &   576.062 - 576.862      & MLS                 & \chem{CO}                                 &    979       \\
                        &                          & MIPAS-KIT           & \chem{CO}                                 &    340       \\
\hline
\end{tabular}}
\end{table}

The verfication dataset (VDS) consists of a represenative subset of
the \smr\ complete dataset, and correlative datasets.
In short, the VDS is a dataset of \smr\ measurements
and collocated measurements from a number of correlative
limb-sounding instruments, i.e. Aura/MLS, ENVISAT/MIPAS,
ISS/JEM/SMILES, Meteor3M/SAGEIII, and Odin/OSIRIS.
Table~\ref{table:comp} gives an overview of the correlative
datasets included in the VDS, and these datasets
are described in more detail in Sect.~\ref{sec:corrmeas}.
Sect.~\ref{sec:vdsselection} describes the collocation criteria
applied and how the VDS was selected.

\section{Correlative limb measurements}
\label{sec:corrmeas}
\subsection{Aura/MLS}

%http://www.atmos-chem-phys.net/9/2387/2009/acp-9-2387-2009.pdf
\def \ESADataURL{https://earth.esa.int/web/sppa/mission-performance/esa-missions/envisat/mipas/products-and-algorithms/products-information}

\begin{table}
\caption{ Characteristics of Aura/MLS, ENVISAT/MIPAS, ISS/JEM/SMILES, Meteor3M/SAGEIII, and Odin/OSIRIS Level2 data products included in the VDS.}
\label{table:complevel2}
\scalebox{0.8}{%
\begin{tabular}{|l|l|l|l|l|l|}
  \hline
  \multicolumn{6}{|c|}{\textbf{Aura/MLS}}\\
  %\multicolumn{6}{|c|}{\textbf{}}\\
  \hline
  \textbf{Product}      & \textbf{Vertical}          & \textbf{Vertical}        & \textbf{Precision} &  \textbf{Version} & \textbf{Reference}   \\
                        & \textbf{coverage}          & \textbf{resolution}      &                    &                   &                      \\
  \hline
  \chem{O_{3}}          & 261--0.02\,hPa             &  3.5--5.5\,km            & 0.03--1.2\,ppmv    &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{ClO}            & 147--1.0\,hPa              &  3--4.5\,km              & 0.1--0.3\,ppbv     &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{N_{2}O}         & 68--0.46\,hPa              &  5.4--11\,km             & \(\sim\)15\,ppbv   &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{HNO_{3}}        & 215--1.5\,hPa              &  4--4.5\,km              & 1--0.5\,ppbv       &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{H_{2}O}         & 316--0.002\,hPa            &  1.3--10\,km             & 4--152\,\(\%\)     &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{CO}             & 215--0.0046\,hPa           &  3.8--6.2\,km            & 9\,ppbv--11\,ppmv  &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \chem{T}             & 261--0.001 \,hPa            &  4.2--13\,km             & 0.7--3.6\,K        &   v04-2x          & \citep{livesey:MLS} \\
  \hline
  \multicolumn{6}{|c|}{\textbf{ENVISAT/MIPAS}}\\
  %\multicolumn{6}{|c|}{\textbf{}}\\
  \hline
  \textbf{Product}      & \textbf{Vertical}          & \textbf{Vertical}        & \textbf{Precision} &  \textbf{Version}        & \textbf{Reference}   \\
                        & \textbf{coverage}          & \textbf{resolution}      &                    &                          &                      \\
  \hline
  \chem{O_{3}}          & \(\sim\)10--60\,km         &  3.5 -- 8\,km            & 0.1--0.2\,ppmv     &  KIT: V5H-O3-21          &  \citep{steck:biasd:07}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        & \(\sim\)10--70\,km         &  2 -- 6\,km              & 0.03--0.09\,ppmv   &  KIT: V5R-O3-22(4/5)     &  \citep{laeng:valid:14}\\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
                        &                            &                          &                    &  ESA: ML2PP version 7.03 &  \href{\ESADataURL}{ESA documentation}\\
  \hline
  \chem{N_{2}O}         & \(\sim\)15--60\,km         &  3--6\,km                & 10--20\,\(\%\)     &  KIT: V5H-N2O-21         &  \citep{plieninger:metha:15}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        & \(\sim\)15--60\,km         &  2.5--6\,km              & 10--20\,\(\%\)     &  KIT: V5R-N2O-22(4/5)    &  \citep{plieninger:metha:15}\\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
                        &                            &                          &                    &  ESA: ML2PP version 7.03 &  \href{\ESADataURL}{ESA documentation}\\
  \hline
  \chem{HNO_{3}}        & \(\sim\)20--50\,km         &  3--8\,km                & 2--6\,\(\%\)       &  KIT: V5H-HNO3-22        &  \citep{wang:valid:07}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        &                            &                          &                    &  KIT: V5R-HNO3-22(4/5)   &  \\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
                        &                            &                          &                    &  ESA: ML2PP version 7.03 &  \href{\ESADataURL}{ESA documentation}\\
  \hline
  \chem{H_{2}O}         & \(\sim\)15--50\,km         &  3.5--4.5\,km            & 5--10\,\(\%\)      &  KIT: V5H-H2O-20         &  \citep{milz:valid:09}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        & \(\sim\)20--50\,km         &  2.3--6.9\,km            & 0.2 -- 0.9 ppmv    &  KIT: V5R-H2O-22(0/1)    &  \citep{stiller:valid:2012}\\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
                        &                            &                          &                    &  ESA: ML2PP version 7.03 &  \href{\ESADataURL}{ESA documentation}\\
  \hline
  \chem{CO}             &  \(\sim\)10--70\,km        &  6--12\,km               & 10--70\,\(\%\)     &  KIT: V5H-CO-20          &  \citep{funke:analy:07}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        &                            &                          &                    &  KIT: V5R-H2O-22(0/1)    &  \\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
  \hline
  \chem{NO}             &  \(\sim\)20--60\,km\       &  3.5--12\,km             & 0.2--0.3\,ppbv     &  KIT: V5H-NO-20          &  \citep{funke:retri:05}\\
                        &                            &                          &                    &  2002-07 -- 2004-03      &  \\
                        &                            &                          &                    &  KIT: V5R-NO-22(0/1)     &  \\
                        &                            &                          &                    &  2005-01 -- 2012-04      &  \\
  \hline
  \multicolumn{6}{|c|}{\textbf{ISS/JEM/SMILES}}\\
  %\multicolumn{6}{|c|}{\textbf{}}\\
  \hline
  \textbf{Product}      & \textbf{Vertical}          & \textbf{Vertical}        & \textbf{Precision} &  \textbf{Version} & \textbf{Reference}  \\
                        & \textbf{coverage}          & \textbf{resolution}      &                    &                   &                     \\
  \hline
  \chem{O_{3}}          & 16--73\,km                 &  2.3--3\,km              & 2--5\,\(\%\)       &  JAXA v2.4 (008-11-0502) & \citep{imai:valid:13} \\
  \hline
  \chem{ClO}            & 20--60\,km                 &  3.5--10\,km             & 20--50\,\(\%\)     &  JAXA v2.4 (008-11-0502) & \citep{jaxa:2013} \\
  \hline
  \chem{HNO_{3}}        & 18--40\,km                 &  \(\sim\)10\,km          & 20--50\,\(\%\)     &  JAXA v2.4 (008-11-0502)  & \citep{jaxa:2013} \\
  \hline
  \multicolumn{6}{|c|}{\textbf{Meteor3M/SAGEIII}}\\
  %\multicolumn{6}{|c|}{\textbf{}}\\
  \hline
  \textbf{Product}      & \textbf{Vertical}          & \textbf{Vertical}        & \textbf{Precision} &  \textbf{Version} & \textbf{Reference}  \\
                        & \textbf{coverage}          & \textbf{resolution}      &                    &                   &                     \\
  \hline
  \chem{O_{3}}          & 6--85\,km                  &  \(\sim\)1\,km           & 10\,\(\%\)         &  NASA v04            & \citep{SAGEIII_DPUG} \\
  \hline
  \chem{H_{2}O}         & 0--50\,km                  &  \(\sim\)1\,km           & 5--15\,\(\%\)      &  NASA v04            & \citep{SAGEIII_DPUG} \\
  \hline
  \multicolumn{6}{|c|}{\textbf{Odin/OSIRIS}}\\
  %\multicolumn{6}{|c|}{\textbf{}}\\
  \hline
  \textbf{Product}      & \textbf{Vertical}          & \textbf{Vertical}        & \textbf{Precision} &  \textbf{Version} & \textbf{Reference}  \\
                        & \textbf{coverage}          & \textbf{resolution}      &                    &                   &                     \\
  \hline
  \chem{O_{3}}          & 10--60\,km                  &  \(\sim\)2-3\,km        & 3--4\,\(\%\)         &  SaskMART v5.07   & \citep{adams:assess:14} \\
  \hline
\end{tabular}}
\end{table}

The Aura satellite was launched on 2004-07-15 into a
sun-synchronous orbit at 705\,km altitude, with an ascending
equator crossing local time of 13:45. Its
orbit is near-polar with a 98\degree inclination,
and the daily Microwave Limb Sounder (MLS) measurements cover
the latitudinal range from about 82\degree\,S to 82\degree\,N.
MLS measures temperature and trace gas profiles
using thermal emission data from the
upper troposphere to the mesosphere. MLS performs each
limb scan and related calibration in 25\,s, and
obtains \(\sim\) 3500 vertical profiles a day
\citep{waters:eos:06}. The MLS data
processing algorithms are based on the optimal estimation
method (OEM), as explained by \citet{livesey:MLS}. MLS uses
spectral bands centered near 118, 190, 240, 640\,GHz,
and 2.3\,THz.

The Aura/MLS Level2 products, and characteristics, included in the
VDS are found in Table~\ref{table:complevel2}.

\subsection{ENVISAT/MIPAS}

The Michelson Interferometer for Passive Atmospheric
Sounding (MIPAS) is a mid-infrared emission spectrometer
mounted on the European ENVIronmantal SATellite (ENVISAT),
which was launched in 2002-03-01 \citep{fischer2008},
and was in operation until 2012-04-08.
ENVISAT has a sun-synchronous orbit at an altitude of 800\,km
and with a 98.55\degree\ inclination and descending equator
crossing local time of 10:00.

The failure of a MIPAS mirror slide in 2004 led to the
division of the 10 years of MIPAS
data into two operational periods: 2002--2004 when the
instrument measured with high spectral resolution
and 2005--2012 when the instrument measured with lower
spectral but better vertical resolution.

MIPAS observed five mid-infrared spectral bands within the
frequency range of 685 to 2410\,cm\(^{-1}\) (14.6 to 4.15\,\(\mu\)m),
with a resolution of 0.0625\,cm\(^{-1}\).
Until 2004-03-26 MIPAS scanned 17 tangent altitudes from
6 to 68\,km with 3--8\,km resolution.
From January 2005 MIPAS started operating in a new mode
at a reduced spectral resolution but at a finer altitude
grid. The latitudinal coverage was from 87\degree\,S to 89\degree\,N.
In the latter mode, MIPAS had about 95 scans per orbit, and about
1360 vertical profiles were recorded in a day.

Level2 data from MIPAS, generated by ESA
(MIPAS Level 2 ML2PP version 7.03)
and by the Institut f\"ur Meteorologie und Klimatforschung
(IMK) at Karlsruhe Institute of Technology (KIT) (V5), are
included in the VDS.
Included Species from the ESA MIPAS dataset are
\chem{O_{3}}, \chem{H_{2}O}, \chem{HNO_{3}}, and \chem{N_{2}O}.
These species plus \chem{NO} and \chem{CO} are also included from the KIT
dataset. The ENVISAT/MIPAS Level2 products and characteristics included in the
VDS are described in more details in Table~\ref{table:complevel2}.

\subsection{ISS/JEM/SMILES}

The Superconducting Submillimeter-Wave Limb-Emission Sounder (SMILES),
attached to the Exposed Facility of the Japanese Experiment Module (JEM),
on the International Space Station (ISS), is a joint project of the
National Institute of Information and Communications Technology (NICT) and
the Japan Aerospace Exploration Agency (JAXA).
The ISS has a non-sun-synchronous circular orbit at
altitudes of 340\,-\,360\,km with an inclination angle of 51.6\degree
to the equator.

SMILES observed a number of trace gases, e.g.: \chem{O_{3}}, \chem{H^{35}Cl},
\chem{H^{37}Cl}, \chem{ClO}, \chem{HOCl}, \chem{HO_{2}}, \chem{BrO}, and \chem{HNO_{3}},
from the upper troposphere up to the lower thermosphere,
with a nominal latitudinal coverage
from 38\degree\,S to 65\degree\,N, between 2009-10-12 and 2010-04-21.
Trace gas profiles are derived from observed thermal emission in two frequency
bands around 625\,GHz and one around 650\,GHz;
624.32--625.52\,GHz (Band-A), 625.12--626.32\,GHz (Band-B),
and 649.12--650.32\,GHz (Band-C), with a frequency resolution
and channel separation of about 1\,MHz and 0.8\,MHz,
respectively.
During each measurement, two out of the three SMILES frequency
bands were observed simultaneously, by two acousto-optical spectrometers,
and with a receiver noise temperature of 310--350\,K.

SMILES performed 1630 scans per day, where the limb was scanned
from about -20\,km to 120\,km (geometric altitude),
with a sampling interval of about 2\,km, and with an angle of
about 45\degree\ from the orbital plane. The size of the antenna beam,
at the tangent point, was about 3 and 6\,km in the vertical and
horizontal direction, respectively.

An interesting feature of SMILES observation is related to the fact
that ISS has a non-sunsynchronous orbit, which gives that SMILES
observations cover different local times and thereby provides insight
of the diurnal variation of atmospheric short-lived species
(e.g \chem{ClO}, \chem{BrO}, \chem{HO_2}, and \chem{HOCl}).
A two month period is required to accumulate measurements covering
24\,h in local time for a given "position". However, such a
dataset can also contain variation due to dynamical, seasonal, and
latitudinal effects.
A second characteristic of SMILES observation is that
measured spectra and retrieved profiles have high precision due
to its 4\,K mechanically cooled superconducting receiver system.

The SMILES Level2 products and characteristics included in the
VDS are found in Table~\ref{table:complevel2}.

\subsection{Meteor3M/SAGE III}

SAGE III on Meteor-3M (SAGEIII) was a third generation, satellite-borne
instrument and an element in NASA's Earth Observing System (EOS) \citep{SAGEIII_DPUG}.
The instrument was launched on the Russian Meteor-3M spacecraft on 2001-12-10
into into a Sun-synchronous orbit at an altitude of 1020 km and with an
approximate 9:00 a.m. equatorial crossing time.  The instrument was active from
2002-02-27 to 2005-11-12.
%\footnote{all text in this section adapted from
%\cite{SAGEIII_DPUG}}

The SAGEIII instrument measures the attenuation of solar radiation resulting
from the scattering and absorption by atmospheric constituents in the Earth's
atmosphere as the spacecraft observes a sunrise or sunset event.  Due to the
orbital parameters, solar occultation measurement opportunities are limited to
mostly high latitudes in the Northern Hemisphere (between 50\degree~and
80\degree~N) and mid-latitudes in the Southern Hemisphere (between
30\degree~and 50\degree~S).  Level2 products from these measurements include
profiles of ozone~(\chem{O_3}), water vapour~(\chem{H_2O}) and nitrogen
dioxide~(\chem{NO_2}).  Of these \chem{O_3} and \chem{H_2O} have been included
in the VDS.  The ozone profiles are are reported as reliable within 10\% for
the altitude range 6--85\,km, whereas the water vapour profiles are reported
reliable to have an uncertainty of less than 5\% for altitudes of 0--33\,km and
in the interval 5--15\% for altitudes 33--50\,km. The SAGEIII Level2
products and characteristics included in the VDS are found in
Table~\ref{table:complevel2}.

Similar measurements were made during the lunar moonrise and moonset.  These
measurements were made only during the second and third quarter phases of
the Moon and when the atmosphere along the line-of-sight was not directly
illuminated by the Sun.  Level2 products from these measurements include
profiles of ozone~(\chem{O_3}), nitrogen dioxide~(\chem{NO_2}), nitrogen
trioxide~(\chem{NO_3}) and chlorine dioxide~(\chem{OClO}).  Due to poor data
coverage, none of these products have been included in the VDS, but are
listed here for completeness.

\subsection{Odin/OSIRIS}

Odin has two optically co-aligned instruments: the SMR
and the Optical Spectrograph and InfraRed Imager System (OSIRIS)
\citep{llewellyn:osiris:04}. OSIRIS
measures limb-scattered sunlight within the wavelength range of 280\,-\,
800\,nm with a spectral resolution of approximately 1\,nm,
OSIRIS is capable of measuring vertical profiles of stratospheric
\chem{O_{3}}, \chem{NO_{2}}, and aerosols.
Ozone measurements are only taken in the
summer hemisphere, with coverage in both hemispheres in
the spring and autumn.
Nominally OSIRIS generates approximately 30
\chem{O_3} profiles per orbit over the sunlit hemisphere.
Characteristics of OSIRIS Level2 \chem{O_{3}} product
are found in Table~\ref{table:complevel2}.

\section{Verification Dataset: collocation criteria and data selection}
\label{sec:vdsselection}

\begin{figure}[t]
\centering
\includegraphics[width=17cm]{test_collocation_fm1.png}
\caption{Positions of collocations for the various limb instruments
and \smr\ frequency mode 1 scans, included in the VDS. The upper two panels show
the latitude of the collocations as function of time. The bottom panels
show the geograpical coverage of the collocations between \smr\
and the other instruments. Note that the figure does not cover the
most recent year, but the VDS contains MLS and OSIRIS data until 2019.}
\label{fig:vdsfm1}
\end{figure}

The VDS should ideally include \smr\ measurements and correlative collocated
data from the complete mission and for all geopraphical regions.
In this section we describe how the VDS was constructed
in order to fulfill this criteria.

Two measurements are considered to be collocated if they
are close in time and space. The applied collocations
criteria are adjusted for the various sensors, in order
to result in a useful comparison dataset, as described below:

\smr\ and SMILES measurements are considered to be collocated if the
differences in distance and observation time between the two profiles are
less than 300\,km and 1\,h, respectively.
All measurements that fulfill this criteria are included
in the VDS. This subset of the VDS
covers 60\degree\,N--40\degree\,S for the SMILES
active observation period, as can be seen in Fig.~\ref{fig:vdsfm1}.

\smr\ and SAGEIII measurements are considered to be collocated if the
difference in distance and observation time between the two profiles are
less than 300\,km and and 3\,h, respectively.
This subset of the VDS covers approximately 80\degree\,N--50\degree\,N and
40\degree\,S--60\degree\,S for the SAGEIII active observation period, as can
be seen in Fig.~\ref{fig:vdsfm1}

A problem with a ``strict'' time difference criteria
between \smr\ and both ENVISAT/MIPAS and Aura/MLS
is that collocations are only found for high latitudes
 (around 80\degree\,N and around 80\degree\,S),
due to the fact each of these platform follows a sun-synchronous orbit
with quite different ascending equator crossing local times
(18:00 hour for \smr\, 10:00 hour for ENVISAT/MIPAS,
 13:45 hour for Aura/MLS).
Thus, for low latitudes the time difference criteria
is relaxed to 6\,hour for ENVISAT/MIPAS and Aura/MLS.
This gives effectively that collocated ENVISAT/MIPAS and Aura/MLS
measurements can be found for almost all \smr\ measurements, and a strategy
to reduce the size of the VDS must be applied.

The set of collocated measurements for ENVISAT/MIPAS and Aura/MLS is reduced
in size in the following way:
For each \smr\ observation mode and month, five collocated scans each
for ENVISAT/MIPAS and Aura/MLS
are selected, within each 10\degree\ latitude bin
(85\degree\,N--75\degree\,N, 75\degree\,N--65\degree\,N, \ldots, 75\degree\,S--85\degree\,S),
to be included in the VDS. For the two outer latitude bins the
time difference criteria is 1\,h, while for the other bins it is set to 6\,h.
Figure~\ref{fig:vdsfm1} shows a graphical view of the position in
time and space for the measurements included in the VDS for
frequency mode 1 of \smr.

The VDS contains both KIT and ESA ENVISAT/MIPAS data. The KIT dataset was first
added to the VDS as described above, and available matching data from the ESA dataset was
then added for all scans where KIT data were already added. This explains
why the VDS contains somewhat more KIT than ESA data.

The \smr\ and Odin/OSIRIS instruments are optically co-alignend and thus
the measurements can always be seen as highly collocated.
The selection of which OSIRIS measurements to include in the
VDS is based on which measurements that are included
for MIPAS, MLS, SAGEIII, and SMILES, in order to not
construct a too large VDS.  That is,
OSIRIS measurements are included in the VDS for all selected
collocations between \smr\ and the other sensors, given
that OSIRIS measurements are available.

Data from the previous \smr\ processing version are included in the VDS.
This data were added for all scans already included in the VDS,
given that previous \smr\ data were available.

The total number of limb measurement collocations included in the VDS, for the various
\smr\ frequency modes, is displayed in Table~\ref{table:comp}. This gives that a few
percent of the total \smr\ dataset is included in the VDS. Included measurements cover
approximately all geographical positions and the complete observation period of \smr.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%                                                                 %
%   MINUIT User Guide -- LaTeX Source                             %
%                                                                 %
%   Chapter 5                                                     %
%                                                                 %
%   The following external EPS files are referenced:              %
%                                                                 %
%   Editor: Michel Goossens / CN-AS                               %
%   Last Mod.: 17 Mar. 1992 10.20 mg                              %
%                                                                 %
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

\chapter{How to get the right answer from Minuit.}

The goal of Minuit --- to be able to minimize and analyze parameter
errors for all possible user functions with any number of variable
parameters --- is of course impossible to realise, even in principle,
in a finite amount of time. In practice, some assumptions must be made
about the behaviour of the function in order to avoid evaluating it
at all possible points.
In this chapter we give some hints on how the user can help Minuit
to make the right assumptions.

\section{Which Minimizer to Use.}

One of the historically interesting advantages of Minuit is that it
was probably the first minimization program to offer the user a choice
of several minimization algorithms.
This could be taken as a reflection of the fact that none of the
algorithms known at that time were good enough to be universal, so
users were encouraged to find the one that worked best for them.
Since then, algorithms have improved considerably, but Minuit still
offers several, mostly so that old users will not feel cheated, but also to
help the occasional user who does manage to defeat the best algorithms.
Minuit currently offers five commands which can be used to find a
smaller function value, in addition to a few others,
like \Cind[MINOs]{MINOS} and \Cind[IMProve]{IMPROVE},
which will retain a smaller function value if they stumble on one
unexpectedly (or, in the case of \Cind[IMProve]{IMPROVE}, hopefully).
The commands which can be used to minimize are:

\subsection{MIGRAD}

This is the best minimizer for nearly all functions. It is a
variable-metric method with inexact line search, a stable
metric updating scheme, and checks for positive-definiteness.
It will run faster if you \Cind[SET STRategy]{SET STRATEGY 0}
and will be more reliable if you \Cind[SET STRategy]{SET STRATEGY 2}
(although the latter option may not help much).
Its main weakness is that it depends heavily on knowledge of the
first derivatives, and fails miserably if they are very inaccurate.
If first derivatives are a problem, they can be
calculated analytically inside \Rind{FCN} (see elsewhere in this writeup) or
if this is not feasible, the user can try to improve the accuracy of
Minuit's numerical approximation by adjusting values using the
\Cind[SET EPSmachine]{SET EPS} and/or \Cind[SET STRategy]{SET STRATEGY} commands
(see Floating Point Precision and \Cind[SET STRategy]{SET STRATEGY}).

\subsection{MINIMIZE}

This is equivalent to \Cind[MIGrad]{MIGRAD},
except that if \Cind[MIGrad]{MIGRAD} fails,
it reverts to \Cind[SIMplex]{SIMPLEX} and then calls
\Cind[MIGrad]{MIGRAD} again.
This is what the old \Cind[MIGrad]{MIGRAD} command used to do,
but it was removed from
the \Cind[MIGrad]{MIGRAD} command so that users would have a choice,
and because it is
seldom of any use to call \Cind[SIMplex]{SIMPLEX} when
\Cind[MIGrad]{MIGRAD} has failed (there are of course exceptions).

\subsection{SCAN}

This is not intended to minimize, and just scans the function, one
parameter at a time.
It does however retain the best value after each scan,
so it does some sort of highly primitive minimization.

\subsection{SEEK}

We have retained this Monte Carlo search mainly for sentimental
reasons, even though the limited experience with it is
less than spectacular.
\index{metropilis algorithm}
\index{Monte Carlo}
The method now incorporates a Metropolis algorithm which always
moves the search region to be centred at a new minimum,
and has probability
$ e ^{(-F/F_{\mathrm{min}})}$
of moving the search region to a higher point with function value $F$.
This gives it the theoretical ability to jump
through function barriers like a multidimensional
quantum mechanical tunneler in search of isolated minima, but it is
widely believed by at least half of the authors of Minuit that this
is unlikely to work in practice (counterexamples are welcome)
since it seems to depend critically on choosing
the right average step size for the random jumps,
and if you knew that, you wouldn't need Minuit.

\Subsection{4cm}{SIMPLEX}

\index{minimization!multidimensional}
\index{multidimensional minimization}
This genuine multidimensional minimization routine is usually much
slower than \Cind[MIGrad]{MIGRAD}, but it does not use first derivatives,
so it should not be so sensitive to the precision of the \Rind{FCN}
calculations, and is even rather robust with respect to
gross fluctuations in the function value.
However, it gives no reliable information about parameter errors,
no information whatsoever about parameter correlations,
and worst of all cannot be expected to converge accurately
to the minimum in a finite time.
Its estimate of \Lit{EDM} is largely fantasy, so it would not even
know if it did converge.

\Section{4cm}{Floating point Precision}

Minuit figures out at execution time the precision with which it was
compiled, and assumes that \Rind{FCN} provides about the same precision.
That means not just the length of the numbers used and returned
by \Rind{FCN}, but the actual mathematical accuracy of the calculations.
The section on Floating point Precision in Chapter One describes
what to do if this is not the case.

\section{Parameter Limits}

Putting limits (absolute bounds) on the allowed values for
a given parameter, causes Minuit to make a non-linear
transformation of its own internal parameter values to obtain the
(external) parameter values passed to \Rind{FCN}.
To understand the adverse effects of limits, see ``The Transformation
for Parameters with Limits'' in Chapter 1.
Basically, the use of limits should be avoided unless needed to
keep the parameter inside a desired range.

If parameter limits are needed, in spite of the effects described
in Chapter One, then the user should be aware of the following
techniques to alleviate problems caused by limits:

\subsection{Getting the Right Minimum with Limits.}

If \Cind[MIGrad]{MIGRAD} converges normally to a point where no parameter is
near one of its limits, then the existence of limits has
probably not prevented Minuit from finding the right minimum.
On the other hand, if one or more parameters is near its limit
at the minimum, this may be because the true minimum is indeed
at a limit, or it may be because the minimizer has become
``blocked'' at a limit.
This may normally happen only if the parameter
is so close to a limit (internal value at an odd multiple
of $\pm \frac{\Tstm \pi}{\Tstm 2}$ that Minuit prints a warning to this effect
when it prints the parameter values.

The minimizer can become blocked at a limit, because at a limit
the derivative seen by the minimizer
$\partial F / \partial P_{\mathrm{int}}$
is zero no matter what the real derivative
$\partial F / \partial P_{\mathrm{ext}}$ is.

$$
\frac{\partial F}{\partial P_{\mathrm{int}}}                =
\frac{\partial F}{\partial P_{\mathrm{ext}}}
\frac{\partial P_{\mathrm{ext}}}{\partial P_{\mathrm{int}}} =
\frac{\partial F}{\partial P_{\mathrm{ext}}}                = 0
$$

For a stepping method (like \Cind[SIMplex]{SIMPLEX})
this seldom poses any problem,
but a method based on derivatives (\Cind[MIGrad]{MIGRAD}) may become blocked
at such a value.
If this happens, it may be necessary to move the value of the
parameter in question a significant distance from the
limit (with \Cind[SET PARameter]{SET PARam}) and restart the minimization, perhaps
with that parameter fixed temporarily.
We are investigating ways to induce Minuit to extricate itself from
such situations automatically, but it is not so obvious as it seems,
and for the moment must sometimes be done by hand.

\subsection{Getting the right parameter errors with limits.}
\label{sec:right-errors}

In the best case, where the minimum is far from any limits,
Minuit will correctly transform the error matrix, and the
parameter errors it reports should be accurate and very
close to those you would have got without limits.
In other cases (which should be more common, since
otherwise you wouldn't need limits), the very meaning of
parameter errors becomes problematic.  Mathematically, since
the limit is an absolute constraint on the parameter, a parameter
at its limit has no error, at least in one direction.
The error matrix, which can assign only symmetric errors, then
becomes essentially meaningless.
On the other hand, the \Cind[MINOs]{MINOS} analysis is still meaningful,
at least in principle, as long as \Cind[MIGrad]{MIGRAD} (which is called
internally by \Cind[MINOs]{MINOS}) does not get blocked at a limit.
Unfortunately, the user has no control over this aspect of
the \Cind[MINOs]{MINOS} calculation, although it is possible to get enough
printout from the \Cind[MINOs]{MINOS} command to be able to determine whether
the results are reliable or not.

\section{Fixing and Releasing Parameters}

When Minuit needs to be guided to the ``right'' minimum,
often the best way to do this is with the \Cind{FIX}
and \Cind[RELease]{RELEASE} commands.
That is, suppose you have a problem with ten free parameters,
and when you minimize with respect to all at once, Minuit goes to
an unphysical solution characterized by an unphysical or unwanted
value of parameter number four.
One way to avoid this is to \Cind{FIX} parameter four at a ``good'' value
(not necessarily the best, since you presumably don't know that yet),
and minimize with respect to the others.
Then \Cind[RELease]{RELEASE 4} and minimize again.
If the problem admits a ``good'' physical solution, you will
normally find it this way.
If it doesn't work,
you may see what is wrong by the following sequence
(where \Lit{xxx} is the expected physical value for parameter four):
\begin{XMP}
SET PARAM 4 xxx
FIX 4
MIGRAD
RELEASE 4
SCAN 4
\end{XMP}
where the \Cind[SCAn]{SCAN} command gives you a picture of \Rind{FCN} as a
function of parameter four alone,
the others being fixed at their current best values.
If you suspect the difficulty is due to parameter five,
then add the command
\begin{XMP}
CONTOUR  4  5
\end{XMP}
to see a two-dimensional picture.

\section{Interpretation of Parameter Errors}

There are two kinds of problems that can arise:
The {\bf reliability} of Minuit's error estimates, and their
{\bf statistical interpretation}, assuming they are accurate.

\subsection{Statistical Interpretation.}

For discussuion of basic concepts, such as the meaning of the elements
of the error matrix, parabolic versus \Cind[MINOs]{MINOS} errors,
the appropriate value for \Lit{UP}
(see \Cind[SET ERRordef]{SET ERRdef}), and setting of exact
confidence levels, see (in order of increasing complexity and completeness):

\begin{UL}
\item {\em ``Interpretation of the Errors on Parameters'',}
      see Part 3 of this write-up.
\item {\em ``Determining the Statistical Significance of Experimental
      Results''}\cite{bib-MIN81}.
\item {\em ``Statistical Methods in Experimental Physics''}\cite{bib-EADIE}.
\end{UL}

\subsection{The Reliability of Minuit Error Estimates.}

Minuit always carries around its own current estimates of the
parameter errors, which it will print out on request, no matter how
accurate they are at any given point in the execution.
For example, at initialization, these estimates are just the starting
step sizes as specified by the user.
After a \Cind[MIGrad]{MIGRAD} or \Cind[HESse]{HESSE} step,
the errors are usually quite accurate, unless there has been a problem.
Minuit, when it prints out error values,
also gives some indication of how reliable it thinks they are.
For example, those marked \Lit{'CURRENT GUESS ERROR'} are only working values
not to be believed, and \Lit{'APPROXIMATE ERROR'} means that they have been
calculated but there is reason to believe that they may not be accurate.
If no mitigating adjective is given, then at least Minuit believes
the errors are accurate, although there is always a small chance
that Minuit has been fooled.
Some visible signs that Minuit may have been fooled are:

\begin{UL}
\item Warning messages produced during the minimization or error analysis.
\item Failure to find new minimum.
\item Value of \Lit{EDM} too big. For a ``normal'' minimization,
      after \Cind[MIGrad]{MIGRAD}, the value of \Lit{EDM} is usually more
      than three orders of magnitude smaller than \Lit{UP}
      (the \Cind{SET ERRordef}), unless a looser tolerance has been specified.
\item Correlation coefficients exactly equal to zero, unless some parameters
      are known to be uncorrelated with the others.
\item Correlation coefficients very close to one (greater than 0.99).
      This indicates both an exceptionally difficult problem, and one
      which has been badly parametrized so that individual errors are not
      very meaningful because they are so highly correlated.
\item Parameter at limit. This condition, signalled by a Minuit warning
      message, may make both the function minimum and parameter errors
      unreliable. See section \ref{sec:right-errors},
      {\em Getting the right parameter errors with limits.}
\end{UL}

The best way to be absolutely sure of the errors, is to use
``independent'' calculations and compare them, or compare the calculated
errors with a picture of the function if possible.
For example, if there is only one free parameter, the command \Cind[SCAn]{SCAN}
allows the user to verify approximately the function curvature.
Similarly, if there are only two free parameters, use \Cind[CONtour]{CONTOUR}.
To verify a full error matrix, compare the results of \Cind[MIGrad]{MIGRAD}
with those (calculated afterward) by \Cind[HESse]{HESSE},
which uses a different method.
And of course the most reliable and most expensive technique,
which must be used if asymmetric errors are required, is \Cind[MINOs]{MINOS}.

\Section{4cm}{Convergence in MIGRAD, and Positive-definiteness.}

\Cind[MIGrad]{MIGRAD} uses its current estimate of the covariance matrix of the
function to determine the current search direction, since this is
the optimal strategy for quadratic functions and ``physical'' functions
should be quadratic in the neighbourhood of the minimum at least.
The search directions determined by \Cind[MIGrad]{MIGRAD} are guaranteed to be
downhill only if the covariance matrix is positive-definite,
so in case this is not true, it makes a positive-definite
approximation by adding an appropriate constant along the diagonal
as determined by the eigenvalues of the matrix.
Theoretically, the covariance matrix for a ``physical'' function must be
positive-definite at the minimum, although it may not be so
for all points far away from the minimum, even for a well-determined
physical problem.
Therefore, if \Cind[MIGrad]{MIGRAD} reports that it has found a
non-positive-definite covariance matrix, this may be
a sign of one or more of the following:

\begin{UL}
\item {\bf A non-physical region.}
      On its way to the minimum, \Cind[MIGrad]{MIGRAD}
      may have traversed a region which has
      unphysical behaviour, which is of course not a serious problem as long
      as it recovers and leaves such a region.
\item {\bf An underdetermined problem.}
      If the matrix is not positive-definite even at the minimum,
      this may mean that the solution is not well-defined, for example
      that there are more unknowns than there are data points, or that the
      parametrization of the fit contains a linear dependence.
      If this is the case, then Minuit (or any other program) cannot solve
      your problem uniquely, and the error matrix will necessarily be
      largely meaningless, so the user must remove the underdeterminedness
      by reformulating the parametrization. Minuit cannot do this itself,
      but it can provide some hints (contours, global correlation coefficients,
      eigenvalues) which can help the clever user to find out what is wrong.
\item {\bf Numerical inaccuracies.}
      It is possible that the apparent lack of positive-definiteness
      is in fact only due to excessive roundoff errors in numerical
      calculations, either in \Rind{FCN} or in Minuit.
      This is unlikely in general, but becomes more likely if the number of
      free parameters is very large, or if the parameters are badly scaled
      (not all of the same order of magnitude), and correlations are
      also large.
      In any  case, whether the non-positive-definiteness is
      real or only numerical is largely irrelevant, since in both cases the
      error matrix will be unreliable and the minimum suspicious.
\end{UL}

\section{Additional Trouble-shooting}

When Minuit just doesn't work, some of the more common causes are:

\begin{UL}
\item {\bf Precision mismatch.}
      Make sure your \Rind{FCN} has been compiled with the same precision as the
      version of Minuit you are using.
      When using \Lit{DOUBLE PRECISION}, it is safest to use the \Lit{IMPLICIT}
      declaration to make sure that everything is \Lit{DOUBLE PRECISION}, not
      just the arguments of \Rind{FCN} but also the internal variables.
      Note that depending on the computer system used, floating-point
      constants may be passed as single precision in subroutine arguments,
      even if there is an \Lit{IMPLICIT DOUBLE PRECISION} statement
      (which is strictly speaking correct since the \Lit{IMPLICIT} statement
      refers only to variables, not constants).
      Therefore, if constants are used as arguments in subroutine calls,
      they must be explicitly of the right precision (for example, on Apollo,
      even 0. is not equal to \Lit{0.D0}).

      If the problem is only one of precision, and not of word length mismatch,
      an appropriate \Cind[SET EPSmachine]{SET EPS} command may fix it.
\item {\bf Trivial bugs in \Rind{FCN}.}
      The possibilities for Fortran bugs are numerous. Probably the most
      common among physicists inexperienced in Fortran is the confusion
      between \Lit{REAL} and \Lit{INTEGER} types,
      which you can sometimes get away with, but not always.
      [For example, if \Lit{A} and \Lit{B} are \Lit{REAL} variables,
      the Fortran statement \Lit{A = 2*B}   is not good programming,
      but happens to do what the user
      probably intended, whereas the statement   \Lit{A = B + 2/3}   almost
      certainly will not do what the user intended.]
      Minuit can spot some trivial bugs itself, and issues
      a warning when it detects an unusual \Rind{FCN} behaviour.  Such a warning
      should be taken seriously.

      Minuit also offers some tools (especially \Cind[SCAn]{SCAN})
      which can help the user to find trivial bugs.
\item {\bf Overwriting in a user routine.}
      Overwriting most often occurs when setting the values of a local
      array or an array in \Lit{COMMON}, and elements outside the
      dimensions of the array are addressed.
      Most computer systems do not detect this error unless you attempt to
      write into a protected area of memory, and of course Minuit is also
      helpless, especially if Minuit itself is being overwritten.
      The symptoms of user overwriting may be almost anything,
      including unusual behaviour of Minuit itself.
      The effects depend critically on where instructions and data are
      loaded in memory, so they may change completely if the same
      program is recompiled with different compiler options or reloaded
      in a different sequence, even though the compiler and loader
      are not at fault.
\item {\bf Changing the values of input arguments.}
      In subroutine \Rind{FCN}, for example, the arguments \Lit{NPAR} and \Lit{IFLAG},
      as well as the values of the parameters themselves, are only
      input to \Rind{FCN} and their values should not be changed inside \Rind{FCN}.
      Minuit is now protected against this in principle, since
      the user only gets a copy of the value, not the actual address
      of the internal Minuit variable, but still this is a symptom of
      misunderstanding by the user.

      If you really want to change the number of variable parameters,
      this must be done with commands like \Cind{FIX} and \Cind[RELease]{RELEASE},
      by redefining parameters using command \Cind[PARameters]{PARAMETER}
      or \Cind[CLEar]{CLEAR}.

      Similarly, if a parameter takes on an unwanted value, it will do no good
      to change its value inside \Rind{FCN}: In the best case,
      Minuit won't see your
      improved value, and in the worst case, it will produce unpredictable
      results. To set a parameter to a certain value, use the command
      \Cind[SET PARameter]{SET PARam}, and to keep it within certain bounds, use the command
      \Cind{SET LIMits}.  If the parameter must obey more complicated constraints,
      you must find a trick such as adding a penalty value to \Rind{FCN} outside
      of the physical region, to force it back to where you want it.
\item {\bf An ill-posed problem.}
      For questions of parameter dependence, see the discussion above
      on postive-definiteness.
      Other mathematical problems which can arise are:
      {\bf excessive numerical roundoff} ---
      be especially careful of exponential and factorial functions
      which get big very quickly and lose accuracy;
      {\bf starting too far from the solution} ---
      the function may have unphysical local minima, especially
      at infinity in some variables;
      {\bf incorrect normalization} ---
      in likelihood functions, the probability distributions must
      be normalized or at least have an integral which is independent
      of the values of the variable parameters.
\item {\bf A bug in Minuit.}
      This is extremely unlikely, but it did happen once. If a bug is suspected, and
      all other possible causes can be eliminated, please try to save a copy of the
      input and output files, listing of \Rind{FCN}, and other information that may be
      relevant, and send them to \Lit{JAMES at CERNVM} or \Lit{VXCERN::JAMES} or
      \Lit{JAMES\atsign CERNAPO.CERN.CH}.
\end{UL}


\documentclass[a4paper,DIV12]{scrartcl}
\usepackage{graphicx}
\usepackage{natbib}
\usepackage{amsmath}
\usepackage{comment}
\usepackage{url}
\usepackage{color}
\usepackage{listings}
\usepackage[pdftex]{hyperref}
\graphicspath{{pics/}}
\include{commands}
\bibliographystyle{apalike}
\parindent 0pt
\author{
Thomas G{\"u}nther\thanks{Leibniz Institute for Applied Geophysics, Hannover (Germany)}
\ \& \
Carsten R{\"u}cker\thanks{Institute of Geology and Geophysics, University of Leipzig (Germany)}
}
\title{GIMLi --\\ Geophysical Inversion and Modelling Library \\-- programmers tutorial}
\newcommand{\cw}[1]{{\textbf{\texttt{#1}}}}
\newcommand{\invert}{invert}
\newcommand{\command}[1]{\par{\texttt{\$ #1}}}
\newcommand{\file}[1]{{\texttt{#1}}}
\newcommand{\sperre}{\,\rule{1ex}{2ex}}
\newcommand{\mycomment}[2]{\sperre{\textem{#1: #2}}\sperre}

\lstloadlanguages{[Visual]C++,[ISO]C++,Python}
\lstset{language=[ISO]C++}
\lstdefinelanguage{C++}{morekeywords={RVector,RMatrix,ModellingBase}}
%\lstset{numbers=left,numberstyle=\tiny}
%\lstset{basicstyle=\small,keywordstyle=\color{red}}
\lstset{basicstyle=\sffamily\small,keywordstyle=\bfseries}
\lstset{frame=shadowbox,commentstyle=\color{blue}}
\lstset{morekeywords={RVector,RMatrix,ModellingBase,RSparseMapMatrix,SparseMatrix}}

\begin{document}
\maketitle
\begin{abstract}
GIMLi is a C++ class library for solving inverse and forward problems in geophysics.
It was build in order to make inversion available to various forward modelling routines.
Template programming algorithms are used to create a purely mathematical framework for solving physics problems.
The inversion can apply various minimisation and regularization schemes, different transformation functions a region approach for sophisticated regularization and the chance to incorporate parametric and structural inversion.

In this tutorial we like to show the programmer how to work with GIMLi by means of different examples.
A simple curve-fitting is used to show how different forward operators can be incorporated.
Some small 1d examples demonstrate the use of different parameterisation and the partitioning of data and model.
The region technique can be used for different target parameters or geological units.

Joining different inversion runs is one of the key issues of ongoing research.
We show three different joint inversion (JI) types: one-parameter JI, petrophysical JI and structural JI.
Finally the time-lapse inversion framework is presented and applied to ERT data using different algorithms.
\end{abstract}

\clearpage
\tableofcontents

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\include{introduction}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\include{firstexample}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\include{concepts}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\include{enhanced}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\include{jointinversion}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Inversion templates}
There are certain tasks that go beyond a classical inversion scheme but still are method-independent.
They can be formulated more generally in order to be applied to a wider range of applications.
There are several cases
\begin{description}
\item[Roll-along inversion:] Geophysical data are often acquired along profiles. Since numerical work usually goes by $N^2$, it can be much more efficient to do the work piece-wise. However, the continuity must be ensured.
\item[Joint inversion:] As described above, the different joint inversions do not have to be programmed individually. Furthermore, more than two methods can be coupled.
\item[Time-lapse inversion:] Although there are several approaches for efficient inversion along the time axis, they are method-independent and can be formulated generally.
\end{description}

\subsection{Laterally constrained inversion}
This type is used when several 1d soundings along a line needed to be inverted together.
The forward modelling just combines the results of several soundings in a long vector.
They are individually connected to local 1d models, i.e. columns of a 2d model, which is regularized like a 2d model to achieve similarity between neighbouring models.
Accordingly, the Jacobian matrices are blocks in a block-diagonal matrix, for which an own matrix type is used.

\sperre{TO BE IMPLEMENTED}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Roll-along inversion}
\sperre{BLA}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Joint inversion}
Assume we have inversions invA, invB and invC, which (or parts of which) are to be coupled.

\subsubsection*{Block inversion}
Block inversion: mesh1d containing thickness and several parameters.

\sperre{TO BE IMPLEMENTED}

\subsubsection*{Structural coupling}
As described in section \ref{sec:structjoint}, the structural coupling consists mainly some preparation steps and a main iteration for the coupling that does individual runs and coupling.

Generally, there can be two possibilities for each inversion: (i) to couple the whole inversion model (as above) or (ii) to couple only one specified region.
For example, structures in an aquifer are to be imaged by cross-hole ERT and GPR. Whereas for the latter it is sufficient to restrict to the aquifer, for ERT the unsaturated zone and a clay layer must be taken into account.

For more than 2 inversions the coupling must be generalized: One can imaging a chain (or ring) or a star scheme coupling.
Whereas in the first the inversions are coupled pair-wise, in the latter the  constraint weights are mixed.

\begin{lstlisting}
SCCInversion SCC;
SCC.append( invA );
SCC.append( invB, regionnumber );
SCC.run();
\end{lstlisting}

Options: type of coupling, e.g. IRLS scheme or self-defined function. Ring or star connection. Terminating criterion.

\sperre{TO BE IMPLEMENTED}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Time lapse inversion}\label{sec:timelapse}
\subsubsection*{Strategies}\label{sec:tlstrategies}
\subsubsection*{Example}
%DC1d infiltration??

\bibliography{gimli}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{appendix}
\include{appendix}
\end{appendix}

\end{document}


 \documentclass [12pt]{article}

\usepackage {amsmath}
\usepackage {amsthm}
\usepackage {amssymb}
\usepackage {graphicx}
\usepackage {float}
\usepackage {multirow}
\usepackage {xcolor}
\usepackage {algorithmic}
\usepackage [ruled,vlined,commentsnumbered,titlenotnumbered]{algorithm2e} \usepackage {array}
\usepackage {booktabs}
\usepackage {url}
\usepackage {parskip}
\usepackage [margin=1in]{geometry}
\usepackage [T1]{fontenc}
\usepackage {cmbright}
\usepackage [many]{tcolorbox}
\usepackage [colorlinks = true,
            linkcolor = blue,
            urlcolor  = blue,
            citecolor = blue,
            anchorcolor = blue]{hyperref}
\usepackage {enumitem}
\usepackage {xparse}
\usepackage {verbatim}
\usepackage{listings}
\usepackage{xcolor}
\lstset { %
    language=C++,
    backgroundcolor=\color{black!5}, % set backgroundcolor
    basicstyle=\footnotesize,% basic font setting
}
\newtheorem{theorem}{Theorem}
\newtheorem{remark}{Remark}

\DeclareTColorBox {Solution}{}{breakable, title={Solution}} \DeclareTColorBox {Solution*}{}{breakable, title={Solution (provided)}} \DeclareTColorBox {Instruction}{}{boxrule=0pt, boxsep=0pt, left=0.5em, right=0.5em, top=0.5em, bottom=0.5em, arc=0pt, toprule=1pt, bottomrule=1pt} \DeclareDocumentCommand {\Expecting }{+m}{\textbf {[We are expecting:} #1\textbf {]}} \DeclareDocumentCommand {\Points }{m}{\textbf {(#1 pt.)}}

\begin {document}

\vspace {1em}
\begin {Instruction}
Adapted From Virginia Williams' lecture notes.
\end {Instruction}

{\LARGE \textbf {COMP 285 (NC A\&T, Spr `22)}\hfill \textbf {Lecture 11} }

\begin{centering}
\section*{Radix Sort and Wrap-Up}
\end{centering}

Today, we will continue our discussion of non-comparison-based sorts, such as Counting Sort and Radix Sort. We will wrap-up our discussion by providing motivation for the study of specialized data structures, such as balanced binary trees.

\section{Counting Sort}
Recall that our sorting lower bounds applied to the class of algorithms that can only evaluate the values being sorted via \textit{comparison queries}, namely via asking whether a given element is greater than, less than, or equal to some other element. For such algorithms, it's been proven that any correct algorithm (even a randomized one!) will require $\Omega(n \log n)$ such queries on some input. As with any lower-bound that we prove in a restricted model, it is fruitful to ask ``is it possible to have an algorithm that does not fall in this class, and hence is not subject to the lowerbound?'' For sorting, the answer is ``yes''.

We start by looking at a very simple non-comparison-based sorting algorithm called Counting Sort. Since it is not comparison-based, it is not restricted by the $\Omega(n \log n)$ lower bound for sorting. For a given input of $n$ objects, each with a corresponding key (or value) in the range $\{0, 1, \cdots, r - 1\}$, Counting Sort will sort the objects by their keys:

\begin{enumerate}
  \item Create an array $A$ of $r$ buckets where each bucket contains a linked list.
  \item For each element in the input array with key $k$, concatenate the element to the end of the linked list $A[k]$.
  \item Concatenate all the linked lists: $A[0], \cdots , A[r - 1]$.
\end{enumerate}

The algorithm correctly sorts the $n$ elements by their keys because the elements are placed into buckets by key where bucket $i$ (containing elements with key = $i$) will come before bucket $j$ (containing elements with key = $j$) in A for $i < j$. Therefore, when the algorithm concatenates the buckets, all elements with key = $i$ will come before elements with key = $j$. The worst case run time of Counting sort is $O(n+r)$ since it performs $O(1)$ passes over the $n$ input elements and $O(1)$ passes over the $r$ buckets of $A$. This is great if the size of the range $r$ is small, but we pay dearly in the running time (and space) if $r$ is large. The algorithm we discuss in the next section builds on Counting Sort and fixes this issue (that Counting Sort
behaves poorly if the range of values $r$ is very large).

An important property (which we will use in the next section) is that the algorithm described above is \textit{stable}: If two input elements $x, y$ have the same key, and $x$ appears before $y$ in the input array, $x$ will appear before $y$ in the output.

\section{Radix Sort}
Radix Sort is another non-comparison-based sorting algorithm that will use Counting Sort as a subroutine. Assuming that the input array contains $d$-digit numbers where each digit ranges from $0$ to $r - 1$, Radix Sort sorts the array digit-by-digit (or field-by-field for non-numerical
inputs). The algorithm works on input array A as follows:

\begin{enumerate}
  \item For $j = 1, \cdots, d$:
  \item Apply Counting Sort to $A$ using the $j$th digit as the key.
\end{enumerate}

Note that we refer to the least significant digit as the first digit. Hence, the algorithm calls Counting Sort first using the least significant digit as the key, then again using the second least significant digit, until the most significant digit.

We will show that Radix Sort correctly sorts an input list of $n$ numbers via induction on the iterations of the loop.

\textbf{Inductive Hypothesis:} At the end of the $j^{\text{th}}$ iteration, the elements in $A$ are sorted when considering only the $j$ least significant digits of each element.

\textbf{Base case}: $(j = 1)$ Radix Sort correctly sorts the numbers by the first digit as it uses Counting Sort to sort the numbers using the least significant digit as a key. (Note: we could have used $j = 0 $as the base case as well).

\textbf/{Inductive case}: We will prove that, if the inductive hypothesis for $j = k -1$ is true, then the inductive hypothesis for $j = k$ is true as well.
By the inductive hypothesis for $j = k - 1$, by the end of iteration $k - 1$, the input numbers have been sorted by the $k - 1$ least significant digits. After we run Counting Sort on the elements using digit $k$ as the key, the numbers are sorted by their $j^{\text{th}}$ digit. Since Counting Sort is stable, the elements in each bucket keep their original order, and by the induction hypothesis, they are ordered by their $k - 1$ least significant digits. Since \textbf{the elements are ordered first by their $k^{\text{th}}$ digit, and then by their $k -1$ least significant digits}, we conclude that they are ordered by their $k$ least significant digits.

To provide more detail for the bolded text in that last sentence, we could consider any two numbers $x$ and $y$ in the input and separately consider two cases as we did in lecture: case (i) where $x$ and $y$ have different $k$th least significant digits, and case (ii) where $x$ and $y$ have
identical $k$th least significant digits. In both cases, we could establish that, in the output,x and y are ordered by their least k significant digits. Since this is true for every pair of
numbers x and y in the input, this means that the output of this iteration is correctly sorted by the $k$ least significant digits.

By induction, the inductive hypothesis is true for all $j \in \{1, \cdots , d\}$. Applying the inductive hypothesis for $j = d$, we conclude that at the end of iteration $d$, the numbers are in sorted order (since the input consists of $d$-digit numbers). In other words, Radix Sort correctly sorts the input.

The worst case running time of Radix Sort is $O(d(n + r ))$ since we are calling Counting Sort on $n$ elements with $r$ possible keys once for each digit in the input numbers. If $r = O(n)$ and $d = O(1)$, then this takes $O(n)$ time.

As we did in lecture, we could consider varying the base $r$ in which we write our numbers and running radix sort (with the Counting Sort in the inner loop using $r$ buckets). Now the maximum number of digits is a function of the maximum size of the numbers in the input and our choice of base $r$. If we have an input consisting of $n$ numbers of value at most $M$, then the number of digits $d = \lfloor log_r (M)\rfloor + 1$. (verify this yourself!) Thus the running time for Radix Sort with base $r$ is $O(d(n + r ))$ which is $O((\lfloor \log_r (M)\rfloor + 1) \cdot (n + r )).$

How should we choose $r$? One reasonable choice is $r = n$ to balance the two values $n$ and $r$ in the term $(n +r)$ in the expression for the running time. For this choice of r, the running time for Radix sort is $O(n \cdot (\lfloor\log_r (M)\rfloor + 1))$. (Why didn’t we drop the $+1$ term in the expression
for the asymptotic running time?) Note that we might make a different choice of $r$ if it was also important to optimize the space required to run Radix Sort.

So the running time of Radix Sort (in terms of $n$) depends on how large the numbers in the input are as a function of $n$. If the upper bound $M \leq n^c$ for some constant $c$, then the running time is $O(n)$. In this regime, Radix Sort beats MergeSort and Quicksort. On the other hand, if $M = 2^n$ , then the running time is $O(n^2/\log n)$. In this regime, we would not use Radix Sort.

\end{document}


\typeout{new file: Using_RADCAL_Chapter.tex}

\chapter{Using RadCal}
\label{chap::using_RADCAL}

This chapter describes in details how to compile RadCal, how to write an input file using the namelist formatting, how to run RadCal, and describes the output files. Important modifications were brought to the code since it last release in 1993 \cite{Grosshandler1993}. In particular, the input file has been completely upgraded and the user who wishes to use this new version of the code must rewrite the old RadCal input file to comply with the new syntax.

\section{Compiling RadCal}

This new version of RadCal is a Fortran 2008 written software, written following modular paradigm. A complete description of the code is presented in Chapter~\ref{chap:Code}. The source code is contained in the file \verb=RADCAL.f90=. It includes the RADCAL module and the main program.

The file \verb=Makefile= is the make file to compile \verb=RADCAL.f90= and to generate the executable \verb=RADCAL.x=. It is made for Linux machine using the Intel Fortran compiler (\verb=ifort=). It has a couple of flags. Typing \verb'make DEBUG=0' will compile RADCAL using the compiler optimization flags. Typing \verb'make DEBUG=1' will compile the code in debugging mode. This is useful to detect any error or bug when the source file is modified. In debug mode, the code displays additional data on the screen. It prints the pressure (in atm), physical length (in cm), the temperature (in K) of each segment that composes the domain. It also prints on screen the values contained of the Lorentz half-width at half-maximum $\gamma_c$ vector for each species included in RadCal. Furthermore, it also prints characteristics pertaining to $\rm CO_2$ if this species is included in the calculation and if the wavenumber $3600~\rm cm^{-1}$ is included in the user defined spectrum. It is recommended to use RadCal with the optimizing flag as it is slightly faster than the debugging mode.

In addition to the optimization flag, a second flag enabling the compilation of the code with \verb=OpenMP= (for loop parallelization) has been implemented. To compile the code with \verb=OpenMP=, just type \verb'make DEBUG=0 PARALL=1' (for optimization version) or \verb'make DEBUG=1 PARALL=1' for the debugging \verb=OpenMP= version. Note that the \verb=OpenMP= version does not improve much the performances, but it was included there for experimentation.

\section{Input file}

The input file is named \verb=RADCAL.in=. The input file format has changed since the last RADCAL version. It now uses the Fortran \verb=namelist= formalism, which is more convenient. What is needed is the knowledge, for each segment along the line of sight, of the local temperature (\verb=T=), distance (\verb=LENGTH=), pressure (\verb=PRESSURE=), soot volume fraction (\verb=Fv=), and species mole fraction, (\verb=X<species name>=).
\textbf{It is very important that the sum of all the species mole fraction over a given segment is equal to 1}. Otherwise the code will not compute and will return an error message in the output file \verb=RADCAL.out=.

A list of all the RadCal available species is included in the code and is printed in a automatically generated \verb=RADCAL.in= in the case the user did not provide any input file. Unlike the old version, you can now solve the radiative Transfer Equation for any mixture of fuels and products of combustion.

\subsection{Example}\label{sec:input_file}
Below is an example of input file \verb=RADCAL.in=, automatically generated by RadCal in the case that RadCal is started without an existing input file. The header prints automatically the list of species present in RadCal.

\begin{lstlisting}
#-----------------------------------------------------------------------
# Generic RADCAL input file
# Created automatically
# List of species currently available:
#-----------------------------------------------------------------------
# <species name>        ! <phase> <comments>
# CO2   ! (gas) Carbon dioxide
# H2O   ! (gas) Water
# CO    ! (gas) Carbon monoxide
# CH4   ! (gas) Methane
# C2H4  ! (gas) Ethylene
# C2H6  ! (gas) Ethane
# C3H6  ! (gas) Propylene
# C3H8  ! (gas) Propane
# C7H8  ! (gas) Toluene
# C7H16 ! (gas) n-Heptane
# CH3OH ! (gas) Methanol
# MMA   ! (gas) MMA, C5H8O2
# Fv    ! (solid) Soot. Defined by its soot volume fraction, Fv
# N2    ! (gas) Nitrogen does not participate to the radiative transfer
#               but is needed for collision broadening
# CH4_OLD       ! (gas) Former Methane data
# O2    ! (gas) Oxygen does not participate to the radiative transfer
#               but is needed for collision broadening
#-----------------------------------------------------------------------
#
# How to use:
#       1) Discretize the line of sight into isothermal, homogeneous
#          segments
#       2) Define each segment temperature (variable "T", in Kelvin) and
#          length (variable "LENGTH", in meters)
#       3) Enter the pressure of each segment (variable "PRESSURE", in
#          atmosphere)
#       4) Enter the composition of the mixture, in mole fraction for
#          gas phase species (variable "X<name of species>")
#          Important: make sure the sum of species mole fraction is
#          equal to 1
#       5) Define bounds of the spectrum OMMIN/OMMAX in wavenumber
#          (1/cm)
#       6) Do not forget to enter the temperature of the surrounding,
#          which is represented by a wall at an infinite distance at its
#          blackbody temperature (variable "TWALL" in Kelvin)
#-----------------------------------------------------------------------
Example:
&HEADER TITLE="Example" CHID="Example" /

&BAND
                OMMIN = 50.0
                OMMAX = 10000.0 /
&WALL TWALL = 500.0 /

&Path_Segment ! Define a homogeneous segment
        T        = 300.0  ! Temperature in Kelvin
        LENGTH   = 0.3175 ! Length of the segment in meters
        PRESSURE = 1.0    ! Pressure in atm
        XC2H4    = 0.01   ! Mole fraction of Ethylene
        XCO2     = 0.0033 ! Mole fraction of CO2
        XH2O     = 0.01   ! Mole fraction of H2O
        XO2      = 0.21   ! Mole fraction of O2
        XN2      = 0.7667 ! Mole fraction of N2
        Fv       = 1.0e-7/! Soot volume fraction
#-----------------------------------------------------------------------
\end{lstlisting}

\subsection{Input file structure}

Each line starting with a character \verb=#= is a comment. The comments on the header in the above input file are generated automatically.

Each namelist name is preceded by a \verb=&= character. The needed namelist are:
\verb=HEADER=, \verb=BAND=, \verb=WALL=, \verb=Path_Segment=. These namelist names are not case-sensitive.

Each namelist has a set of parameters you may provide. Parameters not provided have their values taken by default. They are presented below and in the input file.
A "slash" character '\verb=/=' is needed after providing the parameters of each namelist.

The name of the case is defined by assigning a value to \verb'&HEADER TITLE="<value here>"' and \verb'CHID="<value here>"'.

The band limit, in cm$^{-1}$, is defined with the keyword \verb=OMMIN= and \verb=OMMAX=.

\subsection{Naming the case: the \texorpdfstring{{\tt HEADER}}{HEADER} namelist group}

the namelist \verb=HEADER= defines the case title with the parameter \verb=TITLE= and the CASEID with the parameter \verb=CHID=.
This parameter are of type \verb=string=. The title of the case \verb=TITLE= is just used for the user own organization. The parameter \verb=CHID= is used to name the Tecplot output file: \verb=<CHID>.tec=.

\subsection{Defining the integration bounds: the \texorpdfstring{{\tt BAND}}{BAND} namelist group}

The namelist \verb=BAND= defines the lower bound wavenumber, $\om_{min}$ of the spectrum with the parameter \verb=OMMIN= and the upper bound wavenumber, $\om_{max}$ of the spectrum with the parameter \verb=OMMAX=. Units are in cm$^{-1}$.

\subsection{Defining the surrounding blackbody temperature: the \texorpdfstring{{\tt WALL}}{WALL} namelist group}

The surrounding temperature is given by \verb=TWALL= (given in Kelvin). This defines the temperature of an emitting blackbody located at one extremity of the path (the observer is located on the other side). This corresponds to the temperature of $T_{w}$ in the Eq.~\ref{eq::RTE_Wavenumber}.

\subsection{Characterizing the homogeneous pathlength segment: the \texorpdfstring{{\tt Path\_Segment}}{Path_Segment} namelist group}

Any homogeneous segment can be defined by using the keyword \verb=&Path_Segment=. For each path segment, the user needs to define the local temperature (in Kelvin) using the parameter \verb=T=, the length of the segment (in meters) with \verb=LENGTH=, the segment total pressure (in atm) with \verb=PRESSURE=, the mole fraction of any species present in the segment with the parameter \verb=X<name of species>=, and the volume fraction of soot (if any) with the parameter \verb=Fv=. Values omitted are set internally to zero. The user does not need to enter a value for a species not present in the segment.

It is very important that the sum of mole fraction \verb=X<name of species>= is equal to 1 otherwise the segment will be dismissed.

Each segment definition is terminated with a "slash" character \verb=/=.

If there is more than one segment, the user should add other segments by adding and defining extra \verb=&Path_Segment= keywords. There is no restriction on the number of segment considered. The segments are to be entered from the closest to the observer, \textit{i.e.} closest to where the incident intensity is calculated (variable $s$ in Eq,~\ref{eq::RTE_Wavenumber}), to the furthest (defined as $s = 0$ in Eq.~\ref{eq::RTE_Wavenumber}). It is assumed that the furthest point is bounded by an emitting blackbody wall of temperature specified by \verb=TWALL=.

\section{Output files}

RadCal generates two output files: \verb=RADCAL.out= which contains a summary of the case run and the integrated quantities presented in Section~\ref{sec::Output}, and a Tecplot file of name \verb=<CHID>.tec=, where \verb=CHID= is the value entered by the user. The Tecplot file prints the spectral transmissivity along the whole line of sight (quantity $\bar{\tau}(\om_0; 0 \rightarrow s) $ in Eq.~\ref{eq::RTE_Wavenumber}) expressed in \%, and the incident spectral intensity $I_{\om_0}(s)$, given in $\rm W/m^{2}/str/cm^{-1}$, as calculated using either Eq.~\ref{eq::RTE_wavenumber_H}, against the wavenumber, given in $\rm cm^{-1}$.

If \verb=RADCAL.in= was not provided, the code will print in \verb=RADCAL.out= the following message:
\begin{lstlisting}
WARNING ! RADCAL.in was NOT provided.
Creating Default RADCAL.in for illustration purposes.
\end{lstlisting}

The output file generated by RadCal using the input file \verb=RADCAL.in= presented in Subsection~\ref{sec:input_file} is given below as an example:
\begin{lstlisting}
 CASEID: Example TITLE: Example
-------------------------------------------------------------
 Calculation completed.
 Total path length (m):   0.317500000000000
 Amean (cm-1):                    4.079920581529569E-003
 Planck mean absorption (cm-1):   9.468434716110452E-003
 Total Emissivity:                0.121498337093312
 Received Flux (W/m2/str):         1008.60961294274
 Total Transmissivity:            0.878725505722343
-------------------------------------------------------------
Version: $Revision: 51 $
Version created on: $Date: 2014-06-05 14:56:35 -0400 (Thu, 05 Jun 2014) $
Version built on: Thu Jun 12 18:08:23 EDT 2014
Execution time (ms):  1.85840E+01
\end{lstlisting}
The first line recalls the case title and the caseid. On the fourth line, RadCal recalls the total length of the line of sight (\textit{i.e.} the sum of all the segments \verb=LENGTH=). The value is given in meters. The fifth line prints the effective absorption coefficient as calculated by Eq.~\ref{eq:effective_epsilon}. The sixth line prints the Planck mean absorption coefficient as defined by Eq.~\ref{eq::planck_mean}. The seventh line prints the total emissivity, as calculated from Eq.~\ref{eq:total_emissivity}. The total received flux as calculated by Eq.~\ref{eq::received_flux} is given on the eighth line. Finally, the ninth line prints the value of the total transmissivity, calculated using Eq.~\ref{eq::total_transmissivity}.
The last four lines of \verb=RADCAL.out= recall the version of the code, the date at which this version was created, the date and time at which the code was compiled. The last line indicates the duration of code execution.

\section{Python script}

A Python script has been written to facilitate the visualization of the data present in the Tecplot file. The Python script, named \verb=Start_Radcal.py=, executes RadCal, reads the output Tecplot file and \verb=RADCAL.out=, and displays the plots of $\bar{\tau}(\om_0; 0 \rightarrow s) $ against the wavenumber $\om$ on the top window, and the spectral evolution of the incident intensity $I_{\om_0}(s)$ against the wavenumber $\om$ on the bottom window. The script also prints some integrated quantities and generates automatically a \verb=pdf= file. In order to use this script, beside Python, the \verb=matplotlib= library, Ref.~\cite{Hunter:2007}, is needed. Figure~\ref{fig:EXAMPLE} plots the spectral transmissivity and the incident spectral intensity for the case given as an example in Subsection~\ref{sec:input_file} as generated by the \verb=Start_Radcal.py= script.

\begin{figure}
\includegraphics[width=\textwidth]{Figures/Example.pdf}
\caption{Top: Spectral transmissivity of the medium, in \%, using the input file given in Subsection~\ref{sec:input_file}. Bottom: Associated incident spectral intensity, $I_{\om_0}(s)$, given in $\rm W/m^{2}/str/cm^{-1}$.\label{fig:EXAMPLE}}
\end{figure}


% !TEX root = ../00_thesis.tex

\section{Overview of \DRP}
\label{sec:design_overview}

\afterpage{
\begin{figure}
  \centering
  \includegraphics[scale=1]{dpp}
  \caption{Conceptual view of the DPP, based one the \bolt processor interconnect. %
  \capt{%
    Using functions \emph{\opwrite}, \emph{\opread}, and \emph{\opflush}, the application (\ap) and communication (\cp) processors can asynchronously exchange messages with predictable latency.
    The \AP executes application tasks (\eg sensing, actuation, control, \etc) while the \CP is dedicated to radio communication.}}
  \label{fig:bolt_logical}
\end{figure}
}

This chapter presents the \DRPLong (\DRP), a solution to provide end-to-end real-time guarantees between distributed applications.
Before delving into details, this section provides an overview of \DRP's principles.

The system model of \DRP divides the end-to-end communication between local and wireless parts~(\cref{fig:DRP_sysmodel}):
\pagebreak
\begin{description}
  \item[\AP  $\boldsymbol{\leftrightarrow}$ \CP]
  Applications run on dedicated application processors (\APs) which are isolated from the rest of the network by their attached communication processor (\CP).
  Local communication between \APs and \CPs  takes place over the \bolt interconnect~\cite{sutton2015Bolt}, which provides asynchronous message passing with bounded delays.
  This device architecture, called the Dual-Processor Platform (\DPP), is illustrated in \cref{fig:bolt_logical} (more details in \cref{ch:introduction}).

  \item[\CP  $\boldsymbol{\leftrightarrow}$ \CP]
  The \CPs exchange messages over a multi-hop wireless network using the \blink real-time protocol~\cite{zimmerling2017Blink}.
  \blink is adaptive to dynamic changes in traffic demands, energy efficient, and delivers messages in real-time.
\end{description}

The \DPP and \blink are key building blocks to fulfill the \feature{Reliability}, \feature{Adaptability}, \feature{Composability}, and \feature{Efficiency} requirements.
However, two major issues remain in order to achieve \feature{Timeliness}.

\squarepar{%}
  First, the communication between \APs and \CPs cannot be completely asynchronous: to guarantee end-to-end deadlines, both processors must look for incoming messages with some minimal rate.
  %
  Second, \blink assumes a periodic release of messages at the network interfaces (\ie the \CPs); since our flow model is not periodic but sporadic with jitter~(\cref{sec:problem}), messages may be delayed in \CPs buffer until they can be transmitted over the network.%
}

\DRP strikes a balance between  \feature{Composability} and \feature{Efficiency}; that is, between
\linebreak
\inlineitem decoupling the execution of \APs, \CPs, and Blink, \\
\inlineitem supporting short the end-to-end deadlines between the \APs.\\
The idea behind \DRP is to split the responsibility of meeting end-to-end deadlines between (i)~the source node $n^s_i$ and \blink, and (ii)~the destination node $n^d_i$;
If the source does not write too many messages, \blink guarantees every message will meet a given network deadline $D$, in turns, the destination commits to read its \bolt queue sufficiently often to meet the flow's end-to-end deadlines \deadlineany.

\squarepar{%}
  \DRP formalizes these ``commitments'' into \emph{contracts} between the different entities. The challenge is to define, given the current network state and an end-to-end deadline \deadlineany to satisfy, what must be
  % \begin{itemize}
    % \item
    (i)~the network deadline $D$ requested to \blink and
    % \item
    (ii)~the minimal reading rate at the destination node.
  % \end{itemize}
  The goal is to make these contracts minimally restrictive, such that \APs, \CPs, and Blink can operate as much as possible independently from each other (\feature{Composability}).%
}