fix: fixed figure 5.4 rate --> ratios

5 files changed, 147 insertions, 93 deletions

diff --git a/content/background.tex b/content/background.tex
index 68ce6a2..74083e5 100644
--- a/content/background.tex
+++ b/content/background.tex
@@ -1,12 +1,12 @@
 \chapter{Background}\label{s:background}
 \section{Overview}\label{ss:background_overview}
 \begin{mynote}
-	The contribution in this chapter is three-fold:
+	Addressing RQ$_1$, the contribution in this chapter is three-fold:
 
 	\begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}, itemsep=0.2pt]
-		\item We provide a brief overview on datacenters (\Cref{ss:datacenters}) datacenter simulation (\Cref{sss:simulation}), compute failures (\Cref{sss:failures}), and digital twinning (\Cref{ss:digital-twinning}).
-		\item We survey the state-of-the-art concerning datacenter digital twinning (\Cref{sss:advanced_dts}).
-		\item We construct a system model for existing datacenter digital twins (\Cref{ss:system_model_for_dcdts})
+		\item We provide a brief overview on datacenters (\Cref{ss:datacenters}) datacenter simulation (\Cref{sss:simulation}), compute failures (\Cref{sss:failures}), and digital twinning~ (\Cref{ss:digital-twinning}).
+		\item We survey the state-of-the-art concerning datacenter digital twinning~ (\Cref{sss:advanced_dts}).
+		\item We propose a system model (architecture) for datacenter digital twins, including a novel Digital Thread component for the operational needs linking the digital with the physical worlds~(\Cref{ss:system_model_for_dcdts}).
 	\end{enumerate}
 \end{mynote}
 
@@ -28,7 +28,7 @@ An example datacenter in \gls{cern}, is depicted on \Cref{fig:datacenter}.
 \begin{figure}[t]
 	\centering
 	\includegraphics[width=0.9\linewidth]{images/datacenter.jpg}
-	\caption[Datacenter in CERN.]{Example of a datacenter in \gls{cern}, Switzerland (2010)~\cite{Wikipedia:article/Datacenter}. In the figure we can see servers within servers racks, and the network cables.}
+	\caption[Datacenter in CERN.]{Example of a datacenter in \gls{cern}, Switzerland (2010)~\cite{Wikipedia:article/Datacenter}. The figure depicts servers within servers racks, and network cables interconnecting them.}
 	\label{fig:datacenter}
 \end{figure}
 
@@ -120,11 +120,11 @@ The longer the \gls{dt} is working, the more accurate its predictions, because a
 A generic \gls{dt} architecture is depicted in Figure \ref{fig:five_dimensional_dt} from Tao \etal~\cite{DBLP:conf/cirp/TAO2018169}.
 
 % Why has not anyone done this before?
-Digital twinning has only recently become feasible because of the developments in \gls{hpc}.
-Between 2003 and 2011 the compute needed to run a \gls{dt} was simply not present.
+Although digital twinning through simplified models exists since the 1960s, detailed and accurate digital twinning of complex and realistic scenarios has only recently become feasible because of developments in \gls{hpc}.
+Between 2003 and 2011, the compute needed to run a \gls{dt} was simply not present or was (largely) unaffordable.
 As such, while the concept existed, the hardware did not catch up yet.
 However, in the last decade, multicore computing paradigms and the advent of GPU computing has finally enabled computation needed to run digital twins.
-As a result, digital twins have become more relevant today than 10 years ago~\cite{DBLP:conf/cirp/TAO2018169}.
+As a result, digital twins have become more relevant today than a decade ago~\cite{DBLP:conf/cirp/TAO2018169}.
 
 A crucial part any of any \gls{dt} is \emph{predictive modelling}, which drives actionable insights~\cite{DBLP:usdoe/report/AP26894} (see \Cref{fig:predictive_analytics}).
 \begin{figure}[t]
@@ -270,7 +270,7 @@ Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves su
 \end{figure}
 \subsection{System Model for Datacenter Digital Twinning}
 \label{ss:system_model_for_dcdts}
-In \Cref{fig:system_model} we present a holistic model of \gls{dcdt}s from \Cref{sss:advanced_dts}.
+In \Cref{fig:system_model} we propose a new, holistic model of \gls{dcdt}s from \Cref{sss:advanced_dts}.
 The figure includes the functionality present in the majority of \gls{dcdt}s, combined together into a unified model.
 We distinguish 3 core elements of every \gls{dcdt}:
 \begin{enumerate*}[label=(\arabic*)]
@@ -299,7 +299,7 @@ We distinguish 3 core elements of every \gls{dcdt}:
 	      A digital twin that contains only the infrastructure model, cannot enable insights into the real-time operation of the datacenter.
 	      Likewise, a \gls{dcdt} containing just the operations model does not possess a capability to \eg simulate the datacenter.
 	      Only both, combined together enable the insights envisioned by the \gls{nasem} \gls{dt} definition~\cite{DBLP:usdoe/report/AP26894}.
-	\item \textbf{Digital Thread} connects the virtual world to the physical world.
+	\item \textbf{(novel) Digital Thread} connects the virtual world to the physical world.
 	      This is a novel contribution of our thesis.
 	      The digital thread is a \emph{conceptual} element that unites the components which do not belong in either of the worlds.
 	      All \gls{dcdt} programs from \Cref{sss:advanced_dts} contain elements that are ``in-between'' the physical and virtual twin.
diff --git a/content/design.tex b/content/design.tex
index cb868ab..72414a3 100644
--- a/content/design.tex
+++ b/content/design.tex
@@ -2,12 +2,14 @@
 \chapter{Design of \mysystem, a Digital Twin For Predictive Analysis of Datacenters}\label{s:design}
 \section{Overview}\label{ss:design_overview}
 \begin{mynote}
-	Our contribution in this chapter is three-fold:
+	Addressing RQ$_2$, our contribution in this chapter is three-fold:
 	\vspace{-0.2cm}
 	\begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}, itemsep=0.2pt]
