25 files changed, 303 insertions, 21 deletions

diff --git a/notes/meetin2.txt b/notes/03_06_2026.txt
index 6ed2515..6ed2515 100644
--- a/notes/meetin2.txt
+++ b/notes/03_06_2026.txt
diff --git a/notes/2026-06-10-jd.txt b/notes/10_06_2026.txt
index f058da1..f058da1 100644
--- a/notes/2026-06-10-jd.txt
+++ b/notes/10_06_2026.txt
diff --git a/notes/auto-scaling.txt b/notes/11_05_2026.txt
index a6b009f..6a74ff9 100644
--- a/notes/auto-scaling.txt
+++ b/notes/11_05_2026.txt
@@ -41,3 +41,23 @@ Why is a specific datacenter digital twin different from what there already is.
 
 Versen Thesis Awards they are promoted at ICTO today and tomorrow. 
 
+Create a model in draw.io
+Look at OpenTelemetry (read up - is this a lot of work?)
+https://github.com/atlarge-research/opendc/tree/radice-paper
+Make sure you the fields you specify in the schema itself are automatically exported.
+Measure Kafka latency of exporting. 
+Also ensure whether the user wants to export to database or not.
+Add multiple export functions.
+Make sure specify the config files in the command line.
+The prediction should be about auto-scaling.
+BUT -> there is no auto-scaling.
+Do auto-scaling.
+Idle power takes a lot of energy. 
+Predicting when to turn nodes on and off would be nice.
+Datacenters are heavily underutilized.
+Predict when to turn the hosts on and when to turn them off.
+Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. 
+With auto-scaling you can do it a bit smarter or not.
+Do auto-scaling in OpenDC.
+Rescheduling.
+
diff --git a/notes/notes.txt b/notes/12_05_2026.txt
index d5394cf..d5394cf 100644
--- a/notes/notes.txt
+++ b/notes/12_05_2026.txt
diff --git a/notes/1.txt b/notes/13_05_2026.txt
index 4a11803..4a11803 100644
--- a/notes/1.txt
+++ b/notes/13_05_2026.txt
diff --git a/notes/meeting.txt b/notes/16_06_2026.txt
index 9a544db..788ca85 100644
--- a/notes/meeting.txt
+++ b/notes/16_06_2026.txt
@@ -2,15 +2,16 @@ Find experiments or standard operation that might utilize simulation a bit is no
 Look at the idea of cascading failures.
 A single failure can propagate.
 It makes it difficult simulate to completely.
+
 Why is it difficult with failures to use naive simulation.
 And then your thesis proposal is that a digital twin would help out these failures.
+
 The use case that you are specifically looking at is failures.
 Then of course you need to introduce failures.
 You are not focusing enough on digital twinning.
 You should focus more on this than predictive analytics.
 Digital twinning is the key -- argumentation and whatnot, not yet faults or predictive analysis.
 
-
 Opendc-web-server.
 All the interesting endpoints are defined in `rests/resources`
 Do not use Javalin, use Quarkus, because we use Quarkus in the web module.
