\section{Forward Sampling Strategies}
\label{sec:forwardSamplingStrategies}
In order to perform UQ and dynamic
probabilistic risk assessment (DPRA),
a sampling strategy needs to be employed. The sampling strategy
perturbs the input space (domain of the uncertainties) to explore
the response of a complex system in relation to selected FOMs.

The most widely used strategies to perform UQ and PRA are generally
collected in RAVEN as \textit{\textbf{Forward}} samplers. \textit{\textbf{Forward}} samplers include
all the strategies that simply perform the sampling of the input space.  These strategies sample
without exploiting, through learning approaches,
the information made available from the outcomes of evaluation previously performed (adaptive sampling) and the
common system evolution (patterns) that different sampled calculations can generate in the phase space (Dynamic Event Tree).

As mentioned in Section~\ref{sub:tutorialMultiRun}, RAVEN has
several different \textit{\textbf{Forward}} samplers:
\begin{itemize}
  \item \textit{Monte-Carlo}
  \item \textit{Grid-based}
  \item \textit{Stratified} and its specialization named \textit{Latin Hyper Cube}.
\end{itemize}
In addition, RAVEN posses advanced \textit{\textbf{Forward}} sampling strategies that:
\begin{itemize}
  \item Build a grid in the input space selecting evaluation points
    based on characteristic quadratures as part of stochastic collocation
    for generalized polynomial chaos method (\textit{Sparse
    Grid Collocation} sampler);
  \item Use high-density model reduction (HDMR) a.k.a. Sobol
    decomposition to approximate a function as the sum of
    interactions with increasing complexity (\textit{Sobol} sampler).
\end{itemize}
In the following subsections, we provide examples of input files
in RAVEN using the method, with explanatory commentary.
%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%  MONTE-CARLO %%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Monte-Carlo sampling through RAVEN}
\label{sub:MCexample}
The Monte-Carlo method is one of the most-used methodologies in several mathematic disciplines. In this section,
we will explain the techniques for employing this methodology in RAVEN, and we recommend the user to read the
theory manual to explore the theory of the method.
The goals of this section are about learning how to:
 \begin{enumerate}
   \item Set up a simple Monte-Carlo sampling for perturbing the input space of a driven code
   \item Load the outputs of the code into RAVEN DataObjects (HistorySets and PointSets)
   \item Print the contents of DataObjects to file
   \item Generate plots of the sampling results.
\end{enumerate}
In order to accomplish these tasks, the following RAVEN \textbf{Entities} (XML blocks in the RAVEN input file) are needed:
\begin{enumerate}
   \item \textbf{\textit{RunInfo}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{RunInfo}
     As discussed in Section~\ref{sub:singleRun}, the \textit{RunInfo} \textbf{Entity} sets up the analysis
     that the user wants to perform. The number of steps specified in (\xmlNode{Sequence}) are sequentially run using the number of processors assigned in (\xmlNode{batchSize}).
     Note that the \xmlNode{JobName} is not required, but is useful in identifying the input file.
   \item \textbf{\textit{Models}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{Models}
     The Model used in this example is the \textbf{Projectile} external model, which is defined in section \ref{sec:analyticalbateman}.
   \item \textbf{\textit{Distributions}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{Distributions}
     In the \xmlNode{Distributions} block, the stochastic model for the uncertainties treated by the
     \xmlNode{Sampler} is defined. In this case two distributions are defined:
  \begin{itemize}
    \item $vel\_dist \sim \mathbb{N}(30,5)$, used to model the uncertainties
    associated with  the \textit{velocity};
    \item  $angle\_dist \sim \mathbb{U}(5,85)$,  used to
    model the uncertainties associated with the \textit{angle}.
  \end{itemize}
   \item \textbf{\textit{Samplers}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{Samplers}
      To employ the Monte-Carlo sampling strategy, a
      \xmlNode{MonteCarlo} node needs to be defined. The number of samples is defined within this node. The Monte-Carlo method is employed on model variables listed by name and are associated with a distribution.
   \item \textbf{\textit{DataObjects}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{DataObjects}
      In this block, three \textit{DataObjects} are defined to store results: 1) a PointSet named
      ``samples'', 2) a PointSet named ``dummyIN'' 3) a HistorySet named ``histories''.
      Note that in the \xmlNode{Input} node all the uncertainties
      perturbed through the Monte-Carlo strategy are listed. By this, any
      realization in the input space is linked in the DataObject to the outputs listed in the
      \xmlNode{Output} node. Furthermore, since we use an external model that does not have any input file, we define a pointset named ``dummyIN'' that is used as a dummy input in the multirun step.
   \item \textbf{\textit{OutStreams}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{OutStreams}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure histories
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/MonteCarlo/1-historyPlot_scatter-scatter.png}
  \caption{Plot of the histories generated by the Monte Carlo sampling.}
  \label{fig:historiesMCPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 To see the results of the simulation, \xmlNode{OutStreams} are included in the input.
  In this block, both OutStream types are used:
  \begin{itemize}
    \item \textit{Print}:
     \begin{itemize}
       \item ``samples'' connected with the \textit{DataObjects} \textbf{Entity} ``samples''
                (\xmlNode{source})
       \item ``histories'' connected with the \textit{DataObjects} \textbf{Entity} ``histories'' (\xmlNode{source})
     \end{itemize}
     Note that in RAVEN, multiple entities can have the same name, as it takes a class, a type, and a name to uniquely identify a RAVEN object. When the two OutStream objects are used, all the information contained in the  linked \textit{DataObjects} are going
    to be exported in CSV files (\xmlNode{type}).
    \item \textit{Plot}:
    \begin{itemize}
      \item ``historiesPlot'' connected with the  \textit{DataObjects}
      \textbf{Entity} ``histories''.  This plot shows the variable $range$ with respect to the input variables $velocity$ and $angle$.
      \item ``samplesPlot3D'' connected with the
      \textit{DataObjects} \textbf{Entity} ``samples''. This plot shows the variables $range,time$ with respect to the input variables $velocity$ and $angle$.
    \end{itemize}
     Note that both plots use gridded subplots. Two plots
     are placed in each of the figures.
  \end{itemize}
   \item \textbf{\textit{Steps}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingMontecarlo.xml}{Steps}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure samples
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/MonteCarlo/1-samplesPlot3D_scatter-scatter.png}
  \caption{Plot of the samples generated by the MC sampling.}
  \label{fig:samplesMCPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   Once all the other entities are defined in the RAVEN input file, they must be combined in the
   \xmlNode{Steps} block, which dictates the workflow of RAVEN.  For this case,
   two \xmlNode{Steps} are defined:
   \begin{itemize}
     \item \xmlNode{MultiRun} ``sample'', used to run the multiple
     instances of the driven code and
     collect the outputs in the two \textit{DataObjects}. As it can be
     seen, the \xmlNode{Sampler} is specified to communicate to the
     \textit{Step} that the driven code needs to
     be perturbed through the Monte-Carlo sampling.
     \item  \xmlNode{IOStep} named ``writeHistories'', used to 1) dump
     the ``histories'' and ``samples'' \textit{DataObjects}
     \textbf{Entity} to a CSV file and 2) plot the data in the EPS file.
   \end{itemize}
\end{enumerate}
 Figures~\ref{fig:historiesMCPlotScatter} and ~\ref{fig:samplesMCPlotScatter} show the report
 generated by RAVEN.
%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%          GRID          %%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Grid sampling through RAVEN}
\label{sub:Gridexample}
The Grid sampling method (also known as Full Factorial Design of Experiment) represents one of the simplest methodologies that can be employed in order to explore the interaction of multiple random variables with respect
selected FOMs.
The goal of this section is to show how to:
 \begin{enumerate}
   \item Set up a simple Grid sampling for performing a parametric analysis of a driven code
   \item Load the outputs of the code into the RAVEN DataObjects system
   \item Print out what contained in the DataObjects
   \item Generate basic plots of the code result.