-		\item We analyze the requirements for \mysystem (\Cref{ss:requirements_analysis}).
-		\item We propose a conceptual design for \mysystem's architecture (\Cref{ss:design_of_mysystem})
-		\item We describe how \mysystem fulfills the functional and non-functional requirements in \Cref{ss:requirement_validation}.
+		\item We analyze the requirements for digital twins enabling predictive analysis of datacenters~(\Cref{ss:requirements_analysis}).
+        
+		\item We design the \mysystem architecture as a digital twin enabling predictive analysis of datacenters through discrete-event simulation and ODA~(\Cref{ss:design_of_mysystem}).
+        
+		\item We analyze how \mysystem fulfills the functional and non-functional requirements~(\Cref{ss:requirement_validation}).
 	\end{enumerate}
 \end{mynote}
 \section{Requirements Analysis}\label{ss:requirements_analysis}
diff --git a/content/evaluation.tex b/content/evaluation.tex
index 0498ff7..4978206 100644
--- a/content/evaluation.tex
+++ b/content/evaluation.tex
@@ -2,11 +2,13 @@
 
 \section{Overview}\label{ss:evaluation_overview}
 \begin{mynote}
-	The contribution of this chapter is two-fold:
+	Addressing RQ$_3$ together with the previous chapter, the contribution of this chapter is two-fold:
 	\vspace{-0.2cm}
 	\begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}]
 		\item We provide a novel method for evaluating datacenter digital twins in \Cref{ss:experimental_setup}.
-		\item We provide a set of exhaustive experiments to evaluate \mysystem in \Cref{ss:experiment1,ss:experiment2}.
+
+		\item We provide a comprehensive set of experiments to evaluate \mysystem~(\Cref{ss:experiment1,ss:experiment2}).
+
 	\end{enumerate}
 	Our findings indicate:
 	\vspace{-0.2cm}
@@ -85,7 +87,7 @@ By showing that \mysystem works using this setup, we encourage scientists and ac
 	\caption[The results of Experiment 1.]{The results of Experiment 1. \textcolor{Orange}{\ding{110} \textbf{\sffamily Red Alarms}} signify 90\% of acceptable failure threshold was reached. \textcolor{Goldenrod}{\ding{110} \textbf{\sffamily Yellow Alarms}} signify 80\% of the threshold was reached.}
 	\label{fig:red_yellow_alarms}
 \end{figure}
-For the first experiment we copy the idea of Taheri \etal~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
+For the first experiment we adopt the idea introduced by Taheri \etal~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
 We show 2 different ways a \gls{dcdt} can notify datacenter engineers of detected failures.
 
 \subsection{Context}\label{sss:failure_detection_context}
@@ -95,22 +97,24 @@ Failures in a datacenter can arise from a number of problems, \eg software confi
 Some failures can have negligible consequences (around 38\% of all failures are negligible~\cite{DBLP:report/AnnualOutageAnalysis2025}), whilst other can cause severe downtime and loss of millions of \$USD~\cite{DBLP:report/AnnualOutageAnalysis2025}.
 By differentiating between insignificant and severe failures, datacenter operators can focus their efforts on addressing the most impactful problems, minimizing missed \gls{sla} and ensuring swift datacenter operation.
 
-In \Cref{ss:experiment1} we try to model such scenario.
+In \Cref{ss:experiment1} we model such a scenario.
 For example, imagine the following sequence of events:
 \begin{enumerate}[label=\textbf{\arabic*.},align=left]
 	\item The datacenter receives a scheduled workload.
-	\item To predict what kind of failures might occur during the workload we ask the digital twin to run the workload first.
-	\item  We have no \emph{a priori} knowledge of the workload type, so we can only estimate the distribution of failures. To do this, the \gls{dcdt} will run the workload, assuming failures follow \eg a normal distribution.
+	\item To predict what kind of failures might occur during the workload, we ask the digital twin to run the workload first.
+	\item  We have no \emph{a priori} knowledge of the workload type, so we can only estimate the distribution of failures. To do this, the \gls{dcdt} will run the workload, assuming failures follow \eg a normal distribution. (Unlike traditional analytical tools, the distribution can be selected arbitrarily, even changed during the run, and the predictive results do not rely on underlying  statistical assumptions.)
 	\item After running the simulation, the \gls{dcdt} can analyze the results and compare them with the running workload.
-	\item If the running workload has more failures than what the \gls{dcdt} predicted, it notifies the datacenter operators that something is wrong.
-	      Through the real-time feedback loop, the \gls{dcdt} notifies the datacenter operators that what is happening in reality is different from simulation.
+	\item If the running workload has more failures than what the \gls{dcdt} predicted, with the latter representing the known errors inherent in typical datacenter operations, the discrepancy is used to notify the datacenter operators --
+	      something is wrong.
+	      Through the real-time feedback loop, the \gls{dcdt} not only notifies the datacenter operators, but can also help understand where and how what is happening in reality is different from the simulation.
 \end{enumerate}
 
-In our experiment, we notify the datacenter operators in two cases: if we get within 80\% of the predicted threshold for number of failures we send a yellow alarm.
-If we get within 90\% we send a red alarm.
+In our experiment, we notify the datacenter operators in two cases:
+(1) we send a yellow alarm if the 80\% threshold is reached, that is, the simulated results get within 80\% of the predicted threshold for the number of failures;
+(2) we send a red alarm if the 90\% threshold is reached.
 
-The purpose of this experiment is two fold: \begin{enumerate*}[label=(\arabic*)]
-	\item to show our system works correctly
+The purpose of this experiment is two-fold: \begin{enumerate*}[label=(\arabic*)]
+	\item to show our system works correctly, and
 	\item to show our system fulfills the functional and non-functional requirements.
 \end{enumerate*}
 The technical experimental setup can be described as follows: \begin{enumerate*}[label=(\arabic*)]
