# 2023-04-25 Meeting minutes
###### tags: `Meeting`
**08:00 | Zoom**

Present: Martin, Mathias, Jacob, Christoffer, Linn, Edvin

## Before the meeting
* Continue with coding and writing

## Agenda
* Around the table
* Current status:
* **Fackspråkshandledning 25/4 11.00**
* Today! In this Zoom-meeting.
* (**in 2 days**) 27/4 Send thesis to Yehia for big readthrough (80% inlämning)
* Write about result and discussion (hopefully almost all of it)
* Most of the benchmarks should be completed
* (**in 9 days**) 4/5 Fackspråk send in thesis
* No preparation needed, just send question on that day. (Friday meeting)
* (**in 9 days**) 4/5 Thesis writing workshop with the library
* Could ask any remaining questions about structure and language
* (**in 16 days**) 11/5 Fackspråk-supervision about presentation and film
* (**in 20 days**) 15/5 Sammanställd slutrapport
* Conclusion and abstract, feedback from supervisor and fill out results with benchmarks etc
* (**in 21 days**) 16/5 Contribution Report due date
* Everyone should have filled out their own parts of the [Contribution Report](/L4RI0rM1STaejiVBN2n4CA)
* (**in 22 days**) 17/5 Filmen
* Might do it earlier, or start preparing earlier, but at the latest it will be done during the two days between finished report and film due date
* (**in 27 days**) 22/5 Skriftlig individuell opposition
* (**in 30-31 days**) 25-26/5 Slutredovisning & Opposition
* Create the presentation during this week
* Much can be reused from the film and thesis
* Simultaneously, the opposition will be prepared
* Re-prioritize backlogs
* Go through issues in `New`
* (09:00) Supervisor's wise words
* (11:00) Round two of fackspråkshandledning
* Questions for fackspråk is further down in the document

## Questions for Fackspråk
1. Are we using the "method"-section correctly?
* Are we going too far in Method when we say "This was useful during development of a concurrently executing ECS-engine, as it reduced the number of possible implementation mistakes."?
* Add noun "this x"
* Make the method-introduction describe the different parts more specifically. (what types of tools are used and need to be picked). Mention the different phases
* In "Framework and Languages" we should describe why we chose Rust, rather than state "we chose Rust". Make the transition smoother
2. Are we using the "related works"-section correctly? Is it a good idea to structure it chronologically?
3. How should we structure results? We have thought about dividing it into three parts: first part describes the engine implementation and how to use it, the second part presents and describes our benchmarking results, the third part describes our process of figuring out what implementation to use for the engine. Is this a good idea, or should it be done differently?
4. What is the exact distinction between results and discussion? Is it okay to motivate decisions in results, or is that considered discussion?
* Is it okay to explain our reasoning in the results? And connect it to literature?
* Structure of Result:
* 1) Final Product
* 2) Development process: (Prototype, MVP, Engine Development & Benchmarking)
OR
* 1) Final Product, 2) present the development process of each
* It's okay to comment shortly, but not discuss further.
5. Could you read through our current "Purpose and Goal". Should we change the tempus used there?
* It's okay, leave it as is.
7. "Safely executed concurrently" -- "Safely executed, concurrently" which one should we use, how do we order the words?
* "Safely and concurrently executed"
9. In results, the section of "Rendering and simulation thread decoupling": is it okay to use "our" or should we prefer to not be as personal?
* Try to avoid it where we can, but it is not forbidden to use. However, look over if the usage makes the sentence more informal, such as "In our case..."
11. Is it okay to discuss what other solutions do differently than ours, after having presented our own inside of results? Or should this go in "related works"/"discussion"
13. In the conclusion section: can we have a discuss about experiences from the development process, and what would be done differently or the same in future work?
* It's okay, but it shouldn't be too long. Fits better in the contribution report. Not too much speculation and presenting about what we've learnt. Not reflection.
14. Do you know how strict the "50-page content" limit is? As long as we're under the word limit. We have a lot of figures and tables, do you have any tips?
* Ask examinator!
16. Our supervisor said that figure text should be very short, a single sentence as a title. We have heard in other courses that it should be descriptive and standalone.
* Make figures less "talkative", single-sentence. Not as descriptive.

* In results, focus on what's "visible". Write about prototyping in discussion
* Make sure to update how much emphasis is placed on prototyping in method
* Tone down "Not Being able to exhaustively validate implementation"
* Take up as "future work" in Discussion
* 4.6.2 should be part of a larger "testing" chapter if it should be in result

Konsekvent system för figurtexter

Kan flytta ut deskriptivt till löpnade texten.

Färgläggning och sådant görs gärna i figurtext

Listings kanske figur?

Metod är på tyå på rätt sätt

I intro till metod kan vi göra en mer övergripande översikt
Vilka metoder behövs användas i sådana här projekt
Motivering kan gå bra i metod om det är sparsamt
"This function/ procedure was useful" istället för det gamla

Framework and languages:
Vi behövde väja ett programmeringsspråk och vi hamnade på rust eftersom att NÅGOT. Motivera kan passa på ett sådant sätt. Vi behövde denna typ av programmeringsspråk pga dessa funktionerna

Kan referera till referenser och gå igenom ett exempel istället för att lista allt för att spara plats. Tappar kanske lite styrka i motiveringen

Kanske förklara vad prototyping innebär. Förbered läsaren för att det finns en prototyping phase. Denna kan presenteras i introt.

Background:
Kan ändras till theory

Översikt till även denna sektion

Related works vad är tanken bakom denna sektion?

Om vi ska ha med jämnförelsen mellan ECS och OOP lägg den utanför related works

Kronologiskt fungerar men kanske passar bättre att sortera efter teman och vad som är relevant idag. Känns som vi pliktskyldig redogör historian istället för att beskriva aktuellt relevanta grejer.