\end{enumerate}
In order to accomplish these tasks, the following RAVEN \textbf{Entities} (XML blocks in the input files) are required:
\begin{enumerate}
   \item \textbf{\textit{RunInfo}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{RunInfo}
   As shown in Section~\ref{sub:singleRun}, the \textit{RunInfo} \textbf{Entity} is intended to set up the desired analysis. The number of steps specified in (\xmlNode{Sequence}) are sequentially run using the number of processors assigned in (\xmlNode{batchSize}).
   \item \textbf{\textit{Models}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{Models}
 The Model here is represented by the \textbf{Projectile}, which already dumps its output file in a
 CSV format (standard format that RAVEN can read).
   \item \textbf{\textit{Distributions}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{Distributions}
  In the Distributions XML section, the stochastic model for the
  uncertainties  treated by the Grid sampling are reported. In
  this case two distributions are defined:
  \begin{itemize}
    \item $vel\_dist \sim \mathbb{N}(30,5)$, used to model the uncertainties
    associated with  the \textit{velocity};
    \item  $angle\_dist \sim \mathbb{U}(5,85)$,  used to
    model the uncertainties associated with the \textit{angle}.
  \end{itemize}
   \item \textbf{\textit{Samplers}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{Samplers}
  To employ the Grid sampling strategy, a
  \xmlNode{Grid} node needs to be specified. As shown above, in each variable section, the  \xmlNode{grid} is defined.
   \item \textbf{\textit{DataObjects}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{DataObjects}
  In this block, three \textit{DataObjects} are defined to store results: 1) a PointSet named
      ``samples'', 2) a PointSet named ``dummyIN'' 3) a HistorySet named ``histories''.
  In the \xmlNode{Input} node all the variables  perturbed through the Grid strategy are listed. In this way, any  realization in the input space is linked to the outputs listed in  the
  \xmlNode{Output} node. As described earlier as well, since we use an external model that does not have any input file, we define a pointset named ``dummyIN'' that is used as a dummy input in the multirun step.
    \item \textbf{\textit{OutStreams}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{OutStreams}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure histories
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/Grid/1-historyPlot_scatter-scatter.png}
  \caption{Plot of the histories generated by the Grid sampling.}
  \label{fig:historiesGridPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  In this block, both the Out-Stream types are constructed:
  \begin{itemize}
    \item \textit{Print}:
     \begin{itemize}
       \item named ``samples'' connected with the \textit{DataObjects} \textbf{Entity} ``samples''
                (\xmlNode{source})
       \item named ``histories'' connected with the \textit{DataObjects} \textbf{Entity} ``histories'' (\xmlNode{source}).
     \end{itemize}
      When these objects get used, all the information contained in the
      linked  \textit{DataObjects} are going
    to be exported in CSV files (\xmlNode{type}).
    \item \textit{Plot}:
    \begin{itemize}
      \item named ``historiesPlot'' connected with the  \textit{DataObjects}
      \textbf{Entity} ``histories''.  This plot shows the variable $range$ with respect to the input variables $velocity$ and $angle$.
      \item named ``samplesPlot3D'' connected with the
      \textit{DataObjects} \textbf{Entity} ``samples''. This plot shows the variables $range,time$ with respect to the input variables $velocity$ and $angle$.
    \end{itemize}
  \end{itemize}
   \item \textbf{\textit{Steps}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingGrid.xml}{Steps}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure samples
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/Grid/1-samplesPlot3D_scatter-scatter.png}
  \caption{Plot of the samples generated by the Grid sampling for variables $A,B,C,D$.}
  \label{fig:samplesGridPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   Finally, all the previously defined \textbf{Entities} can be combined in
   the \xmlNode{Steps} block. As inferable,
   two \xmlNode{Steps} have been inputted:
   \begin{itemize}
     \item \xmlNode{MultiRun} named ``sample'', is used to run the multiple
     instances of the code and
     collect the outputs in the two \textit{DataObjects}. As it can be
     seen, the \xmlNode{Sampler} is inputted to communicate to the
     \textit{Step} that the driven code needs to
     be perturbed through the Grid sampling
     \item  \xmlNode{IOStep} named ``writeHistories'', used to 1) dump
     the ``histories'' and ``samples'' \textit{DataObjects}
     \textbf{Entity} in a CSV file and 2) plot the data in the PNG file and
     on the screen.
   \end{itemize}
\end{enumerate}
 Figures~\ref{fig:historiesGridPlotScatter} and ~\ref{fig:samplesGridPlotScatter} display the report generated by RAVEN.

%%%%%%%%%%%%%%%%%%%%%%%%%
%%%%%%%%    STRATIFIED    %%%%%%%%
%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Stratified sampling through RAVEN}
\label{sub:Stratifiedexample}
The Stratified sampling is a class of methods that relies on the assumption that the input space (i.e.,uncertainties)
can be separated in regions (strata) based on similarity of the response of the system for input set within the
same strata. Following this assumption, the most rewarding (in terms of computational cost vs. knowledge gain)
sampling strategy would be to place one sample for each region. In this way, the same information is not
collected more than once and all the prototypical behavior are sampled at least once. In
Figure~\ref{fig:StratifiedSamplingExample}, the Stratified sampling approach is exemplified.
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.55]{pics/StratifiedSamplingExample.png}
  \caption{Example of Stratified sampling approach.}
  \label{fig:StratifiedSamplingExample}
 \end{figure}
\\The goal of this section is to show how to:
 \begin{enumerate}
   \item Set up a simple Stratified sampling in order to perform a parametric analysis on a driven code
   \item Load the outputs of the code into the RAVEN DataObjects system
   \item Print out what contained in the DataObjects
   \item Generate basic plots of the code result.
\end{enumerate}
To accomplish these tasks, the following RAVEN \textbf{Entities} (XML blocks in the input files) are defined:
\begin{enumerate}
   \item \textbf{\textit{RunInfo}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{RunInfo}
   As explained earlier, the \textit{RunInfo} \textbf{Entity} is intended to set up the analysis that the user wants to perform. The number of steps specified in (\xmlNode{Sequence}) are sequentially run using the number of processors assigned in (\xmlNode{batchSize}).
   \item \textbf{\textit{Models}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{Models}
 The Model here is represented by the
 \textbf{Projectile}, which already dumps its output file in a
 CSV format (standard format that RAVEN can read).
   \item \textbf{\textit{Distributions}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{Distributions}
  In the Distributions XML section, the stochastic model for the
  uncertainties  treated by the Stratified sampling are reported. In
  this case two distributions are defined:
  \begin{itemize}
    \item $vel\_dist \sim \mathbb{N}(30,5)$, used to model the uncertainties
    associated with  the \textit{velocity};
    \item  $angle\_dist \sim \mathbb{U}(5,85)$,  used to
    model the uncertainties associated with the \textit{angle}.
  \end{itemize}
   \item \textbf{\textit{Samplers}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{Samplers}
  To employ the Stratified sampling strategy, a
  \xmlNode{Stratified} node needs to be specified. In each variable section, the  \xmlNode{grid} is defined.
  It is important to mention that the number of \xmlAttr{steps} needs to be the same for each of the variables,  since, as reported in previous section, the Stratified sampling strategy it discretizes the domain in strata.
  The number of samples finally requested is equal to $n_{samples} = n_{steps} = 100$.
  If the grid for each variables is defined in CDF and of  \xmlAttr{type} = ``equal'', the Stratified sampling corresponds to the well-known Latin Hyper Cube sampling.
   \item \textbf{\textit{DataObjects}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{DataObjects}
  In this block, two \textit{DataObjects} are defined: 1) a PointSet named
      ``samples'', 2) a PointSet named ``dummyIN'' 3) a HistorySet named ``histories''.
  In the \xmlNode{Input} node all the variables perturbed through the Stratified strategy are listed. In this way, any realization in the input space is linked to the outputs listed in  the
  \xmlNode{Output} node. Since we use an external model that does not have any input file, we define a pointset named ``dummyIN'' that is used as a dummy input in the multirun step.
   \item \textbf{\textit{OutStreams}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{OutStreams}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure histories
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/Stratified/1-historyPlot_scatter-scatter.png}
  \caption{Plot of the histories generated by the Stratified sampling.}
  \label{fig:historiesStratifiedPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  In this block, both the Out-Stream types are constructed:
  \begin{itemize}
    \item \textit{Print}:
     \begin{itemize}
       \item named ``samples'' connected with the \textit{DataObjects} \textbf{Entity} ``samples''
                (\xmlNode{source})
       \item named ``histories'' connected with the \textit{DataObjects} \textbf{Entity} ``histories'' (\xmlNode{source}).
     \end{itemize}
      When these objects get used, all the information contained in the
      linked  \textit{DataObjects} are going
    to be exported in CSV files (\xmlNode{type}).
    \item \textit{Plot}:
    \begin{itemize}
      \item named ``historiesPlot'' connected with the  \textit{DataObjects}
      \textbf{Entity} ``histories''.  This plot shows the variable $range$ with respect to the input variables $velocity$ and $angle$.
      \item named ``samplesPlot3D'' connected with the
      \textit{DataObjects} \textbf{Entity} ``samples''. This plot shows the variables $range,time$ with respect to the input variables $velocity$ and $angle$.
    \end{itemize}
  \end{itemize}
   \item \textbf{\textit{Steps}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingStratified.xml}{Steps}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure samples
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/Stratified/1-samplesPlot3D_scatter-scatter.png}
  \caption{Plot of the samples generated by the Stratified sampling.}
  \label{fig:samplesStratifiedPlotLine}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   Finally, all the previously defined \textbf{Entities} can be combined in
   the \xmlNode{Steps} block. As inferable,
   two \xmlNode{Steps} have been inputted:
   \begin{itemize}
     \item \xmlNode{MultiRun} named ``sample'', used to run the multiple
     instances of the driven code and
     collect the outputs in the two \textit{DataObjects}. As it can be
     seen, the \xmlNode{Sampler} is inputted to communicate to the
     \textit{Step} that the driven code needs to
     be perturbed through the Stratified sampling.
     \item  \xmlNode{IOStep} named ``writeHistories'', used to 1) dump
     the ``histories'' and ``samples'' \textit{DataObjects}
     \textbf{Entity} in a CSV file and 2) plot the data in the PNG file and
     on the screen.
   \end{itemize}
\end{enumerate}
 As previously mentioned, Figures~\ref{fig:historiesStratifiedPlotScatter} and ~\ref{fig:samplesStratifiedPlotScatter}  display the report generated by RAVEN.

%%%%%%%%%%%%%%%%%%%%%%%%%

\subsection{Sparse Grid Collocation sampling through RAVEN}
\label{sub:SGcsamplingExample}
The Sparse Grid Collocation sampler represents an advanced methodology to perform Uncertainty Quantification. They aim
to explore the input space leveraging the information contained in the associated probability density functions. It builds on generic Grid sampling by selecting evaluation points based on characteristic quadratures as part of stochastic collocation for generalized polynomial chaos uncertainty quantification. In collocation an N-D grid is constructed, with each uncertain variable providing an axis. Along each axis, the points of evaluation correspond to quadrature points necessary to integrate polynomials. In the simplest (and most naive) case, a N-D tensor product of all possible combinations of points from each dimension’s quadrature is constructed as sampling points. The number of necessary samples can be reduced by employing Smolyak-like sparse grid algorithms, which use reduced combinations of polynomial orders to reduce the necessary sampling space.
\\The goals of this section are about learning how to:
 \begin{enumerate}
   \item Set up a Sparse Grid Collocation sampling for the construction of a suitable surrogate model of a driven code
   \item Construct a GaussPolynomialRom surrogate model (training stage)
   \item Use the constructed GaussPolynomialRom surrogate model instead of the driven code.