@@ -132,23 +136,19 @@ The results are in \Cref{fig:red_yellow_alarms,fig:alarms_vs_failures,fig:failur
 \subsection{Discussion}\label{sss:experiment1_discussion}
 
 \Cref{fig:red_yellow_alarms} indicates \mysystem is capable of accurately detecting failures in datacenters.
-In the figure we can see that as the mean failure intensity rises, so does the total number of failures detected.
-This validates our design, as this behaviour is expected -- the higher the mean failure intensity, the more severe the failures, the more notifications to datacenter operators are sent.
+In the figure, we can see that as the mean failure intensity rises, so does the total number of failures detected.
+This behaviour is expected -- the higher the mean failure intensity, the more severe the failures, the more notifications to datacenter operators are sent.
 The more failure-intense the trace, the more alarms are raised on behalf of the digital twin.
 What is more, using the different threshold values, \mysystem can differentiate between serious failures and insignificant, single host problems (\ie the number of yellow alarms is smaller than the number of red alarms).
-To offer a second perspective, we provide \Cref{fig:alarms_vs_failures}.
+
+
+To offer a second perspective, we also provide the results depicted in \Cref{fig:alarms_vs_failures}.
 In this figure, we show the total number of alarms raised and the ground truth (how many failures occurred in reality.)
 We can see a clear correlation between the total number of alarms raised, and the actual number of failures have occurred at each time during the workload.
 For this visualization, we combined both the red and yellow alarms into a single metric.
 In short, \Cref{fig:alarms_vs_failures} backs our claims, and verifies the results obtained in \Cref{fig:red_yellow_alarms}.
 
-However, Taheri \etal present their results differently, using the \emph{anomaly detection rate} instead.
-The rate is simply calculated as the anomalies detected correctly over the true amount of anomalies~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
-Therefore, in \Cref{fig:failure_detecton_rate} we also plot the failure detection rate.
-What is surprising is Taheri \etal report almost negligible false positive rate and of their system.
-Moreover, they conclude through DyTwin's experimental setup, Taheri \etal achieve 100\% anomaly detection rate.
-In our experiment, the numbers differ significantly.
-\begin{figure}[t]
+\begin{figure}[!t]
 	\centering
 	\includegraphics[width=0.8\linewidth]{images/failure_detecton_rate2.pdf}
 	\caption[Failure detection rate overview.]{In this figure we show the total failure detection rate (\textcolor{Thistle}{\ding{110} \textbf{\sffamily Red + Yellow Alarms / Total Failures}}).
@@ -156,32 +156,45 @@ In our experiment, the numbers differ significantly.
 		We believe this is due to the irreconcilable differences between our experimental setups.}
 	\label{fig:failure_detecton_rate}
 \end{figure}
-\Cref{fig:failure_detecton_rate} shows the mean failure detection rate to be around 12\%.
-Compared to the DyTwin deployment, the difference is staggering.
-We stipulate the discrepancy stems from the fact in our setup we differentiate between different types of failures.
-This capability is not present in the DyTwin digital twin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
-As a result, we interpret \Cref{fig:failure_detecton_rate} as showing that on average 12\% of failures in the workload are severe.
-Surprisingly, the WhatsApp failure detection rate is the lowest, contrary to the mean failure intensity, which places WhatsApp trace as the 2\textsuperscript{nd} least failure-intensive trace.
+
+However, Taheri \etal present their results differently, using the \emph{anomaly detection rate} instead.
+The rate is simply calculated as the anomalies detected correctly over the true anomaly count~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}. (Note: The correct term for this should be the \emph{anomaly detection ratio}.)
+Therefore, in \Cref{fig:failure_detecton_rate} we also plot the failure detection ratio, defined as the sum of Red and Yellow alarm-counts, over the Total Failure count.
+What is surprising is Taheri \etal report almost negligible false positive rate and of their system.
+Moreover, after testing with DyTwin in a specific experimental setup, Taheri \etal conclude their proposed method achieves 100\% anomaly detection rate.
+In our experiment, the numbers differ significantly; we attribute this to irreconcilable differences between our experimental setups.
+
+
+% Our results are also different from DyTwin's performance~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
+% 		We believe this is due to the irreconcilable differences between our experimental setups.
+
+
+
+\Cref{fig:failure_detecton_rate} shows the mean failure detection ratio to be around 12\%.
+Compared to the DyTwin results reported by Taheri~\etal~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}, the difference is significant.
+We stipulate that the root of the discrepancy is that our setup differentiates between different types of failures, a capability that is not present in the DyTwin digital twin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}.
+As a new result, we interpret \Cref{fig:failure_detecton_rate} as showing that on average 12\% of failures in the workload are severe.
+Surprisingly, the WhatsApp failure detection ratio is the lowest, contrary to the mean failure intensity, which places WhatsApp trace as the 2\textsuperscript{nd} least failure-intensive trace.
 
 \section{Experiment 2: Failure Prediction}\label{ss:experiment2}
 
-In \Cref{ss:experiment1} we show \mysystem is capable of incorporating descriptive analytics.
+In \Cref{ss:experiment1} we showed \mysystem is capable of incorporating descriptive analytics.
 Through experiment-based evaluation, we concluded \mysystem can detect and differentiate between severe and one-off host failures.
-In this section we try to show \mysystem can additionally work together with a predictive analytics engine, enabling actionable insights into the future behaviour of the datacenter.
+In this section, we aim to show \mysystem can additionally work together with a predictive analytics engine, enabling actionable insights into the future behaviour of the datacenter.
 
 \begin{figure}[t]
 	\centering
 	\includegraphics[width=0.8\linewidth]{images/failure_likelihood.png}
