Stage de Jérôme Desroziers - Telecom Nancy - [4/06/18 au 3/08/18]

Important : cette page est réservée au suivi du stage, merci de ne pas la modifier

Informations générales pour les stagiaires

Pour toute information concernant ce stage : contacter André, François-Xavier

Sujet

• Proposition de stage

Stage (Juin - Août 2018)

Juin

• ------ Semaine 1
• 4: Relecture du code côté serveur pour se remémorer le fonctionnement des algorithmes et détecter les éventuelles erreurs
  -> fileSystemV2: source potentielle de bug détectée dans la fonction de génération des données binaires
  -> fileSystemV2: commenté le code
  Installation de jupyter notebook et testé génération du filesystem binaire: pas de bug
• 5: FileSystemV2: bel et bien un bug; n'apparaît théoriquement qu'à partir d'un niveau de profondeur physique dans l'arborescence >7,
  c'est pourquoi il n'a pas posé de problèmes lors des tests effectués sur de petits jeux de données => bug corrigé
  Tests sur un FS plus important: toujours bon
  OctreeFS.js: commenté le code (début)
• 6: Fin commentaires sur OctreeFS.js; nettoyage du code
  Commencé réflexion sur implémentation / maj de l'algo de génération de file system binaire:
  Grosso modo: l'algo actuel fonctionne mais uniquement pour les données issues de coda, plusieurs modifications sont nécéssaires si on veut avoir un algo généraliste
  -> 1ère étape: jump polymorphe; pour l'instant les jumps dans les feuilles s'effectuent avec un flag égal à -2 codé sur 8 octets qui indique l'arrivée sur un jump
  -> nouvelle implémentation possible: avoir en début de feuille le nb de pts relatifs avant le jump le plus proche (plus propre et marche partout)
• 7: Jump polymorphe en cours d'implémentation
• 8: Terminé l'implémentation des jumps polymorphes.
  Nouvelle maj de l'algo pour atteindre généralité: pouvoir faire accepter par l'algo des données quelconques (et pas juste des triplets xyz codés sur 24 bits comme c'est le cas actuellement)
  -> implémentation possible: avoir un (des) fichier(s) de conf qu'il faut paramétrer selon les besoins de la simulation, le reste est pris en charge par l'algo
  -> notamment le fichier de conf indique la structure d'un point de la simulation, nb d'éléments, nombre d'octets par élément, etc...
  Définition d'objectifs 'clairs' (pas dans l'ordre de priorité):
  i) Généralisation de l'application serveur à un jeu de données quelconque (en cours)
  ii) Mettre toute la doc de l'app en anglais (cf diffusion), i.e. partie client, partie serveur, readmes...
  iii) Créer base pour widget jupyter notebook avec fonctionnalités comme chargement fichier en local
  iv) charger intégralité de coda sur FS pour démo
  v) rédiger papier pour présenter application
• ----- Semaine 2
• 11: début implémentation des données polymorphes; de nombreux bugs rencontrés
• 12: fin de l'implémentation des données polymorphes
• 13: conséquence des données polymorphes: modification du reader pour toujours charger un ensemble de points par chunks de 200mo max
  correction d'un bug de réécriture sur les jumps des feuilles si leur taille est <2 (bug apparu après modifications pour données polymorphes)