\end{enumerate}
To accomplish these tasks, the following RAVEN \textbf{Entities} (XML blocks in the input files) need to be defined:
\begin{enumerate}
   \item \textbf{\textit{RunInfo}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{RunInfo}
   AThe \textit{RunInfo} \textbf{Entity} is intended to set up the analysis  that the user wants to perform. The steps listed in (\xmlNode{Sequence}) are going to be sequentially run using the number of processors specified in  (\xmlNode{batchSize}).  The first two steps build the ROM
   (\xmlString{sample}, \xmlString{train}), the next two validate
   the ROM against the original Code Model (\xmlString{validateModel}, \xmlString{validateROM}),
   \xmlString{rom\_stats} stores ROM-related information into DataObject,
   and the last two produce plots and print data (\xmlString{output\_print}, \xmlString{output\_plot}).
   \item \textbf{\textit{Models}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{Models}
 The goal of this example is the generation of a \text{GaussPolynomialRom}
 for subsequent usage.  In addition to the previously explained External model, the ROM of type \textit{GaussPolynomialRom} is specified here. The ROM is generated through a Sparse Grid Collocation sampling strategy. Note that the \xmlNode{Interpolation} nodes are not required, but are included for the sake of demonstration.
   \item \textbf{\textit{Distributions}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{Distributions}
  In the Distributions XML section, the stochastic model for the
  uncertainties  treated by the Sparse Grid Collocation sampling are reported. In
  this case two distributions are defined:
  \begin{itemize}
    \item $vel\_dist \sim \mathbb{N}(30,5)$, used to model the uncertainties
    associated with  the \textit{velocity};
    \item  $angle\_dist \sim \mathbb{U}(5,85)$,  used to
    model the uncertainties associated with the \textit{angle}.
  \end{itemize}
   \item \textbf{\textit{Samplers}}:
     \xmlExample[rom,ROM,SparseGridCollocation,MonteCarlo]{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{Samplers}
  In order to employ the Sparse Grid Collocation sampling strategy, a
  \xmlNode{SparseGridCollocation} node needs to be defined.
  As can be  seen from above, each variable is associated with a different distribution,
  defined in the  \xmlNode{Distributions} block.
  In addition, the \textit{GaussPolynomialRom} \xmlNode{ROM} is linked to the \xmlNode{SparseGridCollocation} sampler.  Because this sampler is used exclusively to build the ROM, some of the parameters of the ROM are  needed by the sampler, and this connection makes that communication possible.  The setting of this ROM (e.g. polynomial order, Index set method, etc.) determines how the Stochastic Collocation Method is employed.

  Additionally, a \xmlNode{MonteCarlo} sampler is set up for validating the ROM against the original Code.  The random number generation seed (\xmlNode{initialSeed}) is specified and set to reset on each use (\xmlNode{reseedEachIteration}) so that the Monte Carlo sampler can be used to compare the ROM against the  original model.  We use 100 samples (\xmlNode{limit}) to sample the ROM and the model, and then print and plot both data sets to compare them.
   \item \textbf{\textit{DataObjects}}:
     \xmlExample[rom,SparseGridCollocation]{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{DataObjects}
  In this block, five \textit{DataObjects} are defined:
  1) a PointSet named ``inputPlaceholder'' used as a placeholder input for the ROM sampling step,
  2) a PointSet named ``samplesModel'' to store the Code responses from Monte Carlo samples,
  3) a PointSet named ``samplesROM'' to store the ROM responses from Monte Carlo samples,
  4) a HistorySet named ``histories'' used to collect the samples needed to train the ROM, and
  5) a DataSet named ``rom\_stats'' to store information from the ROM.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure histories
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/SparseGrid/1-historyPlot_scatter-scatter.png}
  \caption{Plot of the training samples generated by the SparseGridCollocation sampling for variables $A,B,C,D$.}
  \label{fig:historiesSparseGridPlotScatter}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   \item \textbf{\textit{OutStreams}}:
     \xmlExample{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{OutStreams}
  In this block, the following Out-Stream types are constructed:
  \begin{itemize}
    \item \textit{Print}:
     \begin{itemize}
       \item named ``samplesModel'' connected with the \textit{DataObjects} \textbf{Entity} ``samplesModel''
                (\xmlNode{source})
       \item named ``samplesROM'' connected with the \textit{DataObjects} \textbf{Entity} ``samplesROM''
                (\xmlNode{source})
       \item named ``histories'' connected with the \textit{DataObjects} \textbf{Entity} ``histories'' (\xmlNode{source})
       \item named ``rom\_output'' connected with the \textit{ROM} \textbf{Entity} ``rom'' (\xmlNode{source}).
     \end{itemize}
      When these objects get used, all the information contained in the
      linked  \textit{DataObjects} are going
    to be exported in ether CSV files for DataObjects or XML files for ROMs (\xmlNode{type}).
    \item \textit{Plot}:
    \begin{itemize}
      \item named ``historyPlot'' connected with the  \textit{DataObjects}
      \textbf{Entity} ``histories''.  This plots the
      variable $range$ with respect to the input variables $velocity$ and $angle$.
      \item named ``samplesModelPlot3D'' connected with the
      \textit{DataObjects} \textbf{Entity} ``samplesModel''. This plot will draw the
      variables $range,time$ as Monte Carlo sampled on the Code.
      \item named ``samplesROMPlot3D'' connected with the
      \textit{DataObjects} \textbf{Entity} ``samplesROM''. This plot will draw the
      variables $range,time$ as Monte Carlo sampled on the ROM.
    \end{itemize}
  \end{itemize}
   \item \textbf{\textit{Steps}}:
     \xmlExample[rom,SparseGridCollocation]{framework/user_guide/ForwardSamplingStrategies/forwardSamplingSparseGrid.xml}{Steps}
  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure samples
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/SparseGrid/1-samplesModelPlot3D_scatter-scatter.png}
  \caption{Plot of validation samples generated by Monte Carlo sampling on the Code.}
  \label{fig:samplesSparseGridPlotModel}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
   Finally, the previously defined \textbf{Entities} can be combined in
   the \xmlNode{Steps} block.
   The following \xmlNode{Steps} have been defined:
   \begin{itemize}
     \item \xmlNode{MultiRun} named ``sample'', used to run the training
     samples of the driven code and
     collect the outputs in the \textit{DataObjects}.
     The \xmlNode{Sampler} is specified to communicate to the
     \textit{Step} that the driven code needs to
     be sampled through the Sparse Grid Collocation sampling strategy;
     \item \xmlNode{RomTrainer} named ``train'', used to train (i.e.,
     construct) the GaussPolynomial ROM. This step is essential if the
     user want to use the ROM in later steps;
     \item \xmlNode{MultiRun} named ``sampleModel'', used to run the
     Monte Carlo perturbed samples of the original Model for use in verification.  The results are
     collected in the \textit{samplesModel} \textit{DataObjects}.
     \item \xmlNode{MultiRun} named ``sampleROM'', used to run the
     Monte Carlo perturbed samples of the previously constructed ROM for use in verificaiton.  The results are
     collected in the \textit{samplesROM} \textit{DataObjects}.
     \item \xmlNode{IOStep} named ``rom\_stas'', used to dump rom-related information into \textit{DataObject },
     \item  \xmlNode{IOStep} named ``output\_print'', used to dump
     the ``histories'', ``samplesModel'' and ``samplesROM'' \textit{DataObjects}
     \textbf{Entity} in a CSV file,
     \item  \xmlNode{IOStep} named ``output\_plot'', used to
     plot the data and store it in the PNG file and
     on the screen.
   \end{itemize}
\end{enumerate}
 % As previously mentioned, Figure~\ref{fig:historiesSparseGridPlotScatter}
 % shows the evolution of the outputs $A,B,C,D$ under uncertainties.
 % Figures~\ref{fig:samplesSparseGridPlotModel} and
 % \ref{fig:samplesROMSparseGridPlot} show the final responses
 % of the sampling employed using the driven code and the ROM,
 % respectively.
 As it can be seen, the constructed ROM can accurately
 represent the response of the driven code. This example shows the
 potential of reduced order modeling, in general, and of the
 \textit{GaussPolynomialRom}, in particular.

  %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 %figure samples
 \begin{figure}[h!]
  \centering
  \includegraphics[scale=0.7]{../../tests/framework/user_guide/ForwardSamplingStrategies/gold/RunDir/SparseGrid/1-samplesROMPlot3D_scatter-scatter.png}
  \caption{Plot of validation samples generated by Monte Carlo sampling on the ROM.}
  \label{fig:samplesROMSparseGridPlot}
 \end{figure}
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%


\documentclass[11pt]{article}

\usepackage{fancyhdr}
\usepackage{geometry}

%margin
 \geometry{
 left=25mm,
 right=25mm,
 top=25mm,
 bottom=25mm,
 }

\pagestyle{fancy}
%\renewcommand{\headrulewidth}{0pt}
\lhead{Hadoop - Content based Search \& Retrieval}
\rhead{Problem Class Description}

\begin{document}

\noindent
\textbf{
	\large Assignment No 2 \\ \\
}

\textbf{
	Aim:}
Project problem statement feasibility assessment using NP Hard   NP complete or satisfiability issues  using modern algebra and/or relevant mathematical models. \\ \\ \\

\noindent
\textbf{Input:}  A set of input keywords taken as a search query  \\
\textbf{Output:} Question: Whether given recommendation is satisfiable or not? \\ \\ \\

\textbf{P Class Problem : }
\paragraph{}
Since the Application Programming Interface has a searching algorithm which works on map-reduce engine to retrieve the content from HDFS and return the result in the form of paragraph and with relevant contents with the link to download whole document or only a part of it. \\ \\ \\

\textbf{NP Class :}
\paragraph{}
The problem gets converted into NP Class when there is a verifier process to verify the content retrieved by the API . \\ \\ \\

\end{document}


\subsection{Identifying heuristics}

Generating heuristics for search. we can losen restriction to get a much simpler problem and rank moves by how good they are for loosened problem.

eg for for path to goal, assume can go directly from next place in a straight line.