-	\caption[The failure model likelihood over time.]{How closely a \emph{failure model} approximates the real failure distribution (the Skype failure trace) during runtime.}.
+	\caption[The failure model likelihood over time.]{How closely a \emph{failure model} approximates the real failure distribution (the Skype failure trace) during runtime. The vertical axis is linear but does \textit{not} start at 0.}
 	\label{fig:failure_likelihood}
 \end{figure}
 
 \subsection{Context}\label{sss:context_experiment2}
-In order to predict when a host failure might occur, the most straightforward approach is to use long-established statistical methods.
-Our goal was to approximate the real failure distribution of a workload, using past data and relevant statistical distributions.
-For the task at hand, we chose the Skype Failure Trace, because it is supported by 4 different failure models, based on past Skype workload data.
-These 4 statistical distribution, published in a peer-reviewed journal are in \Cref{tab:failure_models_table}~\cite{DBLP:journals/jpdc/JavadiKIE13}.
-The Skype Failure Trace model was taken from the Cloud Uptime Archive~\cite{DBLP:journals/tpds/TalluriNCKCBI26}.
+To predict when a host failure might occur, a straightforward approach is to use long-established statistical methods.
+Our goal is to approximate the real failure distribution of a workload, using past data and relevant statistical distributions.
+For the task at hand, we chose the Skype Failure Trace, because it is supported by 4 different failure models~(see \Cref{tab:failure_models_table}, sourced from~\cite{DBLP:journals/jpdc/JavadiKIE13}), based on past Skype workload data.
+%These 4 statistical distributions, published in a peer-reviewed journal are in .
+The Skype Failure Trace model was sourced from the Cloud Uptime Archive~\cite{DBLP:journals/tpds/TalluriNCKCBI26}.
 The goal is to use the failure distribution to predict when a host will fail, and then in advance re-schedule all the tasks from the hosts onto different machines \emph{before} it crashes.
 
 Initial experiment results were unpromising.
@@ -190,27 +203,42 @@ To investigate why this might be the case, we run an experiment to identify whic
 Using a similarity score $\mathcal{S}$, which is a weighted average of the exported metrics, we tried to determine the most similar distribution at any given time.
 The results are shown in \Cref{fig:failure_likelihood}.
 
-In \Cref{fig:failure_likelihood} we can notice an almost random fluctuation of the similarity score $\mathcal{S}$.
-Any given failure model, at any time interval is almost as likely to model the actual failures as the other models.
-Moreover, the similarity score $\mathcal{S}$ of each failure model is never higher than 32\%.
-\Cref{fig:failure_likelihood} exacerbates the difficulty of predictive analytics.
+% In \Cref{fig:failure_likelihood}, we notice an almost random fluctuation of the similarity score $\mathcal{S}$.
+% Any given failure model, at any time interval is almost as likely to model the actual failures as the other models.
+% Moreover, the similarity score $\mathcal{S}$ of each failure model is never higher than 32\%.
+% \Cref{fig:failure_likelihood} exacerbates the difficulty of predictive analytics.
 
-\begin{figure}[t]
-	\centering
-	\includegraphics[width=0.8\linewidth]{images/conceptual_experiment.png}
-	\caption[The conceptual experiment.]{The conceptual experiment. \textcolor{Apricot}{\ding{110} \textbf{Sunfish}} performance shows the benefits of digital twinning over  a normal datacenter without digital twinning insights \textcolor{Gray}{\ding{110} \textbf{OpenDC}}. Lowering the mean number of failures is of significant importance to datacenter operators.}
-	\label{fig:conceptual_experiment}
-\end{figure}
+% \begin{figure}[!t]
+% 	\centering
+% 	\includegraphics[width=0.8\linewidth]{images/conceptual_experiment.png}
+% 	\caption[What-if experiment.]{The What-if experiment: \textcolor{Apricot}{\ding{110} \textbf{Sunfish}} performance shows the benefits of digital twinning over a normal datacenter without digital twinning insights \textcolor{Gray}{\ding{110} \textbf{OpenDC}}. Lowering the mean number of failures is of significant importance to datacenter operators.}
+% 	\label{fig:conceptual_experiment}
+% \end{figure}
 
-Despite the aforementioned results, we set out for a different solution to show \mysystem is capable of incorporating a predictive analytics engine.
+%Despite the aforementioned results, we set out for a different solution to show 
+We also show \mysystem is capable of incorporating a predictive analytics engine.
 Instead, we designed a \emph{conceptual experiment}.
 In this setup, we \emph{assume} the predictive analytics engine is capable of fully predicting when each failure is going to happen with 100\% accuracy.
 Equipped with this assumption, which only serves to show \mysystem meets the functional and non-functional requirements, we conducted the second experiment.
 The results are shown in \Cref{fig:conceptual_experiment}.
 
 \subsection{Discussion}\label{sss:experiment2_discussion}
-\Cref{fig:failure_likelihood} shows that using a perfect predictive analytics engine, \mysystem is capable of lowering the total number of failures significantly.
-In this experiment we used only 3 failure traces from user reports of Twitter, WhatsApp and Gmail.
+
+In \Cref{fig:failure_likelihood}, we notice an almost random fluctuation of the similarity score $\mathcal{S}$.
+For any failure model, at any time interval, it is almost as likely to accurately model the actual failures as the other models.
+Moreover, the similarity score $\mathcal{S}$ of each failure model is never higher than 32\%.
+\Cref{fig:failure_likelihood} exacerbates the difficulty of predictive analytics.
+
+
+\begin{figure}[!t]
+	\centering
+	\includegraphics[width=0.8\linewidth]{images/conceptual_experiment.png}
+	\caption[What-if experiment.]{The What-if experiment: \textcolor{Apricot}{\ding{110} \textbf{Sunfish}} performance shows the benefits of digital twinning over a normal datacenter without digital twinning insights \textcolor{Gray}{\ding{110} \textbf{OpenDC}}. Lowering the mean number of failures is of significant importance to datacenter operators.}
+	\label{fig:conceptual_experiment}
+\end{figure}
+
+\Cref{fig:conceptual_experiment} shows that using a perfect predictive-analytics engine, \mysystem is capable of lowering the total number of failures significantly.
+In this experiment, we used only 3 failure traces from user reports of Twitter, WhatsApp, and Gmail.
 Importantly, we assume in this experiment a perfect precognition of what failures might occur and when.
 While unrealistic in a practical scenario, this assumption serves to approximate the potential gains from incorporating a predictive analytics engine with \mysystem.
 The results are only indicative.
