\chapter{Background}\label{s:background}
\section{Overview}\label{ss:background_overview}
\begin{mynote}
	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})
	\end{enumerate}
\end{mynote}

\section{Datacenters}\label{ss:datacenters}
In this section we provide a short background on datacenters, datacenter simulation and compute failures.
We find it useful to provide a brief introduction to these topics so as to ensure reader's fullest understanding of subsequent chapters.
%What are the parts of a data center? 

A datacenter is ``a physical room, building, or facility for the purpose of the storage, management, and dissemination of data and information, including training artificial intelligence, housing IT infrastructure, computer systems, and associated components.''~\cite{Wikipedia:article/Datacenter}.
In essence, datacenters contain a large amount servers, and everything that is needed to maintain them.
Most often servers are specially-designed motherboards with a (multicore) \gls{cpu}, \gls{ram} and storage.
More diverse servers include a \gls{cpu}, \gls{tpu}, or \gls{npu}.
To efficiently organize the datacenter, servers are placed within server \emph{racks}.
To maintain a large number of server racks, datacenters contain a cooling system to control the heat transfer and temperature of both the hardware and the entire facility.
Additionally, datacenters consume vast amounts of electricity~\cite{Wikipedia:article/Datacenter}.
Because of this, the datacenter power supply play a critical role in keeping the services running on the servers always available.
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.}
	\label{fig:datacenter}
\end{figure}

%Who are the stakeholders? 
Datacenters form the backbone of the digital society.
The main stakeholders, besides the companies in the \gls{it} sector, are intelligent healthcare, remote work, online gaming, digital government and education, banking and finance, transport and logistics~\cite{DBLP:journals/corr/IosupKLVG22}.
All of the above industries need reliable datacenters to work well in the 21\textsuperscript{st} century.

%Where does the actual complexity come from?
The high demand for online services drives datacenter complexity.
Moreover, due to the Jevon's paradox of Computer Systems~\cite{Wikipedia:article/JevonsParadox}, improved availability increases the demand.
As a result, datacenters contain hundreds, or even thousands of hardware components.
Every device may have a different vendor, new configuration, unusual interface \etc
Because of this, datacenter operators are often faced with difficult operational and architectural challenges~\cite{Wiley:book/Condor2005,DBLP:conf/ccgrid/MastenbroekAJLB21}, which span software and performance engineering.
Making sure that all the parts of the datacenter work together is a tough task.
What drives datacenter complexity even further is that sophisticated systems are not merely a sum of their parts~\cite{Wikipedia:article/Systems_Thinking}.
The combination of the above factors makes datacenter management a difficult, non-trivial challenge.

\subsection{Datacenter Simulation}\label{sss:simulation}
\input{sources/simulator_comparison.tex}

Efficient and timely datacenter management is a difficult challenge, because datacenters are extremely complex facilities.
They require deep understanding to operate properly.
However, running real-world experiments is costly in both time and resources.
Additionally, experimentation \emph{in situ} is unsustainable and difficult to reproduce.
Alternatives to real-world experiments include simulation and mathematical analysis.
Because mathematical analysis is not scalable to modern datacenters~\cite{DBLP:conf/ccgrid/MastenbroekAJLB21}, in this project we only consider simulation as a foundation for the \gls{dcdt}.
%To help datacenter operators, the scientific community proposes to simulate datacenters to make more informed decisions.

Simulation empowers better design, testing and management of datacenters~\cite{DBLP:conf/ccgrid/MastenbroekAJLB21}.
A well-designed datacenter simulator can estimate a months-long workload in a few minutes or hours.
To simulate is to ``imitate of real-world process or system over time, enabling the study of, and experimentation with the internal interactions of complex systems''~\cite{DBLP:books/daglib/0034857}
In this project we only consider  \emph{discrete-event simulation}.
Discrete-event simulation represents system operations as a sequence of events over time, with an assumption that no changes occur between the events.
Due to the scale and complexity of datacenters, most simulators use discrete-event simulation~\cite{DBLP:conf/ccgrid/MastenbroekAJLB21}.
There exist many datacenter simulation tools, for example DGSim~\cite{DBLP:conf/europar/IosupSE08}, CloudSim~\cite{DBLP:journals/spe/CalheirosRBRB11}, SimGrid~\cite{DBLP:journals/corr/CasanovaGLQS13}, iCanCloud~\cite{DBLP:journals/grid/NunezVCCCL12}, GroudSim~\cite{DBLP:conf/europar/OstermannPPF10} and OpenDC~\cite{DBLP:conf/ccgrid/MastenbroekAJLB21}.
See \Cref{tab:datacenter_simulator_comparison} for a comparison of selected datacenter simulators, combined by Mastenbroek \etal~\cite{DBLP:conf/ccgrid/MastenbroekAJLB21}.
In order to narrow the scope of the project, we only consider {OpenDC} as a simulator for the digital twin design.
We decided to use {OpenDC}, because we find it important for a simulator to model hardware failures well.
\emph{Failure models} are a carefully calibrated, advanced feature of {OpenDC}.
Further details about {OpenDC} can be referred to in the linked literature \cite{DBLP:conf/ccgrid/MastenbroekAJLB21}.