% Copyright 2011-2015 David Hadka.  All Rights Reserved.
%
% This file is part of the MOEA Framework User Manual.
%
% Permission is granted to copy, distribute and/or modify this document under
% the terms of the GNU Free Documentation License, Version 1.3 or any later
% version published by the Free Software Foundation; with the Invariant Section
% being the section entitled "Preface", no Front-Cover Texts, and no Back-Cover
% Texts.  A copy of the license is included in the section entitled "GNU Free
% Documentation License".

\chapter{Advanced Topics}

\section{Configuring Hypervolume Calculation}
The hypervolume calculation is an important tool when comparing the performance of MOEAs.  This section details the available configuration options for the hypervolume calculation.

The hypervolume calculation computes the volume of the space dominated between the Pareto front and the nadir point.  The nadir point is set to the extremal objective values of the reference set plus some delta.  A non-zero delta is necessary to ensure such extremal values contribute a non-zero volume.  This delta is configurable by adding the following line to \file{global.properties}:

\begin{lstlisting}[language=Plaintext]
org.moeaframework.core.indicator.hypervolume_delta = 0.01
\end{lstlisting}

The hypervolume calculation is computationally expensive.  Use of the built-in hypervolume calculator may become prohibitive on Pareto fronts with $4$ or more objectives.  For this reason, it may be beneficial to use third-party hypervolume calculators instead.  A number of researchers have released C/C++ implementations of high-performance hypervolume calculators, including those listed below.