@@ -218,7 +246,8 @@ In the figure we can see that the mean number of failures in a ``physical datace
 
 \section{Experiment 3: Failure Exploration}\label{ss:experiment3}
 
-For this experiment, we adapt the idea of multi-modal simulation from Nicolae \etal~\cite{DBLP:conf/cf/NicolaeNTI26} to estimating failures with \gls{dcdt}.
+For this experiment, we adapt the idea of using multi-modal simulation from Nicolae \etal~\cite{DBLP:conf/cf/NicolaeNTI26} to estimate failures with \gls{dcdt}.
+
 \subsection{Context}\label{sss:context_experiment3}
 In this experiment we use the \gls{dcdt} to explore the number of terminated tasks when different failure injection algorithms are used.
 The primary objective of this experiment is to identify the worst-case scenario and best-case scenario of running a workload prone to failures.
@@ -247,7 +276,9 @@ The results are depicted in \Cref{fig:victim_selector_comparison}.
 The victim selector that achieves the most tasks terminated is the \code{CpuUtilSelector}, which stops the hosts with the highest \gls{cpu} utilization.
 It reaches over 700 terminated tasks (709) in total.
 The \code{Random} selector, which randomly picks the hosts to stop, achieves the second-highest number of tasks terminated, at around 450.
-The most optimistic scenario for datacenter operators is presented by the \code{RoundRobin} selector, which picks the hosts to terminate in a round-robin fashion.
+
+The most optimistic scenario for datacenter operators tested here is the \code{RoundRobin} selector, which picks the hosts to terminate in a round-robin fashion.
 No more than 130 tasks are terminated using this fault injection algorithm.
-To summarize, this experiment shows that \mysystem can be used for the exploration of different failure algorithms for the benefit of datacenter operators.
+
+To summarize, this experiment shows that \mysystem can be used to explore different failure algorithms for the benefit of datacenter operators.
 Using \mysystem, on-site engineers can effectively estimate the best-case and worst-case number of terminated tasks during a workload.
diff --git a/content/implementation.tex b/content/implementation.tex
index 16cf7ca..79c5191 100644
--- a/content/implementation.tex
+++ b/content/implementation.tex
@@ -3,17 +3,19 @@
 \section{Overview}\label{ss:overview_implementation}
 
 \begin{mynote}
-	The contribution of this chapter is two-fold:
+	Addressing RQ$_3$ together with the next chapter, the contribution of this chapter is two-fold:
 	\vspace{-0.2cm}
 	\begin{enumerate}[label=\emph{C\textsubscript{\arabic*}}]
 		\item We implement the real-world prototype of \mysystem (see \Cref{ss:detailed_implementation_overview}) realizing key features of the design.
-		\item We engineer \mysystem to enable predictive analytics engines (see \Cref{ss:programming})
+        
+		\item We engineer \mysystem to enable predictive analytics engines (see \Cref{ss:programming}).
+        
 	\end{enumerate}
 \end{mynote}
 
 \section{Detailed Implementation of \mysystem}\label{ss:detailed_implementation_overview}
-In this section we describe the detailed implementation of \gls{my_system}.
-After reading one should understand the technical decisions, choice of tools and modifications to existing software necessary for evaluation of \gls{my_system} in \Cref{s:evaluation}.
+In this section, we describe the detailed implementation of \gls{my_system}.
+After completing it, the reader should understand the technical decisions, choice of tools, and modifications to existing software necessary for evaluation of \gls{my_system} in \Cref{s:evaluation}.
 
 Any complex system is more than the sum of its parts~\cite{Wikipedia:article/Systems_Thinking}.
 To understand \gls{my_system} it is crucial to provide a holistic view on the prototype.
@@ -30,7 +32,7 @@ Lastly, \Cref{ss:programming} carefully explains the design decisions behind the
 
 At the onset of the project, we decided \gls{my_system} will use only state-of-the-art software, deployed in the industry or evaluated in peer-reviewed scientific publications.
 The mapping of software packages used onto the reference architecture can be seen in \Cref{fig:implementation}.
-In order to facilitate visualizations and interactive dashboards, we decided to use \code{Grafana} (\myCircled{2a})~\cite{Wikipedia:article/Grafana}.
+To facilitate visualizations and interactive dashboards, we decided to use \code{Grafana} (\myCircled{2a})~\cite{Wikipedia:article/Grafana}.
 To enable the flow of data into the \gls{dt}, we use \code{Kafka} (\myCircled{2b})~\cite{Wikipedia:article/Confluent}.
 To store the in-band data we use a \code{Redis} (\myCircled{3b})~\cite{Wikipedia:article/Redis} cache, and for out-of-band data we use a \code{PostgreSQL}(\myCircled{3a})~\cite{Wikipedia:article/Postgresql}.
 To enable predictive analytics, we chose a discrete-event simulator, \code{OpenDC}(\myCircled{4a})~\cite{GitHub:software/OpenDC}.
@@ -81,9 +83,9 @@ For a specific overview of advantages of \code{OpenDC}  (\myCircled{4a}) and a t
 	\label{fig:flow_diagram}
 \end{figure}
 
-\section{Data Flow}\label{ss:data_flow}
+\section{Main Data Flow}\label{ss:data_flow}
 