• 14: Amélioration de l'algo: les données dégradées contiennent désormais des informations (moyennes) sur les = paramètres des points qu'elles réprésentent (hors xyz)
  -> chaque feuille a X champs en début de feuille, X étant le nombre de paramètres hors xyz dans un point de la simulation.
  chaque champ X contient la moyenne de chaque point de la feuille pour le paramètre associé, et est mis à jour dynamiquement lors de la génération de la base
  -> lors de la génération des données dégradées: on fait une moyenne pondérée des moyennes de chaque feuille et on associe les moyennes pour chaque champ au point dégradé
  Nouveaux objectif (pour algo généraliste):
  -> le nombre minimum de points par feuille doit varier en fonction de la taille des points (sinon: va causer problèmes si points très petits niveau données)
  -> côté client: il faut modifier la gestion des bornes au niveau 1) de l'outil de zoom 2) des données issues de simulations provenant du serveur
  (cf à l'origine: bornes fixes calquées sur les valeurs de coda: ne va plus si on veut traiter des simulations quelconques)
• 15: problème des bornes plus complexe que prévu, début de la création de la base avec les 600 premiers fichiers de la simulation
• ----- Semaines 3~4
• 18: résultat début création base: succès; 20h pour générer un arbre de 150G environ (à partir des ~350G des 600 fichiers d'origine)
  Aucun bug dans le fichier de log, la génération des données dégradées (+ leur affichage, + chargement de points dans l'arborescence) : tout marche
  Problème: lorsque le nombre de points est trop important: le serveur plante.
  Solution: implémenter un zoom récursif (et changer la façon dont sont faites les données dégradées)
  -> changer les données dégradées en un arbre de structure identique à la base binaire, dont les noeuds contiennent la somme des elts du dessous
  -> permet de cherger la vue dégradée d'une région précise
  + toujours le problème des bornes: de plus: le code côté client possède certaines parties mal implémentées (certaines procédures exécutées plusieurs fois au lieu d'une, buffers pour vidéo qui ne servent à rien dans les simulations...), à améliorer pour optimisation
  Priorité numéro 1: clean le code côté client
• 19-25: gros chantier.
  Grosso modo il faut redéfinir l'organisation des données en interne, côté client.
  Notamment plusieurs types différents de données coexistent (VOTable3d, VOTable2d, Script, etc...) et rendent la maintenance du code très difficile
  De plus de nombreuses fonctionnalités exclusives au type VOTable3d devraient être généralisées à l'ensemble des données, et améliorées, comme l'homogénéisation spatiale / des champs info des données lors de l'ajout/suppression de ces dernières.
  Une fois le modèle de données redéfini, il devrait être possible (facilement) d'étendre l'homogénéisation des données après un changement de ce dernier à une combinaison quelconque de champs, et pas seulement aux champs x y z.
  Travail effectué au 25:
  i) tout mettre en "votable 3D" et clean ce qui ne l'est pas
  - d'abord enlever tt les if(votable3D...)
  - puis enlever les champs metatype dans script et snap
  - ne plus utiliser d'octree dans data mais dans renderableData (idem pour les autres params maintenant fantômes...)
  ii) généraliser l'homogénéisation au système xyz => le système de bornes aux différents niveaux d'imbrication (snapshot, data, view) a été redéfini
  iii) généraliser à un système de coordonnées quelconque => modification du système de changement de coordonnées, notamment au niveau de la gestion des index et du buffer position dans le cadre de la redéfinition de l'octree
  Reste à faire:
  - finir le débuggage (vérifier bon fonctionnement multivues ET outil de zoom (mode normal et simulation))
  - nettoyer le code
  - mettre à jour le passage au log
• 26 - 29 : fin de la restructuration du système de données utilisé par le côté client, le passage à l'échelle logarythmique a été mis à jour
  Début de la modification de la gestion des données issues de simulations par l'application, l'algorithme utilisé par l'outil de zoom en local ne doit plus être utilisé pour les données provenant du serveur;
  les buffers doivent être chargés directement depuis la classe data à partir des données brutes.
• ----- Semaine 5
• 2 : fin des correctifs; le traitement des données issues du serveur par l'outil de zoom est Ok (plus de redimentionnement par rapport à la position de l'outil comme c'est le cas pour les données locales (cf pas nécéssaire du tout), les données passent directement dans les fonctions de redimentionnement dans renderableData)
  Les données dégradées issues du serveur contiennent désormais les bornes globales de la simulation; permet de générer un Octree de bornes quelconques et d'avoir des données dégradées normalisées en 0-1 (les requètes avec le code de morton fonctionnent toujours)
  -> les données dans l'outil de zoom ont désormais leurs propres bornes locales, que ce soit pour la mise en valeur d'infos ou pour l'homogénéisation spatiale (en local lorsque des points provenant de différents jeux de données se trouvent dans l'outil de zoom
  Mise en place d'un premier jet de la nouvelle version des données dégradées:
  - les informations sont contenues dans les noeuds du FS, à tous les niveaux, et non plus dans un système de répertoires à part avec un répertoire par niveau
  - UTILITE: devrait permettre de gérer le zoom récursif lorsque les données sont trop grandes côté client même avec outil de zoom, plus offre paramétrisation du niveau de zoom voulu par l'utilisateur
  - reste à corriger un bug sur la gestion des champs moyenne pour les données dégradées ET à effectuer des tests sur de plus gros jeux de données cf le temps requis pour charger une vie dégradée (par ex. avec un FS de 150Go)
• 3: correction du bug sur les données dégradées et tests pour vérifier intégrité des données; commencé draft de la partie serveur de l'article
• 4: Commencé mise en place du zoom récursif:
  - avant d'effectuer une requète sur la base, on effectue une détection du nb points qu'on va devoir envoyer en se basant sur les infos contenues dans les noeuds; si cette valeur est > seuil (225mo), alors on envoie à la vue esclave la version dégradée de la zone
  - nettoyage du code chargeant 27 octrees dont xxx qui se sauvegardent en mémoire si on se déplace cran à cran (bof bof au final car pas très utile niveau optimisation et obsolète à terme (cf gestion de la taille de la zone chargée directement via l'outil de zoom)
  - mise en place du paramétrage du niveau de profondeur des données dégradées depuis partie client, on peut recharger la vue dégradée à la volée avec un nouveau niveau
• 5: problème: l'implémentation courante des données dégradées ne fonctionne pas lorsque le nombre de feuilles est important (cf grand nombre d'ouverture/fermeture de fichiers; exemple pour une base de 150Go il faut 10 minutes pour générer les donées dégradées)
  i.e. il faut mettre en place une nouvelle implémentation
  Idée: créer un arbre à part qui contiendra uniquement les champs moyenne et weight des feuilles et noeuds, pour un niveau de récursivité de 7 cela permet de passer de ~1100 fichiers à ouvrir pour lire les infos dans les noeuds avec le système actuel à.... 1 seul fichier
  (c.f. 8^7 ~ 2097152 points maximum, i.e. si on a un champ moyenne et un champ weight 2097152*44= , et 200mo= 200 000 000 octets ce qui est largement suffisant)
• 6: continué conception algo données dégradées V2: plusieurs problèmes: il faut parcourir récursivement 2 arbres de profondeurs physique/binaire différentes en simultané; de plus si on veut gérer le zoom récursif il faut prévoir une subdivision de l'arborescence physique (cf on veut aller jusqu'à des niveaux de récursivité de 15.. 18...)
• ----- Semaine 6
• 9: fin de la mise en place de la V2 des données dégradées
  -> petit correctif au niveau de l'actualisation du champ donnée en surbrillance lorsqu'on change de niveau de donnée dégradée
  .....l'algorithme plante sur le FS généré à partir de 70go de données sur le serveur.... il faut débugger
• 10: SUCCES: DEGRADED DATA V2 WORKS (voir la documentation des fonctions associées dans la classe fileSystemHandlerV2 pour plus d'information)
• 11: finalisation de la mise en place du zoom récursif:
  - modification du comportement de l'outil de zoom dans la version client (déplacement) pour l'aligner avec l'octree sur le serveur (cf les zones qu'on charge correspondent à des cubes bien délimités dans le FS du serveur, il faut que le position du cube corresponde exactement à la position des données qu'on charge, pas juste qu'il représente la position approximative du centre)
  - la profondeur du code de morton utilisé dépend de la taille de l'outil de zoom (qui en mode de zoom serveur ne peut être que l'inverse d'une puissance de 8, avec la position centrée sur une feuille de l'octree)
  => reste à faire: mise en place du swap des données entre les vues pour gérer zoom récursif
