This commit is contained in:
Laureηt 2023-08-18 13:39:12 +02:00
parent 9a23fcf063
commit 5960caaaa3
Signed by: Laurent
SSH key fingerprint: SHA256:kZEpW8cMJ54PDeCvOhzreNr4FSh6R13CMGH/POoO8DI
11 changed files with 154 additions and 18 deletions

BIN
assets/LION.jpg (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/classifier-free-guidance.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/classifier-guidance.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/gp.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/graphvae-architecture.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/kpconv-architecture.png (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/pointnet-architecture.jpg (Stored with Git LFS) Normal file

Binary file not shown.

BIN
assets/pvconv.png (Stored with Git LFS) Normal file

Binary file not shown.

View file

@ -6,3 +6,21 @@
url = {https://distill.pub/2017/feature-visualization},
doi = {10.23915/distill.00007}
}
@article{görtler2019a,
author = {Görtler, Jochen and Kehlbeck, Rebecca and Deussen, Oliver},
title = {A Visual Exploration of Gaussian Processes},
journal = {Distill},
year = {2019},
note = {https://distill.pub/2019/visual-exploration-gaussian-processes},
doi = {10.23915/distill.00017}
}
@article{pierzchlewicz2023defusingdiffusion,
title = {Defusing Diffusion Models},
author = {Pierzchlewicz, Paweł A.},
journal = {Perceptron.blog},
year = {2023},
month = {Feb},
url = {https://perceptron.blog/defusing-diffusion/}
}

View file

@ -21,6 +21,7 @@
\usepackage{amsfonts}
\usepackage{bbold}
\usepackage[numbers]{natbib}
\usepackage[hyperpageref]{backref}
\usepackage[french]{babel}
\usepackage{nomencl}
\usepackage{caption}
@ -129,6 +130,8 @@
\newacronym{gp}{GP}{Gaussian Process}
\newacronym{go}{Go}{Gigaoctet}
\newglossary{symbols}{sym}{sbl}{Notations mathématiques et symboles}
\newglossaryentry{fn}{
@ -310,6 +313,10 @@ Il existe plusieurs sous familles de modèles génératifs, chacune basées sur
Les \glspl{gan} sont la famille de modèles génératifs la plus renommée et également la plus ancienne~\cite{goodfellow_generative_2014}. Ces modèles reposent sur un principe compétitif impliquant deux réseaux de neurones. Le premier réseau, connu sous le nom de générateur, a pour objectif de produire de nouvelles données. Le deuxième réseau, appelé discriminateur, est chargé de distinguer les données générées par le générateur des données réelles. Le générateur est entraîné à tromper le discriminateur tandis que le discriminateur est entraîné à identifier les données générées par rapport aux données réelles. Cette compétition entre les deux réseaux permet de former le générateur à générer des données de plus en plus réalistes. Ce type d'apprentissage est auto-supervisé, car il ne nécessite pas l'utilisation d'annotations sur les données pour entraîner le modèle.
Mathématiquement, on peut poser le problème d'optimisation suivant:
\begin{equation}
\min_\text{G} \max_\text{D} L(\text{D}, \text{G}) = \mathbb{E}_{x \sim p(\boldsymbol{x})} [ \log \text{D}(x) ] + \mathbb{E}_{z \sim p(\boldsymbol{z})} [ \log (1 - \text{D}(G(z))) ]
\end{equation}
Les \glspl{gan} ont su démontrer leur efficacité pour générer des images réalistes. Cependant, ces modèles sont très difficiles à entraîner~\cite{arjovsky_towards_2017}. Les \glspl{gan} sont par exemple suceptibles à de nombreux problème~\cite{zhao_bias_2018}, tel que le problème de \textit{mode collapse}, où le générateur génère toujours la même image, mais aussi le problème de \textit{non convergence}, où le générateur et/ou le discriminateur ont une fonction de cout instable et ne convergent ainsi pas vers un équilibre de Nash, ou encore au problème de \textit{vanishing gradient}, où le discriminateur devient trop efficace et empêche le générateur d'apprendre.
Au fil des années, de nombreuses améliorations~\cite{salimans_improved_2016}, variations (WGAN~\cite{arjovsky_wasserstein_2017}, etc.) et cas d'applications (CycleGAN~\cite{zhu_unpaired_2020}, SGAN~\cite{odena_semi-supervised_2016}, SRGAN~\cite{ledig_photo-realistic_2017}, DragGAN~\cite{pan_drag_2023}, etc.) ont été proposées, mais ces modèles restent complexes à entraîner et à évaluer. De plus, ces modèles sont très sensibles aux hyperparamètres et nécessitent une grande quantité de données pour être efficaces.
@ -420,7 +427,7 @@ Soit $S_g$ un ensemble de nuages de points générés et $S_r$ un ensemble de nu
\begin{equation}
\text{JSD}(S_g, S_r) = \frac12 D_{\text{KL}}(S_g \| M) + \frac12 D_{\text{KL}}(S_r \| M), \quad M = \frac12 (S_g + S_r)
\end{equation}
La divergence de Jensen-Shannon est une mesure de la similarité entre deux distributions de probabilité. Elle est calculée comme la moyenne des \glspl{kld} entre chaque distribution et la moyenne de ces distributions.
La divergence de Jensen-Shannon est une mesure de la similarité entre deux distributions de probabilité. Elle est calculée comme la moyenne des \glspl{kld} entre chaque distribution et la moyenne de ces distributions. Contrairement à la \gls{kld}, la \gls{jsd} est symétrique et bornée entre 0 et 1.
Cependant, la \gls{jsd} utilise la distribution globale des nuages de points et non la distribution des nuages de points individuellements. Ainsi, un modèle qui produit toujours une "forme moyenne" peut obtenir un score \gls{jsd} parfait sans apprendre de distributions significatives.
\glsunset{cov}
@ -547,6 +554,15 @@ Si l'on remplace $q( y | \boldsymbol{x}_t )$ par $f_\phi ( y | \boldsymbol{x}_t
& = - \frac{1}{ \sqrt{1 - \overline{\alpha}_t} }\epsilon_\theta(\boldsymbol{x}_t, t) + \gamma \nabla_{\boldsymbol{x}_t} \log f_\phi (y | \boldsymbol{x}_t)
\end{align}
\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{classifier-guidance.png}
\caption{Conditionnement par Classifier Guidance}
\vspace*{-11pt}
\caption*{Source: \href{https://perceptron.blog/defusing-diffusion/}{Perceptron.blog, 2023}}
\label{fig:classifier_guidance}
\end{figure}
% https://perceptron.blog/defusing-diffusion/
La seconde méthode est appelée Classifer-Free Guidance~\cite{ho_classifier-free_2022, nichol_glide_2022} et repose sur l'entraînement d'un unique réseau de neurones ayant pour objectif d'apprend à la fois la distribution conditionnelle et non conditionnelle. En réarrangeant l'équation \ref{eq:165}, on obtient:
@ -559,15 +575,24 @@ En subsituant l'équation \ref{eq:166} dans l'équation ci-dessus, on obtient:
& = \underbrace{ \gamma \nabla_{\boldsymbol{x}_t} \log p(\boldsymbol{x}_t | y) }_{\text{conditional score}} + \underbrace{ (1 - \gamma) \nabla_{\boldsymbol{x}_t} \log p(\boldsymbol{x}_t) }_{\text{unconditional score}}
\end{align}
\begin{figure}[h!]
\centering
\includegraphics[width=14cm]{classifier-free-guidance.png}
\caption{Conditionnement par Classifier-free Guidance}
\vspace*{-11pt}
\caption*{Source: \href{https://perceptron.blog/defusing-diffusion/}{Perceptron.blog, 2023}}
\label{fig:classifier_free_guidance}
\end{figure}
Cette approche présente divers avantages. Premièrement, elle s'appuie sur un unique réseau de neurones, contrairement à la méthode guidée par classificateur qui en utilise deux. Deuxièmement, l'entraînement ne devient pas significativement plus complexe ; nous procédons de la même manière qu'auparavant, en ajoutant simplement les embeddings et en parfois excluant ces embeddings pour apprendre en conditionnement non contraint. Troisièmement, les données telles que le texte se prêtent difficilement à une classification en classes, et l'approche sans classificateur permet l'utilisation de vecteurs scalaires pour le conditionnement.
Dans notre cas d'application, nous pouvons conditionner sur les scalaires representant les performances de nos maillages.
% https://liorsinai.github.io/coding/2023/01/04/denoising-diffusion-3-guidance.html#guided-diffusion
\cite{zhou_3d_2021}
\cite{nguyen_point-set_2021}
\cite{zeng_lion_2022}
% \cite{zhou_3d_2021}
% \cite{nguyen_point-set_2021}
% \cite{zeng_lion_2022}
\FloatBarrier
\glsunset{arm}
@ -620,9 +645,9 @@ Je décrirai dans les prochaines sections les différentes étapes de mon stage,
Les premiers jours de mon stage ont été dédiés à mon intégration au sein de l'entreprise. J'ai rencontré mes tuteurs de stage qui m'ont présenté l'équipe et les différents membres du département. Une visite des locaux de l'entreprise m'a été proposée, accompagnée d'explications sur les mesures de sécurité en vigueur. J'ai également pris connaissance des outils et des logiciels utilisés dans le cadre de mon projet. Ces premiers jours ont été l'occasion pour moi de participer à des réunions d'équipe, en présence d'autres stagiaires et d'ingénieurs, afin de me familiariser avec les différents projets en cours et de préciser les objectifs de mon stage.
Les deux premières semaines de mon stage ont été dédiées à la lecture approfondie de la littérature scientifique liée à mon domaine d'étude. J'ai effectué des recherches bibliographiques afin de recueillir des informations pertinentes sur les avancées récentes, les théories et les techniques utilisées dans le domaine des modèles génératifs. J'ai majoritairement consulté des articles de conférence et des documents en ligne pour obtenir une vue d'ensemble complète des travaux antérieurs réalisés par des chercheurs et des ingénieurs. Pour appronfondir mes recherches, j'ai également utilisé des outils, tels que Semantic Scholar ou Papers with code, pour trouver les codes sources des papiers ainsi que des papiers ayant pour citation ou référence les articles que j'avais déjà lus, me permettant ainsi de découvrir de nouvelles publications pertinentes.
Les deux premières semaines de mon stage ont été dédiées à la lecture approfondie de la littérature scientifique liée à mon domaine d'étude. J'ai effectué des recherches bibliographiques afin de recueillir des informations pertinentes sur les avancées récentes, les théories et les techniques utilisées dans le domaine des modèles génératifs. J'ai majoritairement consulté des articles de conférence et des documents en ligne pour obtenir une vue d'ensemble complète des travaux antérieurs réalisés par des chercheurs et des ingénieurs. Pour appronfondir mes recherches, j'ai également utilisé des outils, tels que \href{https://www.semanticscholar.org/}{Semantic Scholar} ou \href{https://paperswithcode.com/}{Papers with code}, pour trouver les codes sources des papiers ainsi que des papiers ayant pour citation ou référence les articles que j'avais déjà lus, me permettant ainsi de découvrir de nouvelles publications pertinentes.
Lors de ma lecture, j'ai pris des notes (via les logiciels Logseq et Zotero) sur les concepts clés, les méthodologies et les résultats des études. J'ai analysé et comparé les différentes approches proposées dans la littérature afin de mieux comprendre les avantages et les limites de chaque méthode. Cette phase de lecture m'a permis d'acquérir une solide base de connaissances et de me familiariser avec les travaux existants dans le domaine. Ces connaissances préliminaires ont été essentielles pour orienter mes travaux ultérieurs de développement et de recherche lors du stage.
Lors de ma lecture, j'ai pris des notes (via les logiciels \href{https://logseq.com/}{Logseq} et \href{https://www.zotero.org/}{Zotero}) sur les concepts clés, les méthodologies et les résultats des études. J'ai analysé et comparé les différentes approches proposées dans la littérature afin de mieux comprendre les avantages et les limites de chaque méthode. Cette phase de lecture m'a permis d'acquérir une solide base de connaissances et de me familiariser avec les travaux existants dans le domaine. Ces connaissances préliminaires ont été essentielles pour orienter mes travaux ultérieurs de développement et de recherche lors du stage.
Au cours de cette période, j'ai également eu des discussions régulières avec mes tuteurs de stage pour discuter des articles lus, clarifier certains points et définir la direction à suivre pour mon projet. Ces échanges m'ont permis d'approfondir ma compréhension et de cibler les aspects spécifiques sur lesquels je devais me concentrer lors des prochaines phases de mon stage.
@ -649,68 +674,120 @@ Le principal ensemble de données sur lequel j'ai travaillé pendant mon stage s
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}.
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}. L'ensemble de ces fichiers pèsent environ 60 \glspl{go} et sont stockés dans un dossier spécifique read-only (en lecture seule) sur le cluster de calcul de Safran.
% TODO: rajouter la liste exhaustive de **tous** les champs phyisques
% TODO: mettre ici un plot de la distribution des données (perfs + positions et autres)
Cet ensemble de données peut être séparé en deux sous-ensembles : un ensemble d'apprentissage de 1000 échantillons (83\% des données) et un ensemble de validation de 200 échantillons (17\% des données). L'ensemble d'apprentissage est utilisé pour entraîner les modèles génératifs, tandis que l'ensemble de validation est utilisé pour évaluer les performances des modèles génératifs.
Afin de simplifier le chargement de données, j'ai choisi d'utiliser la bibliothèque HuggingFace Datasets~\cite{lhoest-etal-2021-datasets}. Cette bibliothèque se distingue par son utilisation innovante de la technologie Apache Arrow~\cite{arrow} pour stocker les données de manière tabulaire en colonnes, permettant des lectures sans copie (zero copy reads) ainsi que les opérations de mapping prenant en charge le multi-threading. Grâce à une approche de chargement paresseux (lazy loading), elle évite les problèmes de mémoire et assure la reproductibilité en sauvegardant en cache les transformations intermédiaires des données.
En complément de Rotor37\_1200, j'ai également travaillé sur un ensemble de données plus grand appelé Rotor37\_11000, qui contient 11000 échantillons. Cet ensemble de données a été créé via le même processus d'optimisation que Rotor37\_1200, cepandant les déformations qu'il contient sont d'un ordre de grandeur plus élevé.
% TODO: insérer viz rotor37_11000
% parler de la simulation full, qui comporte plusieurs millions de points, ainsi que la nacelle ?
\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.
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 500 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.
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. Pour communiquer, pour les visioconférences nous utilisons principalement Microsoft Teams, qui permet de passer des appels audio et vidéo, de partager son écran et de discuter par écrit, pour les échanges rapides nous utilisons la messagerie instantanée chiffrée de bout en bout Citadel.
La stack technique utilisée par l'équipe est basée sur Python, avec des bibliothèques telles que PyTorch, PyTorch Geometric, PyTorch Lightning, NumPy, SciPy, GPy, Matplotlib, Seaborn, Scikit-Learn, etc. Nous utilisons également des outils de gestion d'environnement virtuels Python tels que Conda et Micromamba, ainsi que de l'outils de gestion de version Git. Le cluster de calcul étant coupé d'internet, nous utilisons accédons à un artifcatory pour télécharger les dépendances nécessaire.
% parler un peu des outils, python, pytorch, toussa toussa, conda, mamba, artifactory, coupé internet proxy
% décrire le process de réservation slurm ?
\FloatBarrier
\section{Application de l'état de l'art}
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 et idées que j'ai pris le temps d'évaluer, ainsi que mes observations à leur sujet. plus ou moins chronolgique
À la suite de ma recherche bibliographique, j'ai consacré du temps à expérimenter diverses implémentations des articles que j'avais identifiés. Voici la liste des implémentations que j'ai évaluées, les idées que j'ai explorées, ainsi que mes observations relatives à chaque approche, dans un ordre approximativement chronologique.
\FloatBarrier
\glsunset{vae}
\subsection{Approche par \acrfull{vae}}
% parler du fait que pytorch geometric à facilité un peu la tache d'implem
L'une de nos premières initiatives a été de tester des réseaux basés sur les \glspl{vae}. Après avoir lu des articles de recherche sur les \glspl{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é.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{graphvae-architecture.png}
\caption{Architecture de GraphVAE}
\label{fig:graphvae_archi}
\end{figure}
L'une de nos premières initiatives a été de tester des réseaux basés sur les \glspl{vae}. Après avoir lu des articles de recherche sur les \glspl{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 via GraphVae~\cite{simonovsky_graphvae_2018}. 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é.
% insérer ici screen des résultats de graphvae
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}.
Une première solution simple consistait en l'utilisation de une ou plusieurs couches denses pour convertir le vecteur latent 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 aisaiment exploser la complexité lorsque nous utilisions des couches denses.
Une première solution simple consistait en l'utilisation de une ou plusieurs couches denses (\glspl{mlp}) pour convertir le vecteur latent 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 $n=30000$ nœuds, cela impliquait une matrice de connectivité de taille $n^2 = 30000^2 = 9.10^9$, ce qui faisait aisaiment 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 d'une seule couche dense 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.
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 d'une seule couche dense impliquait déjà $8 \times 30000 \times 3 = 7,2.10^6$ paramètres. Prédire la connectivité était tout simplement impossible, car il aurait fallu une couche dense avec plus de $8 \times 30000^2 = 7,2.10^{10}$ paramètres, 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}
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}.
\FloatBarrier
\glsunset{nf}
\subsection{Approche par \acrfull{nf}}
% Pointflow (à l'origine du dataset PointFlow, une modif de shapenet, code à chier)
Pointflow est approche la plus connue pour faire du nf sur des nuages de points. Modifier l'implémentation originale pour pouvoir utiliser Rotor\_37 était facile, les résultats étaient meilleurs que ceux de GraphVAE, mais pas exceptionnels. L'architecture du code était également plutôt difficile à utiliser et à modifier, tel un bon code académique.
PointFlow aura tout de même contribué à la création d'un dataset de référence pour les nuages de points, qui est désormais utilisé par de nombreux articles de recherche. Ce dataset est basé sur ShapeNet, un dataset d'objets 3D, et a été modifié via un furthest point sampling. De même PointFlow aura contribué à l'implémentation en cuda des différentes méteriques et distances telles que la chamfer distance, la earth mover distance, etc.
\FloatBarrier
\glsunset{vdm}
\subsection{Approche par \acrfull{vdm}}
Pour prédire le bruit dans le processus de diffusion, conformément à la section intitulée "État de l'art" dans ce document, il est essentiel de sélectionner une architecture de réseau de neurones. Dans notre cas, puisque nous travaillons sur nuages de points, il convient d'utiliser des architectures adaptées à ce type de données.
Dans le contexte de l'apprentissage sur les nuages de points, une architecture a émergé comme la norme, à savoir PointNet. PointNet est une architecture basée sur des shared MLPs (Multi-Layer Perceptrons, qui peuvent être vus comme des convolutions de noyau 1x1) qui permettent de traiter des nuages de points, indépendemment du nombre de points. archi interessante car permutation invariant, mais aussi robuste à certaines transformations comme les rotations et translations.
Par la suite, amélioration de pointnet et désormais la norme, PointNet++ propose une approche profonde hiérarchique qui exploite une combinaison d'échantillonnage, d'agrégation et de suréchantillonnage pour permettre l'extension d'opérateurs locaux aux champs globaux réceptifs, entre autres.
Dans le contexte de l'apprentissage sur les nuages de points, une architecture standard est PointNet. PointNet est une architecture basée sur des shared MLPs (Multi-Layer Perceptrons, qui peuvent être vus comme des convolutions de noyau 1x1) qui permettent de traiter des nuages de points, indépendemment du nombre de points. archi interessante car permutation invariant, mais aussi robuste à certaines transformations comme les rotations et translations.
Par la suite, une amélioration conséquente du modèle PointNet a abouti à l'émergence de PointNet++, désormais considérée comme l'architecture de référence dans le domaine. PointNet++ présente une approche hiérarchique en profondeur qui capitalise sur une fusion de techniques d'échantillonnage (furthest point sampling) et d'agrégations (knn) des points du nuage. Cette approche permet ainsi d'élargir la portée des opérateurs locaux pour englober des champs globaux réceptifs, et ainsi améliorer les performances du réseau.
% insérer ici image archite pointnet et poitnet++
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{pointnet-architecture.jpg}
\caption{Architecture de PointNet et PointNet++}
\label{fig:pointnet_archi}
\end{figure}
% KPConv (c'est français, pas mal non ?)
autre archi bien connue dans le traitement de point clouds, archi semblable à pointnet++, mais le sampling est fait via une grille de voxelle, et l'aggragation est faite via des KPConv, qui sont une ball query. c'est français
Une autre architecture largement reconnue dans le domaine du traitement de nuages de points, présentant des similitudes avec PointNet++, est nommée KPConv. Cette architecture utilise un échantillonnage basé sur une grille de voxels et l'opération d'agrégation par des KPConv, qui sont des convolutions sur boules. Cette architecture est également très efficace, et surpasse généralement les autres architectures sur les taches de segmentation.
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{kpconv-architecture.png}
\caption{Architecture de KP-FCNN et KP-CNN}
\label{fig:kpconv_archi}
\end{figure}
Appliqué à de la diffusion, KPFCNN
% PVCNN (code à chier, basé sur pointnet)
point voxel convolution, efficace, mais bcp de cuda
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{pvconv.png}
\caption{Architecture d'une PVConv}
\label{fig:pvconv_archi}
\end{figure}
% SPVCNN (torchsparse, pas réussi à faire marcher pour la diffusion)
version plus efficace, mais pas trop réussi à faire marche, cuda très esotérique
@ -727,6 +804,7 @@ le plus récent
Les premiers résultats concluant que nous avons obtenus ont été avec l'architecture KPFCNN. Cette architecture est basée sur PointNet++ et utilise des convolutions de type KPConv. Nous avons utilisé cette archi pour prédire le bruit lors de l'entraiment d'un \gls{vdm} (schedulers via huggingface diffusers). Les résultats étaient encourageants, mais nous avons constaté que le réseau avait du mal à apprendre à prédire le bruit en fin de sampling. en effet, les aubes finales semblaient encore un peu bruitées.
<insérer image ici>
\FloatBarrier
\glsunset{ldm}
\subsection{Approche par \acrfull{ldm}}
@ -738,17 +816,26 @@ on test d'autres méthodes parameter free, comme la POD, marche moins bien
second temps, on compress nuages de points via un AE, pas encore finis, mais inch ça marche
\FloatBarrier
\glsunset{cfg}
\subsection{Application du \acrfull{cfg}}
conditionnemnt, classifier-free guidance
\FloatBarrier
\glsunset{gp}
\subsection{Vérification par \acrfull{gp}}
\begin{figure}[h!]
\centering
\includegraphics[width=0.8\textwidth]{gp.png}
\caption{Régression par \gls{gp}}
\label{fig:gp_regression}
\end{figure}
pour vérif si la génération est bonne, on entraine des GP
\FloatBarrier
\chapter{Conclusion}
% conclusion, présenter résultats, adéquation objectifs, enirchessiement personnel, connaissance techniques et rapport humain.

View file

@ -52,3 +52,10 @@
url = {https://github.com/huggingface/diffusers},
version = {0.12.1}
}
@manual{arrow,
title = {arrow: Integration to 'Apache' 'Arrow'},
author = {Neal Richardson and Ian Cook and Nic Crane and Dewey Dunnington and Romain François and Jonathan Keane and Dragoș Moldovan-Grünfeld and Jeroen Ooms and {Apache Arrow}},
year = {2023},
note = {https://github.com/apache/arrow/, https://arrow.apache.org/docs/r/}
}