\subsection{Compute Failures}\label{sss:failures}
A failure is defined as ``an event that makes a system fail to operate according to its specifications``~\cite{DBLP:journals/jpdc/JavadiKIE13}.
A simple example of a failure is when an old hard drive stops working.
Data on the disk is lost, and services running on the respective server are disrupted.
In reality, problems with the power supply account for most failures (54\%).
The runner-ups are problems with cooling (13\%), and \gls{it}/software (12\%)~\cite{DBLP:report/AnnualOutageAnalysis2025}.
Power related failures may stem from software/firmware issues, battery degradation, overheating, power generator failure, mechanical problems, faulty control logic \etc~\cite{DBLP:report/AnnualOutageAnalysis2025}.

Failure-caused outages are costly.
According to the Uptime Institute, 20\% of all outages cost more than 1 million
USD\$~\cite{DBLP:report/AnnualOutageAnalysis2025}.
Moreover, failures in datacenters result in service downtime, missed \gls{sla} and user inconvenience~\cite{DBLP:conf/acsos/TalluriOVTI21, DBLP:journals/jpdc/JavadiKIE13}.
Industries that rely on 24 hour access suffer the most from datacenter outages.
The impact of failures on medical informatics, nuclear power-plants, banks and financial institutions, airlines, and e-commerce is the most severe~\cite{Wikipedia:article/Downtime}.
Because of this, it is important to prevent failures.

OpenDC uses the notion of a \emph{failure model} to simulate failures, alongside \emph{failure traces}.
In OpenDC, a failure constitutes a full host crash, regardless of whether the cause of the failure is a hardware of software problem.
A result of a failure in OpenDC, all tasks running on the given host are killed, and need to be rescheduled.
A failure model consists of two statistical distributions:
\begin{enumerate*}[label=(\arabic*)]
	\item to model service unavailability
	\item to model service availability.
\end{enumerate*}
A failure trace is defined by an interval, duration, and intensity of several failures, which are later looped throughout the simulated workload~\cite{GitHub:software/OpenDC}.
In summary OpenDC enables experimentation with failures that enables insights that are not provided by other state-of-the-art software.
However, the fidelity of failure modeling inside a datacenter simulation is still insufficient to predict in failures in real-time, as they happen in a physical datacenter.
Since a datacenter simulator is quite different from a digital twin, we cannot use the same computation methods from simulation to predict real-time failures.
\begin{figure}[t]
	\centering
	\includegraphics[width=0.95\linewidth]{images/five_dimensional_dt.pdf}
	\caption[A basic framework for the \gls{dt}.]{A basic framework for the \gls{dt}. Four core elements of a \gls{dt} are defined: The physical entity (\myCircled{1}) and the simulated virtual twin (\myCircled{2}). A service for out-of-band data analytics (\myCircled{3}) and a persistent storage of historical data (\myCircled{4}) are crucial to the \gls{dt} because they are necessary to gain meaningful monitoring insights. Adapted from Tao \etal ~\cite{DBLP:conf/cirp/TAO2018169}.}
	%Fei Tao is a renowned figure with over 62k citations. He is a figure of authority on digital twins.%
	\label{fig:five_dimensional_dt}
\end{figure}
\section{Digital Twinning}\label{ss:digital-twinning}
In this section we explore how the datacenter management can be improved using a novel modelling technique, digital twinning.
We present the generic, field-agnostic \gls{dt} definition and investigate how \emph{datacenter} digital twinning applies the definition in practice.

\subsection{What is Digital Twinning?}\label{sss:what_is_digital_twinning}