-In this section we describe the data flow within \Cref{fig:implementation} using a separate diagram.
+In this section, we describe the data flow within \Cref{fig:implementation} using a separate diagram.
 Efficient data flow is of utmost importance to \gls{dt}s.
 In \Cref{fig:flow_diagram} we present the moving of data within \gls{my_system}.
 In the diagram whenever we refer to \emph{control}, we mean small, one-in-a-while data packets that contain either instructions, insights or small amount of data.
@@ -133,7 +135,7 @@ Scheduling in \code{OpenDC} also works using this method.
 \Cref{fig:scheduling_in_opendc} represents how a task is assigned to a host in the simulation.
 
 A task (\myCircled{1}) is represented by its submission time, duration and computational requirements.
-In order to be assigned a server to run on, it is deserialized into a \code{ServiceTask} (\myCircled{2}).
+To be assigned a server to run on, it is deserialized into a \code{ServiceTask} (\myCircled{2}).
 The \code{FilterScheduler} (\myCircled{4}) class takes care of scheduling the service task once the simulation reaches its submission time.
 \code{OpenDC} maps tasks to available hosts via an \emph{allocation policy}~\cite{VUAmsterdam:thesis/AnaMariaMusca2025}.
 In our work, this is always (also in \code{SmartScheduler}) the \code{FilterPolicy}.