"Stora utvecklingen har skett genom industrin"

Den historiska översikten stör inte eftersom den är kort men kan ändras till teman och aktuella saker

Purpose and goal:
Framgår inte varför vår ECS behövs skapas.

Dokumentations vinkeln funkar. Kompetensvinkel kan också fungera

Tempus fungerar bra behövs inte petas.

Resultat:
Implementation, Benchmarking Processen

Översiktligt fungerade strukturen strukturen vi skickade bra

Kronologi inte ofta bra sätt att presentera. Utgå från teman och frågor istället.

Tänk på hur saker presenterats tidigare så att det blir någon form av strukturer som kanske passar bra över löpande avsnitt.

Om strukturen mellan avsnitt ändras kan detta presenteras i intro översikten av kapittlet

Översikten av kapittlet är bra att börja med.

Eftersom vi nämnt mycket om prototyping tidigare kanske lite av detta ska med i resultatet men slutgiltiga resultatet är det definitivt viktigaste

Prototyping kan tas upp mer i diskussionen för de delar vi inte använder

Resultat som vi fått kan kommenteras men diskussioner ska in i diskussionsavsnittet

System schedule: Börja inte med "slow endeavour" utan börja med det statiska schemat så att vi får en annan vinkel på stycket

NBATEVI🤢🤮: Det som inte gick att göras kan tonas ner och tas upp i diskussion som vidareutveckling.
Under sektion för validering?

Mindre utrymme i texten för saker som inte används.

Safely and concurrently executed.

Safely executed concurrently funkar då den används ofta.

Our går att använda men "our case" = "our system"

Undvik att använda our. Tona ner användningen men behövs inte tänkas på jättemycket.

Kan motivera användningen av our genom att säga att vi comparar mellan vår och en annan motor

Mycket av publikationer är lite mer informella i data it området

Jämnförelse mellan motorer ser att fungera i resultat men kan läggas i teori sektionen om det passar.

Future work kan finnas i diskussion men inte för mycket spekulation och får inte bli för lång. Får inte bli för mycket reflektion i diskussionen.

Fråga examinator om ordgräns + sidgräns.

## Comments from Yehia
* Enhance introduction with the content of 2.1.
* Q: "how deep should we go in the introduction?" A: If you will not talk about OOP vs ECS, you do not have to present the historical background.
* You do not need to go deep on the history of ECS. I do not think we learn anything from it?
* ddmin algorithm - You need small test-cases for easier debugging.
* You can shorten the explanation of readers and writers
* Explain what the sceenshots of the profiling tool mean, what does it mean that 'gravity' is run concurrently?
* Include this (intra-system parallelism) explanation of how or why the gravity system can work on multiple entities.
* Add a second screenshot where you explain the safety problem with batches.
* You should make some captions shorter, use the caption as a title, example: "An Example of a RECS simulation implementation"
* You do not need all these longs listings. Use concise and short listings. Show one thing at a time, and do not show things that you have already shown again.
* You should have the comments that is part of the listings in your text instead.
* If the listing is very complex and have many sub-listings, then long captions can be used, but they are very rare.
* Why mention Amdahl's Law everyone knows this law.
* I have a suggestion: I don't think these results are representative, because they do not show a pattern. Look at smaller body count step sizes, 20_000, 30_000... To show where it stabilizes. you should then recommend that others should use your system for large number of entities.

## Kommentarer från fackspråk:
4.1 - bra längd på text.

4.2 - lite för mycket text. dela upp i två delar: a och b.
vad innehåller bilden för delar, vad är det man ska lägga märke till.
kolla gärna på andra exempel och välj ett system.

Ska man skilja på listings och figures? - Varför gör ni det?
kalla allt för figur.

Man kan lägga en kommentar på hur något är färglagt eller hur layouten ser ut i bildtexten.

* Fråga: Har vi tolkat metod på rätt sätt?
* Förbättra översikten: man måste välja språk, göra benchmarks. var lite mer specifika
* Vilka metoder måste man använda sig av.
* "this was useful during development": Det är en motivering till metoden.
* Varför använder ni Rust? - Förklara varför det valdes.
* Problem med sidantal
* Använd ett exempel från punktlistan kan korta ner.
* Beskriv att prototypes kommer presenteras i metod.
* Ni introducerar ECS igen i background, ni jämför också med OOP.
* Fråga: Fungerar det att presentera ECS kronologiskt?
* Skulle kunna presenteras enligt tema.
* Presentationen verkar lite pliktenlig och verkra inte fylla något syfte.
* Fråga: purpose and goal
* Finns det en kontrast mellan motorer och ramverk? Varför behöver ni bygga ett eget ramverk.
* Att ändra vinklingen skulle fungera
* Användningen av presens fungerar.
* Fråga: Resulatet
* En kronologisk presentationsordning är inte alltid den bästa, teman brukar vara att föredra.
* Att börja med en översikt är bra, sedan implementation, benchmarking...
* Tänk på hur ni presenterat saker tidigare och knyt samman till det.
* Om Prototyping nämns tidigt bör man nämna det senare.
* Fokusera på det ni använt, om prototyping inte varit en viktig del så nämn den inte i lika stor gard.
* Man kan kommentera resultat men inte ha långa utläggningar
* Loom skulle kunna nämnas i vidareutveckling i diskussion, istället för Resultat.
* Ok att använda "Our" om de är få, men används inte "our case", använd "in our system".
* Förslag på formulering: "safely and concurrently executed"
* Att jämföra mot andra motorer är ok i Result.
* Håll diskussionen kring vad ni lärt er kort och med minimala spekulationer.

## Decisions
*

## Next meeting

**2023-04-28 | 13:00 | Zoom**

*