% Here talk a bit about different types of data analytics that are performed in a digital twin.
``A \emph{digital twin} is a set of virtual information constructs that mimics the structure, context and behaviour of a natural, engineered or social system, is dynamically updated with data from its physical twin, has predictive capability, and informs decisions that realize value''~\cite{DBLP:usdoe/report/AP26894}.
A crucial characteristic that differentiates digital twinning from simulation and statistical modelling is the \emph{digital thread}: a bi-directional channel that enables continuous interaction between the virtual and physical entities.
The longer the \gls{dt} is working, the more accurate its predictions, because a holistic twin aggregates historical patterns together with up-to-date monitoring data.
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.
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}.

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]
	\includegraphics[width=\linewidth]{images/predictive_analytics.pdf}
	\caption[Datacenter digital twin diagram.]{Datacenter digital twin diagram. There are 5 core elements to any Digital Twin: \myCircled{A} The Digital $\rightarrow$ Physical Twin link, \myCircled{B} the Physical Twin (\emph{e.g.,} the datacenter), \myCircled{C} the Physical $\rightarrow$ Digital Twin link, \myCircled{D} the Digital Twin, \myCircled{E} the features necessary to any Digital Twin.}
	\label{fig:predictive_analytics}
\end{figure}
Predictive modelling uses statistics to predict outcomes.
When deployed commercially, for example in datacenters, predictive modelling is often referred to as predictive analytics~\cite{Wikipedia:article/PredictiveModelling}.
Almost any statistical model can be used for prediction purposes, but nowadays predictive analysis is synonymous with \gls{ml}.
A primary example of popular analysis type is linear regression.
However, any modelling technique (\eg \emph{discrete-event simulation}) can be used to make the predictions.

Predictive analysis belongs to a larger domain of \gls{oda}.
\gls{oda} is the ``use of operational data instrumentation, analysis, integration, and archiving, towards effective design, commissioning, and optimization of datacenter operations'' \cite{DBLP:conf/icppw/BourassaJBCJVS19}.

Operational analytics are present at all layers of a datacenter.
A reference architecture, proposed by \emph{Suman et al.} describes the kind of operational analysis performed at each distributed system layer.
For example, at the resource manager layer, \gls{oda} should enable workload modeling capabilities, which use predictive analysis to determine submitted user job properties~\cite{DBLP:conf/wosp/SumanCNTMI24}.
There exist several \gls{oda} frameworks, for example OMNI \cite{DBLP:conf/icppw/BourassaJBCJVS19}, Wintermute DCDB \cite{DBLP:conf/hpdc/NettiMGOTO020},  ExaMon \cite{DBLP:journals/tpds/BorghesiMMB22}, AutoDiagn \cite{DBLP:journals/tc/DemirbagaWNMAGZ22} and ODAbler \cite{DBLP:conf/wosp/SumanCNTMI24}.

A major limitation of predictive analytics is that history cannot always predict the future.
Using historical data to predict outcomes works only under the assumption that there are certain long lasting patterns in the system.
Additionally, no matter how extensive is the training data, there is always the possibility of new variables that have not been considered or even defined, yet are critical to the outcome of the prediction~\cite{Wikipedia:article/PredictiveModelling}.

\section{Literature Survey of Digital Twins for Datacenters}\label{ss:digital_twins_for_datacenters}
In this section, we survey the work related to datacenter digital twinning.
We summarize our results in Table \ref{tab:dt_features_comparison} to compare and contrast the features of existing datacenter digital twins.
We select only the digital twins that adhere closest to the \gls{nasem} definition~\cite{DBLP:usdoe/report/AP26894}.

\subsection{Methodology}\label{sss:method}
The aim of this survey is to search and organize the field of \gls{dcdt}s.
In this subsection, we describe the methods for collecting relevant scientific articles and present the design of the system model for generic \gls{dcdt}s.