• 12: - optimisation mémoire pour la génération des données non-dégradées: les champs moyenne dans les feuilles ne sont plus stockés dans l'arbre; mais générés à la volée lors de la création des données dégradées.
  - commencé mise en place du zoom récursif: basiquement si les données chargées dans la vue esclave sont des données dégradées, on peut charger ces dernières dans la vue maître en se basant sur le code de morton courant
• 13: finalisé mise en place du zoom récursif (correction de multiples bugs mineurs: problèmes de redimensionnement de l'outil de zoom sur les bords du cube de données, écrasement du code de morton courant lors du zoom récursif si la vue dégradée était regénérée et que l'outil de zoom n'était pas actif, problèmes de mise à jour des buffers pour l'affichage des données esclave après une mise à jour du niveau de vue dégradée, problème de mise à jour des bornes des données esclaves lors du zoom récursif)
  + modification du format de commande pour la génaration du FS (le format binaire est désormais le seul format)
• --- Semaine 7
• 16: - début de la création du FS CoDa sur Amazon, des problèmes ont été rencontrés au niveau de la gestion de la pile:
  -> taille de la pile insuffisante: modification du reader CoDa pour traiter les paquets de 200mo dès leur création (auparavant les paquets étaient traités... tout à la fin... ce qui permettait de gérer la taille des buffers mais pas la taille maximum des fichiers lus)
  -> utilisation de https://stackoverflow.com/questions/36216151/avoiding-stack-overflow-by-using-settimeout pour éviter une surcharge de la pile
  MAIS ce trick ne fonctionne pas spécifiquement avec Node.js: il faut utiliser setimmediate
  - début du travail sur l'implémentation Jupyter de l'application