diff --git a/notes/17_06_2026.txt b/notes/17_06_2026.txt
new file mode 100644
index 0000000..1f2423d
--- /dev/null
+++ b/notes/17_06_2026.txt
@@ -0,0 +1,59 @@
+==Presentation__Meeting==
+1) Use the recipe.
+If you deviate from that, then what it's at your own risk.
+Hard limit on the number of slides is 10.
+Each slide is 1-2 minutes.
+You can have between 5-10 slides.
+>10 slides -> very good change you won't have the time to talk about what's on the slides.
+You _can_ have extra slides.
+The QnA is the questions by everybody in the room.
+You can also ask questions/should ask questions.
+The last couple of minutes the _supervisors_ ask questions.
+
+2) Make sure your slides are numbered.
+First slide has to have the title plus your name.
+The slides can be posted online, so the first slide might be the business card.
+You can use the first slide for a little bit more than just title -- add an _abstract_.
+Add a short text.
+"At a top level, my project is ..."
+Have a bit of an introduction on the very first slide.
+
+3) The second slide: this is societal context of your work.
+How does this work affect society at large?
+
+4) After comes the problem statement OR the research question.
+You can KEEP the problem statement.We used
+AIP, DBLP, and Google Scholar as the main
+digital libraries for querying the literature
+sources, amongst which Google Scholar re-
+ferred to
+You can also show the contributions.
+
+5) Design to present --> USE Animations to make things appear one by one.
+A lot of material all at once is BAD.
+Make colored boxes appear one by one in the order you talk about them.
+OR include red highlight boxes.
+If you look at the component in the red boxes --> steer the attention in the audience, if you want to show something that has so many components as something like Ana Maria's slide 5.
+
+Focus on the most _innovative_ part of the design.
+Design has a lot of elements --> focus on what made _this_ design special.
+Focus on the most interesting thing that you have added.
+
+Show what is important, highlight some boxes, tell them the `cool stuff of the thesis.`
+
+6) It's not given which contributions are worth more and which aren't.
+At the level of the bachelor, it is typically easiest to make an impression with the experiments.
+The design and implementation are unlikely the most groundbreaking part of the thesis.
+Most bachelor thesis are experiment heavy, so most presentations are experiment heavy.
+
+7) Are we given a clicker or do we plug in our own laptop?
+We are plugging in our own laptop.
+
+8) Replicate a result from a previous study to show that the system works.
+Replicate an experiment!!!!!!
+You can show this to the audience to show you can demonstrate your capability in the presentation.
+
+9) Jesse strongly recommends: there should be something you are really excited about.
+Whatevery you found the most enjoyable or challenging --> try to incorporate this in the presentation.
+"Now we go to my favourite part".
+"Now we go to the most difficult part, and I am really proud I can show you these experimental results today"
diff --git a/notes/19_06_2026.txt b/notes/19_06_2026.txt
new file mode 100644
index 0000000..cdd1838
--- /dev/null
+++ b/notes/19_06_2026.txt
@@ -0,0 +1,118 @@
+You do not know which failure trace it is going on.
+Using my system we could utilize a model that.
+Make this a hypothetical setting.
+Make this very clear that its hypothetical.
+
+1) Make it clear why this experiment shows what we are doing?
+2) Why is this significant?
+3) Just need to show that this is NOT some trivial experiment because the setup is simple.
+
+4) Make the experiment not look fake based on the numbers that there are.
+        -- This experiment shows that our system works; make the experiment look realistic.
+
+"If we had a model that could perfectly predict our system"
+
+Have a look at the ``Victim Selector''.
+Alter it somehow! Make this based on metric.
+Use some CPU or Host Age metric.
+The more tasks are running on a host the more likely it is to fail.
+
+``Host B has 20\% chance of failing''
+``Host C has 30\% chance of failing''
+
+Explain why these results are significant and why are they important.
+
+You have some model, and this can be based on multiple traces.
+Get insight from CINECA --> you get a probability of certain hosts failing.
+You run a simulation/multiple in the digital twin knowing which failures are going to happen.
+
+
+You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
+=====TO_DO====
+Run different ways of scheduling.
+I want to schedule these tasks, find me the best way to schedule them.
+-> Send to the digital twin, the DT can run different scheduling algorithms.
+Run the same experiment with different random seeds. Run it 20 times, on average, this order of scheduling is the best.
+===========
+
+**Make the simulator run multiple failure traces and pick the most likely hosts to fail.**.
+
+Anomaly detection --> CINECA, how good their detection is?
+If you incorporate that? If you can make the case that because of our new digital twin we can incorporate such models, anomaly/failure detection, from CINECA.
+If we had that in, we can reach these kinds of gains.
+
+You can have some weights to each host: "What is the chance of this host failing?"
+Be careful with spending too much time on this.
+
+1) First: think about a way you want to explain this experiment.
+Couple this experiment with real world simulation -- how this connect to a real simulation that might happen in the future.
+What are the assumptions that I could make?
+I need to make the victim selector have some probability to select a victim.
+Explain why the experiment makes sense.
+Say in the future work: this is more of a proof of concept, there are some caveats.
+It is more important to work on the explain-ability.
+Why did we make certain design.
+
+
+CONSIDER SUPPORT VECTOR REGRESSION within VICTIM SELECTOR.
+
+2) Presentation:
+Add highlights --> to show you are going through the system in slide 7.
+
+DO THIS: Show a slide with a video showing the system is working.
+Make a video --> things are moving, there are communications, they are working.
+
+One slide briefly: what is this experiment, what is the setup why is it important.
+Add this slide before slide 7 --> show this experiment.
+
+Slide 7 -- why these requirements are not filled by the digital twins in the industry.
+Slide 8 -- show the video/pictures of some terminals: "We have a simulation running here, a Kafka broker running here".
+Show a video --> short but precise.
+Things being sent to each other.
+Slide 9 -- this is an example of what you could do.
+You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
+''There is a model designed to achieve certain requirements, we can show that it works, we can show that this is happening here.''
+
+There experiment is a result of WHAT YOU COULD DO.
+Then the precise numeric values are less important.
+Then this is OK to show that the setup is not fully realistic.
+
+FOR SURE HAVE AN INTRODUCTION WHERE YOU EXPLAIN THE EXPERIMENTS.
+SHOW THE SETUP IN A SLIDE.
+
+Slide 6 -- think how you are going to introduce this slide.
+Argument the `Digital Thread` well.
+All the sort of, orchestrator layer or managing layer which makes it so these 2 can work together is the Digital Thread.
+Say ``We introduce the Digital Thread'', if this is something you introduce, try to say "This is the important thing in the graph".
+
+Slide 7 --> make it named datacenter, NOT digital twin.
+DO datacenter (physical twin).
+You still establish the connection between the digital twin and the datacenter.
+
+Change KV Cache -- to Cache. Or Caching Subsystem.
+
+Make sure slides 6, 7 and new 8 are very strong.
+
+Make it very clear why we need this new model, model in slide 7.
+
+One of the original contributions -> the idea of introducing a way to evaluate digital twin architecture.
+
+The 3rd contribution is how you experiment.
+You cannot just go and test digital twins on large systems, because we do not have large systems at hand.
+They way we test this, is by using multiple simulators.
+We use an additional simulator to run these experiments.
+
+Do NOT go above 10 slides.
+What you could do is say "this is my dt diagram" in slide 6 -- make this more abstract.
+Because we had this image (dt <-> dc) and circle <dc> and say "Many researchers do not have access to this".
+Instead we replace <dc> with a <simulator>.
+We do not have access to a cluster.
+
+Slides look OK.
+AtLarge style : what things we think are important to introduce in the slide.
+
+Figure 1.5 is too much text for a presentation.
+
+Be careful with not having too much text: too much text is too bad.
+
+Add animations at the end.
diff --git a/notes/20260513_140457.png b/notes/20260513_140457.png
deleted file mode 100644
index 15f29c1..0000000
--- a/notes/20260513_140457.png
+++ /dev/null
diff --git a/notes/20_07_2026.txt b/notes/20_07_2026.txt
new file mode 100644
index 0000000..33c6ecb
--- /dev/null
+++ b/notes/20_07_2026.txt
@@ -0,0 +1,15 @@
+1. The thesis feedback and general comments about the work.
+2. The OnStage problem is not yet resolved. We need to get Alex to reply urgently.
+Send the final version through slack and email to Dante and Alex.
+To a good reproducibility capsule and make a good experiment section.
+Quality over quantity.
+Dante would prefer much more if the artifact for your work is good.
+Expand on the experiments you have now, in your artifact, then implement a whole new thing.
+Spend 1 or 2 more days on the artifact.
+***For the experiment section try to make it less overwhelming.***
+***Add a higher level of abstraction.***
+Make sure the thesis is done on Wednesday.
+Ideally tomorrow evening.
+Write to Matthijs and Alex:
+Hey guys, this is the final final version, I have made the following changes to the previous version.
+Like a path or a bugfix in a github repo.
diff --git a/notes/23_06_2026.txt b/notes/23_06_2026.txt
new file mode 100644
index 0000000..b5b8075
--- /dev/null
+++ b/notes/23_06_2026.txt
@@ -0,0 +1,19 @@
+Try to make the demo after slide 7 so that it shows Kafka and Postgres receive data from the real datacenter.
+Just to show things are connected.
+Consider showing the experiment with alarms live.
+Figure 1.5 is fine.
+Change the caption to figure 1.5, it cannot be just another text-box i.e., make it _less_ informative overall.
+Caption 1.5 -> visualisation of the digital twin.
+Currently the caption 1.5 is NOT the description of the figure.
+TODO("Change caption 1.5. Captions should be shorter, figure descriptions should be in captions, at most one line description if you _really_ want to have it in the caption.")
+
+Make the "Solution - use a 2nd simulator" green instead.
+Change the "how did you solve the problem" into green.
+Keep the upper cloud ("the problem") red.
+
+Align figure 1.5 better --> do not make the lower part of the figure moved to the left.
+Change the figure 1.5 so that it is aligned vertically.
+
+In your figure it is not clear that what you see on the top is the problem.
+The second thing is too similar to the first thing in the figure.
+If you align that perfectly (the first thing and the second thing), align everything, AND you add some clear some arrow, it becomes more clear that "this is an implementation of that".
diff --git a/notes/24_06_2026.txt b/notes/24_06_2026.txt
new file mode 100644
index 0000000..8bede01
--- /dev/null
+++ b/notes/24_06_2026.txt
@@ -0,0 +1,66 @@
+==__==
+Typically atLarge is a bit more lenient when it comes to deadlines.
+You can submit your thesis until 15 of July by the faculty, but by atLarge you can submit it even later.
+Make sure you tell your supervisor when you plan to hand in your thesis.
+
+For the findings and the experiment section really try to follow the format that we have tried to teach you:
+1) Show what the main findings are
+2) Show the main setup
+3) Have multiple plots or tables to show your finding
+
+Recipe to explain experiments:
+How to evaluate something?
+Real world setting, simulation, mathematical analysis etc.
+Argue that --> "We do simulation based experiments".
+For experimental approach -- checklist:
+1) Workload --> I should explain what I run on my system and why that makes sense.
+You have a simulator run something, or you will inject failures, or you will expose the system to something.
+Is it realistic to expose the system to this workload?
+Does it make sense?
+
+2) Environment --> For a simulator: on what machine do you run the simulator, does it make sense to run this kind of experiment on the machine.
+
+3) (System-under-test) -> How did you configure OpenDC? What settings did you configured to run it? How did you configure redis?
+How did you configure the Kafka filters? Why does these settings make sense?
+
+4) Metrics --> why are you measuring these metrics? Why does this make sense?
+Why are the metrics representative.
+
+If the experiment setup is standard --> you can skip over it.
+You can say that you did a look through the literature about the kinds of use-cases your work can be beneficial for.
+One of the use-cases is an experiment that this related work, (DyTwin) did.
+Through my work I designed and Implemented this to be something that you can experiment with easily instead, not one-off.
+DyTwin was a one-off system. My system allows experimentation like this much more convenient, and NOT one-off.
+DyTwin was one-off system, now using our system can do this much more easily and not one-off.
+We IMPROVE on the work of DyTwin.
+
+We replicate their experiment, we get practically the same results, that validates THEIR work and YOUR OWN work.COMPARE on the same slide THEIR results, and OUR results.
+
+A lot of questions will be about the soundness of your approach.
+There will NOT be a lot of questions about the technical details.
+The more senior people in the room will ask more questions about the methodological approach.
+You DESIGN-ed a system: "what method did you follow for system design?"
+"Why did you choose that method? How did you follow it?"
+"How do you argue that you answers for research questions are good?"
+"Are your research questions good? Why are they good? Why do they align with the rest of the thesis?"
+"Argue why your research questions are challenging, why are they scientific?"
+
+Approach, research questions, methodology, the analysis of experiments.
+Frequent experiment analysis questions: "Why just the mean?" "Is there performance variability?" "Do you always get the same results?" "What can we learn if we look at the distribution?" "How many times did you repeat your experiments?" "What is the standard deviation?"
+
+SHOW IN YOUR ANSWERS YOU HAVE A JUSTIFICATION FOR THESE QUESTIONS.
+Explain that you have though about things.
+
+If you do not know the answer say: "Let me speculate..."
+Indicate honestly that you do not know, and then try to answer.
+
+As a presenter: be there just that day.
+Ask questions during other presentations.
+Support your team.
+Be there for the entire day or your slot perhaps.
+The rest of the day is appreciated, the entire slot is mandatory.
+Agree with the supervisor whether you passed or failed the presentation.
+It never happened that we let someone present and THEN fail.
+Usually they tell them that they have to do on more or two more things.
+Once you have some answer to your research questions, it is heavily unlikely you will fail.
+
diff --git a/notes/Background+Conclusion_Annot_Alexandru.pdf b/notes/Background+Conclusion_Annot_Alexandru.pdf
new file mode 100644
index 0000000..4a45a0e
--- /dev/null
+++ b/notes/Background+Conclusion_Annot_Alexandru.pdf
diff --git a/notes/Full_Document_Annot_Dante.pdf b/notes/Full_Document_Annot_Dante.pdf
new file mode 100644
index 0000000..726f301
--- /dev/null
+++ b/notes/Full_Document_Annot_Dante.pdf
diff --git a/notes/MJKwiatkowski_Dante_Feedback_Applied_Notes.pdf b/notes/MJKwiatkowski_Dante_Feedback_Applied_Notes.pdf
new file mode 100644
index 0000000..194db0a
--- /dev/null
+++ b/notes/MJKwiatkowski_Dante_Feedback_Applied_Notes.pdf
diff --git a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf b/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf
deleted file mode 100644
index 4e51e3d..0000000
--- a/notes/VU_BSc_Defense_Slides_Mateusz_Kwiatkowski-20260610-annot-jd.pdf
+++ /dev/null
diff --git a/notes/dante.txt b/notes/dante.txt
deleted file mode 100644
index 6c55eb3..0000000
--- a/notes/dante.txt
+++ /dev/null
@@ -1,20 +0,0 @@
-Create a model in draw.io
-Look at OpenTelemetry (read up - is this a lot of work?)
-https://github.com/atlarge-research/opendc/tree/radice-paper
-Make sure you the fields you specify in the schema itself are automatically exported.
-Measure Kafka latency of exporting. 
-Also ensure whether the user wants to export to database or not.
-Add multiple export functions.
-Make sure specify the config files in the command line.
-The prediction should be about auto-scaling.
-BUT -> there is no auto-scaling.
-Do auto-scaling.
-Idle power takes a lot of energy. 
-Predicting when to turn nodes on and off would be nice.
-Datacenters are heavily underutilized.
-Predict when to turn the hosts on and when to turn them off.
-Look at the failure models and how they work in OpenDC - this is how I stop a host, and this is how I start back a host. 
-With auto-scaling you can do it a bit smarter or not.
-Do auto-scaling in OpenDC.
-Rescheduling.
-
diff --git a/notes/image (2).png b/notes/image (2).png
deleted file mode 100644
index be41833..0000000
--- a/notes/image (2).png
+++ /dev/null
diff --git a/notes/20260513_140254.png b/notes/screenshots/common_pitfalls.png
index 3ebc53a..3ebc53a 100644
--- a/notes/20260513_140254.png
+++ b/notes/screenshots/common_pitfalls.png
diff --git a/notes/image (1).png b/notes/screenshots/good_figure_from_dante.png
index be41833..be41833 100644
--- a/notes/image (1).png
+++ b/notes/screenshots/good_figure_from_dante.png
diff --git a/notes/image.png b/notes/screenshots/good_figure_from_dante_2.png
index 09c7043..09c7043 100644
--- a/notes/image.png
+++ b/notes/screenshots/good_figure_from_dante_2.png
diff --git a/notes/20260513_133444.png b/notes/screenshots/introduction_timeline.png
index ed2124d..ed2124d 100644
--- a/notes/20260513_133444.png
+++ b/notes/screenshots/introduction_timeline.png
diff --git a/notes/20260513_135756.png b/notes/screenshots/map_of_thesis.png
index a0729d8..a0729d8 100644
--- a/notes/20260513_135756.png
+++ b/notes/screenshots/map_of_thesis.png
diff --git a/notes/updated_experiments.txt b/notes/updated_experiments.txt
new file mode 100644
index 0000000..38f1df5
--- /dev/null
+++ b/notes/updated_experiments.txt
@@ -0,0 +1,4 @@
+Changes to be added to basic OpenDC (make a fork.)
+1. Add new scheduling mechanisms and run an experiment with that: FIFO, HEFT, Random, Filter, Memorizing.
+2. Change the VictimSelector and run an experiment with that.
+
diff --git a/notes/vu_thesis_template_advice.pdf b/notes/vu_thesis_template_advice.pdf
deleted file mode 100644
index 8eb63fe..0000000
--- a/notes/vu_thesis_template_advice.pdf
+++ /dev/null