\begin{enumerate}[label=\textbf{\arabic*.}]
	\item \textbf{Review Strategy}\\
	      The most common methods for conducting literature surveys are \begin{enumerate*}[label=(\arabic*)]
		      \item random traversal of the related literature,
		      \item snowballing~\cite{ACM:article/Webster2002},
		      \item systematic literature survey as proposed by Kitchenham \etal~\cite{DBLP:journals/infsof/KitchenhamPBBTNL10}
	      \end{enumerate*}~\cite{DBLP:conf/wosp/SumanCNTMI24}
	      Random traversal encompasses surveying the field by following suggestions from portals like Google Scholar and randomly querying the different databases.
	      It is an unstructured way to conduct the literature review, and requires little effort.
	      Snowballing is similar to random traversal, but it is more structured.
	      The surveyor follows references from the relevant articles, and there is a depth limit~\cite{DBLP:conf/wosp/SumanCNTMI24}.
	      Systematic literature survey is a rigorous, fully-structured process to searching for literature, and it follows the method devised by Barbara Kitchenham~\cite{DBLP:journals/infsof/KitchenhamPBBTNL10}.
	      In our work, to scope down the project we chose a mix of (1) and (2), with some elements of (3) instead of following solely the systematic literature review process of Kitchenham \etal.
	      Therefore, our literature cannot be regarded as systematic, instead we can refer to it as comprehensive or semi-structured.
	\item \textbf{Analysis of Selected Material}\\
	      We borrow the process of Suman \etal conducted during his MSc thesis for a literature survey of \gls{oda}~\cite{DBLP:conf/wosp/SumanCNTMI24}.
	      The process can be described as follows.
	      \begin{enumerate*}[label=(\arabic*)]
		      \item first, search given queries followed by a manual inspection of the context of the article
		      \item then scan each article, by reading over the abstract, introduction and conclusion and decide whether it applies to \gls{dcdt}s.
		      \item after selection, extract the details of the \gls{dcdt} from the publication by reading carefully over the article.
		      \item lastly, interpret the functionality of the \gls{dcdt}s and systematically organize them.
	      \end{enumerate*}
	\item \textbf{Design of the System Model}\\
	      Based on the findings of the literature survey, we create a conceptual model of the \gls{dcdt} field.
	      We decided to create a system model, as the field of \gls{dcdt}s is still under development, and does not include many digital  twin deployments.
	      An alternative to a system model would be a taxonomy.
	      To create the system model, we first gathered the functionality present in all the \gls{dcdt}s.
	      For each \gls{dcdt} feature in every article, we evaluated whether this feature is present in other deployments and how important it is for the \gls{dt}.
	      The result of this process is a set of \gls{dcdt} features that belong to the largest proportion of all \gls{dcdt}s.
	      Afterwards, for each of the features, we decide how it is interconnected.
\end{enumerate}

\input{sources/dt_features_comparison.tex}

\subsection{Advanced Digital Twins for Datacenters}\label{sss:advanced_dts}
ExaDigiT~\cite{DBLP:conf/sc/BrewerMKWBHSGGW24} is an open-source framework for developing digital twins of supercomputers.
It consists of 3 modules:
\begin{enumerate*}[label=(\arabic*)]
	\item resource allocator and power simulator
	\item thermal cooling model
	\item augmented reality 3D model
\end{enumerate*}
of the supercomputer.
ExaDigiT has been used at the Frontier supercomputer at the Oak Ridge National Laboratory in the USA, successfully predicting potential energy losses at the supercomputer.
Brewer \etal include alongside the framework architecture an open-source artifact and a set of extensive verification and validation experiments.
The authors differentiate between different digital twins within ExaDigiT, such as \begin{enumerate*}[label=(\arabic*)]
	\item descriptive twin
	\item informative twin
	\item predictive twin
	\item comprehensive twin
	\item autonomous twin
\end{enumerate*}
that together form the system.
The \emph{predictive twin} leverages data driven operational analytics to create \gls{ml} models. Authors argue that alongside simulation, \gls{ml} models should also have a significant role for modeling system workloads in \eg application fingerprinting.
Within the \emph{autonomous twin} the authors use \gls{rl} to train agents that can be used to make control decisions in order to optimize different processes.
In order to model the cooling system the authors use the Modelica software, and to predict energy power draw they coded a Python script.
The authors provide a intuitive way to interact with the system using a visual dashboard, and an advanced augmented reality model.
The authors posit that the best way to address the 3V's of data (velocity, volume and variety) is to use augmented reality coupled with dashboards.