\begin{itemize}
  \item \webpage{http://ls11-www.cs.uni-dortmund.de/rudolph/hypervolume/start}
  \item \webpage{http://iridia.ulb.ac.be/~manuel/hypervolume/}
  \item \webpage{http://www.wfg.csse.uwa.edu.au/hypervolume/}\footnote{Some source code editing is necessary to modify the input and output format to be compatible with the MOEA Framework.}
\end{itemize}

Such hypervolume calculators can be used by the MOEA Framework by following two steps.  First, download and compile the desired hypervolume code.  This should result in an executable file, such as \file{hyp.exe}.  Second, configure the MOEA Framework to use this executable by adding a line similar to the following to the \file{global.properties} file.

\begin{lstlisting}[language=Plaintext]
org.moeaframework.core.indicator.hypervolume = hyp.exe {0} {1} {2} {3}
\end{lstlisting}

This property is specifying the executable and any required arguments.  The arguments are configurable by using the appropriate variable, such as \{0\}.  The complete list of available variables are shown in the table below.

\begin{center}
\begin{tabular}{ll}
  Variable & Description \\
  \hline
  \{0\} & Number of objectives \\
  \{1\} & Approximation set size \\
  \{2\} & File containing the approximation set \\
  \{3\} & File containing the reference point \\
  \{4\} & The reference point, separated by spaces
\end{tabular}
\end{center}

If all else fails, the hypervolume calculation can be disabled.  When disabled, the hypervolume will be reported as \java{NaN}.  To disable all hypervolume calculations, add the following line to \file{global.properties}:

\begin{lstlisting}[language=Plaintext]
org.moeaframework.core.indicator.hypervolume_enabled = false
\end{lstlisting}

\section{Storing Large Datasets}
When dealing with large datasets, proper data organization and management is key to avoiding headaches.  A number of tools are provided by the MOEA Framework for storing and manipulating large datasets.  The two key classes are the \java{ResultFileWriter} and \java{ResultFileReader}.  A result file is a collection of one or more approximation sets.  Each entry in the result file is the approximation set, including the decision variables and objectives for all solutions in the approximation set, and any additional metadata you provide.  Note that this approximation set does not contain any constraints, as only feasible solutions are written in a result file.

\subsection{Writing Result Files}

The \java{ResultFileWriter} class is used to write result files.  The example code below demonstrates running the UF1 problem and recording the approximation set at each generation.  In addition, two pieces of metadata are stored: the current number of objective function evaluations (NFE) and the elapsed time.

\begin{lstlisting}[language=Java]
Problem problem = null;
Algorithm algorithm = null;
ResultFileWriter writer = null;
long startTime = System.currentTimeMillis();

try {
  problem = ProblemFactory.getInstance().getProblem("UF1");
  algorithm = AlgorithmFactory.getInstance().getAlgorithm(
      "NSGAII", new Properties(), problem);

  try {
    writer = new ResultFileWriter(problem, new File("result.set"));

    //run the algorithm
    while (!algorithm.isTerminated() &&
        (algorithm.getNumberOfEvaluations() < 10000)) {
      algorithm.step(); //run one generation of the algorithm

      TypedProperties properties = new TypedProperties();
      properties.setInt("NFE", algorithm.getNumberOfEvaluations());
      properties.setLong("ElapsedTime", System.currentTimeMillis()-start);

      writer.append(new ResultEntry(algorithm.getResult(), properties));
    }
  } finally {
    //close the result file writer
    if (writer != null) {
      writer.close();
    }
  }
} finally {
  //close the problem to free any resources
  if (problem != null) {
    problem.close();
  }
}
\end{lstlisting}

\begin{important}
If the file you are saving already exists, the \java{ResultFileWriter} appends any new data to the end of the file.  If you do not want to append to any existing data, delete any old file first.
\end{important}

\subsection{Extract Information from Result Files}
The \java{ExtractData} command line utility is an extremely useful tool for extracting information from a result file.  It can extract any properties from the file as well as calculate specific performance indicators, and outputs this data in a clean, tabular format which can be read into spreadsheet software, such as LibreOffice Calc or Microsoft Excel.  When only extracting metadata, you need only specify the input file and the property keys to extract.  For instance, continuing the example from above, we can extract the \plaintext{NFE} and \plaintext{ElapsedTime} properties with the following command:

\begin{lstlisting}[language=Plaintext]
java org.moeaframework.analysis.sensitivity.ExtractData
    --problem UF1
    --input result.set
    NFE ElapsedTime
\end{lstlisting}

The output of this command will appear similar to:

\begin{lstlisting}[language=Plaintext]
#NFE ElapsedTime
100     125
200     156
300     172
400     187
500     203
...
\end{lstlisting}

Performance indicators can be calculated using one of the ``plus options.''  The options for the supported performance indicators include \plaintext{+hypervolume} for hypervolume, \plaintext{+generational} for generational distance, \plaintext{+inverted} for inverted generational distance, \plaintext{+epsilon} for additive $\epsilon$-indicator, \plaintext{+error} for maximum Pareto front error, \plaintext{+spacing} for spacing, and \plaintext{+contribution} for reference set contribution/coverage.  In addition, you must specify the problem, reference set, and optionally the $\epsilon$ values to use when calculating contribution.  For example:

\begin{lstlisting}[language=Plaintext]
java org.moeaframework.analysis.sensitivity.ExtractData
    --problem UF1
    --input result.set
    --reference ./pf/UF1.dat
    NFE ElapsedTime +hypervolume +epsilon +coverage
\end{lstlisting}

The added performance indicators will appear alongside the other properties:

\begin{lstlisting}[language=Plaintext]
#NFE ElapsedTime +hypervolume +epsilon +contribution
100     125          0.0      1.287951      0.0
200     156          0.0      1.149751      0.0
300     172          0.0      1.102796      0.0
400     187          0.0      1.083581      0.0
500     203          0.0      0.959353      0.0
...
\end{lstlisting}

Additional command line options allow you to format the output, such as removing the column header line or specifying the column separator character.

\section{Dealing with Maximized Objectives}
\label{sect:maximizing}
The MOEA Framework is setup to minimize objectives; it can not by itself maximize objectives.  This simplifies the program and increases its performance considerably.  By only allowing minimization objectives, the MOEA Framework can avoid the overhead of constantly determining the optimization direction whenever calculating the Pareto dominance relation.

This approach, however, puts the burden on the user to make the appropriate adjustments to their problem definition to allow maximization objectives.  The easiest way to allow maximization objectives is to negate the objective value, as demonstrated below:

\begin{lstlisting}[language=Java]
solution.setObjective(0, obj1);
solution.setObjective(1, -obj2); //negate the original objective value
\end{lstlisting}

By minimizing the negated objective value, we are maximizing the original objective value.  These negated objective values will be carried through to any output files produced by the MOEA Framework.  The help assist in managing these output files, version 1.13 includes the \java{Negater} command line utility.  The \java{Negater} tool processes any output file produced by the MOEA Framework and negates any specified objective.  For example, without the two objective example above, we can remove the negation in any output file with the following command.  Specifying a direction of 1 will negate the corresponding objective values in the processed file.

\begin{lstlisting}[language=Plaintext]
java org.moeaframework.analysis.sensitivity.Negater
    --direction 0,1
    output.set
\end{lstlisting}

\begin{important}
It is best to wait until all post-processing is complete before negating the objectives back to their original, maximized form as any calculations on the maximized form will be invalid.  You can always apply the \java{Negater} a second time to undo the change.  It is the responsibility of the user to manage their data files accordingly.
\end{important}

\section{Checkpointing}

The MOEA Framework provides checkpointing functionality.  As an algorithm is running, checkpoint files will be periodically saved.  The checkpoint file stores the current state of the algorithm.  If the run is interrupted, such as during a power outage, the run can be resumed at the last saved checkpoint.  The \texttt{setCheckpointFile} sets the file location for the checkpoint file, and \texttt{checkpointEveryIteration} or \texttt{setCheckpointFrequency} control how frequently the checkpoint file is saved.

Resuming a run from a checkpoint occurs automatically.  If the checkpoint file does not exist, a run starts from the beginning.  However, if the checkpoint file exists, then the run is automatically resumed at that checkpoint.  For this reason, care must be taken when using checkpoints as they can be a source of confusion for new users.  For instance, using the same checkpoint file from an unrelated run can cause unexpected behavior or an error.  For this reason, checkpoints are recommended only when solving time-consuming problems.

The code snippet below demonstrates the use of checkpointing.

\begin{lstlisting}[language=Java]
NondominatedPopulation result = new Executor()
		.withProblem("UF1")
		.withAlgorithm("NSGAII")
		.withMaxEvaluations(1000000)
		.checkpointEveryIteration()
		.withCheckpointFile(new File("UF1_NSGAII.chkpt"))
		.run();
\end{lstlisting}

\begin{important}
Checkpoint files are never deleted by the MOEA Framework.  Each time you run this example, it will resume from its last save point.  If you want to run this example from the beginning, you must delete the checkpoint file manually.  In this example, the checkpoint file is saved in the \folder{\moeaframework} folder.
\end{important}

\section{Referencing the Problem}
Once a new problem is defined in Java, it can be referenced by the MOEA Framework in a number of ways.  This section details the various methods for referencing problems.

\subsection{By Class}
The \class{Executor}, \class{Instrumenter} and \class{Analyzer} classes introduced in \chptref{chpt:executor} all accept direct references to the problem class using the \java{withProblemClass} method.  For example, following the previous example with the Kursawe problem, we can optimize this problem with the following code:

\begin{lstlisting}[language=Java]
new Executor()
		.withProblemClass(Kursawe.class)
		.withAlgorithm("NSGAII")
		.withMaxEvaluations(10000)
		.run();
\end{lstlisting}

Note how the Kursawe problem is specified by name followed by \java{.class}.  This passes a direct reference to the Kursawe class we created in the previous chapter.

Problems can also define constructors with arguments.  For example, consider a problem that needs to load data from a file.  For this to work, define a constructor in the problem class that accepts the desired inputs.  In this case, our constructor would be called \java{public ProblemWithArgument(File dataFile) { ... }}.  You can then solve this problem as shown below.

\begin{lstlisting}[language=Java]
new Executor()
		.withProblemClass(ProblemWithArgument.class, new File("inputFile.txt"))
		.withAlgorithm("NSGAII")
		.withMaxEvaluations(10000)
		.run();
\end{lstlisting}

\subsection{By Class Name}
As of version 1.11, problems can be referenced by their fully-qualified class name.  The fully-qualified class name includes the Java package in which the class is defined.  For example, the Schaffer problem's fully-qualified class name is \classpath{org.moeaframework.problem.misc.Schaffer}.  The problem \emph{must} have an empty (no argument) constructor.

The class name can be used to run problems anywhere the MOEA Framework accepts a string representation of the problem.  This includes but is not limited to
\begin{enumerate}
  \item The \java{withProblem} method in \class{Executor}, \class{Instrumenter} and \class{Analyzer}
  \item Any command line utilities with a problem argument
  \item The problem selection combo box in the MOEA Diagnostic Tool
\end{enumerate}

\subsection{By Name}

The MOEA Framework also provides the option to reference problems by name.  There are two advantages to using this approach.  First, this approach allows the use of short, meaningful names.  For example, rather than specifying the fully-qualified class name for the Schaffer problem, \classpath{org.moeaframework.problem.misc.Schaffer}, one can use the name \class{Schaffer} instead.  Second, a reference set for named problems can optionally be defined.  This reference set will be automatically used wherever a reference set is required.  Without this, a reference set must be manually specified by the user or programmer each time it is required.

The disadvantage to this approach is that some additional configuration is necessary to provide the mapping from the problem name to the problem class.  As such, this approach is recommended for third-party library developers who are developing new problems to be used with the MOEA Framework.  The remainder of this section describes two such methods for referencing problems by name.

The problem name can be used to run problems anywhere the MOEA Framework accepts a string representation of the problem.  This includes but is not limited to
\begin{enumerate}
  \item The \texttt{withProblem} method in \class{Executor}, \class{Instrumenter} and \class{Analyzer}
  \item Any command line utilities with a problem argument
  \item The problem selection combo box in the MOEA Diagnostic Tool
\end{enumerate}

\subsection{With a ProblemProvider}
The first way to reference problems by name is to define a \class{ProblemProvider}.  The \class{ProblemProvider} uses the Java Service Provider Interface (SPI).  The SPI allows the MOEA Framework to load all available providers from the classpath.  This approach allows third-party software vendors to distribute compiled JAR files containing \class{ProblemProvider} instances that are automatically loaded by the MOEA Framework.  To create a new \class{ProblemProvider}, first create a subclass of the \class{ProblemProvider} class.  To do so, you must define two methods:
\begin{enumerate}
  \item \java{Problem getProblem(String name)}
  \item \java{NondominatedPopulation getReferenceSet(String name)}
\end{enumerate}

Both methods are provided the problem name as the argument.  The \texttt{getProblem} method should return a new instance of the specified problem, or \java{null} if the provider does not support the given problem name.  Likewise, the \java{getReferenceSet} method should return the reference set of the specified problem if one is available, or \java{null} otherwise.  Returning \java{null} when the problem is not supported by the provider is important, as the Java SPI will scan all available \class{ProblemProvider} instances until it finds a suitable provider.

\begin{lstlisting}[language=Java]
import org.moeaframework.core.NondominatedPopulation;
import org.moeaframework.core.Problem;
import org.moeaframework.core.spi.ProblemProvider;

public class ExampleProblemProvider extends ProblemProvider {

	public Problem getProblem(String name) {
		if (name.equalsIgnoreCase("kursawe")) {
			return new Kursawe();
		} else {
			return null;
		}
	}

	public NondominatedPopulation getReferenceSet(String name) {
		return null;
	}

}
\end{lstlisting}

Lastly, a special configuration file used by the SPI must be created.  The file is located at \file{META-INF/services/org.moeaframework.core.spi.ProblemProvider}.  Each line of this file must contain the fully-qualified class name for each of the \class{ProblemProvider}s being introduced.  When bundling the compiled class files into a JAR, be sure that this configuration file is also copied into the JAR.

Once packaged as a JAR, the provider is ready to be used.  Place the JAR on the classpath used by the MOEA Framework.  Once on the classpath, the Java SPI mechanism used by the MOEA Framework will be able to scan and load all providers contained in all available JAR files.

\subsection{With the \texttt{global.properties} File}
The second way to reference problems by name is to add the problem definition to the \file{global.properties} file.  This \file{global.properties} file contains the configuration options for the MOEA Framework.  This file usually accompanies a MOEA Framework distribution, but in the event it does not exist, you can just create a new empty text file.  Adding a new problem is as simple as adding the following two lines to \file{global.properties}:

\begin{lstlisting}[language=Plaintext]
org.moeaframework.problem.problems = Kursawe
org.moeaframework.problem.Kursawe.class = Kursawe
\end{lstlisting}

Line 1 lists all problems configured in the \file{global.properties} file.  The string provided here becomes the problem name.  This is the name you would subsequently provide to any of the MOEA Framework tools to instantiate the problem.  More than one problem can be specified by separating the problem names with commas.

Line 2 identifies the class for the specified problem.  Note that this entry follows the naming convention \plaintext{org.moeaframework.problem.NAME.class = value}.  The \plaintext{NAME} used must match the problem name defined in line 1.  The value is the fully-qualified Java classname.  In this case, the class is located in the default package.  If this class were located, for example, in the package \classpath{foo.bar}, the value must be set to \class{foo.bar.Kursawe}.

The reference set file for the problem can be optionally specified as well.  If a reference set is available for the problem, add the following line to \file{global.properties}:

\begin{lstlisting}[language=Plaintext]
org.moeaframework.problem.Kursawe.referenceSet = kursawe.ref
\end{lstlisting}


\section{NEB}
\label{NEB}
\begin{ipifield}{}%
{Contains the required parameters for performing nudged elastic band (NEB) calculations}%
{}%
{\ipiitem{mode}%
{The geometry optimization algorithm to be used}%
{default: `lbfgs'; data type: string; options: `sd', `cg', `bfgs', `lbfgs'; }%
}
\begin{ipifield}{biggest\_step}%
{The maximum step size for (L)-BFGS line minimizations.}%
{default:  100.0 ; data type: float; }%
{}
\end{ipifield}
\begin{ipifield}{scale\_lbfgs}%
{Scale choice for the initial hessian.
                                            0 identity.
                                            1 Use first member of position/gradient list.
                                            2 Use last  member of position/gradient list.}%
{default:  2 ; data type: integer; }%
{}
\end{ipifield}
\begin{ipifield}{corrections\_lbfgs}%
{The number of past vectors to store for L-BFGS.}%
{default:  5 ; data type: integer; }%
{}
\end{ipifield}
\begin{ipifield}{tolerances}%
{Generic input value}%
{}%
{}
\end{ipifield}
\begin{ipifield}{glist\_lbfgs}%
{List of previous gradient differences for L-BFGS, if known.}%
{default:  [ ] ; data type: float; }%
{\ipiitem{shape}%
{The shape of the array.}%
{default:  (0,) ; data type: tuple; }%
\ipiitem{mode}%
{If 'mode' is 'manual', then the array is read from the content of 'cell' takes a 9-elements vector containing the cell matrix (row-major). If 'mode' is 'abcABC', then 'cell' takes an array of 6 floats, the first three being the length of the sides of the system parallelopiped, and the last three being the angles (in degrees) between those sides. Angle A corresponds to the angle between sides b and c, and so on for B and C. If mode is 'abc', then this is the same as for 'abcABC', but the cell is assumed to be orthorhombic. 'pdb' and 'chk' read the cell from a PDB or a checkpoint file, respectively.}%
{default: `manual'; data type: string; options: `manual', `file'; }%
}
\end{ipifield}
\begin{ipifield}{spring}%
{Uniform or variable spring constants along the elastic band}%
{}%
{}
\end{ipifield}
\begin{ipifield}{old\_direction}%
{The previous direction.}%
{default:  [ ] ; data type: float; }%
{\ipiitem{shape}%
{The shape of the array.}%
{default:  (0,) ; data type: tuple; }%
\ipiitem{mode}%
{If 'mode' is 'manual', then the array is read from the content of 'cell' takes a 9-elements vector containing the cell matrix (row-major). If 'mode' is 'abcABC', then 'cell' takes an array of 6 floats, the first three being the length of the sides of the system parallelopiped, and the last three being the angles (in degrees) between those sides. Angle A corresponds to the angle between sides b and c, and so on for B and C. If mode is 'abc', then this is the same as for 'abcABC', but the cell is assumed to be orthorhombic. 'pdb' and 'chk' read the cell from a PDB or a checkpoint file, respectively.}%
{default: `manual'; data type: string; options: `manual', `file'; }%
}
\end{ipifield}
\begin{ipifield}{old\_force}%
{The previous force in an optimization step.}%
{dimension: force; default:  [ ] ; data type: float; }%
{\ipiitem{units}%
{The units the input data is given in.}%
{default: `automatic'; data type: string; }%
\ipiitem{shape}%
{The shape of the array.}%
{default:  (0,) ; data type: tuple; }%
\ipiitem{mode}%
{If 'mode' is 'manual', then the array is read from the content of 'cell' takes a 9-elements vector containing the cell matrix (row-major). If 'mode' is 'abcABC', then 'cell' takes an array of 6 floats, the first three being the length of the sides of the system parallelopiped, and the last three being the angles (in degrees) between those sides. Angle A corresponds to the angle between sides b and c, and so on for B and C. If mode is 'abc', then this is the same as for 'abcABC', but the cell is assumed to be orthorhombic. 'pdb' and 'chk' read the cell from a PDB or a checkpoint file, respectively.}%
{default: `manual'; data type: string; options: `manual', `file'; }%
}
\end{ipifield}
\begin{ipifield}{qlist\_lbfgs}%
{List of previous position differences for L-BFGS, if known.}%
{default:  [ ] ; data type: float; }%
{\ipiitem{shape}%
{The shape of the array.}%
{default:  (0,) ; data type: tuple; }%
\ipiitem{mode}%
{If 'mode' is 'manual', then the array is read from the content of 'cell' takes a 9-elements vector containing the cell matrix (row-major). If 'mode' is 'abcABC', then 'cell' takes an array of 6 floats, the first three being the length of the sides of the system parallelopiped, and the last three being the angles (in degrees) between those sides. Angle A corresponds to the angle between sides b and c, and so on for B and C. If mode is 'abc', then this is the same as for 'abcABC', but the cell is assumed to be orthorhombic. 'pdb' and 'chk' read the cell from a PDB or a checkpoint file, respectively.}%
{default: `manual'; data type: string; options: `manual', `file'; }%
}
\end{ipifield}
\begin{ipifield}{invhessian\_bfgs}%
{Approximate inverse Hessian for BFGS, if known.}%
{default:  [ ] ; data type: float; }%
{\ipiitem{shape}%
{The shape of the array.}%
{default:  (0, 0) ; data type: tuple; }%
\ipiitem{mode}%
{If 'mode' is 'manual', then the array is read from the content of 'cell' takes a 9-elements vector containing the cell matrix (row-major). If 'mode' is 'abcABC', then 'cell' takes an array of 6 floats, the first three being the length of the sides of the system parallelopiped, and the last three being the angles (in degrees) between those sides. Angle A corresponds to the angle between sides b and c, and so on for B and C. If mode is 'abc', then this is the same as for 'abcABC', but the cell is assumed to be orthorhombic. 'pdb' and 'chk' read the cell from a PDB or a checkpoint file, respectively.}%
{default: `manual'; data type: string; options: `manual', `file'; }%
}
\end{ipifield}
\begin{ipifield}{climb}%
{Use climbing image NEB}%
{default:  False ; data type: boolean; }%
{}
\end{ipifield}
\begin{ipifield}{endpoints}%
{Geometry optimization of endpoints}%
{}%
{}
\end{ipifield}
\begin{ipifield}{ls\_options}%
{Options for line search methods. Includes:
                              tolerance: stopping tolerance for the search,
                              grad\_tolerance: stopping tolerance on gradient for
                              BFGS line search,
                              iter: the maximum number of iterations,
                              step: initial step for bracketing,
                              adaptive: whether to update initial step.
                              }%
{}%
{}
\end{ipifield}
\end{ipifield}


\documentstyle[12pt,fullpage,misc,titlepage]{report}

\newcommand {\progname}[1] {\mbox {\bf {\sf #1}}}
\newcommand {\Hii} {\mbox {H$_{ii}$}}
\newcommand {\Hiip} {\mbox {H$_{ii}^{(k+1)}$}}
\newcommand {\Hiik} {\mbox {H$_{ii}^{(k)}$}}

\newcommand {\pvar}[1] {\mbox {\sl #1}}

\newenvironment{sampfile}
{ \baselineskip=12pt
\begin{verbatim}}
{\end{verbatim}}

\begin{document}

\begin{center}
{\huge Charge Iteration in \calcprog }

{\large Greg Landrum}

{\large \today}

\end{center}

\baselineskip = 20pt

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Goals and Problems}

The basic idea of charge iteration is to use calculated charges to
adjust the diagonal elements of the hamiltonian (the \Hii's) in a
self-consistent manner.  The main reason I see for doing this is to
have parameters that are reasonable for a given system that are
generated in a well defined manner (instead of having a different {\em
ad hoc} set of parameters for every calculation).  The way this is
done is using the equation:
\begin{equation}
\Hiip = A (Q^{(k)})^{2} + B Q^{(k)} + C
\label{eqn:basic_chg_it}
\end{equation}
where \Hiip\ is the new value of \Hii\ for step $k+1$, $A,B$ and $C$ are
parameters and $Q^{(k)}$ is the net charge on the atom calculated
using the value of $\Hii^{(k)}$.

The traditional problem with charge iteration, as I see it, is that
the self consistent calculations do not always converge in a timely
fashion.  Some don't converge at all.  Since the form of the
expression for \Hiip (Equation \ref{eqn:basic_chg_it}) seems simple
and unlikely to lead to numeric explosions, I would say that the
convergence problems may be due to the implementation of the charge
iteration procedure.

For the sake of clarity (and because I haven't implemented the other
scheme), I'm going to limit myself to only discussing charge iteration
using a single configuration (a single set of parameters).

\section{The Old Way}

The implementation of charge iteration in \progname{ICON}, which is
what we've used, is pretty complicated.  Here's how it works.

The underlying form is that of equation \ref{eqn:basic_chg_it}, but
the calculation of
the value of $Q$ is complicated.  First of all, the occupancy of each
orbital ($p_i$ where $i$ indexes the orbital) is calculated using a
damping scheme:
\begin{equation}
p_i^{(k+1)}(initial) = p_i^{(k)}(initial) + \lambda \Delta p_i^{(k)}
\label{eqn:orb_occup_def}
\end{equation}
again $i$ indexes the orbital, $k$ indicates which step we're on,
$(initial)$ refers to the occupancy at the beginning of the step (not
the occupancy calculated using the results from this step), $\lambda$
is a step size, and $\Delta p_i^{(k)}$ is defined as:
\begin{equation}
\Delta p_i^{(k)} = p_i^{(k)}(final) - p_i^{(k)}(initial)
\label{eqn:delta_def}
\end{equation}
In equation \ref{eqn:delta_def} $(final)$ refers to the orbital
occupancy which was calculated in this step.

These orbital occupancies are used to calculate the net charge on each
atom $\nu$:
\begin{equation}
Q_{\nu}^{(k+1)} = \sum_{i\ on\ \nu} p_i^{(k+1)}(initial)
\label{eqn:old_net_chg_def}
\end{equation}
and these $Q_{\nu}^{(k+1)}$'s are used to generate the \Hiip's:
\begin{equation}
\Hiip = A_i (Q_{\nu}^{(k+1)})^2 + B_i Q_{\nu}^{(k+1)} + C_i
\label{eqn:Hiip_def}
\end{equation}

The new \Hiip's are used to generate a new hamiltonian and the process
repeats until some convergence criterion is met.

The presence of the $\lambda$ (step size) in equation
\ref{eqn:orb_occup_def} is to provide some damping for the adjustment
(note that $\lambda < 1$).  This lessens problems with \Hii\ values
``sloshing'' between 2 values.
In \progname{ICON}, the value of $\lambda$ is adjusted as the
calculation proceeds.  This is supposed to speed convergence.  The
formula for adjusting $\lambda$ is fairly complicated, so I'm not
going to go into it here.

\section{The New Way}

The way charge iteration is currently done in \calcprog\ is a lot
simpler and it doesn't seem to have bad convergence problems (of
course, it hasn't been extensively tested yet).  I've
taken a very ``first order'' approach.  Instead of damping the changes
in orbital occupations, I damp the changes in \Hii.
So the orbital occupations are not played around with, i.e.:
\begin{equation}
p_i^{(k+1)}(initial) = p_i^{(k)}(final)
\end{equation}
Equation \ref{eqn:old_net_chg_def} is still used to generate the net
charges.
Then, an undamped new value of \Hii\ is calculated:
\begin{equation}
\Hii^{'} = A_i (Q_{\nu}^{(k+1)})^2 + B_i Q_{\nu}^{(k+1)} + C_i
\label{eqn:Hiinew_def}
\end{equation}
and \Hiip\ is
calculated as follows:
\begin{equation}
\Hiip = \Hiik + \lambda (\Hii^{'} - \Hiik)
\end{equation}

That's it.  It's very first order, but it seems to work reasonably
well.  It's worth testing this whole thing some more.

\end{document}


\graphicspath{{Appendix/appendix_figures/}}

\chapter{Characterisation of MOFA factors in the scNMT-seq gastrulation data set} \label{appendix:mofa_gastrulation}

% TO REWRITE
\begin{figure}[H]
	\centering
	\includegraphics[width=0.95\linewidth]{mofa_gastrulation_factor3}
	\caption[]{\textbf{Characterisation of MOFA Factor 3 as antero-posterior axial patterning and mesoderm maturation.} \\
	(a) Beeswarm plot of Factor 3 values, grouped and coloured by cell type. The mesoderm cells are subclassified into nascent and mature mesoderm. \\
	(b) RNA expression weights for Factor 3. Genes with large positive weights increase expression in the positive factor values (more anterior), whereas genes with negative weights increase expression in the negative factor values (more posterior).\\
	(c) Same beeswarm plots as in (a), coloured by the relative RNA expression of genes with the highest positive (top) or negative (bottom) weight.\\
	(d) Gene set enrichment analysis of the gene weights of Factor 3. Shown are the top most significant pathways from MSigDB C2 \cite{Subramanian2005,Ashburner2000}.
	}
	\label{fig:mofa_gastrulation_factor3}
\end{figure}

% TO REWRITE
\begin{figure}[H]
	\centering
	\includegraphics[width=0.95\linewidth]{mofa_gastrulation_factor4}
	\caption[]{\textbf{Characterisation of MOFA Factor 4 as notochord formation.} \\
		(a) Beeswarm plot of Factor 4 values, grouped and coloured by cell type. The endoderm cells are subclassified into notochord (dark green) and not notochord (green) (see Figure S2). \\
		(b) RNA expression weights for Factor 4. Genes with large positive weights increase expression in the positive factor values (endoderm cells), whereas genes with negative weights increase expression in the negative factor values (notochord cells).\\
		(c) Same beeswarm plots as in (a), coloured by the relative RNA expression of genes with the highest negative weight (notochord markers).
	}
	\label{fig:mofa_gastrulation_factor4}
\end{figure}

% TO REWRITE
\begin{figure}[H]
	\centering
	\includegraphics[width=0.95\linewidth]{mofa_gastrulation_factor5}
	\caption[]{\textbf{Characterisation of MOFA Factor 5 as mesoderm patterning.} \\
	(a) Beeswarm plot of Factor 5 values, grouped and coloured by cell type. \\
	(b) RNA expression weights for Factor 5. A higher absolute value indicates higher feature importance.\\
	(c) Same beeswarm plots as in (a), coloured by the relative RNA expression of genes with the highest weight on this factor.}
	\label{fig:mofa_gastrulation_factor5}
\end{figure}

% TO REWRITE
\begin{figure}[H]
	\centering
	\includegraphics[width=0.95\linewidth]{mofa_gastrulation_factor6}
	\caption[]{\textbf{Characterisation of MOFA Factor 6 as cell cycle.} \\
	(a) Beeswarm plot of Factor 6 values, grouped by cell type and coloured by infered cell cycle state using \textit{cyclone}\cite{Scialdone2015}.\\
	(b) RNA expression weights for Factor 6. Genes with large positive weights increase expression in the positive factor values (G1/S phase), whereas genes with negative weights increase expression in the negative factor values (G2/M phase).}
	\label{fig:mofa_gastrulation_factor6}
\end{figure}


\LoadClass[comfy]{mathmx}
\addbibresource{hpdefbib.bib}

\begin{titlepage}
    \sffamily
    \begin{center}
        \Huge
        {\textbf{\color{clrsec}Pokemon\\}}
        \vspace{0.5cm}
        \huge
        {\textit{\color{clrssec}
            Optimizing EV Distribution for HP and a Given Defense\\
        }}
        \vspace{1.5cm}
        {\color{clrsssec}Michael Xiong}
    \end{center}
\end{titlepage}
\begin{document}
\section{Introduction}
\section{Derivation}
Stat \cite{BulbStat} \cite{BulbDmg}
\section{Simplification for Level 100}
\section{Simplification for Level 50}
\section{Sample Calculation}
\printbibliography
\end{document}


% !TEX root = ../../../proposal.tex
\ifext
\subsection{Lessons for protocol design}
A natural question is to ask whether SSLv3 or later versions of TLS could also be vulnerable.
Our attack exploits two properties of the \ssltwo protocol:

\paragraph{Server authenticates first.}
First, the fact that in \ssltwo the server responds to the \texttt{ClientMasterKey} message before the client proves it has knowledge of the RSA plaintext, provides a direct message side channel. In SSLv3 and later, the client must demonstrate knowledge of the RSA plaintext first via a valid \texttt{ClientFinished} message before the server sends a message derived from the RSA plaintext.  In order to perform a similar attack in this case, the client would need to perform an online brute-force attack\ifext, significantly increasing the workload\fi.

We characterize this behavior of \ssltwo as a protocol vulnerability and not an implementation vulnerability, although this behavior is not rigorously determined by the standard itself.  The standard's presentation of message ordering is contradictory: the prose states that the \texttt{ServerVerify} message is sent immediately after the server receives the \texttt{ClientMasterKey} message, while the diagrams in Section 5.2, "Typical Protocol Message Flow", depict the server waiting for \texttt{ClientFinished} message before sending its own \texttt{ServerVerify}.  The three widely-used implementations of the protocol that we examined, OpenSSL, Microsoft IIS, and NSS, all took the former interpretation, and responded immediately with a \texttt{ServerVerify} message after the \texttt{ClientMasterKey}, rendering them vulnerable in this respect.

\paragraph{Short secrets.} Second, \ssltwo allows RSA plaintexts that are short enough to be vulnerable to a feasible-time brute force search.  For export ciphers, the unpadded RSA plaintext is five bytes long.  In SSLv3 and later versions of TLS, the RSA plaintexts and \pms length is 48 bytes, even for export ciphers with 40-bit strength.  For later protocol versions, an attacker can perform a brute-force search over the derived 40-bit key if a client negotiates an export cipher suite, but the 48-byte \pms length appears to prevent an attacker from escalating the weakness of the export cipher strength into a similar protocol vulnerability.
\fi

\subsection{Implications for modern protocols}
Although the protocol flaws in SSLv2 enabling DROWN are not present in recent TLS versions, many modern protocols meet a subset of the requirements to be vulnerable to a DROWN-style attack. For example:
\begin{enumerate}
	\item RSA key exchange. TLS 1.2~\cite{rfc5246} allows this.
	\item Reuse of server-side nonce by the client. QUIC~\cite{quic-langley-2014} allows this.
	\item Server sends a message encrypted with the derived key before the client. QUIC, TLS 1.3~\cite{rfc8446}, and TLS False Start~\cite{rfc7918} do this.
	\item Deterministic cipher parameters are generated from the \pms and nonces. This is the case for all TLS stream ciphers and TLS 1.0 block ciphers.
\end{enumerate}

\if0
When all three properties are combined, a natural adaptation of our attack presents itself.
The attacker obtains a Bleichenbacher oracle by connecting to the server twice with the same RSA ciphertext and the same server-side nonce, and comparing the messages sent by the server.
If the RSA ciphertext is PKCS conformant, the two messages will be identical.
Otherwise, they will differ.
Note that we also assumed that all symmetric cipher parameters, including IVs for block ciphers, are deterministically generated from the \pms and nonces; this is the case for TLS 1.0.
If that is not the case, the attacker can choose a stream cipher.
\fi

DROWN has a natural adaptation when all three properties are present. The attacker exposes a Bleichenbacher oracle by connecting to the server twice with the identical RSA ciphertexts and server-side nonces. If the RSA ciphertext is PKCS conformant, the server will respond with identical messages across both connections; otherwise they will differ.

\looseness=-1

\ifext
% NA: I'm pretty sure the following argument is wrong, after discussing this with Juraj.
% Basically, even if the attacker correctly guesses the encryption and MAC keys,
% he needs to also guess the *contents* of the ClientFinished message.
% The length of this content is independent of the chosen MAC and cipher, and is usually unfeasibly long to guess.
%
% Even if the third property above does not hold, an attacker may reduce the session strength to the weakest symmetric cipher plus the weakest MAC supported by the server.
% The attacker proceeds as follows:
% \begin{itemize}
%	\item Choose arbitrary server and client nonces, $r_s$ and $r_c$\ifext, which will be used throughout the attack\fi.
	%\item Connect to the server with $c$ as the RSA ciphertext, $r_s$ and $r_c$ as the nonces, and choose the symmetric cipher and MAC with the smallest key size out of those supported. Denote these key sizes $L_1$ and $L_2$ respectively.
%	\item Generate random symmetric encryption and MAC keys of these sizes, denoted by $k_1$ and $k_2$ respectively, and hope they are identical to the correct keys computed by the server.  The probability that both $k_1$ and $k_2$ are identical to the correct keys is $2^{-(L_1 + L_2)}$.
%	\item Send a \texttt{Finished} message encrypted and MACed using $k_1$ and $k_2$.
%	If the RSA ciphertext was valid, the same keys $k_1$ and $k_2$ will produce two identical \texttt{ServerFinished} messages in two TLS handshakes. Otherwise, the two \texttt{ServerFinished} message will be invalid.
%\end{itemize}
\fi

\if0
% Really not sure what this has to do with anything...
An attacker can use False Start to cause a victim client to perform TLS handshakes using RSA for key exchange\ifext, and send secret application layer data after these handshakes\fi, even if the server supports other key exchange methods which provide Perfect Forward Secrecy. The attacker masquerades as the server and indicates support for RSA key exchange only. The client will then handshake using RSA, and send application layer data, before the server authenticates by sending the \texttt{Finished} message. The False Start standard indeed discourages the use of RSA for key exchange, but does not explicitly forbid it, leaving the security of the protocol dependent on correct choices in the client configuration. Our attacks show that relying on such assumptions is extremely brittle protocol design.
% nothing in DROWN is a client flaw...
\fi

\subsection{Lessons for key reuse}

DROWN illustrates the cryptographic principle that keys should be single use.
Often, this principle is primarily applied to keys that are used to both sign
and decrypt, but DROWN illustrates that using keys \emph{for different protocol
versions} can also be a serious security risk.
Unfortunately, there is no widely supported way to pin X.509 certificates to specific
protocols. While using per-protocol certificates may help defend against
passive attacks, an active attacker could still leverage any certificate with a
matching name.

\subsection{Harms from obsolete cryptography}

Recent years have seen a significant number of serious attacks exploiting
outdated and obsolete cryptography. Many protocols and cryptographic primitives
that were demonstrated to be weak decades ago are surprisingly common in
real-world systems.

% BEAST Lucky13 TLS truncation

DROWN exploits a modification of an 18-year-old attack against a combination of protocols and ciphers that have long been superseded by better options: the \ssltwo protocol, export cipher suites, and PKCS \#1 v1.5 RSA padding. In fact, support for RSA as a key exchange method, including the use of PKCS \#1 v1.5, is mandatory even for TLS 1.2. The attack is made more severe by implementation flaws in rarely used code.

Our work serves as yet another reminder of the importance of removing
deprecated technologies before they become exploitable vulnerabilities. In
response to many of the vulnerabilities listed above, browser vendors have
been aggressively warning end users when TLS connections are negotiated with
unsafe cryptographic parameters, including SHA-1 certificates, small RSA and
Diffie-Hellman parameters, and SSLv3 connections. This process is currently
happening in a piecemeal fashion, primitive by primitive. Vendors and
developers rightly prioritize usability and backward compatibility in
standards, and are willing to sacrifice these only for practical attacks.
This approach works less well for cryptographic vulnerabilities, where the
first sign of a weakness, while far from being practically exploitable, can
signal trouble in the future. Communication issues between academic
researchers and vendors and developers have been voiced by many in the
community, including Green~\cite{green-2015} and Jager
et~al.\@~\cite{jager-2013}.

The long-term solution is to proactively remove these obsolete technologies.
There is movement towards this already: TLS 1.3 has entirely removed RSA key
exchange and has restricted Diffie-Hellman key exchange to a few groups large
enough to withstand cryptanalytic attacks long in the future. The CA/Browser
forum will remove support for SHA-1 certificates this year. Resources such as
the SSL Labs SSL Reports have gathered information about best practices and
vulnerabilities in one place, in order to encourage administrators to make
the best choices.

\subsection{Harms from weakening cryptography}

Export-grade cipher suites for TLS deliberately weakened three primitives to
the point that they are now broken even to enthusiastic amateurs: 512-bit RSA
key exchange, 512-bit Diffie-Hellman key exchange, and 40-bit symmetric
encryption. All three deliberately weakened primitives have been cornerstones
of high-profile attacks: FREAK exploits export RSA, Logjam exploits export
Diffie-Hellman, and now DROWN exploits export symmetric encryption.

Like FREAK and Logjam, our results illustrate the continued harm that a
legacy of deliberately weakened export-grade cryptography inflicts on the
security of modern systems, even decades after the regulations influencing
the original design were lifted. The attacks described in this paper are
fully feasible against export cipher suites today. The technical debt induced
by cryptographic ``front doors'' has left implementations vulnerable for
decades. With the slow rate at which obsolete protocols and primitives fade
away, we can expect some fraction of hosts to remain vulnerable for years to
come.


The id number follow the scheme described in D4.2.1-SPEC (Table 3)The base URI for the SPARQL-MM vocabulary is
\texttt{http://linkedmultimedia.org/sparql-mm/ns/2.0.0/function#}.
When abbreviating terms the suggested prefix is \texttt{mm}.
Each function in this function set has a URI constructed by appending a term name to the vocabulary URI. For example:
\texttt{http://linkedmultimedia.org/sparql-mm/ns/2.0.0/function#area}.
There are machine readable function description using \textit{SPARQL Extension Description Vocabulary}\footurl{http://www.ldodds.com/schemas/sparql-extension-description/} e.g. in RDF/XML\footurl{https://raw.githubusercontent.com/tkurz/sparql-mm/master/ns/1.0.0/function/index.rdf}.
%
\subsubsection*{Spatial Relations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:intersects\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1 has at least one common point with p2, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:within\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape contains all points of p2.shape an p1.shape.edge has not point in common with p2.shape.edge, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:above\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is above p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:below\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is below p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:coveredBy\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & is the inverse function to covers.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:covers\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if all points of p1.shape are points of p2.shape, else false. \\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:crosses\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape and p2.shape have common points and p1.shape.edge and p2.shape.edge has common points, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:leftAbove\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is left above p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:leftBelow\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is left below p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:leftBeside\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is left beside p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:rightAbove\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is right above p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:rightBelow\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is right below p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:rightBeside\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true p1 if is right beside p2 (based on model m), else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialContains\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape contains p2.shape\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialDisjoint\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true is p1.shape has no common points with p2.shape, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialEquals\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape == p2.shape, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialOverlaps\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape and p2.shape have common points, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:touches\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns true if p1.shape.edge has at least one common point with p2.shape.edge and p1.shape.interior has no common point with p2.shape.interior, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{Spatial Aggregations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialBoundingBox\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with spatial fragment out of existing resources p1 and p2, so that x = min( p1.x, p2.x ) and y = min( p1.y, p2.y ) and w = max( p1.x + p1.w, p2.x + p2.w ) and h = max( p1.y + p1.h, p2.y + p2.h ).\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialIntersection\\
\hline Properties & \textit{SpatialEntity}, \textit{SpatialEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with spatial fragment out of existing resources p1 and p2, so that x = max( p1.x, p2.x ) and y = max( p1.y, p2.y ) and w = min( p1.x + p1.w, p2.x + p2.w ) - max( p1.x, p2.x ) and h = min( p1.y + p1.h, p2.y + p2.h ) - max( p1.y, p1.x )\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{Spatial Accessors}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:area\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns the area of BoundingBox of a shape, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:center\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns the center of a BoundingBox of a shape, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:height\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns the height of a shape, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:spatialFragment\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns a string representation of a spatial fragment.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:hasSpatialFragment\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns true is value is or includes a spatial fragment.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:width\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns the width of a shape, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:xy\\
\hline Properties & \textit{SpatialEntity} \\
\hline Description & returns the left-upper-bound of a BoundingBox of a shape, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{Temporal Relations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:overlappedBy\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & is the inverse function of overlaps.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:precedes\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.end < p2.start, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:after\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns *true* if resource1.start >= resource2.end, else *false*.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:during\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & inverse function of contains.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:finishedBy\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & is the inverse function of finishes.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:finishes\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.end == p2.end and p1.start > p1.start , else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalMeets\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if resource1.start = resource2.end or resource1.end = resource2.start, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:metBy\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & is the inverse function of meets.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:startedBy\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & is the inverse function of starts.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:starts\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.start == p2.start and p1.end < p2.end , else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalContains\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.start < p2.start and p1.end > p2.end, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalEquals\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.start == p2.start and p1.end == p2.end, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalOverlaps\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns true if p1.start < p2.start < p1.end < p2.end or p2.start < p.start < p.end < p.end, else false.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{Temporal Aggregations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalIntermediate\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with temporal fragment ( Min( p1.end, p2.end ), Max( p1.start, p2.start ) ) if intersection not exists, else null.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalBoundingBox\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with temporal fragment ( Min( p1.start, p2.start ), Max( p1.end, p2.end ) ).\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalIntersection\\
\hline Properties & \textit{TemporalEntity}, \textit{TemporalEntity} \\
\hline Description & returns new MediaFragmentURI with temporal fragment ( Max( resource1.start, resource2.start ), Min( resource1.end, resource2.end ) ) if intersection exists, else null.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{Temporal Accessors}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:duration\\
\hline Properties & \textit{TemporalEntity} \\
\hline Description & returns the duration of an interval, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:end\\
\hline Properties & \textit{TemporalEntity} \\
\hline Description & returns the end of an interval, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:start\\
\hline Properties & \textit{TemporalEntity} \\
\hline Description & returns the start of an interval, null if there is none.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:temporalFragment\\
\hline Properties & \textit{TemporalEntity} \\
\hline Description & returns a string representation of a temporal fragment.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:hasTemporalFragment\\
\hline Properties & \textit{TemporalEntity} \\
\hline Description & returns true is value is or includes a temporal fragment.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{General Relations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:contains\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{SpatialTemporalEntity} \\
\hline Description & returns if mm:temporalContains(p1,p2) and mm:spatialContains(p1,p2).\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:equals\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{SpatialTemporalEntity} \\
\hline Description & returns if mm:temporalEquals(p1,p2) and mm:spatialEquals(p1,p2).\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:overlaps\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{SpatialTemporalEntity} \\
\hline Description & returns if mm:temporalOverlaps(p1,p2) and mm:spatialOverlaps(p1,p2).\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{General Aggregations}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:boundingBox\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{SpatialTemporalEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with spatial and temporal fragment. It it works like spatialFunction:boundingBox, temporalFunction:boundingBox or both together.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:intersection\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{SpatialTemporalEntity} \\
\hline Description & returns new MediaFragment / MediaFragmentURI with spatial and temporal fragment. It works like spatialFunction:boundingBox, temporalFunction:intersection and both.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\subsubsection*{General Accessors}
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:mediaFragment\\
\hline Properties & \textit{SpatialTemporalEntity} \\
\hline Description & returns a string representation of a media fragment.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:isMediaFragment\\
\hline Properties & \textit{URI} \\
\hline Description & returns if value is a MediaFragment\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:isMediaFragmentURI\\
\hline Properties & \textit{URI} \\
\hline Description & returns if value is a MediaFragmentURI\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:toPercent\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{Double} \\
\hline Description & returns a string representation of a media fragment (uri) transformed to percent using a double parameter.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline
\begin{tabular}{|p{3cm}|p{10cm}|}
\hline Name & mm:toPixel\\
\hline Properties & \textit{SpatialTemporalEntity}, \textit{Double} \\
\hline Description & returns a string representation of a media fragment (uri) transformed to pixel using a double parameter.\\
\hline
\end{tabular}
\vspace{0.3cm}
\newline