@@ -148,7 +150,7 @@ The \code{SimHost} object is created via the \code{HostProvisioningStep} class (
 \section{Extensions to \code{OpenDC}}\label{ss:extensions}
 
 \code{OpenDC} is a state-of-the-art datacenter simulator.
-In order to turn it into a \gls{dt}, we have made several design decisions and extensions.
+To turn it into a \gls{dt}, we have made several design decisions and extensions.
 
 \begin{enumerate}[label=\textbf{\arabic*.}]
 	\item \textbf{\code{SmartScheduler}}\\
@@ -166,7 +168,7 @@ In order to turn it into a \gls{dt}, we have made several design decisions and e
 	      The \code{HTTPClient} offers the necessary functionality to communicate between the \gls{dt} and the datacenter.
 	      We decided to use the \gls{http} protocol for short, one-off communications between the \gls{dt} and the datacenter, as is common industry practice.
 	\item \textbf{\code{CpuUtilVictimSelector}}\\
-	      In order to ensure \code{OpenDC} can model different failure injection algorithms, we added new methods for selecting the hosts to be stopped.
+	      To ensure \code{OpenDC} can model different failure injection algorithms, we added new methods for selecting the hosts to be stopped.
 	      The \code{CpuUtilVictimSelector} selects hosts based on their current \gls{cpu} utilization (\ie the hosts with the highest utilization are stopped first).
 	\item \textbf{\code{RoundRobinVictimSelector}}\\
 	      The \code{RoundRobinVictimSelector} is another algorithm to used to inject failures into hosts.
@@ -193,12 +195,12 @@ For future work, we envision a system that implements the reference architecture
 
 \begin{enumerate}[label=\textbf{\arabic*.}]
 	\item \textbf{\code{AnalyticsEngine}}\\
-	      The \code{AnalyticsEngine} module is necessary in order to encapsulate the logic of data preprocessing and analysis from monitoring.
+	      The \code{AnalyticsEngine} module is necessary to encapsulate the logic of data preprocessing and analysis from monitoring.
 	      This component can contain capabilities for different statistical metrics, subject to \gls{dt}s focus.
 	      In \gls{my_system} \code{AnalyticsEngine} continuously checks whether the incoming datacenter sensor readings exceed different thresholds.
 	      For example, the \code{AnalyticsEngine} is capable of calculating a similarity score $S$ between potential failure distributions and the true failure distribution.
 	\item \textbf{\code{HTTPServer}}\\
-	      The \code{HTTPServer} is crucial for interrupting the operation of the datacenter in order to adjust its operation or offer insights.
+	      The \code{HTTPServer} is crucial for interrupting the operation of the datacenter to adjust its operation or offer insights.
 	      It maintains a python \code{Queue} structure.
 	      The \code{Queue} \emph{producer} is the \code{AnalyticsEngine} (\grayCircled{4}).
 	      The \emph{consumer} is the \code{HTTPClient} within \code{OpenDC} (\ie the real datacenter, (\myCircled{2}), (\myCircled{1})).
diff --git a/content/intro.tex b/content/intro.tex
index 11170ca..85ae205 100644
--- a/content/intro.tex
+++ b/content/intro.tex
@@ -30,6 +30,10 @@ Preventing failure-caused outages in advance could help datacenter operators red
 The high computational demand of \gls{ai} and the end of Dennard's scaling have resulted in the rise of larger and more heterogeneous datacenter architectures~\cite{DBLP:conf/date/MilojicicFDR21}.
 Both events create a need for more careful datacenter management to tackle the unprecedented complexity and ensure availability of all cloud services.
 To address this new problem a concept of a datacenter \gls{dt} was proposed~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
+% Explain DT here, very briefly
+A \gls{dt} is a virtual model of an intended or actual real-world system that serves as its counterpart for purposes such as simulation, integration, testing, monitoring and maintenance.
+The digital twin replicates the physical system to predict failures, prescribe real-time actions for mitigating unexpected events, observing and evaluating the behaviour of the system~\cite{Wikipedia:article/DigitalTwin}.
+%
 This thesis explores the use of digital twins to cope with increasing operational complexity in datacenters, by enabling both historical and online data to pass through the digital twin's analytical and predictive loops. 
 
 \begin{figure}[t]
@@ -44,25 +48,26 @@ This thesis explores the use of digital twins to cope with increasing operationa
 
 % A digital twin is often called a virtual twin.
 % The communication between a physical entity and the digital twin is referred to as a digital thread.
-A \gls{dt} is a virtual model of an intended or actual real-world system that serves as its counterpart for purposes such as simulation, integration, testing, monitoring and maintenance.
-The digital twin replicates the physical system to predict failures, prescribe real-time actions for mitigating unexpected events, observing and evaluating the behaviour of the system~\cite{Wikipedia:article/DigitalTwin}.
+%
+% A \gls{dt} is a virtual model of an intended or actual real-world system that serves as its counterpart for purposes such as simulation, integration, testing, monitoring and maintenance.
+% The digital twin replicates the physical system to predict failures, prescribe real-time actions for mitigating unexpected events, observing and evaluating the behaviour of the system~\cite{Wikipedia:article/DigitalTwin}.
 
-Most modern \gls{dt} usages are related to prognostics and system health management~\cite{DBLP:conf/cirp/TAO2018169}.
+Much modern \gls{dt} usages are related to prognostics and system health management~\cite{DBLP:conf/cirp/TAO2018169}.
 For example, in aerospace engineering, the \gls{dt} analyzes operational data (\eg temperature, vibration) to predict when a airplane component is likely to fail.
 The \gls{dt} can reliably manage the health of the physical entity by detecting fatigue cracks on aircraft wings or damage to the wind turbine blades~\cite{DBLP:journal/IJAE/Teugel2011}.
 This allows maintenance to be scheduled proactively, reducing unplanned downtime and preventing catastrophic failures.
 Forecasting future maintenance and managing the physical health of an object or facility are the prime purpose of many \gls{dt}s used in practice~\cite{DBLP:conf/AIAA/Teugel2012}.
 
 The concept of a \gls{dt} began in 1960s, at the \gls{nasa}~\cite{Nature:article/Görtz2026}.
-\gls{nasa} pioneered the concept in order to debug issues with its spacecraft.
+\gls{nasa} pioneered the concept to debug issues with its spacecraft.
 However, the term ``digital-twin'' dates back to 2003, when Dr. Michael Grieves of Dassault Syst\'emes introduced the 3 core components of a \gls{dt}: the virtual entity, physical entity and the two-way connection (see Figure \ref{fig:simple_dt}).
 Due to insufficient technological foundations, little work is available on \gls{dt}s between 2003 and 2018, and it is only with the rapid growth of cloud computing, \gls{iot} and Big Data analytics that \gls{dt}s have re-emerged.
 Today, research is focused on bridging the gap between the long-established foundations of \gls{dt}s and new, novel applications in academia and industry, such as the \gls{dcdt}~\cite{DBLP:conf/cirp/TAO2018169, DBLP:journals/computer/AthavaleBBMMPS24}.
 
-A \gls{dcdt} mirrors the structure, context and behaviour of a datacenter~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
+A \gls{dcdt} mirrors the structure, context, and behaviour of a datacenter~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
 The foundation to any digital twin is good monitoring and sensing capabilities in the physical entity.
 Datacenters, meet this requirement easily because they already connect hundreds of monitoring sensors.
-With hundreds of gigabytes of useful information coming from distributed \gls{iot} sensors inside the warehouse, we can gain insight into failure patterns, energy usage, heat dissipation \etc
+With hundreds of gigabytes of useful information coming from distributed \gls{iot} sensors inside the warehouse, we can gain insight into failure patterns, energy usage, heat dissipation, \etc
 What remains challenging is to connect the physical and virtual spaces with a bi-directional connection
 and to use the monitoring insights and data analysis results for autonomous decision-making.
 Crucial to \gls{dcdt} operation are predictive capabilities and the continuous interaction with the real-world datacenter.
@@ -70,7 +75,7 @@ Crucial to \gls{dcdt} operation are predictive capabilities and the continuous i
 There already exist \gls{dcdt} deployments.
 For example, ExaDigiT~\cite{DBLP:conf/sc/BrewerMKWBHSGGW24} is a framework for digital twin development of supercomputers.
 It has been demonstrated at the Frontier supercomputer and it facilitates virtual prototyping and system optimization.
-
+%
 Nonetheless, existing \gls{dcdt}'s are still very limited in their capabilities as the definition and scope of a \gls{dcdt} concept is shallow and unclear.
 After all, only recently did the hardware capabilities needed to continuously simulate a datacenter become available~\cite{DBLP:conf/cirp/TAO2018169}.
 Many \gls{dcdt} frameworks still lack critical data analysis components, fault detection mechanisms, profiling techniques \etc~\cite{DBLP:conf/wosp/SumanCNTMI24}, rendering them unusable in large-scale systems.
@@ -95,9 +100,13 @@ In this work, we address the lack of a unified \gls{dcdt} system model and the a
 We argue that the current state-of-the-art \gls{dcdt}'s lack sufficient predictive capabilities that are essential to real-time facility management of a modern datacenter.
 Because the main purpose of many \gls{dt}s is to forecast the short and long-term facility behaviour, \gls{dcdt} without predictive capabilities cannot maintain the health of the datacenter effectively.
 We posit that including holistic predictive analysis in \gls{dcdt} design can aid in efficient datacenter management and prevent missing \gls{sla}'s.
+%
 For example, preventing compute failures could greatly benefit datacenter operators.
-To enable insights from both historical data and immediate telemetry, we propose that digital twinning can be enhanced by integrating predictive analytics through \gls{oda}.
+
+
+%To enable insights from both historical data and immediate telemetry, we propose that digital twinning can be enhanced by integrating predictive analytics through \gls{oda}.
 We envision \gls{dcdt}'s as systems indispensable in future datacenters, actively interacting with the real-world facility, lowering operational costs and predicting hardware failure and software faults.
+In particular, to enable insights from both historical data and immediate telemetry, we propose that digital twinning can be enhanced by integrating predictive analytics through \gls{oda}.
 Our solution to this problem encompasses different levels of \gls{oda} (\eg in-band analytics, out-of-band analytics) for holistic datacenter modelling.
 Together with a unified \gls{dcdt} system model and a revolutionary evaluation method of \gls{dcdt}'s, we hope to bring the modern vision of \gls{dt}'s to datacenters.
 
@@ -105,7 +114,7 @@ Together with a unified \gls{dcdt} system model and a revolutionary evaluation m
 
 \emph{Main Research Question:} How to enable predictive analytics in datacenters through digital twinning?\\
 
-\noindent We divide the problem of designing a predictive \gls{dcdt} into three research questions:
+\noindent We scope the problem of designing a predictive \gls{dcdt} by proposing three research questions:
 \begin{enumerate}[label=\emph{RQ\textsubscript{\arabic*}}, align=left, itemsep=0pt]
 	% First research question stolen from Capelin by Georgios Andreadis and adapted to my work.
 	\item \emph{How to assess the current state-of-the-art of digital twinning for datacenters?}\\
@@ -128,9 +137,9 @@ Together with a unified \gls{dcdt} system model and a revolutionary evaluation m
 \section{Research Methodology}\label{s:research-methodology}
 To answer \emph{RQ\textsubscript{1}} we conduct a literature review as proposed by \textit{Kitchenham et al.} \cite{DBLP:journals/infsof/KitchenhamPBBTNL10} along with the guidance of the supervisor.
 Firstly, we determine the right review method.
-Secondly, we identify the various works related to \gls{dcdt}'s using different search strings
+Secondly, we identify the various works related to \gls{dcdt}'s using different search strings~
 (\eg ``Datacenter Digital Twinning'', ``ICT Virtual Twin'') and query combinations (``Datacenter \code{AND} Maintenance'').
-To search for the results we use the digital libraries of Google Scholar, DBLP, ACM Digital Library, IEEExplore, Springer \etc
+To search for the results we use the digital libraries of Google Scholar, DBLP, ACM Digital Library, IEEExplore, Springer, \etc
 Thirdly, we select work relevant to our research and organize the details of each article into a table.
 A potential outcome of this could be a system model for \gls{dcdt}'s.
 We envision the literature review supplying us with potential use-cases for the predictive \gls{dcdt}.
@@ -168,16 +177,22 @@ We define the correct experiment setup(s) and perform the experiments on a speci
 		      \item We provide the experiment setup, validation and evaluation of \mysystem for detecting and predicting datacenter failures in real-time as an Open Science artifact.
 	      \end{enumerate}
 \end{enumerate}
+
 \section{Academic Integrity Declaration}\label{s:academic_integrity_declaration}
+
+The statements in this section address an ongoing and seemingly growing problem in academia, that of integrity breaches primarily through the generation of material using AI techniques, such as LLM services.
+
 \subsection{Non-Plagiarism Declaration}\label{ss:plagiarism-declaraion}
 I hereby declare that this thesis is my own independent work and writing.
 The thesis does not contain any material copied from other sources (person, Internet, or \gls{ai}), and has not been submitted for assessment elsewhere.
 I acknowledge that the usage of material from other works or paraphrase of such material without proper citations or credit will be treated as plagiarism.
 I declare that this thesis is free from \gls{ai} generated content and has been written without the help of any \gls{ai} tools.
-To order to adhere to the strictest restrictions on AI-usage in higher education, this work follows the Berkley School of Law Artificial Intelligence Policy, as stated in \url{https://www.law.berkeley.edu/wp-content/uploads/2026/05/AI-Final-Policy-26.pdf}.
+
+To adhere to the current (strictest) restrictions on AI-usage in higher education, this work follows the Berkley School of Law Artificial Intelligence Policy, as stated in \url{https://www.law.berkeley.edu/wp-content/uploads/2026/05/AI-Final-Policy-26.pdf}.
 
 \subsection{Preventing Reference Fraud}\label{ss:plagiarism_references}
-I hereby declare that all the references in this thesis refer to genuine scientific work published in peer-reviewed journals or other sources of reliable and safe online information (\eg Wikipedia articles) and have been used in accordance to the article authors' wishes.
+I hereby declare that all the references in this thesis refer to genuine scientific work published in peer-reviewed journals or other sources of reliable and safe online information~ (\eg Wikipedia articles) and have been used in accordance to the article authors' wishes.
+
 Additionally, under the guidance of the supervisor this work adheres to the strictest rules for referencing and to prove the originality of all references, each \BibTeX citation contains a \texttt{note} field with the following comment: \emph{This BibTeX citation comes from:} followed by the URL leading directly to the citation source.
 In case of citations not formatted in \BibTeX, the same format follows but with adequate reference-style name (\eg APA, Chicago, MLA).
 
@@ -194,11 +209,15 @@ This work addresses the four grand societal challenges related to this goal: \be
 	\item sustainability
 	\item usability
 \end{enumerate*}~\cite{DBLP:journals/corr/IosupKLVG22}.
-\mysystem addresses (1) directly by making large-scale datacenter management easier.
+
+\mysystem addresses goal (1) directly by making large-scale datacenter management easier.
+
 We address (2) by ensuring our work adheres to the \gls{fair} principles of Open Science.
 Moreover, in this thesis we try to make \gls{dcdt} systems more understandable to the broader scientific community by providing a unified system model.
 Additionally, we contribute to responsible software design by adhering to best software engineering practices in the design of the prototype.
-(3) is addressed indirectly, as the consequences of the insights provided by a holistic, \gls{oda} powered \gls{dcdt} can help datacenter managers make decisions that are more sustainable in the future.
+
+Goal (3) is addressed indirectly, as the consequences of the insights provided by a holistic, \gls{oda} powered \gls{dcdt} can help datacenter managers make decisions that are more sustainable in the future.
+
 We contribute to (4) by helping predict unexpected failures and lowering operational costs, ensuring datacenters can continue to be usable in the future.
 We believe this work has a strong societal impact due to addressing the four grand societal challenges described by Iosup \etal and we hope through this work we can advance the scientific research community towards a more sustainable future.
 Abiding the FAIR data principles, the entire source code of the prototype and related work has been made available at the \url{https://github.com/M-J-Kwiatkowski/opendc} and the \url{https://github.com/M-J-Kwiatkowski/sunfish} repositories.