SmartDC~\cite{DBLP:conf/noms/ZhangZLZWC22} is a digital twin solution for optimization of power consumption in datacenters.
Specifically, Zhang \etal propose that using \gls{ai} enhanced modeling paired with digital twinning can help make dynamic adjustments to the datacenter cooling subsystem.
SmartDC has been proven to ensure efficient energy-saving rate of a China Telecom datacenter at 41\%.
However, the main purpose of SmartDC is not to continuously interact with the facility, but to provide additional training data for a more accurate, \gls{ml} solution.
The digital twin is designed to provide extra datasets for training \gls{ai} models.
% This digital twin together with ExaDigiT use computational fluid dynamics (CFD).
% ExaDigiT uses open-source Modelica software and SmartDC uses proprietary 6SigmaDC.
% At this point it would make sense to create the distinction between _structural_ digital twinning and _behavioural_ digital twinning.
% Link to 6SigmaDC: https://www5.cadence.com/trial_datacenter_insights_lp.html

DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} is an adaptive digital twin with visualization and anomaly detection features.
The system, developed at \gls{hp} is a precursor to the vision on datacenter digital twinning published by Athavale \etal~\cite{DBLP:journals/computer/AthavaleBBMMPS24}.
DyTwin is the only system capable of failure detection in datacenters.
Moreover, it is the only system to incorporate the idea of federation into the concept of digital twinning.
DyTwin is designed to interact not only with the physical facility, but also other federated digital twins.
Taheri \etal show that DyTwin can effectively detect 100\% of CPU usage anomalies (\ie irregularities that affect CPU utilization, ranging from 5\% to 60\%).

ChatTwin~\cite{DBLP:conf/sensys/LiW0Z0T23} is an \gls{ai} and \gls{llm} powered system that enables easy deployment and configuration of digital twins for datacenters.
It is a \emph{text-to-3D} approach to building digital twins of datacenters.
ChatTwin is the only work in the field that does not share the simulation technique used to construct the digital twin based on ChatTwin's configuration.
Li \etal provide a thorough set of experiments to show ChatTwin generates the \gls{json} \gls{dcdt} configuration efficiently, but do not share the final 3D visualization results.

Reducio~\cite{DBLP:conf/sensys/CaoW0022} is a system designed to further optimize the \gls{cfd} approach to datacenter modeling.
Instead of using plain \gls{cfd} the authors focus on \gls{pod} approaches to approximate the heat transfer.
Using the \gls{pod} technique, the authors are able to model the datacenter more efficiently, achieving sub 1 degree Celsius \gls{mae} in temperature prediction.
Moreover, their model outperforms the \gls{cfd} approaches.
Cao \etal evaluate their system on an edge datacenter with 70 CPU-only server racks (see Figure 3 in \cite{DBLP:conf/sensys/CaoW0022}), and on a hyper-scale datacenter with thousands of servers (see Figure 4 in \cite{DBLP:conf/sensys/CaoW0022}).
Their results show promising gains in physics-based datacenter modelling over the conventional approaches.

NetGraph~\cite{DBLP:conf/sigcomm/HongWDSSHZY21}, designed by Huawei Technologies and China Mobile.
NetGraph is the only system in our literature review that focuses on network management (see \Cref{tab:dt_features_comparison}).
Moreover, NetGraph employs a unique modelling technique, combining device, network and service models using graph theory.
The authors evaluate their system in a Huawei datacenter with over 50000 server racks.
With over 20 million connections in the network graphs, the system is a prime example of datacenter digital twin potential.

Kalibre~\cite{DBLP:conf/sensys/WangZD0TCWZ20} is a system designed by Wang \etal in order to overcome the cons of \gls{cfd}.
To lessen the computational overhead, Wang \etal propose to use a knowledge-based neural surrogate to calibrate the different \gls{cfd} models.
Kalibre takes the best of both \gls{ml} and \gls{cfd} approaches and achieves sub 1 degree Celsius \gls{mae}, similarly to Reducio~\cite{DBLP:conf/sensys/CaoW0022}.
% What is more, Microsoft already offers digital twinning as a service https://azure.microsoft.com/en-us/products/digital-twins/
% Documentation: https://learn.microsoft.com/en-us/azure/digital-twins/
% Moreover, NVIDIA is doing too as well https://www.nvidia.com/en-sg/omniverse/

\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}.
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*)]
	\item the virtual world
	\item digital thread
	\item the physical world
