From 1672434749229b932e1e727da5be9158394d5a1c Mon Sep 17 00:00:00 2001
From: mjkwiatkowski <mati.rewa@gmail.com>
Date: Fri, 12 Jun 2026 11:18:23 +0200
Subject: feat: added a new remote at denounce.ai

---
 content/background.tex | 31 +++++++++++++++++++++++--------
 1 file changed, 23 insertions(+), 8 deletions(-)

(limited to 'content/background.tex')

diff --git a/content/background.tex b/content/background.tex
index 8adcae5..4884995 100644
--- a/content/background.tex
+++ b/content/background.tex
@@ -2,7 +2,6 @@
 
 \section{Overview}\label{s:background_overview}
 
-
 \section{Datacenters}\label{ss:datacenters}
 
 \subsection{Computing Infrastructure}\label{sss:failures}
@@ -36,7 +35,6 @@ Since a digital twin is not a standalone simulator, a change to how we both pred
 
 \input{sources/simulator_comparison.tex}
 \section{Digital Twinning}\label{ss:digital-twinning}
-
 % To fix: remove the \gls commands for ExaDigiT.
 % This is getting silly.
 \subsection{What is Digital Twinning?}\label{sss:what_is_digital_twinning}
@@ -65,13 +63,10 @@ As a result, digital twins have become more relevant today than 10 years ago~\ci
 \subsection{Digital Twins across Domains}\label{sss:digital_twins_across_domains}
 
 \subsection{Digital Twins for Datacenters}\label{sss:digital_twins_for_datacenters}
-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
-Moreover, CPU profiling, VM uptime, workload type enable datacenter managers to leverage \gls{oda} to gain meaningful insights into datacenter operation.
-But currently one of the key challenges is to somehow connect the physical and virtual spaces with a bi-directional connection, that aims to use the monitoring insights and data analysis results to make autonomous decisions.
-\gls{dcdt}'s emerged to address this problem.
 
+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}.
 
 \input{sources/dt_features_comparison.tex}
 
@@ -115,6 +110,17 @@ DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} is an adaptive digital twin with vi
 % Documentation: https://learn.microsoft.com/en-us/azure/digital-twins/
 % Moreover, NVIDIA is doing too as well https://www.nvidia.com/en-sg/omniverse/
 
+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
@@ -126,6 +132,15 @@ DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24} is an adaptive digital twin with vi
 	\label{fig:system_model}
 \end{figure}
 
+The design of DyTwin~\cite{DBLP:conf/sc/TaheriBPRHDEWPM24}  incorporates in its architecture a ``virtual-to-virtual`` digital thread between different digital twins.
+Zhao \etal include this element in their architecture too~\cite{DBLP:conf/AppliedEnergy/Zhao20}.
+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.
+
 
 
 
-- 
cgit v1.2.3

