ajout paragprahes test vae début du stage (premier mois environ)

src/paper.tex

@@ -66,6 +66,7 @@
 
 \newacronym{gnn}{GNN}{Graph Neural Networks}
 \newacronym{cnn}{CNN}{Convolutional Neural Network}
+\newacronym{pvcnn}{PVCNN}{Point-Voxel CNN}
 \newacronym{arm}{ARM}{Auto-Regressive Model}
 \newacronym{nf}{NF}{Normalizing Flows}
 \newacronym{vdm}{VDM}{Variational Diffusion Models}
@@ -203,9 +204,6 @@ Dans le cadre de cette étude, nous nous intéressons à la génération de géo
 
 Il reste pertinent de noter que les méthodes présentées dans ce chapitre sont récentes et que la littérature évolue très rapidement. De plus, les méthodes présentées ici sont très nombreuses et il est impossible de toutes les présenter. Nous avons donc choisi de présenter les méthodes les plus pertinentes pour permettre une bonne compréhension globale du travail réalisé durant ce stage.
 
-% \cite{peng_shape_2021}
-% \cite{sulzer_deep_2022}
-
 \FloatBarrier
 \glsreset{gnn}
 \section{\gls{gnn}}
@@ -376,11 +374,9 @@ Le principe des \gls{nerf} est de modéliser une fonction de densité de rayon (
 
 L'un des aspects fascinants des \gls{nerf} réside dans leur capacité à apprendre des scènes complexes et à générer des rendus à partir d'un nombre limité de vues ou de données d'entraînement. Grâce à leur architecture neuronale et à leur capacité à modéliser la distribution des couleurs et des formes, les \gls{nerf} sont en mesure de synthétiser des scènes réalistes même à partir de quelques images.
 
-Dans notre cas, étant donné que notre ensemble de données ne convient pas à l'application des \gls{nerf}, nous n'utiliserons pas cette approche spécifique.
+Les \gls{nerf} sont donc une alternative aux méthodes traditionnelles de reconstructions de scènes par résolution d'un problème inverse. Cependant ces modèles peuvent aussi être utilisé conjointement avec d'autres réseau pour permettre d'obtenir des réseaux génératifs\cite{nichol_point-e_2022,takikawa_neural_2021,nam_3d-ldm_2022}.
-
-\cite{takikawa_neural_2021}
-\cite{nam_3d-ldm_2022}
 
+Dans notre cas, étant donné que notre ensemble de données ne convient pas à l'application des \gls{nerf}, puisque cela necessiterait un travail lourd de pre-processing (conversion de nos maillages/scènes en image via un moteur de rendu) et de post-precessing (marching cube) de notre dataset. Nous n'utiliserons donc pas cette approche.
 
 \chapter{Déroulement du stage}
 
@@ -413,24 +409,49 @@ Le principal ensemble de données sur lequel j'ai travaillé pendant mon stage s
   \label{fig:process-rotor37-1200}
 \end{figure}
 
-Chaque aube du jeu de données est une déformation de l'aube nominale. Ainsi tout les maillages possèdent le même nombre de points et la même connectivité. Pour donner un ordre de grandeur, chaque maillage est constitué de 29773 points, 59328 triangles et 89100 arêtes.
+Chaque aube du jeu de données est une déformation de l'aube nominale. Ainsi tous les maillages possèdent le même nombre de points et la même connectivité. Pour donner un ordre de grandeur, chaque maillage est constitué de 29773 points, 59328 triangles et 89100 arêtes.
 
 Chaque échantillon est constitué de deux fichiers distincts. Le premier est un fichier au format .vtk qui contient le maillage de l'aube, comprenant les positions 3D, les normales et la connectivité de chaque point du maillage. Ce fichier .vtk inclut également les champs physiques associés à chaque point, tels que la température, la pression, etc. Le second fichier est un fichier .csv qui contient des métadonnées globales spécifiques à l'échantillon, telles que les entrées et les sorties de la simulation \gls{cfd}.
 
+\FloatBarrier
+\section{Description de l'environnement de travail}
+
+L'équipe de mes tuteurs est basée à Châteaufort, sur le plateau de Saclay, où se trouve le site de l'entreprise. J'ai réussi à trouver un logement dans le nord de Palaiseau, à environ 40 minutes de trajet en bus. En moyenne, le nombre d'employés présents sur le site s'élève à environ mille personnes.
+
+Les locaux de l'entreprise se présentent sous la forme de vastes openspaces, partagés par un maximum d'une dizaine de personnes. Ils sont séparés par de grandes baies vitrées et répartis dans 3 bâtiments sur plusieurs étages. Les bureaux sont spacieux équipés d'au moins un grand écran, d'un clavier et d'une souris. Nous disposons également de salles de réunion, de salles de détente et d'une salle de sport.
+
+Chaque employé dispose d'une station de travail sous la forme d'un ordinateur portable, connecté à un dock sur le bureau. Afin de réaliser des calculs intensifs, nous avons la possibilité de nous connecter au cluster de calcul local, appelé Rosetta, utilisant le système slurm. Ce cluster est composé d'environ 3000 cœurs CPU, 50 GPU et dispose de plusieurs téraoctets de RAM et de stockage disque. Pour le développement de nos projets, nous exploitons la forge interne de Safran, qui est une plateforme GitLab dédiée. En outre, chaque employé a accès à la suite professionnelle Office 365, qui facilite la gestion des documents et des e-mails.
+
 \FloatBarrier
 \section{Test de l'état de l'art}
 
-Les implémentations que j'ai pris le temps de tester car le code était disponible sont les suivantes :
+En complément de ma recherche bibliographique, j'ai consacré du temps à tester différentes implémentations des papiers que j'ai pu trouver. Voici la liste des implémentations que j'ai pris le temps d'évaluer, ainsi que mes observations à leur sujet.
-VAE (sur des images)
+
-Graph VAE (geometric)
+\subsection{\gls{vae}}
-Graph U-net (geometric)
+
-Pointflow (à l'origine du dataset PointFlow, une modif de shapenet, code à chier)
+% parler du fait que pytorch geometric à facilité un peu la tache d'implem
-pointnet (pointcloud unquement, pas de graphe, code original à chier, mais plein d'implems mieux)
+
-PVCNN (code à chier, basé sur pointnet)
+L'une de nos premières initiatives a été de tester des réseaux basés sur les \gls{vae}. Après avoir lu des articles de recherche sur les \gls{vae}, j'ai réalisé plusieurs implémentations sur des images pour me familiariser avec ces concepts. Nous avons ensuite étendu ces expérimentations à des architectures spécifiques aux graphes. Les résultats obtenus étaient encourageants: le réseau était capable de générer des structures, mais la qualité des générations n'était pas exceptionnelle. De plus, nous avons constaté que le réseau était beaucoup trop volumineux par rapport à sa fonctionnalité.
-SPVCNN (torchsparse, pas réussi à faire marcher pour la diffusion)
+
-PVD (checkpoint, code à chier, trop chiant les opérations de voxelization devox en cuda + les métriques qui changent entre chaque papiers emd chamfer 1-NNA, en cuda aussi)
+En effet, dans le contexte des graphes, les opérations de "upsampling" n'existent pas de manière directe. Par conséquent, nous avons rencontré des difficultés lors du passage du vecteur latent (représentant une distribution gaussienne) à une représentation sous forme de graphe (noeuds + connectivité) dans le décodeur du \gls{vae}.
-KPConv (c'est français, pas mal non ?)
+
-LION (pas de checkpoint, mais code utile)
+Une première solution simple consistait à utiliser une ou plusieurs couches denses pour convertir le vecteur en un couple de matrices décrivant les positions et la connectivité des noeuds. Cependant, cette approche posait problème en raison de la taille des graphes que nous manipulions. En effet, avec des graphes de 30000 nœuds, cela impliquait une matrice de connectivité de taille $30000^2$, ce qui faisait exploser la complexité lorsque nous utilisions des couches denses.
+
+Pour donner un ordre de grandeur, si l'on utilisai un espace latent de taille 8, rien que pour prédire les positions 3D des points dans notre maillage (sans prendre en compte la connectivité), l'utilisation de couches denses impliquait déjà pratiquement 1 million de paramètres ($8 \times 30000 \times 3$). Prédire la connectivité était tout simplement impossible, car il aurait fallu une couche dense avec plus de $7$ milliards de paramètres ($8 \times 30000 \times 30000$), ce qui dépassait largement les capacités de calcul de nos ressources GPU.
+
+Une seconde solution consitait à utiliser une architecture plus intelligente, telle que Graph U-Net. Cette approche permettait d'éviter l'utilisation de couches denses dans le décodeur grâce aux connexions résiduelles (skip connections). Cependant, ce faisant l'information ne passait pas entièrement par l'espace latent entre le décodeur et l'encodeur. Par conséquent, il était impossible de créer un modèle génératif complet avec cette architecture, puisqu'une partie de l'information pour générer des échantillons était compris dans les skip connections.
+
+Face aux difficultés rencontrées avec les réseaux basés sur les VAE et les limitations de l'architecture Graph U-Net, nous avons pris la décision de mettre de côté ces approches. Et plus largement puisque la connectivité de nos graphes est "locale" (les noeuds sont connectés à leurs voisins proches dans l'espace), nous avons décidé de nous orienter vers des approches basées uniquement sur les positions des noeuds. En effet, la connectivité d'un nuage de points peut facilement être retrouvé via diverses techniques\cite{peng_shape_2021,sulzer_deep_2022}
+
+\subsection{\gls{pvcnn}}
+
+% Pointflow (à l'origine du dataset PointFlow, une modif de shapenet, code à chier)
+% pointnet (pointcloud unquement, pas de graphe, code original à chier, mais plein d'implems mieux)
+% PVCNN (code à chier, basé sur pointnet)
+% SPVCNN (torchsparse, pas réussi à faire marcher pour la diffusion)
+% PVD (checkpoint, code à chier, trop chiant les opérations de voxelization devox en cuda + les métriques qui changent entre chaque papiers emd chamfer 1-NNA, en cuda aussi)
+% KPConv (c'est français, pas mal non ?)
+% LION (pas de checkpoint, mais code utile)
 
 \FloatBarrier
 \section{Réimplementation de l'état de l'art}