\end{enumerate*}.
\begin{enumerate}[label=\textbf{\arabic*.}]
	\item \textbf{Virtual World} contains the \gls{dcdt}.
	      It represents all the components that exist in software.
	      Every \gls{dcdt} model can be categorized into two sub-categories:
	      \begin{enumerate*}[label=(\arabic*)]
		      \item infrastructure model
		      \item operations model
	      \end{enumerate*}.
	      Each \gls{dcdt} from \Cref{sss:advanced_dts} contains a model of the infrastructure within the datacenter.
	      This includes virtual replicas of the hardware elements (\eg servers, networking, server racks, rooms).
	      These elements have varying degrees of fidelity.
	      For example, NetGraph models the datacenter interconnect using purely configuration files.
	      On the contrary ExaDigiT models the datacenter hardware fully in 3D.
	      Both offer virtual infrastructure models as a part of the \gls{dcdt}.

	      The operations model is likewise present in all deployments.
	      It models the \emph{behaviour} of the datacenter, \ie the data flow, the different workloads running on the compute, the amount of data stored in each hosts \etc.
	      Both the infrastructure model and the operations model are part of all \gls{dcdt} deployments from \Cref{sss:advanced_dts}.
	      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.
	      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.
	      After comparing and corroborating these components across deployments, we find 4 that prevail the most:
	      \begin{enumerate*}[label=(\arabic*)]
		      \item the visualization interface
		      \item the message broker
		      \item the monitoring system
		      \item the system knobs
	      \end{enumerate*}.
	      These elements \emph{connect} facilitate the connection between the physical and the virtual.
	      For example, the visualization interface provides insights from the metrics collected by the \gls{dcdt} (virtual world) to the datacenter operators (physical world).
	      The message broker transfers the data from the real datacenter (physical world) to the digital twin (virtual world).
	\item \textbf{Physical World} models the real datacenter.
	      All deployments in \Cref{sss:advanced_dts} contain this element.
	      Moreover, within the datacenter, we distinguish between 3 core elements that are necessary to model the datacenter faithfully\begin{enumerate*}[label=(\arabic*)]
		      \item the \gls{it} equipment
		      \item cooling subsystem
		      \item power supply
	      \end{enumerate*}.
	      All of the aforementioned systems from \Cref{sss:advanced_dts} model either of the 3 elements.
	      In order to adhere to the holistic view of \gls{dcdt}s, and to fulfill the \gls{nasem}'s definition, the system must contain all 3 of these elements.
\end{enumerate}

\begin{figure}[t]
	\centering
	\includegraphics[width=0.95\linewidth]{images/system_model.png}
	\caption[A system model for datacenter digital twins.]{A generic system model for datacenter digital twin deployments.
		The design of DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}  indirectly incorporates in its architecture a ``virtual-to-virtual`` digital thread between different digital twins.
		Zhao \etal likewise present key elements to the digital thread in their architecture~\cite{DBLP:conf/AppliedEnergy/Zhao20}. We add the \emph{Digital Thread} to our model explicitly.}
	\label{fig:system_model}
\end{figure}

%To summarize, many \gls{dcdt}'s model the cooling systems inside the warehouse, because in a typical datacenter cooling accounts for more than 40\% of total electricity usage~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
%Since the cooling subsystem is mainly airflow-based, \gls{dt} designers often opt for a \gls{cfd} approach to model the facility.
%The reason why a digital twin might be needed for a cooling subsystem is primarily because of inefficient operational strategy.
%The cooling system parameters are often set constant, regardless of outdoor temperature \etc~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
%Zhang \etal argues that their system is akin to an IoT sensor, essentially.
% This is an important consideration -- DT is not simply a sensor, it must have predictive capabilities and be able to simulate the future.
% Zhang argues that ``digital twin services'' are enabled by simulation monitoring \etc.
% Nonetheless, I dub that they are primarily data analysis services.

%\gls{oda} can be performed in-band (real-time) and out-of-band (from historical data).
%Likewise, Zhao \etal shows that crucial to the digital twin system are ``always-on'' analytics (akin to in-band \gls{oda}) and ``on-demand`` analytics (akin to out-of-band \gls{oda}).

%Include something about data-preprocessing in the pipeline.
%See the article by Fei Tao

%Moreover, a crucial parallel between the work of Zhao \etal and ExaDigiT is the concept of multiple models within a single digital twin.
%Brewer \etal argue ExaDigiT is compromised of 5 ``smaller'' twins too.
%In Zhang \etal the digital twin can communicate with different other digital twins, as in the work of Taheri \etal.
%To do this, the working program has an API, with a specific API endpoint to communicate with other Digital Twins.

%In your work, consider adding such an endpoint, albeit explain in future work that you envision \emph{implementing} this endpoint in the future.

\section{Discussion}\label{ss:background_discussion}