• 17 - 18 : début de l'intégration d'AstroViz3D dans un jupyter notebook
  Objectif: juste réussir pour le moment à afficher le widget depuis un notebook.
  Problèmes: 1 - en utilisant le package fourni par jupyter (qui utilise npm et node), les classes javascript utilisées sont "compilées" et stockées dans les fichiers de conf de jupyter; et nécéssitent d'utiliser les fonctions 'require' et 'module.export' pour réaliser l'édition des liens.
  2 - jupyter réalise la mise en place du widget sur un élément div détaché du document principal, or l'application utilise ce document pour accéder à la div de l'application (par ex. via getElementById)
  Résolution problème 1: -> il n'est pas possible d'utiliser les 'require' car cela impliquerait de devoir réécrire l'ensemble des classes de l'application (en remplaçant chaque appel à une classe par nom_require.nomClasse), de plus l'application ne fonctionnerait plus en local, etc...
  une solution envisagée était d'utiliser getScript de jQuery pour charger dynamiquement les scripts sans avoir à faire une édition des liens au préalable, mais comme l'appel se fait depuis les fichiers de conf jupyter et pas depuis le dépôt... pas propre...
  Solution: via un script bach compiler l'ensemble des scripts en un seul fichier et l'utiliser pour le notebook: Note: certaines librairies utilisées étaient compatibles avec node.js et causaient un plantage lors du lancement du widget sur jupyer (car elles
  reconnaissaient l'objet global module et réaliaient un export en conséquence, au lieu de s'ajouter au root comme voulu) -> il a fallu encapsuler le bloc complet dans une fonction anonyme où on déclare une variable module= undefined, et faire l'appel
  module.exports ensuite
  Résolution problème 2: -> utilisation des MutationObserver pour ne lancer l'application que lorsque jupyter ajoute le widget au dom
• 19: fin de la mise en place du widget "seul": gestion du redimentionnement, des listeners, etc: chargement des sprites via variables les contenant en format base64 lorsque lancé depuis un jupyter notebook
• 20: redéfini listeners de la souris pour le mode widget, mise en place d'un prompt pour rentrer à la volée ses propres scripts du côté client de l'application
  tests + intégration du script de lecture et des simulations de frédéric marin dans l'application
  correction du bug de référence double à une texture rencontré lors des tests sur les simulations
• ----- Semaine 8
• 23: les animations par interpolation fonctionnent de nouveau (le code pour le remplissage des buffers direction par index n'était plus à jour depuis la mise à jour de la gestion des données en interne -> cf plus de typage des données etc...)
  mise en place d'un script côté serveur pour la lecture de simulations binaires Marin
  mise en place d'un garde fou lors du chargement de données dégradées depuis le serveur (cf si points avec trop de champs: peut être supérieur à poids json au moment de l'envoyer, par ex. au niveau 7)
• 24: mise en place du chargement des données locales depuis le Jupyter Notebook (pour le moment non binaires, mais normalement juste quelques modifications pour accepter les données binaires)

Juillet

• ...

Août

• ...

Liens

• ...

Versions testables

• ...

Documentation

• rapport
• présentation

Travail post stage éventuel

• ...

Liste des améliorations à envisager

• ...

Bugs connus

• ..